NAT simétrico y VPN: mida la asignación, no la etiqueta

Un hilo de soporte termina con el veredicto «NAT simétrico, la VPN no funcionará aquí», y después el cliente se reinstala tres veces sin motivo. La etiqueta hace daño porque responde a una pregunta que nadie hizo. Un cliente que se conecta hacia fuera con un servidor fijo crea una asignación en el momento en que envía el primer paquete, y la respuesta se deja volver según reglas que casi todas las redes implementan. Lo que la asignación dependiente del extremo complica de verdad es que dos pares intenten alcanzarse a la vez, y eso es otra prueba.

Dos preguntas se esconden tras una etiqueta

La primera pregunta es si un host detrás de esta red puede abrir una sesión hacia una dirección pública y un puerto conocidos. Para un cliente de túnel ese es el caso normal, y la respuesta es casi siempre sí. El router registra el origen interno, asigna un puerto externo y deja pasar la respuesta porque pertenece a una sesión que empezó desde dentro.

La segunda pregunta es si dos hosts detrás de redes distintas pueden descubrir un camino compartido y enviarse sin un servidor en medio. Eso depende de cómo asigna cada red esos puertos externos, y es el único lugar donde el comportamiento de la asignación importa.

Confundir las dos produce el diagnóstico erróneo clásico: falla una función entre pares, alguien ejecuta una prueba de tipo de NAT, ve la peor categoría y concluye que el túnel corriente tampoco puede funcionar. El túnel nunca fue lo que falló.

La asignación y el filtrado son propiedades separadas

La terminología del RFC es más precisa que los nombres que usan los fabricantes, y vale la pena llevarla al tique porque zanja discusiones. La asignación es cómo se asigna el puerto externo. El filtrado es qué paquetes entrantes se dejan pasar. Una red puede ser estricta en una y liberal en la otra, y esa combinación es lo que un protocolo entre pares tiene que sobrevivir.

La tercera fila es lo que la mayoría de los routers domésticos y operadores móviles entienden por simétrico. Note que la etiqueta describe solo la asignación. Una red con esa asignación y filtrado liberal todavía puede aceptar paquetes entrantes al puerto que acaba de asignar, y por eso el perforado de agujeros funciona en algunas y falla en otras.

El filtrado tiene sus propios tres casos y su propio nombre para cada uno. Escribir «NAT simétrico» en un tique cuando quiere decir «filtrado dependiente de dirección y puerto» envía a la siguiente persona al capítulo equivocado del manual. Los dos se comportan distinto en la prueba, así que el error no es académico.

Mida la asignación en lugar de nombrarla

Puede observar el puerto asignado directamente desde el lado servidor de cualquier servicio UDP que controle. Inicie una captura en el host público, envíe desde el cliente y lea el puerto de origen con el que llegó el paquete:

sudo tcpdump -ni eth0 -c 10 'udp port 51820'
sudo wg show wg0 endpoints
sudo conntrack -L -p udp --dport 51820

La línea del extremo es la más útil de las tres, porque WireGuard registra la última dirección y el último puerto que recibió de cada par. Compare ese puerto con el que el cliente cree que usa. Diferirán siempre que ocurra cualquier traducción, y la pregunta importante es si el valor se mantiene estable.

Repita la observación contra un segundo puerto de destino o un segundo servidor y compare otra vez. Si el puerto externo cambia por destino, la asignación depende de la dirección y el puerto. Si se mantiene igual, la red le da una sola asignación y el descubrimiento tiene una oportunidad.

Las herramientas basadas en STUN informan de la misma clasificación en un solo paso, y se pueden usar cuando la red permite UDP de salida hacia un servidor STUN público. Cuando no lo permite, el método de captura anterior sigue funcionando y no requiere nada más que un host que ya controla.

Elija una solución que encaje con el fallo

Si la función que falla es entre pares, las respuestas admitidas son un relé, un servicio de encuentro al que ambos pares puedan llegar, o una topología distinta. TURN existe exactamente para esto, y un producto que incluye su propio relé le está diciendo que espera que algunas redes sean hostiles.

Si la función que falla es un túnel corriente, el comportamiento de la asignación no es su problema y nada de lo anterior se aplica. Compruebe que el cliente envía de verdad, que el servidor ve el paquete y que la respuesta vuelve. Esa secuencia son tres observaciones y no exige saber nada sobre la categoría NAT del router.

Lo que no funciona es repartir cambios de puerto local hasta que algo se conecte. Cambiar el puerto de origen del cliente no cambia cómo asigna la red las asignaciones. Un éxito casual al quinto intento es un falso positivo, y se citará como solución durante meses.

Registre la arquitectura, no el veredicto

Una nota útil dice qué protocolo, en qué dirección empieza la sesión, si hay un relé en el camino y qué se observó en el cable. «NAT simétrico, no funciona» es inutilizable, porque a la vez es erróneo sobre el túnel y no informa sobre el camino entre pares.

Incluya la estabilidad del puerto medida y el comportamiento del filtrado si los probó. Esos dos hechos permiten a otra persona predecir si una función nueva funcionará en esa red sin repetir toda la investigación. También envejecen mejor que una categoría de fabricante que significa algo ligeramente distinto en cada página de ayuda.

Por último, tenga a mano la terminología del RFC 4787 cuando lo escriba. Usar los términos precisos cuesta una frase y evita que el siguiente lector repita el mismo diagnóstico erróneo, que es todo el sentido de escribir la nota.