Domēnu frontings nav VPN: divi nosaukumi, viens pieprasījums
Divi nosaukumi vienā HTTPS pieprasījumā nav tunelis. Frontings ir atkarīgs no pakalpojumu sniedzēja maršrutēšanas noteikumiem; VPN izvēlas, kuri paketes ceļo. Uzzīmējiet tos atsevišķi.
Šīs divas metodes tiek liktas vienā plauktā, jo abas ietver starpnieku un abas izklausās pēc slēpšanās. Taču tās darbojas ar atšķirīgiem objektiem. Domēnu frontings ir par to, kurš nosaukums parādās kurā viena HTTPS pieprasījuma slānī. VPN ir par to, kuras paketes iet noteiktu ceļu līdz partnerim. Frontingu saukt par VPN veidu noved pie projektiem, kas nevar darboties, un pie apskatiem, kas uzdod nepareizo jautājumu.
Divi nosaukumi, divi slāņi
TLS savienojums savā rokasspiedienā var nest servera nosaukumu. Kad savienojums pastāv, HTTP pieprasījums norāda vēlamo autoritāti, parasti Host galvenē. Tie ir divi lauki, ko divos dažādos brīžos nolasa divas dažādas programmatūras daļas.
| Layer | What carries the name | Who reads it |
|---|---|---|
| TLS handshake | Server name indication | The TLS terminator in front of the service |
| HTTP request | Authority or Host header | The routing layer that picks a backend |
| Network path | Destination address and port | Routers, and the VPN peer if one is in use |
Domēnu frontings izmanto atšķirību starp pirmajiem diviem, lai frontinga pakalpojums pieņemtu savienojumu un pēc tam novirzītu pieprasījumu citur. Tas darbojas tikai tur, kur pakalpojums ir gatavs to novirzīt, un tas ir pakalpojumu sniedzēja politikas jautājums, nevis protokola triks.
Frontings ir atkarīgs no pakalpojumu sniedzēja, nevis no metodes
Kā ierobežotu piemēru, Front Door biežāk uzdotie jautājumi Azure rokasgrāmata dokumentē aizsardzību pret domēnu frontingu. Tajā aprakstīta atļauta neatbilstība domēniem vienā abonementā un konfigurētos maršrutos, un 421 Misdirected Request atbilde, kad neatbilstības aizsardzība bloķē pieprasījumu.
Šī vienīgā dokumentētā politika vienlaikus atceļ abus saukļus. Ne katrs dažādu nosaukumu pāris darbojas, un ne katra neatbilstība ir aizliegta. Citiem pakalpojumiem ir savas pārbaudes, savas izvietošanas prasības un savi kļūdu kodi.
Tas arī nav norādījums, kā apiet citas tīkla ierobežojumus. Pakalpojumu sniedzēja maršrutēšanas noteikumu lasīšana, lai saprastu, ko tas atļauj, ir arhitektūras darbs; šo noteikumu uzskatīšana par apiešanas recepti ir cita darbība ar citām sekām. Turiet šīs divas darbības atsevišķi dokumentā, ko rakstāt. Tieši otrā ir tā, kuras dēļ projekts tiek noraidīts apskatā.
Ko VPN faktiski izvēlas
Tīkla VPN gadījumā maršrutēšana un platformas politika izvēlas iekšējo satiksmi tunelim līdz partnerim. Atkarībā no izkārtojuma tas var aptvert vairākas lietotnes vai noteiktu apakškopu, un tas var pārvadāt protokolus, kuriem vispār nav HTTP pieprasījuma.
Frontings neko no tā nedara. Viena HTTPS pieprasījuma organizēšana caur frontinga pakalpojumu neinstalē privāta tīkla maršrutu, nepārvadā patvaļīgas UDP lietotnes un nepanāk, ka katra ierīces programma izmanto pakalpojumu. Ja jums vajag šādu pārklājumu, jums vajag starpniekserveri vai tuneli, nevis nosaukuma triku.
Tāpēc apskatā abi tiek sajaukti: abi tiek aprakstīti kā starpnieki, un abi parādās dokumentos par piekļuvi. Saskarne, ko katrs piedāvā, ir pilnīgi atšķirīga, un tikai viens no tiem ir tīkla ceļš.
Redzamība nav bināra
Arī salīdzinājums nav vienkārši slēpts pret redzamu. DNS vaicājumi, galamērķa adreses, rokasspiediena pazīmes, pakešu izmēri un laiks visi paliek novērojami tam, kurš atrodas pozīcijā tos redzēt, un tas, ko šis novērotājs uzzina, ir atkarīgs no tā, kur viņš sēž.
Lietotnes dati ir redzami arī tajos galapunktos, kas tos pārtrauc. Frontinga pakalpojums, kas novirza jūsu pieprasījumu, ir viens no šiem galapunktiem, un VPN partneris ir cits. Neviena no shēmām nepadara saturu necaurredzamu tai pusei, kurai tas jāizlasa, lai jums kalpotu.
Uzzīmējiet trīs kastes
Arhitektūras apskatam uzzīmējiet TLS galapunktu, HTTP maršrutēšanas pakalpojumu un galīgo lietotni kā trīs atsevišķas kastes, pēc tam uzzīmējiet jebkuru VPN partneri atkal citur. Vietai, kas izvēlas tīmekļa galamērķi, un vietai, kas pārvadā privāta tīkla paketes, nav jābūt vienai sistēmai, un parasti tā nav.
Kad kastes ir atsevišķi, jautājumi kļūst atbildami: kurus nosaukumus šis sniedzējs pieņem, kuriem protokoliem vajadzīga pārvadāšana un kura puse ko var redzēt. Diagramma, kas tos sapludina, rada projektu, ko neviens nevar ieviest, un apskatu, kas strīdas par vārdu krājumu.