Домейн фронтендингът не е VPN: две имена, една заявка

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

Две имена, два слоя

TLS връзката може да носи име на сървър в ръкостискането си. След като връзката съществува, HTTP заявката посочва органа, който иска, обикновено в заглавката Host. Това са две полета, четени в два различни момента от два различни софтуерни компонента.

Домейн фронтендингът използва разлика между първите две, така че фронтендинг услуга приема връзката и след това насочва заявката другаде. Това работи само там, където услугата е готова да я насочи, което е въпрос на политика на доставчика, а не на протоколна хитрост.

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

За ограничен пример, ръководството Front Door FAQ на Azure документира защити срещу домейн фронтендинг. Те описват разрешено несъответствие за домейни в рамките на един и същ абонамент и конфигурирани маршрути, и отговор 421 Misdirected Request, когато защитата срещу несъответствие блокира заявка.

Тази единствена документирана политика обезсмисля и двата лозунга наведнъж. Не всяка двойка различни имена работи и не всяко несъответствие е забранено. Другите услуги имат свои проверки, свои изисквания за внедряване и свои кодове за грешки.

Това също не е инструкция за заобикаляне на ограниченията на друга мрежа. Четенето на правилата за маршрутизиране на доставчик, за да се разбере какво разрешава, е архитектурна работа; третирането на тези правила като рецепта за заобикаляне е друга дейност с други последствия. Дръжте тези две дейности отделно в документа, който пишете. Втората е това, което проваля един проект при преглед.

Какво всъщност избира VPN

В мрежов VPN маршрутизирането и платформената политика избират вътрешен трафик за тунел към партньор. В зависимост от подредбата това може да покрива няколко приложения или определено подмножество, и може да носи протоколи, които изобщо нямат HTTP заявка.

Фронтендингът не прави нищо от това. Подреждането на една HTTPS заявка през фронтендинг услуга не инсталира маршрут към частна мрежа, не носи произволни UDP приложения и не кара всяка програма на устройството да използва услугата. Ако ви трябва това покритие, ви трябва прокси или тунел, а не трик с имена.

Ето защо двете се бъркат при преглед: и двете се описват като посредници и двете се появяват в документи за достъп. Интерфейсът, който всяка от тях предлага, е напълно различен и само една от тях е мрежов път.

Видимостта не е двоична

И сравнението не е просто скрито срещу видимо. DNS заявките, адресите на местоназначение, характеристиките на ръкостискането, размерите на пакетите и времето остават наблюдаеми за всеки, който е в позиция да ги види, и какво научава този наблюдател зависи от това къде се намира.

Данните на приложението също са видими в крайните точки, които ги прекратяват. Фронтендинг услугата, която насочва заявката ви, е една от тези крайни точки, а VPN партньорът е друга. Нито една от двете подредби не прави съдържанието непрозрачно за страната, която трябва да го прочете, за да ви обслужи.

Начертайте трите квадрата

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

След като квадратите са отделни, въпросите стават отговорими: кои имена приема този доставчик, кои протоколи се нуждаят от пренасяне и коя страна може да вижда какво. Диаграма, която ги слива, създава проект, който никой не може да реализира, и преглед, който спори за речника.