Домејн фронтот не е VPN: две имиња, едно барање

Двете техники се редат заедно зашто и двете вклучуваат посредник и двете звучат како криење. Но тие работат на различни објекти. Домејн фронтот е за тоа кое име се појавува на кој слој од едно HTTPS барање. VPN е за тоа кои пакети одат по определен пат до партнер. Да се нарече фронтот вид VPN води до проекти што не можат да работат и до прегледи што го поставуваат погрешното прашање.

Две имиња, два слоја

TLS врската може да носи име на сервер во своето ракување. Кога врската постои, HTTP барањето ја идентификува власта што ја сака, обично во заглавието Host. Тоа се две полиња што се читаат во два различни моменти од два различни делови на софтвер.

Домејн фронтот ја искористува разликата меѓу првите две, така што услугата за фронт ја прифаќа врската и потоа го пренасочува барањето на друго место. Тоа работи само таму каде што таа услуга е подготвена да го пренасочи, а тоа е прашање на политика на давателот, не на протоколен трик.

Фронтот зависи од давателот, не од техниката

Како ограничен пример, Често поставувани прашања за Front Door Azure го документира штитот против домејн фронтот. Таму е опишано дозволено несовпаѓање за домени во истата претплата и конфигурирани рути, и одговор 421 Misdirected Request кога заштитата од несовпаѓање блокира барање.

Таа единствена документирана политика ги укинува двата слогана одеднаш. Не секој пар различни имиња работи, ниту пак секое несовпаѓање е забрането. Другите услуги имаат свои проверки, свои барања за распоредување и свои кодови за грешки.

Тоа исто така не е упатство за заобиколување на ограничувањата на друга мрежа. Читањето на правилата за маршрутирање на давателот за да се разбере што дозволува е архитектонска работа; третирањето на тие правила како рецепт за заобиколување е друга активност со други последици. Држете ги тие две активности одделно во документот што го пишувате. Втората е онаа поради која проектот се отфрла на преглед.

Што всушност избира VPN

Во мрежен VPN, маршрутирањето и политиката на платформата избираат внатрешен сообраќај за тунел до партнер. Во зависност од распоредот тоа може да покрие неколку апликации или определено подмножество, и може да носи протоколи што воопшто немаат HTTP барање.

Фронтот не прави ништо од тоа. Уредувањето на едно HTTPS барање преку услуга за фронт не инсталира рута до приватна мрежа, не носи произволни UDP апликации и не прави секоја програма на уредот да ја користи услугата. Ако ви треба такво покривање, ви треба прокси или тунел, а не трик со име.

Затоа двете се мешаат на преглед: и двете се опишуваат како посредници и двете се појавуваат во документи за пристап. Интерфејсот што го нуди секоја од нив е сосема различен, и само едната од нив е мрежен пат.

Видливоста не е бинарна

Ни споредбата не е едноставно скриено наспроти видливо. DNS прашањата, адресите на одредиштето, карактеристиките на ракувањето, големините на пакетите и времето остануваат набљудувани за секој што е во позиција да ги види, и тоа што тој набљудувач го учи зависи од тоа каде седи.

Податоците на апликацијата се исто така видливи на крајните точки што ги завршуваат. Услугата за фронт што го пренасочува вашето барање е една од тие крајни точки, а партнерот на VPN е друга. Ниту еден од двата распореди не го прави содржината непрозирна за страната што мора да ја прочита за да ви служи.

Нацртајте ги трите кутии

За архитектонски преглед, нацртајте ја крајната точка на TLS, услугата за маршрутирање HTTP и конечната апликација како три одделни кутии, а потоа нацртајте го секој партнер на VPN повторно на друго место. Местото што избира веб одредиште и местото што пренесува пакети на приватна мрежа не мора да бидат истиот систем, и обично не се.

Кога кутиите се одделни, прашањата стануваат одговорливи: кои имиња ги прифаќа овој давател, кои протоколи бараат пренос и која страна може да види што. Дијаграмот што ги спојува создава проект што никој не може да го спроведе и преглед што се расправа за речник.