El domain fronting no es una VPN: dos nombres, una petición
Dos nombres en una sola petición HTTPS no son un túnel. El fronting depende de las reglas de enrutamiento del proveedor; una VPN elige qué paquetes viajan. Dibújalos por separado.
Las dos técnicas se archivan juntas porque ambas implican un intermediario y ambas suenan a ocultación. Operan sobre objetos distintos. El domain fronting trata de qué nombre aparece en qué capa de una petición HTTPS. Una VPN trata de qué paquetes siguen un camino concreto hacia un par. Llamar al fronting un tipo de VPN lleva a diseños que no pueden funcionar y a revisiones que hacen la pregunta equivocada.
Dos nombres, dos capas
Una conexión TLS puede llevar un nombre de servidor en su handshake. Una vez que la conexión existe, la petición HTTP identifica la autoridad que quiere, normalmente en la cabecera Host. Son dos campos leídos en dos momentos distintos por dos piezas 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 |
El domain fronting aprovecha una diferencia entre los dos primeros para que un servicio de fronting acepte la conexión y luego dirija la petición a otro lugar. Solo funciona donde ese servicio está dispuesto a dirigirla, lo que es una cuestión de política del proveedor y no un truco de protocolo.
El fronting depende del proveedor, no de la técnica
Como ejemplo acotado, la guía Front Door FAQ de Azure documenta las protecciones contra el domain fronting. Describe una discrepancia permitida para dominios dentro de la misma suscripción y rutas configuradas, y una respuesta 421 Misdirected Request cuando la protección de discrepancia bloquea una petición.
Esa única política documentada desmonta ambos eslóganes a la vez. No todos los pares de nombres distintos funcionan, y no toda discrepancia está prohibida. Otros servicios tienen sus propias comprobaciones, sus propios requisitos de despliegue y sus propios códigos de error.
Tampoco es una instrucción para saltarse las restricciones de otra red. Leer las reglas de enrutamiento de un proveedor para entender qué permite es trabajo de arquitectura; tratar esas reglas como una receta de evasión es otra actividad con otras consecuencias. Mantén esas dos actividades separadas en el documento que escribes. La segunda es la que hace que un diseño sea rechazado en una revisión.
Qué elige realmente una VPN
En una VPN de red, el enrutamiento y la política de plataforma seleccionan el tráfico interno para un túnel hacia un par. Según la disposición, eso puede cubrir varias aplicaciones o un subconjunto definido, y puede transportar protocolos que no tienen ninguna petición HTTP.
El fronting no hace nada de eso. Organizar una petición HTTPS a través de un servicio de fronting no instala una ruta de red privada, no transporta aplicaciones UDP arbitrarias y no hace que todos los programas del dispositivo usen el servicio. Si necesitas esa cobertura, necesitas un proxy o un túnel, no un truco de nombres.
Por eso las dos se confunden en la revisión: ambas se describen como intermediarios y ambas aparecen en documentos sobre acceso. La interfaz que ofrece cada una es completamente distinta, y solo una de ellas es un camino de red.
La visibilidad no es binaria
Ni la comparación es simplemente oculto frente a visible. Las consultas DNS, las direcciones de destino, las características del handshake, los tamaños de paquete y el tiempo siguen siendo observables para quien esté en posición de verlos, y lo que ese observador aprende depende de dónde se siente.
Los datos de la aplicación también son visibles en los extremos que los terminan. Un servicio de fronting que dirige tu petición es uno de esos extremos, y un par de VPN es otro. Ninguna de las dos disposiciones hace que el contenido sea opaco para la parte que tiene que leerlo para servirte.
Dibuja las tres cajas
Para una revisión de arquitectura, dibuja el extremo TLS, el servicio de enrutamiento HTTP y la aplicación final como tres cajas separadas, y luego dibuja cualquier par de VPN en otro sitio. El lugar que elige un destino web y el lugar que transporta paquetes de red privada no tienen por qué ser el mismo sistema, y normalmente no lo son.
Una vez que las cajas están separadas, las preguntas se vuelven respondibles: qué nombres acepta este proveedor, qué protocolos necesitan transporte y qué parte puede ver qué. Un diagrama que las fusiona produce un diseño que nadie puede implementar y una revisión que discute sobre vocabulario.