A domain fronting nem VPN: két név, egy kérés
Két név egy HTTPS-kérésben nem alagút. A fronting a szolgáltató útválasztási szabályaitól függ; a VPN azt választja ki, mely csomagok haladnak. Rajzold külön.
A két technika azért kerül egy polcra, mert mindkettő tartalmaz közvetítőt, és mindkettő rejtőzködésnek hangzik. Mégis különböző objektumokon működnek. A domain fronting arról szól, melyik név melyik rétegben jelenik meg egy HTTPS-kérésben. A VPN arról szól, mely csomagok haladnak egy adott úton egy peer felé. Ha a frontinget a VPN egy fajtájának nevezzük, olyan tervekhez jutunk, amelyek nem működhetnek, és olyan átvizsgálásokhoz, amelyek rossz kérdést tesznek fel.
Két név, két réteg
Egy TLS-kapcsolat hordozhat szervernevet a kézfogásában. Amint a kapcsolat létrejön, a HTTP-kérés megnevezi a kívánt hatóságot, általában a Host fejlécben. Ez két mező, amelyet két különböző pillanatban két különböző szoftverrész olvas.
| 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 |
A domain fronting az első kettő közötti különbséget használja ki, hogy egy fronting szolgáltatás elfogadja a kapcsolatot, majd máshová irányítsa a kérést. Csak ott működik, ahol a szolgáltatás hajlandó irányítani, és ez szolgáltatói szabályzat kérdése, nem protokolltrükké.
A fronting a szolgáltatótól függ, nem a technikától
Határolt példaként a Front Door FAQ útmutató dokumentálja a domain fronting elleni védelmet. Leír egy engedélyezett eltérést azonos előfizetésen és beállított útvonalakon belüli domainek esetére, valamint egy 421 Misdirected Request választ, amikor az eltérésvédelmi védelem blokkol egy kérést.
Ez az egyetlen dokumentált szabályzat egyszerre dönti meg mindkét szlogent. Nem minden különböző névpár működik, és nem minden eltérés tilos. Más szolgáltatásoknak saját ellenőrzéseik, saját telepítési követelményeik és saját hibakódjaik vannak.
Ez nem is útmutatás egy másik hálózat korlátainak megkerüléséhez. Egy szolgáltató útválasztási szabályainak olvasása annak megértéséért, mit engedélyez, architektúramunka; e szabályok megkerülési receptként kezelése más tevékenység más következményekkel. Tartsd ezt a két tevékenységet külön az írt dokumentumban. A második az, ami miatt egy tervet elutasítanak az átvizsgáláson.
Mit választ valójában a VPN
Egy hálózati VPN-ben az útválasztás és a platformszabályzat választja ki a belső forgalmat egy peer felé vezető alagút számára. Az elrendezéstől függően ez több alkalmazást vagy egy meghatározott részhalmazt fedhet le, és olyan protokollokat is szállíthat, amelyeknek egyáltalán nincs HTTP-kérése.
A fronting ebből semmit nem tesz. Egy HTTPS-kérés fronting szolgáltatáson keresztüli megszervezése nem telepít magánhálózati útvonalat, nem szállít tetszőleges UDP-alkalmazásokat, és nem éri el, hogy az eszköz minden programja a szolgáltatást használja. Ha erre a lefedettségre van szükséged, proxyra vagy alagútra van szükséged, nem névtrükkre.
Ezért keveredik a kettő az átvizsgáláson: mindkettőt közvetítőként írják le, és mindkettő megjelenik a hozzáférésről szóló dokumentumokban. A felület, amelyet kínálnak, teljesen különbözik, és csak az egyikük hálózati útvonal.
A láthatóság nem bináris
Az összehasonlítás sem csupán rejtett kontra látható. A DNS-lekérdezések, a célcímek, a kézfogás jellemzői, a csomagméretek és az időzítés mind megfigyelhetők maradnak az számára, aki olyan helyzetben van, hogy lássa őket, és hogy mit tanul ez a megfigyelő, az attól függ, hol ül.
Az alkalmazásadatok azokon a végpontokon is láthatók, amelyek lezárják őket. Egy fronting szolgáltatás, amely a kérésedet irányítja, e végpontok egyike, a VPN peer pedig egy másik. Egyik elrendezés sem teszi a tartalmat átláthatatlanná azon fél számára, akinek el kell olvasnia ahhoz, hogy kiszolgáljon téged.
Rajzold meg a három dobozt
Egy architektúra-átvizsgáláshoz rajzold meg a TLS-végpontot, a HTTP-útválasztó szolgáltatást és a végső alkalmazást három külön dobozként, majd rajzolj minden VPN-peert újra valahol máshol. A webcél kiválasztásának helye és a magánhálózati csomagok szállításának helye nem kell, hogy ugyanaz a rendszer legyen, és általában nem is az.
Amint a dobozok külön vannak, a kérdések megválaszolhatóvá válnak: mely neveket fogadja el ez a szolgáltató, mely protokollokhoz kell szállítás, és melyik fél mit láthat. Az a diagram, amely egybeolvasztja őket, olyan tervet ad, amelyet senki nem tud megvalósítani, és olyan átvizsgálást, amely a szókincsről vitatkozik.