SMB over QUIC: настройка, когда внутренний FQDN сервера и внешняя точка входа отличаются

Ключевой принцип

SMB over QUIC привязывает сертификат не к серверу как к «машине», а к конкретному DNS-имени, по которому клиенты будут подключаться.

Параметр -Name в New-SmbServerCertificateMapping должен содержать то имя, которое набирает клиент в UNC-пути, а не внутренний AD FQDN сервера.

Сертификат тоже должен быть выписан на это внешнее имя (поле SAN), а не на внутреннее имя сервера. Внутренний FQDN сервера при этом продолжает использоваться как обычно — для AD, Kerberos, внутренних SMB-подключений по TCP/445. Внешнее имя — это отдельная «дверь» со своим сертификатом и своим транспортом (QUIC поверх UDP/443).

Архитектура

                          Интернет
                             │
                   files.company.com (DNS A-запись → публичный IP)
                             │
                     ┌───────▼────────┐
                     │  NAT / Edge GW │   UDP 443 → внутренний IP сервера
                     └───────┬────────┘
                             │
                  ┌──────────▼───────────────┐
                  │  fileserver01.corp.local │
                  │  (внутренний AD FQDN)    │
                  │                          │
                  │  Сертификат: SAN=files.company.com      │
                  │  SMB QUIC mapping -Name files.company.com │
                  └──────────────────────────┘

Внутренние клиенты домена продолжают ходить к серверу как обычно — \\fileserver01.corp.local\share, по TCP/445, без QUIC. Внешние — только через \\files.company.com\share, через QUIC.

Шаг 1. Сертификат на внешнее имя

Сертификат должен содержать в Subject Alternative Name именно внешнее имя точки входа:


$cert = Get-ChildItem Cert:\LocalMachine\My | Where-Object { $_.Subject -like "*files.company.com*" }

Если используется Let's Encrypt — например через win-acme (wacs.exe) — сертификат сразу ставится в Cert:\LocalMachine\My на нужное имя. Для внешнего DNS-имени публичный CA предпочтительнее внутреннего AD CA: иначе придётся вручную распространять корневой сертификат на все внешние устройства.

Шаг 2. Привязка сертификата к SMB QUIC — с внешним именем

Это центральный момент всей настройки:

New-SmbServerCertificateMapping -Name "files.company.com" -Thumbprint $cert.Thumbprint -StoreName My

Здесь указывается files.company.com, а не fileserver01.corp.local. Именно по этому имени SMB-клиент при установке QUIC-туннеля проверяет соответствие набранного пути и SAN сертификата.

Включить QUIC на сервере нужно один раз, независимо от количества внешних имён:

Set-SmbServerConfiguration -EnableSMBQUIC $true
Get-SmbServerCertificateMapping

Шаг 3. DNS

Публичная зона должна резолвить внешнее имя в публичный IP, который транслируется (NAT) на сервер:

files.company.com.   A   <публичный IP>

Внутренний FQDN сервера (fileserver01.corp.local) продолжает резолвиться через внутренний AD DNS как раньше — обе записи независимы друг от друга.

Шаг 4. NAT и файрвол — самая частая точка отказа

Если сервер находится за NAT, edge gateway или в облачной виртуализации (VMware Cloud Director, Azure NSG и т.п.), необходимо перенаправить только UDP/443 на внутренний адрес сервера:

# Пример для MikroTik (если сервер CHR/VPS использует MikroTik как edge)
/ip firewall nat add chain=dstnat action=dst-nat to-addresses=<внутренний IP сервера> to-ports=443 protocol=udp dst-port=443

Важный нюанс многослойного NAT (актуально для VMware Cloud Director, Azure, AWS): если перед сервером есть ещё один уровень NAT — например, Edge Gateway в облаке — то правило dstnat с условием dst-address=<публичный IP> может не сработать. К моменту прихода пакета на внутренний firewall публичный адрес уже заменён вышестоящим NAT на промежуточный адрес. В таких правилах не указывайте публичный IP в dst-address — либо указывайте именно тот адрес, который реально приходит на интерфейс (проверяется через sniffer или временное лог-правило).

TCP/445 наружу не открывается. Это принципиально — весь смысл SMB over QUIC в том, чтобы не выставлять классический SMB-порт в интернет:

/ip firewall filter add chain=forward action=drop protocol=tcp dst-port=445 in-interface-list=WAN comment="Block SMB from Internet"

На самом Windows Server дополнительно убедитесь, что правило File and Printer Sharing (SMB-In) (TCP/445) разрешено только для профилей Domain/Private:

Set-NetFirewallRule -DisplayName "File and Printer Sharing (SMB-In)" -Profile Domain,Private

А правило для QUIC должно быть разрешено и для профиля Public:

Get-NetFirewallRule -DisplayName "File and Printer Sharing (SMB-QUIC-In)" | Set-NetFirewallRule -Enabled True -Profile Any

Шаг 5. Особый случай — DFS

Если на сервере настроен DFS-namespace, есть важная ловушка: DFS-referral отдаёт клиенту внутренний FQDN реального таргета (например, fileserver01.corp.local), а не внешнее имя точки входа. В результате внешний клиент:

не сможет резолвить внутренний FQDN через публичный DNS;
даже если резолвинг подделать через hosts-файл, сертификат QUIC выписан на SAN внешнего имени — TLS не пройдёт, имена не совпадут.

Решение: для внешнего доступа не используйте DFS-namespace вообще. Подключайтесь напрямую к физическому share через внешнее имя:

\\files.company.com\share

вместо

\\corp.local\dfsroot\share

DFS продолжает обслуживать только внутренних пользователей домена; для внешних публикуется отдельный прямой путь к нужным share через имя точки входа.

Шаг 6. Подключение клиента

New-SmbMapping -LocalPath Z: -RemotePath "\\files.company.com\share" -TransportType QUIC

Либо просто открыть путь в проводнике — SMB-клиент на Windows 11 24H2+ автоматически пробует TCP/445, не находит его снаружи и переключается на QUIC прозрачно для пользователя.

Проверка

На клиенте:

Get-SmbConnection | Select-Object ServerName, ShareName, Dialect, Transport

Поле Transport должно показывать QUIC.

В Event Viewer клиента (Applications and Services Logs → Microsoft → Windows → SMBClient → Connectivity) ищите Event ID 30832 — успешное QUIC-подключение, либо 30803 — проблема доверия к сертификату, обычно из-за несовпадения имени или непроверенной цепочки CA.

Проверка, что TCP/445 действительно закрыт снаружи (выполняется с внешней машины, не из внутренней сети):

Test-NetConnection -ComputerName files.company.com -Port 445

Ожидаемый результат — TcpTestSucceeded: False.

Типичные ошибки

Симптом	Причина
Event 30803 на клиенте	`-Name` в `New-SmbServerCertificateMapping` не совпадает с именем в UNC-пути, либо SAN сертификата не содержит внешнее имя
Подключение зависает, таймаут	NAT/файрвол не пропускает UDP/443 до сервера, либо upstream anti-DDoS режет нестандартный UDP-трафик
DFS-путь не открывается снаружи	DFS-referral отдаёт внутренний FQDN — подключайтесь к прямому share, минуя namespace
445 всё равно доступен снаружи	Забыли явный drop на edge firewall, либо NAT/DNAT правило для 445 осталось активным с предыдущих настроек
Правило NAT с `dst-address=<публичный IP>` не матчится	Многослойный NAT (облачный edge gateway) — публичный адрес уже заменён до прихода на внутренний firewall, нужно матчить по реальному промежуточному адресу

Итог

Главное правило при несовпадении внутреннего FQDN сервера и внешней точки входа: везде, где встречается имя для SMB over QUIC — в сертификате (SAN), в New-SmbServerCertificateMapping -Name, в DNS A-записи и в UNC-пути клиента — должно фигурировать одно и то же внешнее имя, отдельное от внутреннего AD FQDN сервера. Внутренний FQDN при этом продолжает использоваться как раньше, для всех внутренних SMB- и AD-операций, никаких изменений там не требуется.