Los puertos UDP fijos pueden saltarse el reenvío de puertos, pero no todos los NAT

Dos routers domésticos, ningún puerto reenviado y una VPN que a veces se conecta de todos modos. UDP lo permite, porque un cortafuegos admitirá un paquete que pueda emparejar con un flujo que la máquina ya inició. Es un truco condicional, no una función, y las condiciones son fáciles de enunciar cuando sabes qué compara el cortafuegos. También son la razón por la que perfiles idénticos se comportan distinto en redes distintas.

La comparación que hace un cortafuegos

Cada datagrama saliente crea una entrada efímera: dirección de origen, puerto de origen, dirección de destino, puerto de destino. Todo lo que llega y coincide con la entrada se trata como respuesta y se deja pasar. Las reglas de entrada no intervienen.

Así que la pregunta no es si el cortafuegos deja entrar al par. Es si el paquete del par parece la respuesta que la entrada espera. Cambia un campo de esa tupla de cuatro partes y el paquete se vuelve un extraño. Por eso una configuración que funciona puede romperse cuando solo cambia el número de puerto, y por eso el mismo puerto puede funcionar en un router y fallar en el siguiente.

Fija el puerto de origen local y el mismo número aparece a ambos lados del intercambio. Ese es todo el mecanismo, y explica por qué el truco es frágil y no misterioso.

Fijar un puerto en cada extremo

El puerto UDP predeterminado de OpenVPN es el 1194, y lport fija el puerto de origen desde el que envía. Fija ambos pares y la tupla saliente de cada uno apuntará a un puerto en el que el otro escucha:

# peer A
lport 1194
remote 198.51.100.20 1194
# peer B
lport 1194
remote 203.0.113.10 1194

Eso solo funciona mientras ningún router entre ellos reescriba el puerto de origen. Cuando los paquetes aparecen en una captura pero no levanta ningún túnel, la reescritura es el primer sospechoso.

Dónde deja de coincidir la tupla

Un NAT que mapea por destino da a cada par un puerto externo distinto. La dirección que le dijeron a tu par que usara no es la dirección que le llega, así que el paquete entrante no coincide con nada y se descarta en silencio.

La traducción de operador, el NAT apilado y la aleatorización de puertos acaban igual. También cualquier dispositivo intermedio que reescriba puertos y deje las direcciones tranquilas.

Los transportes de flujo están peor. Un handshake TCP se sigue paso a paso, así que una VPN basada en TCP no se puede perforar así en absoluto y necesita un oyente en algún punto del camino.

Normalmente un lado falla primero

En la práctica las dos redes rara vez se comportan igual. Un router puede repartir un mapeo predecible mientras el otro reparte puertos por destino, y el resultado es una configuración que funciona entre dos casas y falla desde una red móvil. Los informes que se contradicen suelen describir dos parejas de routers distintas. Ninguno de los dos autores se equivoca, y ninguno de los dos resultados se generaliza.

Averigua qué lado descartó el paquete antes de tocar los perfiles. Las capturas en ambos extremos lo resuelven en un solo intento: los datagramas que salen de A y nunca llegan a B significan que el flujo se reescribió en tránsito, mientras que los que llegan a B sin que vuelva ninguna respuesta significan que el cortafuegos no los aceptó como relacionados.

Dos pares con direcciones IPv6 públicas esquivan todo el problema. Sin traducción no hay nada que emparejar, así que basta una regla de cortafuegos que nombre a los pares y el diseño deja de depender del comportamiento del router.

Cuándo dejar de intentarlo

Un host con dirección pública es la respuesta fiable. Puede terminar el túnel para ambos pares, o simplemente ayudarles a descubrir la dirección externa actual del otro, y ambos arreglos funcionan haga lo que haga el NAT. Una capa superpuesta gestionada ofrece la misma coordinación si la política lo permite.

Ninguno de estos necesita un cortafuegos desactivado. Apagar la protección para ganar la conexión directa descarta la razón por la que el intento directo era atractivo, y deja la máquina abierta durante toda la prueba.

Prueba primero el arreglo directo y luego anota lo que viste. El comportamiento del NAT y la captura que lo mostró valen más que el par de puertos que acabaste usando, porque la próxima red será distinta. El manual de OpenVPN 2.6 documenta lport y las opciones remote de las que depende esto.