Дамэнны фронтынг — гэта не VPN: два імені, адзін запыт

Дзве тэхнікі кладуць у адну папку, бо абедзве маюць пасярэдніка і абедзве гучаць як хаванне. Яны працуюць з рознымі аб’ектамі. Дамэнны фронтынг — гэта пра тое, якое імя з’яўляецца на якім узроўні аднаго запыту HTTPS. VPN — гэта пра тое, якія пакеты ідуць пэўным шляхам да партнёра. Называць фронтынг разнавіднасцю VPN — значыць атрымаць праекты, якія не могуць працаваць, і агляды, якія задаюць няправільнае пытанне.

Два імені, два ўзроўні

Злучэнне TLS можа несці імя сервера ў сваім рукапацісканні. Калі злучэнне існуе, запыт HTTP вызначае паўнамоцтва, якое хоча, звычайна ў загалоўку Host. Гэта два поля, якія чытаюцца ў два розныя моманты двума рознымі часткамі праграмнага забеспячэння.

Дамэнны фронтынг выкарыстоўвае розніцу паміж першымі двума, каб служба фронтынгу прыняла злучэнне і затым накіравала запыт у іншае месца. Гэта працуе толькі там, дзе гэтая служба гатовая яго накіраваць, а гэта пытанне палітыкі пастаўшчыка, а не хітрасці пратаколу.

Фронтынг залежыць ад пастаўшчыка, а не ад тэхнікі

Для абмежаванага прыкладу, даведнік Front Door FAQ ад Azure апісвае абарону ад дамэннага фронтынгу. Там апісана дазволеная неадпаведнасць для даменаў у межах адной падпіскі і наладжаных маршрутаў, а таксама адказ 421 Misdirected Request, калі абарона ад неадпаведнасці блакуе запыт.

Гэтая адзіная апісаная палітыка адразу адмяняе абодва лозунгі. Не кожная пара розных імёнаў працуе, і не кожная неадпаведнасць забароненая. Іншыя службы маюць свае праверкі, свае патрабаванні да разгортвання і свае коды памылак.

Гэта таксама не інструкцыя, як абысці абмежаванні іншай сеткі. Чытанне правілаў маршрутызацыі пастаўшчыка, каб зразумець, што ён дазваляе, — гэта архітэктурная праца; стаўленне да гэтых правілаў як да рэцэпту абыходу — іншая дзейнасць з іншымі наступствамі. Трымайце гэтыя дзве дзейнасці асобна ў дакуменце, які вы пішаце. Менавіта другая прыводзіць да адхілення праекта на аглядзе.

Што насамрэч выбірае VPN

У сеткавым VPN маршрутызацыя і палітыка платформы выбіраюць унутраны трафік для тунелю да партнёра. У залежнасці ад схемы гэта можа ахопліваць некалькі праграм або пэўнае падмноства, і можа несці пратаколы, якія зусім не маюць запыту HTTP.

Фронтынг не робіць нічога з гэтага. Арганізацыя аднаго запыту HTTPS праз службу фронтынгу не ўсталёўвае маршрут да прыватнай сеткі, не нясе адвольныя праграмы UDP і не прымушае кожную праграму на прыладзе карыстацца службай. Калі вам патрэбна такое пакрыццё, вам патрэбен проксі або тунель, а не хітрасць з іменем.

Вось чаму гэтыя дзве блытаюць на аглядзе: абедзве апісваюць як пасярэднікаў, і абедзве з’яўляюцца ў дакументах пра доступ. Інтэрфейс, які кожная прапануе, цалкам розны, і толькі адна з іх — сеткавы шлях.

Бачнасць не бінарная

І параўнанне не зводзіцца да схаванага супраць бачнага. Запыты DNS, адрасы прызначэння, асаблівасці рукапаціскання, памеры пакетаў і час — усё гэта застаецца назіраным для таго, хто знаходзіцца ў пазіцыі бачыць іх, і тое, што гэты назіральнік даведаецца, залежыць ад таго, дзе ён знаходзіцца.

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

Намалюйце тры скрыні

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

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