VPN en el router o reenvío de puerto: ¿cuál gana?

El router termina el VPN por sí mismo, y una regla de reenvío antigua sigue enviando el mismo puerto UDP a una máquina de la LAN. Solo una de las dos puede ser el punto final real, y el núcleo no arbitra. La traducción de destino reescribe el paquete antes de consultar el servicio local, así que el proceso VPN espera tráfico que ya se ha enviado a otro sitio. La tarea es decidir quién posee el puerto y luego hacer que las reglas coincidan.

Un puerto, dos propietarios reclamados

Un servidor VPN que se ejecuta dentro del router necesita un permiso de entrada que lleve a su propio socket. Una entrada de NAT de destino para el mismo puerto lleva a un sitio completamente distinto: una dirección de la LAN y una decisión de reenvío. Son puntos finales diferentes con registros diferentes y modos de fallo diferentes. La pista habitual es que una familia de direcciones funciona y la otra no, porque la entrada sobrante se escribió para una sola familia y nunca se revisó.

Anota la reclamación antes de editar: familia, dirección externa, transporte, puerto y el objetivo traducido.

La traducción va antes de la comprobación local

El NAT de destino cambia el objetivo del paquete en la etapa de prerouting, antes de que el núcleo elija entre entrega local y reenvío. Cuando el objetivo es un host de la LAN, el paquete toma la ruta de reenvío. Las reglas de entrada para el socket propio del router nunca se consultan, por eso el registro del VPN queda vacío mientras el cliente agota el tiempo.

Intended local entry:
WAN UDP 1194 -> router local socket -> input path

Conflicting old entry:
WAN UDP 1194 -> DNAT 192.168.50.10:1194 -> forward path

Ese orden es todo el mecanismo, y las interfaces de los equipos lo esconden tras casillas sin cambiarlo. El propietario del destino sigue decidiendo qué ruta toma un paquete.

Si el host de la LAN es el punto final previsto, el reenvío es correcto y el router no debería escuchar también en ese puerto.

Conserva una asignación y elimina la otra

Enumera las entradas NAT para ese puerto y familia y elige al superviviente:

sudo iptables -t nat -S | grep 1194
sudo ss -lunp | grep :1194

Una entrada TCP con el mismo número es irrelevante para un fallo de UDP, y tratarlas como un solo objeto lleva a borrar la regla equivocada. Cuando el socket local debe ganar, el propietario de la asignación conflictiva elimina o reescribe esa única entrada, y el permiso de entrada para el puerto propio del router se queda en su sitio. Los reenvíos no relacionados, la ruta de gestión y una copia del conjunto de reglas deberían sobrevivir al cambio.

Si el VPN vive en un host separado, el reenvío es el objeto correcto. Un servicio en un contenedor o máquina virtual puede necesitar un puerto publicado incluso cuando la caja se llama router, así que sigue el socket y su espacio de nombres, no la etiqueta de la carcasa.

Confirma el propietario desde fuera

Prueba cada familia por separado, porque una conexión IPv6 que termina en el router no dice nada de una conexión IPv4 que una regla obsoleta redirige. Lee el registro del servicio receptor para ver qué punto final respondió, y trata el mensaje de éxito del cliente como una prueba débil. Hace falta un flujo nuevo para una prueba significativa. Envía una sonda desde un host externo con nc -zvu 203.0.113.7 1194 y lee el registro del ganador con journalctl -u openvpn@server -n 20. El receptor del router registra la conexión él mismo, mientras que un host de la LAN la registra en su propio servicio.

El seguimiento de conexiones mantiene los flujos existentes en su asignación original, así que una sesión establecida puede sobrevivir a la regla que acabas de corregir.

Cuando el punto final previsto responda con sus comprobaciones de identidad habituales, prueba un recurso privado detrás del túnel. Llegar al receptor exterior es solo el primer salto; el enrutamiento interno y la autorización de la aplicación son resultados separados.