¿Bloquea el ISP el UDP o es la aplicación dentro del túnel?

Alguien informa de que la VPN «bloquea el UDP», y esa frase esconde dos afirmaciones completamente distintas. Una trata del transporte que puede ver la red de acceso, la otra de los paquetes de una aplicación después de descifrarse dentro del túnel. Un túnel cifrado se puede filtrar desde fuera sin ninguna clave, y una aplicación UDP interna puede fallar por motivos que nada tienen que ver con el filtrado. Decide qué afirmación estás probando antes de reunir pruebas.

Dos cabeceras, una palabra

En un despliegue de IPsec con NAT-traversal, el paquete exterior es UDP, direccionado entre los dos extremos de la VPN, normalmente en el puerto 4500. Dentro, la carga útil cifrada transporta todo lo que reenvía el túnel, que a su vez puede ser TCP o UDP. La palabra UDP aparece, por tanto, dos veces con significados y visibilidad distintos.

Una red intermedia ve la cabecera exterior y nada de la interior. Puede permitir, moldear o descartar el flujo exterior, y no necesita descifrar nada para hacerlo. Esa asimetría es la razón completa de que las dos afirmaciones se confundan: la misma palabra describe lo que filtra la red y lo que envía la aplicación. Escribe la capa junto a la palabra cada vez que registres un hallazgo, y la confusión desaparece en su mayor parte.

La cabecera interior solo se hace visible en el extremo receptor, tras el descifrado. A partir de ese punto el paquete se reenvía como cualquier otro, sujeto a rutas, políticas y al filtrado propio del extremo. Son decisiones separadas tomadas por aparatos distintos.

Lo que la red todavía puede ver

El cifrado oculta la carga útil y la cabecera de transporte interna, no el hecho de que exista un flujo. Las direcciones de los extremos, los puertos, los tamaños de paquete y los tiempos siguen visibles, y eso basta para clasificar el tráfico de forma heurística o para bloquear un destino concreto.

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

La primera captura muestra el flujo exterior en la interfaz física, y la segunda muestra el flujo interior en la interfaz del túnel. Ejecutar ambas a la vez responde directamente a la pregunta: si el flujo exterior existe y el interior no, la aplicación nunca envió nada al túnel. Si ambos existen y no vuelve nada, el problema está más allá del túnel, en el destino o en el camino de vuelta.

RFC 3948 define la encapsulación UDP exterior, y la especificación de ESP define la disposición protegida en su interior. Ninguno de los dos documentos promete que una red de acceso deje pasar el flujo exterior, por eso merece la pena ejecutar una prueba de alcanzabilidad sobre la tupla exterior antes de cualquier teoría sobre la interior. Una tupla exterior bloqueada produce un túnel que nunca se forma, no un túnel que se forma y luego pierde una aplicación.

Por qué una aplicación UDP falla dentro de un túnel que funciona

Un túnel que transporta una aplicación web pero no una aplicación UDP tiene varias explicaciones plausibles, y el filtrado del protocolo interno por parte del ISP no es la primera. La más habitual es la cobertura: las dos aplicaciones no entran ambas en el mismo túnel, porque falta la ruta hacia el destino UDP o las reglas de túnel dividido del cliente la excluyen.

La segunda es el extremo. Un servidor VPN que permite una lista de protocolos, un cortafuegos en el destino o un servicio que nunca escucha en el puerto esperado producirán todos un tiempo de espera que parece idéntico a un bloqueo de red.

La tercera es el tamaño de paquete. Las aplicaciones UDP suelen enviar datagramas mayores que una petición web, y la encapsulación reduce la MTU utilizable, así que tras un handshake correcto puede venir el silencio en la primera carga de tamaño completo. Ese patrón se malinterpreta fácilmente como un bloqueo, porque los paquetes pequeños pasan y los grandes desaparecen. Una sonda rápida de MTU lo resuelve en menos de un minuto, y la respuesta suele ser una carga menor o un MSS corregido, no un filtro de red.

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

El primer comando comprueba si un paquete grande sobrevive al camino con la fragmentación desactivada, lo que expone rápidamente un problema de MTU. El segundo envía un flujo UDP pequeño y acotado e informa de pérdidas y jitter. Un flujo que empieza y luego se detiene apunta al tamaño, no a un bloqueo.

Informa de la capa, no del protocolo

Escribe el hallazgo en una de tres formas: falló la entrega exterior, falló el reenvío interior o falló la aplicación. Cada una tiene un responsable distinto, y mezclarlas envía el ticket al equipo equivocado.

Cambiar un puerto local no puede crear un receptor correspondiente en el extremo remoto, así que un apaño del lado del cliente que parece ayudar suele ser evidencia de que el destino original era incorrecto. Del mismo modo, un perfil alternativo proporcionado demuestra algo sobre la alcanzabilidad y nada sobre si la aplicación está bien configurada.

Mantén la inferencia separada de la observación. El análisis de tráfico puede sugerir qué es un flujo sin descifrarlo, y es un hallazgo útil, pero no es la misma afirmación que leer la cabecera interna. Indica cuál de las dos tienes realmente.