Domain fronting — это не VPN: два имени, один запрос

Эти две техники попадают в одну папку, потому что обе подразумевают посредника и обе звучат как сокрытие. Но работают они с разными объектами. Domain fronting — это про то, какое имя на каком уровне одного HTTPS-запроса появляется. VPN — это про то, какие пакеты идут определённым путём к пиру. Называть фронтинг разновидностью VPN значит приходить к проектам, которые не могут работать, и к обзорам, которые задают неправильный вопрос.

Два имени, два уровня

TLS-соединение может нести имя сервера в своём рукопожатии. Когда соединение установлено, HTTP-запрос указывает нужную ему полномочную сторону, обычно в заголовке Host. Это два поля, которые читаются в два разных момента двумя разными частями программного обеспечения.

Domain fronting использует различие между первыми двумя, так что сервис фронтинга принимает соединение и затем направляет запрос в другое место. Это работает только там, где сервис готов его направить, а это вопрос политики провайдера, а не протокольного трюка.

Фронтинг зависит от провайдера, а не от техники

В качестве ограниченного примера, часто задаваемые вопросы по Front Door в документации Azure описывают защиту от domain fronting. Там описано разрешённое несоответствие для доменов в пределах одной подписки и настроенных маршрутов, а также ответ 421 Misdirected Request, когда защита от несоответствия блокирует запрос.

Эта единственная документированная политика отменяет оба лозунга сразу. Не каждая пара разных имён работает, и не каждое несоответствие запрещено. У других сервисов свои проверки, свои требования к развёртыванию и свои коды ошибок.

Это также не инструкция по обходу ограничений другой сети. Читать правила маршрутизации провайдера, чтобы понять, что он разрешает, это архитектурная работа; относиться к этим правилам как к рецепту обхода другая деятельность с другими последствиями. Держите эти две деятельности отдельно в документе, который вы пишете. Именно вторая приводит к тому, что проект отклоняют на обзоре.

Что на самом деле выбирает VPN

В сетевом VPN маршрутизация и политика платформы выбирают внутренний трафик для туннеля к пиру. В зависимости от схемы это может охватывать несколько приложений или определённое подмножество, и это может нести протоколы, у которых вообще нет HTTP-запроса.

Фронтинг ничего из этого не делает. Организация одного HTTPS-запроса через сервис фронтинга не устанавливает маршрут в частную сеть, не несёт произвольные UDP-приложения и не заставляет каждую программу на устройстве использовать сервис. Если вам нужен такой охват, вам нужен прокси или туннель, а не трюк с именем.

Поэтому эти две путают на обзоре: обе описываются как посредники, и обе появляются в документах о доступе. Интерфейс, который предлагает каждая, полностью разный, и только одна из них сетевой путь.

Видимость не бинарна

И сравнение не сводится просто к скрытому против видимого. DNS-запросы, адреса назначения, особенности рукопожатия, размеры пакетов и тайминг остаются наблюдаемыми для того, кто находится в позиции их видеть, и то, что узнаёт этот наблюдатель, зависит от того, где он сидит.

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

Нарисуйте три квадрата

Для архитектурного обзора нарисуйте оконечную точку TLS, сервис маршрутизации HTTP и конечное приложение как три отдельных квадрата, а затем нарисуйте любой пир VPN снова где-то ещё. Место, которое выбирает веб-назначение, и место, которое переносит пакеты частной сети, не обязаны быть одной системой и обычно ими не являются.

Когда квадраты разделены, вопросы становятся отвечаемыми: какие имена принимает этот провайдер, какие протоколы нуждаются в переносе и какая сторона что может видеть. Диаграмма, которая их сливает, даёт проект, который никто не может реализовать, и обзор, который спорит о словаре.