Por qué un servidor VPN detrás de CGNAT nunca acepta conexiones

El router informa de una dirección WAN que empieza por 100.72, el nombre DNS dinámico se resuelve a otra dirección pública y el servidor VPN de ese router nunca completa un saludo desde fuera. El reenvío de puertos está configurado, el servicio se ejecuta y una prueba desde la LAN sigue funcionando. Nada en el registro del router parece un error. Esa combinación es NAT de grado operador, y ninguna regla de cortafuegos puede abrir un puerto en una dirección que el ISP posee.

Confirmar la dirección compartida lleva dos minutos y evita una semana de cambios de configuración.

Las señales que apuntan al NAT del operador

Compare la dirección WAN de la página de estado del router con la dirección que informa una consulta externa. Una dirección WAN dentro de 100.64.0.0/10 es la señal habitual, y los rangos privados 10/8, 172.16/12 y 192.168/16 significan lo mismo. Si traceroute muestra el mismo salto público repetido, o un salto temprano responde con una dirección privada, hay otro traductor entre el router e internet. Algunos ISP solo listan la dirección asignada en el portal de clientes, así que exporte ese valor junto con el traceroute.

Cambiar de protocolo o de puerto no ayuda, porque el problema es la accesibilidad entrante y no un puerto cerrado.

Por qué el reenvío y el DNS dinámico no pueden arreglarlo

Una regla de reenvío de puertos asigna un puerto de la interfaz WAN del router, pero el tráfico entrante nunca llega a esa interfaz: el ISP lo traduce primero y solo reenvía lo que permite su propia tabla. Publicar la dirección compartida en el DNS dinámico apunta a los clientes hacia una puerta de enlace del ISP usada por muchos abonados, por eso el nombre resuelve y el saludo sigue fallando. Las pruebas de hairpin funcionan porque el router responde a su propia regla desde dentro, y UPnP tiene exactamente el mismo punto ciego.

Reconfigurar el cliente tampoco ayudará, ya que el fallo ocurre antes de que se lea cualquier ajuste del cliente.

Retransmitir a través de un VPS con rutas explícitas

Ponga una dirección pública delante alquilando el VPS más pequeño capaz de transportar el tráfico, y luego haga que el router de casa marque hacia él. El UDP saliente desde la red doméstica atraviesa el NAT del operador, así que el túnel se establece desde dentro y el VPS pasa a ser el extremo accesible. El lado doméstico se convierte en un cliente con una dirección de túnel fija, no en un servidor.

En el VPS, añada una entrada de directorio específica del cliente para que el servidor sepa qué par posee la subred doméstica, y añada una ruta de núcleo correspondiente.

# /etc/openvpn/server/ccd/home-site.conf
ifconfig-push 10.8.0.10 255.255.255.0
iroute 192.168.50.0 255.255.255.0

# server.conf
client-config-dir /etc/openvpn/server/ccd
route 192.168.50.0 255.255.255.0
push "route 10.8.0.0 255.255.255.0"

La línea iroute indica a OpenVPN qué cliente recibe el tráfico de la subred doméstica; la línea route pone esa subred en la tabla del núcleo del VPS para que los paquetes entren siquiera en el túnel. Para un servicio publicado, añada una regla de NAT de destino que reenvíe el puerto público a 10.8.0.10 y active net.ipv4.ip_forward.

Pruebe la ruta desde fuera

Verifique cada salto en el lado público, porque un túnel correcto no demuestra que el servicio sea accesible. El estado de escucha y la captura de paquetes en el VPS separan «no llegó nada» de «llegó y se descartó».

ss -lunp | grep 1194
tcpdump -ni any udp port 1194
nft list ruleset | grep -A4 dnat

# from a phone on mobile data, not the home Wi-Fi
nc -vz -u 203.0.113.10 1194

Si la captura muestra paquetes del teléfono pero ninguna respuesta, la configuración del servidor o el cortafuegos son la siguiente parada. Si la captura no muestra nada, el cliente sigue resolviendo o enviando a la dirección equivocada.

Alternativas que conviene valorar primero

Una dirección IPv4 dedicada del ISP es la solución más corta y suele ser una pequeña cuota mensual. El IPv6 nativo elimina la traducción en ambos extremos cuando la VPN, la red del cliente y los registros DNS lo soportan todos. Una superposición de malla con un enrutador de subred dentro de la red doméstica logra la misma retransmisión sin un VPS, a costa de depender de un servicio de coordinación.

Elija la retransmisión cuando el requisito sea acceso entrante estable y cada regla deba quedar bajo su control. Elija la dirección del ISP cuando el presupuesto lo permita y el objetivo sea simplemente dejar de pensar en ello.