SMB over QUIC в Windows Server 2022: тестируем доступ к файлам без VPN для удалённого офиса

Одна из функций Windows Server 2022, которую Microsoft активно продвигает - SMB over QUIC. Идея красивая: файловый доступ через порт 443, без VPN, поверх QUIC-транспорта с встроенным TLS 1.3. Удалённый офис или сотрудник на ноуте коннектится к файловому серверу напрямую, как к HTTPS-ресурсу. Нет VPN-клиента, нет туннеля, нет лишних hop-ов.

Мы это потрогали. Вот что получилось.

Контекст: зачем вообще трогать

Есть клиент с небольшим удалённым офисом - десяток человек, Windows-окружение, файлы лежат на центральном сервере. Сейчас они ходят через site-to-site VPN, поверх которого работает обычный SMB. Схема рабочая, но не без боли: VPN иногда нестабилен, при разрыве SMB-сессии приходится переподключаться вручную, на медленных каналах latency накапливается. Стандартная история.

SMB over QUIC обещает те же файлы, но без VPN-туннеля. QUIC по природе лучше переживает смену сети и потерю пакетов - это не маркетинг, это то, что Google вложил в протокол ещё на этапе разработки HTTP/3. Восстановление соединения дешевле, чем у TCP.

Что нужно, чтобы это заработало

Здесь первый холодный душ. SMB over QUIC доступен только в Windows Server 2022 Azure Edition. Не в Standard. Не в Datacenter. Именно Azure Edition - редакция, которая предназначена для запуска в Azure или на Azure Stack HCI.

Для клиентской стороны ограничений меньше: Windows 11 и актуальные Insider-сборки Windows 10 поддерживают клиентскую часть SMB over QUIC. Но сервер - только Azure Edition.

На практике это означает: если вы хотите эту функцию на физическом железе в своём ЦОД или у клиента в серверной комнате - не получится. Стандартный или Datacenter вариант Server 2022 SMB over QUIC не умеет. Это не баг и не временное ограничение - это архитектурное решение Microsoft, которое явно привязывает функцию к Azure-периметру.

Для нашего теста мы подняли Azure Edition в Azure (логично) и подключали клиентские машины снаружи.

Как это настраивается

Настройка на стороне сервера сводится к нескольким шагам через PowerShell или Windows Admin Center:

• Включить функцию SMB over QUIC через Set-SmbServerConfiguration -EnableSMBQUIC $true
• Выдать TLS-сертификат на файловый сервер - нужен нормальный сертификат с Subject Alternative Name, который совпадает с именем, по которому клиенты будут ходить. Самоподписанный работает для теста, но клиент будет ругаться.
• Открыть порт 443 - SMB over QUIC ходит по UDP 443, а не TCP. Это нюанс для firewall-правил.
• Настроить KDC proxy если нужна Kerberos-аутентификация без прямой видимости DC - это отдельная тема, без VPN Kerberos требует специальной обвязки.

Клиентам не нужен никакой специальный агент - Windows 11 умеет SMB over QUIC из коробки. Подключение через \\сервер.домен.com\шара - система сама определяет, что сервер поддерживает QUIC, и использует его.

Что мы померили

Сравнивали два сценария: VPN + SMB (OpenVPN site-to-site, поверх него стандартный SMB) и SMB over QUIC (напрямую через Azure Edition).

По latency на операции с файлами разница есть, но не сказать что драматическая на хорошем канале. SMB over QUIC действительно чуть быстрее на мелких операциях - много мелких файлов, открытие директорий - за счёт меньшего количества round-trip при установке соединения. На крупных файлах разница нивелируется, упираешься в пропускную способность канала.

Где SMB over QUIC реально выигрывает - восстановление после разрыва. При имитации нестабильного канала с packet loss SMB over QUIC восстанавливался заметно быстрее. VPN-туннель при разрыве требует переподключения всего стека, это несколько секунд паузы в работе. QUIC восстанавливается быстрее за счёт встроенного механизма connection migration.

Для пользователя разница между «секунда паузы» и «три секунды паузы» выглядит незначительно. Но если разрывы случаются часто - это уже ощутимо.

Ограничения, которые важно понимать

Помимо привязки к Azure Edition, есть несколько вещей, которые нужно держать в голове.

Kerberos без VPN - нетривиально. SMB сам по себе аутентифицируется, но если нужна интеграция с AD (а она нужна почти всегда), требуется доступность DC или KDC proxy. Без VPN клиент не видит DC напрямую. KDC proxy решает задачу, но это дополнительная настройка и ещё одна точка отказа.

Сертификат - обязательно нормальный. Самоподписанный сертификат для пилота - окей, для продакшена нужен CA-выданный. На клиентах сертификат должен быть в доверенных, иначе подключение не установится.

Мониторинг и логирование SMB over QUIC - пока скромные. Стандартные инструменты вроде Get-SmbConnection показывают тип транспорта, но глубокой телеметрии меньше, чем хотелось бы.

Производительность на слабых каналах - надо тестировать конкретно. QUIC эффективнее TCP при потерях, но само по себе шифрование на QUIC немного дороже, чем VPN-туннель без него (хотя TLS 1.3 давно не является узким местом на нормальном железе).

Итог

SMB over QUIC - это интересная функция с реальными техническими преимуществами. Для сценария «сотрудники без VPN-клиента получают доступ к файлам» это работающее решение. Восстановление соединения лучше, чем у классической схемы.

Но Azure Edition - серьёзное ограничение. Если инфраструктура клиента не в Azure и не на Azure Stack HCI, этой функции нет. Для нашего клиента с удалённым офисом пока остаёмся на VPN+SMB: перетаскивать файловый сервер в Azure ради SMB over QUIC никто не готов, это не пропорциональный ответ на задачу.

Наблюдаем за тем, появится ли функция в Standard/Datacenter редакциях. Пока - нет. Клиентам на managed-сопровождении рекомендуем смотреть на SMB over QUIC если Azure Edition уже в планах или инфраструктура строится с расчётом на гибридный Azure-сценарий.