VPN por UDP em silêncio numa varredura de portas? Porque isso acontece

Você varre a porta da VPN, não recebe resposta e conclui que o serviço está em baixo ou que a firewall está fechada. Com o WireGuard, e com os canais de controlo do OpenVPN que transportam a sua própria autenticação, essa conclusão não se segue. Um datagrama sem material de autenticação válido é descartado sem resposta, por isso o silêncio é o aspeto de um serviço saudável visto de fora. A sonda está errada antes de o túnel estar.

O silêncio é o protocolo, não uma avaria

O UDP não tem estabelecimento de ligação, por isso não há SYN nem confirmação que permita a um scanner distinguir uma porta aberta de uma filtrada. A sonda chega como um datagrama isolado, e o serviço verifica se corresponde ao protocolo que espera. Quando não corresponde, o pacote é descartado, e descartar é o comportamento documentado e não um mau funcionamento.

O WireGuard valida criptograficamente as suas mensagens de handshake e ignora tudo o que falha. OpenVPN com tls-auth ou tls-crypt faz o mesmo para o seu canal de controlo. Em ambos os casos uma carga arbitrária nunca chega a uma fase virada para o utilizador, por isso não há nada com que responder nem erro a devolver.

O TCP ter-lhe-ia dado um reset de uma porta fechada. O UDP deixa-o na ambiguidade, que os scanners resolvem imprimindo aberta ou filtrada em vez de adivinhar.

O que um scanner pode e não pode concluir

O resultado de uma varredura é tão informativo como a carga que enviou. Ordene as observações possíveis segundo o que cada uma sustenta realmente:

Leia a terceira linha como o único teste positivo da lista. Exige o perfil real, a chave real e o ponto final correto, e é exatamente isso que um scanner genérico não tem.

Olhe para as duas pontas do caminho

Para um servidor que administra, capture na interface antes de tirar qualquer conclusão e depois pergunte ao serviço o que viu. Ambos os comandos exigem root no gateway:

tcpdump -ni any udp port 51820
tcpdump -ni any udp port 1194
wg show

Se não aparecer nenhum pacote na interface, o caminho descartou-o antes de o serviço ver alguma coisa, e a próxima paragem é o encaminhamento e a filtragem. Se os pacotes chegarem mas nenhum handshake se completar, o serviço está acessível e a discrepância está nas chaves, na configuração do ponto final ou na versão do protocolo. Essa comparação responde à pergunta que o scanner não conseguia. Execute-a enquanto um cliente real tenta ligar-se, não enquanto o scanner se repete.

Mude o teste, não a proteção

O atalho tentador é desativar a proteção do canal de controlo para que um diagnóstico receba resposta. Isso troca uma propriedade de segurança real por um resultado de varredura mais bonito, e é a direção errada. Use antes um perfil válido de uma rede aprovada e anote o ponto final e a hora para que a comparação seja repetível.

O teste mais útil é diferencial: o mesmo perfil num caminho que funciona e no caminho que não funciona. Se o caminho que funciona produz um handshake e o caminho que falha não produz nada na interface, localizou a rutura sem enfraquecer nada.

Um pacote UDP sem resposta não prova, portanto, nem que o servidor está offline nem que é seguro. Prova que esta sonda, neste caminho, neste momento, não foi aceite.