Domeinvoorfronting is nie ’n VPN nie: twee name, een versoek
Twee name in een HTTPS-versoek is nie ’n tonnel nie. Voorfronting hang van die verskaffer se roetereëls af; ’n VPN kies watter pakkette beweeg. Teken hulle apart.
Die twee tegnieke beland saam in een lêer omdat albei ’n tussenganger betrek en albei na wegsteek klink. Hulle werk op verskillende objekte. Domeinvoorfronting handel oor watter naam op watter laag van een HTTPS-versoek verskyn. ’n VPN handel oor watter pakkette ’n bepaalde pad na ’n eweknie volg. Om voorfronting ’n soort VPN te noem, lei tot ontwerpe wat nie kan werk nie, en tot oudits wat die verkeerde vraag vra.
Twee name, twee lae
’n TLS-verbinding kan ’n bedienernaam in sy handdruk dra. Sodra die verbinding bestaan, identifiseer die HTTP-versoek die gesag wat dit wil hê, gewoonlik in die Host-kop. Dit is twee velde wat op twee verskillende oomblikke deur twee verskillende stukke sagteware gelees word.
| 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 |
Domeinvoorfronting buit ’n verskil tussen die eerste twee uit, sodat ’n voorfrontingsdiens die verbinding aanvaar en die versoek dan elders heen stuur. Dit werk net waar daardie diens bereid is om dit te stuur, wat ’n kwessie van verskafferbeleid is eerder as ’n protokolfoefie.
Voorfronting hang van die verskaffer af, nie van die tegniek nie
Vir ’n begrensde voorbeeld: Azure se Front Door FAQ dokumenteer beskermings teen domeinvoorfronting. Dit beskryf ’n toegelate wanverhouding vir domeine binne dieselfde intekening en gekonfigureerde roetes, en ’n 421 Misdirected Request-antwoord wanneer die wanverhoudingbeskerming ’n versoek blokkeer.
Daardie enkele gedokumenteerde beleid maak beide slagspreuke tegelyk ongeldig. Nie elke paar verskillende name werk nie, en nie elke wanverhouding is verbode nie. Ander dienste het hul eie kontroles, hul eie ontplooiingsvereistes en hul eie foutkodes.
Dit is ook nie ’n instruksie om ’n ander netwerk se beperkings te omseil nie. Om ’n verskaffer se roetereëls te lees om te verstaan wat dit toelaat, is argitektuurwerk; om daardie reëls as ’n omseilresep te behandel, is ’n ander aktiwiteit met ander gevolge. Hou daardie twee aktiwiteite apart in die dokument wat jy skryf. Die tweede een is wat ’n ontwerp in ’n oudit laat sneuwel.
Wat ’n VPN werklik kies
In ’n netwerk-VPN kies roetering en platformbeleid binneste verkeer vir ’n tonnel na ’n eweknie. Afhangend van die reëling kan dit verskeie toepassings of ’n bepaalde subset dek, en dit kan protokolle dra wat glad geen HTTP-versoek het nie.
Voorfronting doen niks daarvan nie. Om een HTTPS-versoek deur ’n voorfrontingsdiens te reël, installeer nie ’n privaatnetwerkroete nie, dra nie willekeurige UDP-toepassings nie, en laat nie elke program op die toestel die diens gebruik nie. As jy daardie dekking nodig het, het jy ’n instaanbediener of ’n tonnel nodig, nie ’n naamfoefie nie.
Dit is waarom die twee in oudits verwar word: albei word as tussengangers beskryf, en albei verskyn in dokumente oor toegang. Die koppelvlak wat elkeen bied, is heeltemal verskillend, en net een van hulle is ’n netwerkpad.
Sigbaarheid is nie binêr nie
Die vergelyking is ook nie bloot versteek teenoor sigbaar nie. DNS-navrae, bestemmingsadresse, handdrukkenmerke, pakketgroottes en tydsberekening bly alles waarneembaar vir iemand wat geposisioneer is om dit te sien, en wat daardie waarnemer leer, hang daarvan af waar hy sit.
Toepassingsdata is ook sigbaar by die eindpunte wat dit termineer. ’n Voorfrontingsdiens wat jou versoek stuur, is een van daardie eindpunte, en ’n VPN-eweknie is ’n ander. Nie een van die reëlings maak die inhoud ondeursigtig vir die party wat dit moet lees om jou te dien nie.
Teken die drie blokkies
Teken vir ’n argitektuuradit die TLS-eindpunt, die HTTP-roeteringsdiens en die finale toepassing as drie aparte blokkies, en teken dan enige VPN-eweknie weer elders. Die plek wat ’n webbestemming kies en die plek wat privaatnetwerkpakkette vervoer, hoef nie dieselfde stelsel te wees nie, en is gewoonlik nie.
Sodra die blokkies apart is, word die vrae beantwoordbaar: watter name aanvaar hierdie verskaffer, watter protokolle moet vervoer word, en watter party kan wat sien. ’n Diagram wat hulle saamsmelt, lewer ’n ontwerp wat niemand kan implementeer nie en ’n oudit wat oor woordeskat stry.