É o ISP que bloqueia o UDP, ou é a aplicação dentro do túnel?

Alguém relata que a VPN „bloqueia o UDP“, e essa frase esconde duas afirmações completamente diferentes. Uma trata do transporte que a rede de acesso consegue ver, a outra dos pacotes de uma aplicação depois de serem decifrados dentro do túnel. Um túnel cifrado pode ser filtrado de fora sem qualquer chave, e uma aplicação UDP interna pode falhar por motivos que nada têm a ver com filtragem. Decida qual afirmação está a testar antes de reunir provas.

Dois cabeçalhos, uma palavra

Numa implementação de IPsec com NAT-traversal, o pacote exterior é UDP, endereçado entre os dois extremos da VPN, normalmente na porta 4500. Lá dentro, a carga útil cifrada transporta tudo o que o túnel encaminha, o que pode ele próprio ser TCP ou UDP. A palavra UDP aparece, portanto, duas vezes, com significados e visibilidade diferentes.

Uma rede intermédia vê o cabeçalho exterior e nada do interior. Pode permitir, moldar ou descartar o fluxo exterior, e não precisa de decifrar nada para o fazer. É essa assimetria a razão completa de as duas afirmações se confundirem: a mesma palavra descreve o que a rede filtra e o que a aplicação envia. Escreva a camada ao lado da palavra sempre que registar uma constatação, e a confusão desaparece na maior parte.

O cabeçalho interno só se torna visível no extremo recetor, após a decifragem. A partir desse ponto o pacote é encaminhado como qualquer outro, sujeito a rotas, política e à filtragem própria do extremo. São decisões separadas tomadas por equipamentos diferentes.

O que a rede ainda consegue ver

A cifra esconde a carga útil e o cabeçalho de transporte interno, não o facto de existir um fluxo. Os endereços dos extremos, as portas, os tamanhos dos pacotes e o tempo continuam visíveis, e isso basta para classificar o tráfego de forma heurística ou para bloquear um destino concreto.

sudo tcpdump -ni eth0 'udp port 4500'
sudo tcpdump -ni tun0 'udp port 5201'

A primeira captura mostra o fluxo exterior na interface física, e a segunda mostra o fluxo interior na interface do túnel. Executar as duas ao mesmo tempo responde diretamente à pergunta: se o fluxo exterior existe e o interior não, a aplicação nunca enviou nada para o túnel. Se ambos existem e nada regressa, o problema está para lá do túnel, no destino ou no caminho de volta.

RFC 3948 define o encapsulamento UDP exterior, e a especificação do ESP define a disposição protegida no seu interior. Nenhum dos dois documentos promete que uma rede de acesso deixe passar o fluxo exterior, e é por isso que vale a pena executar um teste de alcançabilidade sobre o tuplo exterior antes de qualquer teoria sobre o interior. Um tuplo exterior bloqueado produz um túnel que nunca se forma, não um túnel que se forma e depois perde uma aplicação.

Porque é que uma aplicação UDP falha dentro de um túnel que funciona

Um túnel que transporta uma aplicação web mas não uma aplicação UDP tem várias explicações plausíveis, e a filtragem do protocolo interno pelo ISP não é a primeira. A mais comum é a cobertura: as duas aplicações não entram ambas no mesmo túnel, porque falta a rota para o destino UDP ou as regras de túnel dividido do cliente excluem-na.

A segunda é o extremo. Um servidor VPN que permite uma lista de protocolos, uma firewall no destino ou um serviço que nunca escuta na porta esperada produzem todos um tempo de espera que parece idêntico a um bloqueio de rede.

A terceira é o tamanho do pacote. As aplicações UDP enviam frequentemente datagramas maiores do que um pedido web, e o encapsulamento reduz a MTU utilizável, pelo que após um aperto de mão bem-sucedido pode seguir-se silêncio na primeira carga de tamanho completo. Esse padrão é fácil de ler erradamente como um bloqueio, porque os pacotes pequenos passam e os grandes desaparecem. Uma sonda rápida de MTU resolve a questão em menos de um minuto, e a resposta costuma ser uma carga menor ou um MSS corrigido, não um filtro de rede.

ping -M do -s 1400 -c 2 10.60.0.20
iperf3 -u -c 10.60.0.20 -p 5201 -b 1M -t 5

O primeiro comando testa se um pacote grande sobrevive ao caminho com a fragmentação desativada, o que expõe rapidamente um problema de MTU. O segundo envia um fluxo UDP pequeno e limitado e relata perdas e jitter. Um fluxo que começa e depois pára aponta para o tamanho, não para um bloqueio.

Relate a camada, não o protocolo

Escreva a constatação numa de três formas: a entrega exterior falhou, o encaminhamento interno falhou, ou a aplicação falhou. Cada uma tem um responsável diferente, e misturá-las envia o ticket para a equipa errada.

Mudar uma porta local não pode criar um ouvinte correspondente no extremo remoto, pelo que uma solução do lado do cliente que parece ajudar é geralmente prova de que o destino original estava errado. Do mesmo modo, um perfil alternativo fornecido prova algo sobre a alcançabilidade e nada sobre se a aplicação está corretamente configurada.

Mantenha a inferência separada da observação. A análise de tráfego pode sugerir o que é um fluxo sem o decifrar, e é uma constatação útil, mas não é a mesma afirmação que ler o cabeçalho interno. Indique qual das duas tem realmente.