Bloquea o ISP o UDP ou é a aplicación dentro do túnel?

Alguén informa de que a VPN «bloquea o UDP», e esa frase esconde dúas afirmacións completamente distintas. Unha trata do transporte que pode ver a rede de acceso, a outra dos paquetes dunha aplicación despois de descifrarse dentro do túnel. Un túnel cifrado pódese filtrar desde fóra sen ningunha clave, e unha aplicación UDP interna pode fallar por motivos que nada teñen que ver coa filtraxe. Decide que afirmación estás probando antes de reunir probas.

Dúas cabeceiras, unha palabra

Nun despregamento de IPsec con NAT-traversal, o paquete exterior é UDP, dirixido entre os dous extremos da VPN, normalmente no porto 4500. Dentro, a carga útil cifrada transporta todo o que reenvía o túnel, que á súa vez pode ser TCP ou UDP. A palabra UDP aparece, xa que logo, dúas veces con significados e visibilidade distintos.

Unha rede intermedia ve a cabeceira exterior e nada da interior. Pode permitir, moldear ou descartar o fluxo exterior, e non necesita descifrar nada para facelo. Esa asimetría é a razón completa de que as dúas afirmacións se confundan: a mesma palabra describe o que filtra a rede e o que envía a aplicación. Escribe a capa xunto á palabra cada vez que rexistres un achado, e a confusión desaparece na súa maior parte.

A cabeceira interior só se fai visible no extremo receptor, tras o descifrado. A partir dese punto o paquete reenvíase como calquera outro, suxeito a rutas, políticas e á filtraxe propia do extremo. Son decisións separadas tomadas por aparellos distintos.

O que a rede aínda pode ver

O cifrado oculta a carga útil e a cabeceira de transporte interna, non o feito de que exista un fluxo. Os enderezos dos extremos, os portos, os tamaños de paquete e os tempos seguen visibles, e iso abonda para clasificar o tráfico de forma heurística ou para bloquear un 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 ambas á vez responde directamente á pregunta: se o fluxo exterior existe e o interior non, a aplicación nunca enviou nada ao túnel. Se ambos existen e non volve nada, o problema está máis alá do túnel, no destino ou no camiño de volta.

RFC 3948 define a encapsulación UDP exterior, e a especificación de ESP define a disposición protexida no seu interior. Ningún dos dous documentos promete que unha rede de acceso deixe pasar o fluxo exterior, por iso paga a pena executar unha proba de alcanzabilidade sobre a tupla exterior antes de calquera teoría sobre a interior. Unha tupla exterior bloqueada produce un túnel que nunca se forma, non un túnel que se forma e logo perde unha aplicación.

Por que unha aplicación UDP falla dentro dun túnel que funciona

Un túnel que transporta unha aplicación web pero non unha aplicación UDP ten varias explicacións plausibles, e a filtraxe do protocolo interno por parte do ISP non é a primeira. A máis habitual é a cobertura: as dúas aplicacións non entran ambas no mesmo túnel, porque falta a ruta cara ao destino UDP ou as regras de túnel dividido do cliente exclúena.

A segunda é o extremo. Un servidor VPN que permite unha lista de protocolos, un cortafogos no destino ou un servizo que nunca escoita no porto esperado producirán todos un tempo de espera que parece idéntico a un bloqueo de rede.

A terceira é o tamaño de paquete. As aplicacións UDP adoitan enviar datagramas maiores que unha petición web, e a encapsulación reduce a MTU utilizábel, así que tras un handshake correcto pode vir o silencio na primeira carga de tamaño completo. Ese patrón malinterprétase facilmente como un bloqueo, porque os paquetes pequenos pasan e os grandes desaparecen. Unha sonda rápida de MTU resólveo en menos dun minuto, e a resposta adoita ser unha carga menor ou un MSS corrixido, non un 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 comproba se un paquete grande sobrevive ao camiño coa fragmentación desactivada, o que expón rapidamente un problema de MTU. O segundo envía un fluxo UDP pequeno e acoutado e informa de perdas e jitter. Un fluxo que comeza e logo se detén apunta ao tamaño, non a un bloqueo.

Informa da capa, non do protocolo

Escribe o achado nunha de tres formas: fallou a entrega exterior, fallou o reenvío interior ou fallou a aplicación. Cada unha ten un responsable distinto, e mesturalas envía o ticket ao equipo equivocado.

Cambiar un porto local non pode crear un receptor correspondente no extremo remoto, así que unha solución provisional do lado do cliente que parece axudar adoita ser evidencia de que o destino orixinal era incorrecto. Do mesmo xeito, un perfil alternativo fornecido demostra algo sobre a alcanzabilidade e nada sobre se a aplicación está ben configurada.

Mantén a inferencia separada da observación. A análise de tráfico pode suxerir que é un fluxo sen descifralo, e é un achado útil, pero non é a mesma afirmación que ler a cabeceira interna. Indica cal das dúas tes realmente.