O domain fronting non é unha VPN: dous nomes, unha petición
Dous nomes nunha soa petición HTTPS non son un túnel. O fronting depende das regras de enrutamento do provedor; unha VPN escolle que paquetes viaxan. Debúxaos por separado.
As dúas técnicas arquívanse xuntas porque ambas implican un intermediario e ambas soan a ocultación. Operan sobre obxectos distintos. O domain fronting trata de que nome aparece en que capa dunha petición HTTPS. Unha VPN trata de que paquetes seguen un camiño concreto ata un par. Chamarlle ao fronting un tipo de VPN leva a deseños que non poden funcionar e a revisións que fan a pregunta equivocada.
Dous nomes, dúas capas
Unha conexión TLS pode levar un nome de servidor no seu handshake. Unha vez que a conexión existe, a petición HTTP identifica a autoridade que quere, normalmente na cabeceira Host. Son dous campos lidos en dous momentos distintos por dúas pezas de software distintas.
| 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 |
O domain fronting aproveita unha diferenza entre os dous primeiros para que un servizo de fronting acepte a conexión e despois dirixa a petición a outro lugar. Só funciona onde ese servizo está disposto a dirixila, o que é unha cuestión de política do provedor e non un truco de protocolo.
O fronting depende do provedor, non da técnica
Como exemplo acoutado, a guía Front Door FAQ de Azure documenta as proteccións contra o domain fronting. Describe unha discrepancia permitida para dominios dentro da mesma subscrición e rutas configuradas, e unha resposta 421 Misdirected Request cando a protección de discrepancia bloquea unha petición.
Esa única política documentada desmonta ambos os lemas á vez. Non todos os pares de nomes distintos funcionan, e non toda discrepancia está prohibida. Outros servizos teñen as súas propias comprobacións, os seus propios requisitos de despregamento e os seus propios códigos de erro.
Tampouco é unha instrución para saltar as restricións doutra rede. Ler as regras de enrutamento dun provedor para entender que permite é traballo de arquitectura; tratar esas regras como unha receita de evasión é outra actividade con outras consecuencias. Mantén esas dúas actividades separadas no documento que escribes. A segunda é a que fai que un deseño sexa rexeitado nunha revisión.
Que escolle realmente unha VPN
Nunha VPN de rede, o enrutamento e a política de plataforma seleccionan o tráfico interno para un túnel cara a un par. Segundo a disposición, iso pode cubrir varias aplicacións ou un subconxunto definido, e pode transportar protocolos que non teñen ningunha petición HTTP.
O fronting non fai nada diso. Organizar unha petición HTTPS a través dun servizo de fronting non instala unha ruta de rede privada, non transporta aplicacións UDP arbitrarias e non fai que todos os programas do dispositivo usen o servizo. Se necesitas esa cobertura, necesitas un proxy ou un túnel, non un truco de nomes.
Por iso as dúas se confunden na revisión: ambas se describen como intermediarios e ambas aparecen en documentos sobre acceso. A interface que ofrece cada unha é completamente distinta, e só unha delas é un camiño de rede.
A visibilidade non é binaria
Nin a comparación é simplemente oculto fronte a visible. As consultas DNS, os enderezos de destino, as características do handshake, os tamaños de paquete e o tempo seguen sendo observables para quen estea en posición de velos, e o que ese observador aprende depende de onde se sente.
Os datos da aplicación tamén son visibles nos extremos que os terminan. Un servizo de fronting que dirixe a túa petición é un deses extremos, e un par de VPN é outro. Ningunha das dúas disposicións fai que o contido sexa opaco para a parte que ten que lelo para servírete.
Debuxa as tres caixas
Para unha revisión de arquitectura, debuxa o extremo TLS, o servizo de enrutamento HTTP e a aplicación final como tres caixas separadas, e despois debuxa calquera par de VPN noutro sitio. O lugar que escolle un destino web e o lugar que transporta paquetes de rede privada non teñen por que ser o mesmo sistema, e normalmente non o son.
Unha vez que as caixas están separadas, as preguntas vólvense respondibles: que nomes acepta este provedor, que protocolos necesitan transporte e que parte pode ver que. Un diagrama que as fusiona produce un deseño que ninguén pode implementar e unha revisión que discute sobre vocabulario.