Domain fronting não é VPN: dois nomes, uma requisição
Dois nomes numa única requisição HTTPS não são um túnel. O fronting depende das regras de roteamento do provedor; uma VPN escolhe quais pacotes viajam. Desenhe-os separadamente.
As duas técnicas acabam arquivadas juntas porque ambas envolvem um intermediário e ambas soam como ocultação. Operam sobre objetos diferentes. O domain fronting trata de qual nome aparece em qual camada de uma requisição HTTPS. Uma VPN trata de quais pacotes seguem um caminho específico até um par. Chamar o fronting de um tipo de VPN leva a projetos que não podem funcionar e a revisões que fazem a pergunta errada.
Dois nomes, duas camadas
Uma conexão TLS pode carregar um nome de servidor no seu handshake. Depois que a conexão existe, a requisição HTTP identifica a autoridade que deseja, normalmente no cabeçalho Host. São dois campos lidos em dois momentos diferentes por duas peças de software diferentes.
| 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 explora uma diferença entre os dois primeiros para que um serviço de fronting aceite a conexão e então encaminhe a requisição para outro lugar. Só funciona onde esse serviço está disposto a encaminhá-la, o que é uma questão de política do provedor e não um truque de protocolo.
O fronting depende do provedor, não da técnica
Como exemplo delimitado, Perguntas frequentes do Front Door a documentação da Azure descreve as proteções contra domain fronting. Ela descreve uma incompatibilidade permitida para domínios dentro da mesma assinatura e rotas configuradas, e uma resposta 421 Misdirected Request quando a proteção de incompatibilidade bloqueia uma requisição.
Essa única política documentada derruba os dois slogans de uma vez. Nem todo par de nomes diferentes funciona, e nem toda incompatibilidade é proibida. Outros serviços têm as próprias verificações, os próprios requisitos de implantação e os próprios códigos de erro.
Também não é uma instrução para contornar as restrições de outra rede. Ler as regras de roteamento de um provedor para entender o que ele permite é trabalho de arquitetura; tratar essas regras como receita de contorno é outra atividade com outras consequências. Mantenha as duas atividades separadas no documento que você escreve. É a segunda que faz um projeto ser rejeitado em revisão.
O que uma VPN realmente seleciona
Numa VPN de rede, o roteamento e a política da plataforma selecionam o tráfego interno para um túnel até um par. Dependendo do arranjo, isso pode cobrir várias aplicações ou um subconjunto definido, e pode transportar protocolos que não têm nenhuma requisição HTTP.
O fronting não faz nada disso. Organizar uma requisição HTTPS através de um serviço de fronting não instala uma rota de rede privada, não transporta aplicações UDP arbitrárias e não faz todo programa do dispositivo usar o serviço. Se você precisa dessa cobertura, precisa de um proxy ou de um túnel, não de um truque de nomes.
É por isso que os dois se confundem em revisão: ambos são descritos como intermediários, e ambos aparecem em documentos sobre acesso. A interface que cada um oferece é completamente diferente, e apenas um deles é um caminho de rede.
A visibilidade não é binária
Nem a comparação é simplesmente oculto contra visível. Consultas DNS, endereços de destino, características do handshake, tamanhos de pacote e tempo continuam todos observáveis para quem esteja em posição de vê-los, e o que esse observador aprende depende de onde ele está.
Os dados da aplicação também são visíveis nos endpoints que os terminam. Um serviço de fronting que encaminha a sua requisição é um desses endpoints, e um par de VPN é outro. Nenhum dos arranjos torna o conteúdo opaco para a parte que precisa lê-lo para atendê-lo.
Desenhe as três caixas
Para uma revisão de arquitetura, desenhe o endpoint TLS, o serviço de roteamento HTTP e a aplicação final como três caixas separadas, e depois desenhe qualquer par de VPN em outro lugar. O lugar que escolhe um destino web e o lugar que transporta pacotes de rede privada não precisam ser o mesmo sistema, e normalmente não são.
Uma vez que as caixas estejam separadas, as perguntas tornam-se respondíveis: que nomes este provedor aceita, que protocolos precisam de transporte e que parte pode ver o quê. Um diagrama que as funde produz um projeto que ninguém consegue implementar e uma revisão que discute vocabulário.