VPN sobre DNS não é o mesmo que um servidor DNS de VPN

VPN sobre DNS descreve uma ideia de transporte e não é sinônimo de apontar um dispositivo para um resolvedor personalizado. A pergunta que resolve a confusão é simples: o que as mensagens DNS realmente transportam? Uma VPN comum pode instalar um resolvedor para que as aplicações cobertas encontrem nomes privados, e mudar esse resolvedor altera apenas a resolução de nomes. Execute as verificações abaixo em ordem, porque os três arranjos compartilham vocabulário e quase nada mais.

Separe os três arranjos

No primeiro arranjo, a VPN fornece um resolvedor ou uma configuração de política de nomes. Os dados das aplicações ainda trafegam pelas suas próprias conexões de rede, e o túnel influencia apenas qual servidor responde à consulta.

No segundo, o DNS cifrado protege a própria troca de DNS. DNS sobre HTTPS e DNS sobre TLS envolvem as consultas ao resolvedor escolhido e não transportam pacotes de nenhuma outra aplicação. Também não escondem os nomes das consultas do resolvedor que você escolheu, o que é uma fronteira de confiança diferente de escondê-los da rede local.

No terceiro, um cliente cooperante codifica outros dados em mensagens DNS e um ponto de extremidade cooperante os reconstrói. O caminho comum do resolvedor torna-se o transporte, e o resolvedor agora é um componente do caminho de dados em vez de um serviço de nomes.

Verifique o que as mensagens DNS transportam

Mude o resolvedor e observe se o caminho do tráfego da aplicação muda. Se a aplicação continua conectando aos mesmos endereços pelos mesmos sockets, você mudou a resolução de nomes e nada mais.

Um túnel transportado pelo DNS precisa de um arranjo correspondente no lado do servidor. O Iodine é um exemplo documentado: a sua documentação do projeto descreve um túnel IP através do DNS, e ele exige um componente de servidor que entenda a codificação. Inserir um endereço de resolvedor público no Android não fornece esse ponto de extremidade, e um termo de marketing compartilhado por dois produtos não é uma especificação de protocolo.

A captura é a verificação decisiva. Se você vê consultas comuns ao resolvedor e nada mais, não há túnel. Se você vê carga codificada nos nomes das consultas e nas respostas, encontrou o portador, e a próxima pergunta é quanto ele pode mover.

Verifique a capacidade antes de se comprometer

O DNS foi projetado para consultas e respostas, não para entrega em massa. A sobrecarga de codificação, os limites de tamanho das mensagens e o comportamento do resolvedor tomam sua parte do caminho nominal, então a capacidade útil é menor do que o enlace subjacente sugere. Trate qualquer número de throughput que você não mediu no seu próprio caminho como hipótese e não como orçamento. Meça as duas direções, porque envio e recebimento podem encontrar limites diferentes em um portador do tipo requisição-resposta.

O cliente também precisa decidir qual tráfego entra no túnel. Uma interface local do serviço de VPN pode coletar pacotes, mas a interface não diz nada sobre como o transporte remoto os protege ou os encaminha. A fragmentação e a retransmissão comportam-se de forma diferente quando o portador é um protocolo de requisição e resposta em vez de um fluxo, e uma conexão que permanece aberta diz pouco sobre a latência interativa.

Meça com o tráfego que você pretende transportar. Um túnel que parece bom para um batimento periódico pode ser inutilizável para uma sessão interativa, e o contrário também é verdadeiro.

Verifique a segurança do portador

Não presuma que o encapsulamento DNS fornece confidencialidade ou autenticação forte. O caminho do resolvedor e o ponto de extremidade do túnel veem o que a implementação expõe, e essa exposição varia conforme o projeto.

A cifragem e a escolha do portador são propriedades separadas. Um túnel pode ser cifrado sobre um caminho IP simples, e um túnel transportado pelo DNS pode ser construído com ou sem proteção para sua carga. Mantenha o HTTPS da aplicação no lugar de qualquer forma, e avalie o projeto de segurança real do túnel e não o seu nome.

Se o requisito é privacidade em relação à rede local, o DNS cifrado e um túnel de dados respondem a partes diferentes disso. Anote contra qual observador você se defende antes de escolher um.

Adapte a correção à falha real

Para uma VPN lenta comum, substituí-la por um túnel transportado pelo DNS acrescenta um transporte restrito em cima do problema. Não corrige a qualidade de rádio, o congestionamento nem a carga do servidor, e normalmente torna esses problemas mais visíveis.

Para falhas de nomes privados, examine primeiro a política de resolvedor pretendida: qual servidor deve responder, quais nomes estão no escopo e se o cliente tem permissão para usá-lo. Depois escolha um transporte autorizado que corresponda ao requisito, e mantenha a configuração do resolvedor no registro de alterações para que o próximo incidente não reinicie a mesma busca.

A lista de verificação é curta: identifique o arranjo, confirme o que as mensagens transportam, meça a capacidade e depois reveja a confiança. Qualquer passo que não corresponda ao sintoma significa que os outros dois arranjos ainda estão em jogo.