OpenVPN na porta 53: três conversas que as pessoas confundem
A resolução do endpoint, o transporte cifrado e o DNS após o túnel são três conversas. Identifique qual etapa falhou antes de mudar uma porta ou um resolvedor.
Os relatos que dizem que a VPN está bloqueada na porta 53 misturam três observações que falham por motivos diferentes. A resolução do nome do endpoint acontece antes de existir qualquer túnel, o transporte cifrado é uma conversa separada, e as consultas DNS feitas depois são a terceira. Cada uma tem a sua própria assinatura de falha, e apenas uma delas tem a ver com DNS.
Ordene os pacotes por finalidade antes de mudar qualquer coisa, porque a correção segue a etapa.
Três conversas, um número de porta
A primeira conversa é uma pesquisa de nome para o endpoint: a sua máquina pergunta ao resolvedor configurado onde fica vpn.example.com, e essa resposta chega por DNS comum antes de o cliente enviar um único pacote de túnel. A segunda é o próprio transporte OpenVPN, que se liga ao endereço que a pesquisa produziu no protocolo e na porta que o perfil indica. A terceira acontece depois de o túnel estar ativo, quando as aplicações pedem nomes e as configurações de resolvedor enviadas decidem quem responde.
Essas três podem ter sucesso ou falhar de forma independente. Um cliente pode resolver o seu endpoint perfeitamente e ainda assim não alcançar o listener, e pode estabelecer um túnel enquanto todas as pesquisas de nomes internos falham porque as configurações de DNS nunca chegaram.
| Conversation | When it happens | What has to be true |
|---|---|---|
| Endpoint lookup | Before the client contacts a hostname | An underlying resolver path can answer for the endpoint name |
| OpenVPN transport | During tunnel establishment | The gateway listens on its configured transport, address and port, and nothing filters it |
| Application DNS | During or after the protected session | A resolver the client can reach, plus routing that carries its queries |
Leia a tabela como uma lista de verificação e não como uma descrição. Se o nome do endpoint não for resolvido, nada depois pode funcionar, e o túnel nunca começa.
O número da porta não nomeia a aplicação
A porta 53 transporta DNS por convenção, e um operador de OpenVPN também pode publicar ali um listener, e é exatamente por isso que o número é um mau identificador. Uma sessão OpenVPN em UDP 53 continua a ser uma sessão OpenVPN, e uma consulta DNS a um servidor na porta 53 não diz nada sobre se um túnel é permitido. As linhas proto e remote do perfil definem o endpoint externo; o número da porta não define nada por si só.
Isso corta nos dois sentidos ao diagnosticar: uma sonda UDP genérica para a porta 53 prova que uma porta responde, não que o serviço de VPN responde. Teste com o cliente real e o perfil real, porque só isso exercita o handshake que o serviço espera.
Prove o listener antes de culpar a rede
No servidor, confirme o que está associado com ss -lunp | grep 53 e compare com o protocolo e a porta do perfil. A partir da rede do cliente, execute o cliente com mais detalhe para que o registo mostre que endereço e transporte tentou. Se o servidor estiver à escuta e os pacotes do cliente não chegarem, é o caminho ou a política que os recusa, e isso é uma conversa com o dono da rede e não um motivo para trocar de porta.
Uma porta diferente só ajuda quando o serviço está realmente à escuta nela e a implementação o permite. Mover um listener para contornar a filtragem de uma rede gerida é uma decisão de política, não um passo de resolução de problemas. Pergunte ao dono da rede o que é permitido antes de mudar o serviço, porque uma solução alternativa que viola a política acaba por ser fechada mais tarde. Anote essa resposta junto ao perfil para que a próxima pessoa não repita o pedido.
Verifique o DNS depois do túnel, em separado
Depois de o túnel estar ativo, inspecione o estado do resolvedor na interface VPN e consulte um nome interno e um nome público. Se os nomes internos falharem enquanto o túnel transporta tráfego, as configurações de DNS enviadas não foram aplicadas, o que é uma questão de integração do cliente e não de transporte. Se os nomes públicos falharem e os internos funcionarem, a política de túnel dividido está a fazer o que foi configurada para fazer.
Deixe as alterações de DNS com o dono do resolvedor. Substituir uma configuração de resolvedor gerida para fazer passar um teste pode quebrar nomes privados para todo o resto da máquina. Se o túnel enviar um resolvedor e o cliente o ignorar, corrija a integração do cliente em vez de acrescentar uma entrada estática noutro sítio. As entradas estáticas escondem a falha até alguém mudar de rede. Anote qual resolvedor se espera que responda a cada espaço de nomes.