Dvije tehnike se svrstavaju zajedno jer obje uključuju posrednika i obje zvuče kao skrivanje. One rade na različitim objektima. Domain fronting se odnosi na to koje se ime pojavljuje na kojem sloju jednog HTTPS zahtjeva. VPN se odnosi na to koji paketi idu određenim putem do peer-a. Nazvati fronting vrstom VPN-a vodi do dizajna koji ne mogu funkcionirati i do pregleda koji postavljaju pogrešno pitanje.

Dva imena, dva sloja

TLS veza može nositi ime poslužitelja u svom handshake-u. Kada veza postoji, HTTP zahtjev identificira autoritet koji želi, obično u Host zaglavlju. To su dva polja koja se čitaju u dva različita trenutka od strane dva različita dijela softvera.

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 koristi razliku između prva dva, tako da fronting servis prihvati vezu i zatim usmjeri zahtjev negdje drugo. To funkcionira samo tamo gdje je taj servis spreman usmjeriti ga, što je pitanje politike davatelja usluge, a ne protokolarnog trika.

Fronting zavisi od davatelja usluge, a ne od tehnike

Za ograničen primjer, vodič Front Door FAQ kompanije Azure dokumentira zaštite od domain frontinga. Opisuje dopušteno neslaganje za domene unutar iste pretplate i konfiguriranih ruta, te odgovor 421 Misdirected Request kada zaštita od neslaganja blokira zahtjev.

Ta jedna dokumentirana politika ukida oba slogana odjednom. Ne radi svaki par različitih imena, a ni svako neslaganje nije zabranjeno. Drugi servisi imaju svoje provjere, svoje zahtjeve za implementaciju i svoje kodove pogrešaka.

To također nije uputa za zaobilaženje ograničenja druge mreže. Čitanje pravila rutiranja davatelja usluge da bi se razumjelo što dopušta jest arhitektonski posao; tretiranje tih pravila kao recepta za zaobilaženje druga je aktivnost s drugim posljedicama. Držite te dvije aktivnosti odvojeno u dokumentu koji pišete. Druga je ono zbog čega dizajn biva odbijen na pregledu.

Što VPN zapravo bira

U mrežnom VPN-u, rutiranje i platformna politika biraju unutarnji promet za tunel do peer-a. Ovisno o rasporedu, to može pokrivati nekoliko aplikacija ili definiran podskup, i može nositi protokole koji uopće nemaju HTTP zahtjev.

Fronting ne radi ništa od toga. Organiziranje jednog HTTPS zahtjeva kroz fronting servis ne instalira rutu do privatne mreže, ne nosi proizvoljne UDP aplikacije i ne prisiljava svaki program na uređaju da koristi servis. Ako vam treba takvo pokrivanje, treba vam proxy ili tunel, a ne trik s imenom.

Zato se to dvoje brka na pregledu: oba se opisuju kao posrednici i oba se pojavljuju u dokumentima o pristupu. Sučelje koje svaki nudi potpuno je različito, a samo jedan od njih je mrežni put.

Vidljivost nije binarna

Niti je usporedba jednostavno skriveno nasuprot vidljivom. DNS upiti, odredišne adrese, karakteristike handshake-a, veličine paketa i tajming sve ostaje uočljivo onome tko je u poziciji da ih vidi, a ono što taj promatrač nauči zavisi od toga gdje se nalazi.

Podaci aplikacije također su vidljivi na krajnjim točkama koje ih prekidaju. Fronting servis koji usmjerava vaš zahtjev jedna je od tih krajnjih točaka, a VPN peer je druga. Nijedan raspored ne čini sadržaj neprozirnim za stranu koja ga mora pročitati da bi vam poslužila.

Nacrtajte tri kutije

Za arhitektonski pregled nacrtajte TLS krajnju točku, HTTP servis za rutiranje i konačnu aplikaciju kao tri odvojene kutije, a zatim nacrtajte bilo koji VPN peer opet negdje drugo. Mjesto koje bira web odredište i mjesto koje prenosi pakete privatne mreže ne moraju biti isti sustav, i obično nisu.

Kada su kutije odvojene, pitanja postaju odgovoriva: koja imena ovaj davatelj usluge prihvaća, koji protokoli trebaju prijenos i koja strana može što vidjeti. Dijagram koji ih spaja proizvodi dizajn koji nitko ne može implementirati i pregled koji se svađa oko rječnika.

Povezani članci