Tæknunum tveimur er raðað saman því báðar fela í sér millilið og báðar hljóma eins og fela. Þær vinna á mismunandi hlutum. Domain fronting snýst um hvaða nafn birtist á hvaða lagi í einni HTTPS-beiðni. VPN snýst um hvaða pakkar fara ákveðna leið að jafningja. Að kalla fronting tegund af VPN leiðir til hönnunar sem getur ekki virkað, og til yfirferðar sem spyr rangrar spurningar.

Tvö nöfn, tvö lög

TLS-tenging getur borið netþjónsnafn í handabandi sínu. Þegar tengingin er til staðar auðkennir HTTP-beiðnin það vald sem hún vill, venjulega í Host-hausnum. Þetta eru tveir reitir sem eru lesnir á tveimur mismunandi augnablikum af tveimur mismunandi hugbúnaðarhlutum.

LayerWhat carries the nameWho reads it
TLS handshakeServer name indicationThe TLS terminator in front of the service
HTTP requestAuthority or Host headerThe routing layer that picks a backend
Network pathDestination address and portRouters, and the VPN peer if one is in use

Domain fronting nýtir mun á fyrstu tveimur þannig að fronting-þjónusta samþykkir tenginguna og beinir beiðninni svo annað. Það virkar aðeins þar sem þjónustan er reiðubúin að beina henni, og það er spurning um stefnu veitandans, ekki sniðleysu.

Fronting fer eftir veitandanum, ekki tækninni

Sem takmarkað dæmi, leiðarvísirinn Front Door FAQ frá Azure skjalfestir varnir gegn domain fronting. Hann lýsir leyfðu misræmi fyrir lén innan sömu áskriftar og skilgreindra slóða, og 421 Misdirected Request-svari þegar misræmisvörnin lokar beiðni.

Þessi eina skjalfesta stefna hnekkir báðum slagorðunum í einu. Ekki virkar hvert par af mismunandi nöfnum, og ekki er hvert misræmi bannað. Aðrar þjónustur hafa sínar eigin athuganir, sínar eigin kröfur um uppsetningu og sína eigin villukóða.

Þetta er heldur ekki leiðbeining um að komast fram hjá takmörkunum annars nets. Að lesa leiðarreglur veitanda til að skilja hvað hann leyfir er arkitektúrvinnu; að meðhöndla þessar reglur sem uppskrift til að komast hjá er önnur athöfn með öðrum afleiðingum. Haltu þessum tveimur athöfnum aðskildum í skjalinu sem þú skrifar. Það er sú seinni sem veldur því að hönnun er hafnað í yfirferð.

Hvað VPN velur í raun

Í net-VPN velja leiðsögn og stefna kerfisins innri umferð fyrir göng að jafningja. Eftir fyrirkomulagi getur það náð yfir nokkur forrit eða skilgreint undirmengi, og það getur borið samskiptareglur sem hafa alls enga HTTP-beiðni.

Fronting gerir ekkert af þessu. Að koma einni HTTPS-beiðni í gegnum fronting-þjónustu setur ekki upp leið á einkaneti, ber ekki handahófskennd UDP-forrit og lætur ekki hvert forrit á tækinu nota þjónustuna. Ef þú þarft þá umfjöllun þarftu umboðsþjón eða göng, ekki nafnasnið.

Þess vegna er þessum tveimur ruglað saman í yfirferð: báðum er lýst sem milliliðum, og báðar birtast í skjölum um aðgang. Viðmótið sem hvort um sig býður er gjörólíkt, og aðeins annað þeirra er netleið.

Sýnileiki er ekki tvíundarlegur

Samanburðurinn er heldur ekki einfaldlega falið á móti sýnilegu. DNS-fyrirspurnir, áfangastaðir, eiginleikar handabands, pakkastærðir og tímasetning eru allt áfram sjáanleg fyrir þann sem er í stöðu til að sjá þau, og það sem sá áhorfandi lærir fer eftir því hvar hann situr.

Forritsgögn eru einnig sýnileg á endapunktunum sem ljúka þeim. Fronting-þjónusta sem beinir beiðninni þinni er einn af þeim endapunktum, og VPN-jafningi er annar. Hvort fyrirkomulagið sem er gerir efnið ógagnsætt fyrir þeim aðila sem verður að lesa það til að þjóna þér.

Teiknaðu þrjá kassa

Fyrir arkitektúryfirferð skaltu teikna TLS-endapunktinn, HTTP-leiðarþjónustuna og endanlega forritið sem þrjá aðskilda kassa, og teikna svo hvaða VPN-jafningja sem er annars staðar aftur. Staðurinn sem velur vefáfangastað og staðurinn sem flytur pakka á einkaneti þurfa ekki að vera sama kerfið, og eru það venjulega ekki.

Þegar kassarnir eru aðskildir verða spurningarnar svaraðar: hvaða nöfn þessi veitandi samþykkir, hvaða samskiptareglur þurfa flutning og hvaða aðili getur séð hvað. Skýringarmynd sem rennir þeim saman framleiðir hönnun sem enginn getur útfært og yfirferð sem deilir um orðaforða.

Tengdir greinar