Domain fronting nu este VPN: două nume, o singură cerere
Două nume într-o singură cerere HTTPS nu sunt un tunel. Frontingul depinde de regulile de rutare ale furnizorului; un VPN alege ce pachete călătoresc. Desenează-le separat.
Cele două tehnici ajung în aceeași fișă pentru că ambele implică un intermediar și ambele sună a ascundere. Însă lucrează pe obiecte diferite. Domain fronting se referă la ce nume apare la ce nivel al unei cereri HTTPS. Un VPN se referă la ce pachete merg pe o anumită cale către un peer. A numi frontingul un tip de VPN duce la proiecte care nu pot funcționa și la recenzii care pun întrebarea greșită.
Două nume, două niveluri
O conexiune TLS poate purta numele serverului în handshake-ul său. Odată ce conexiunea există, cererea HTTP identifică autoritatea pe care o vrea, de obicei în antetul Host. Sunt două câmpuri citite în două momente diferite de două bucăți diferite de software.
| 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 |
Domain fronting exploatează o diferență între primele două, astfel încât un serviciu de fronting acceptă conexiunea și apoi rutează cererea în altă parte. Funcționează doar acolo unde serviciul este dispus să o ruteze, iar asta este o chestiune de politică a furnizorului, nu un truc de protocol.
Frontingul depinde de furnizor, nu de tehnică
Ca exemplu delimitat, Întrebări frecvente despre Front Door documentația Azure descrie protecțiile împotriva domain fronting. Ea descrie o nepotrivire permisă pentru domeniile din același abonament și rutele configurate, și un răspuns 421 Misdirected Request când protecția împotriva nepotrivirii blochează o cerere.
Acea singură politică documentată anulează ambele sloganuri deodată. Nu fiecare pereche de nume diferite funcționează și nu orice nepotrivire este interzisă. Alte servicii au propriile verificări, propriile cerințe de implementare și propriile coduri de eroare.
Nu este nici o instrucțiune pentru ocolirea restricțiilor altei rețele. Citirea regulilor de rutare ale unui furnizor pentru a înțelege ce permite este muncă de arhitectură; tratarea acelor reguli ca rețetă de ocolire este altă activitate, cu alte consecințe. Ține cele două activități separate în documentul pe care îl scrii. A doua este cea din cauza căreia un proiect este respins la recenzie.
Ce selectează de fapt un VPN
Într-un VPN de rețea, rutarea și politica platformei selectează traficul intern pentru un tunel către un peer. În funcție de aranjament, asta poate acoperi mai multe aplicații sau un subset definit și poate transporta protocoale care nu au deloc cerere HTTP.
Frontingul nu face nimic din toate acestea. Organizarea unei cereri HTTPS printr-un serviciu de fronting nu instalează o rută de rețea privată, nu transportă aplicații UDP arbitrare și nu face fiecare program de pe dispozitiv să folosească serviciul. Dacă ai nevoie de acea acoperire, ai nevoie de un proxy sau de un tunel, nu de un truc cu nume.
De aceea cele două se confundă la recenzie: ambele sunt descrise ca intermediari și ambele apar în documente despre acces. Interfața pe care o oferă fiecare este complet diferită și doar una dintre ele este o cale de rețea.
Vizibilitatea nu este binară
Nici comparația nu este pur și simplu ascuns contra vizibil. Interogările DNS, adresele de destinație, caracteristicile handshake-ului, dimensiunile pachetelor și momentul rămân toate observabile pentru cineva aflat în poziția de a le vedea, iar ce învață acel observator depinde de unde stă.
Datele aplicației sunt și ele vizibile la punctele terminale care le încheie. Un serviciu de fronting care rutează cererea ta este unul dintre aceste puncte, iar un peer VPN este altul. Niciunul dintre aranjamente nu face conținutul opac pentru partea care trebuie să îl citească pentru a te servi.
Desenează cele trei cutii
Pentru o recenzie de arhitectură, desenează punctul terminal TLS, serviciul de rutare HTTP și aplicația finală ca trei cutii separate, apoi desenează orice peer VPN în alt loc. Locul care alege o destinație web și locul care transportă pachete de rețea privată nu trebuie să fie același sistem și de obicei nu sunt.
Odată ce cutiile sunt separate, întrebările devin respondibile: ce nume acceptă acest furnizor, ce protocoale au nevoie de transport și ce parte poate vedea ce. O diagramă care le fuzionează produce un proiect pe care nimeni nu îl poate implementa și o recenzie care se ceartă pe vocabular.