Servidor VPN doméstico inaccesible: recorre la cadena NAT

El servidor responde en la LAN, la regla de reenvío de puerto parece correcta y, aun así, un cliente externo no puede conectarse. Avanzar hacia fuera una frontera a la vez es más rápido que editar la regla por cuarta vez, porque cada frontera deja su propia evidencia: la página WAN del router, la traducción del proveedor y el oyente en el host. Empieza por la página de administración que ya tienes abierta y termina con una prueba desde una red que no controlas. Anota cada resultado sobre la marcha, porque la secuencia es el diagnóstico y un número recordado no es una prueba. Si solo necesitas un túnel de salida, la traducción no es tu problema: solo se bloquea el tráfico entrante no solicitado.

Empieza en la página WAN del router

Inicia sesión en el router y lee la página de estado en lugar de la lista de reenvío de puertos. Anota la dirección WAN, la interfaz a la que pertenece y si el tipo de conexión es DHCP, PPPoE o algo que proporcione el proveedor. Después compara esa dirección con lo que informa un servicio externo, usando un teléfono con datos móviles para que la observación no vuelva por el mismo router. Los dos números responden preguntas distintas, y compararlos es todo el objetivo de este paso.

Una dirección WAN que difiere de la dirección pública observada significa que al menos un traductor está por encima del router. Todavía no es una avería, porque muchos proveedores traducen por diseño y el servicio sigue funcionando. Si las dos coinciden, probablemente el router posee la dirección y el problema se ha trasladado al interior de tu red. En cualquier caso, anota el par con la fecha, porque los proveedores reasignan direcciones y una comparación con las notas del mes pasado no vale nada.

Sube un salto hacia arriba

Ejecuta un traceroute desde el propio router y lee los primeros saltos. Direcciones públicas repetidas, un primer salto que responde con una dirección privada o una dirección dentro del rango compartido 100.64.0.0/10 apuntan todas a un traductor aguas arriba. RFC 6598 define ese rango justamente para este tipo de despliegue, y por eso verlo en el campo WAN es una señal fuerte y no una curiosidad. Dos traductores en la ruta hacen la traza menos evidente, así que lee el patrón y no una sola línea.

Algunos proveedores solo muestran la dirección asignada en el portal de cliente, así que mira allí antes de concluir que el router miente. Una dirección del portal que coincide con tu observación externa mientras el router informa otra cosa es la prueba más clara de un traductor aguas arriba. Guarda ambas páginas en el registro de cambios, porque la discusión sobre quién posee qué frontera avanza mucho más rápido con dos imágenes fechadas.

Confirma el oyente y el reenvío

Una prueba en la LAN demuestra que el servicio funciona localmente y no demuestra nada sobre el alcance desde fuera. Muchos routers responden su propia regla de reenvío desde dentro, así que una prueba de bucle tiene éxito mientras la ruta externa sigue cerrada. Confirma que el demonio está ligado a la dirección y el puerto que crees que usa, y después prueba desde fuera. Todo lo que sigue es solo de lectura.

ss -lunp | grep -E '1194|51820'
ip -4 addr show | grep -E 'inet '
curl -s --max-time 5 ifconfig.me
traceroute -n -m 5 1.1.1.1

Si la prueba externa muestra que no llega ningún paquete al router, la caída ocurrió aguas arriba y ninguna regla local la arreglará. Si los paquetes llegan y nada responde, la siguiente frontera es el oyente o el cortafuegos del host. Una captura de paquetes en el host aclara cuál de los dos estás mirando y lleva menos tiempo que otra ronda de adivinar reglas. Mantén el oyente y su transporte sin cambios mientras comparas, o la siguiente prueba responderá otra pregunta.

Cambia la topología, no la misma regla

Cuando el traductor es del proveedor, la solución es otra ruta y no otro reenvío. Un VPS pequeño con dirección pública, unido por un túnel de salida desde el lado de casa, pone un extremo alcanzable delante del servicio. Una dirección pública proporcionada por el proveedor es más sencilla donde existe y normalmente más barata que mantener una máquina. IPv6 elimina la traducción por completo, siempre que la red del cliente, los registros DNS y la política del cortafuegos lo soporten todo.

DNS dinámico solo actualiza un nombre; no crea alcance, y apuntarlo a una dirección compartida envía a los clientes a una pasarela del proveedor que otros abonados también usan. Ese fallo se parece exactamente a un servidor muerto, y por eso importa el registro de los pasos anteriores. Anota a qué dirección resolvió el nombre cuando la prueba falló, y guarda la respuesta con el resultado de la prueba.

Reescribe el plan en torno a la frontera que controlas: el oyente, el túnel y las rutas. Mantén el reenvío antiguo solo mientras siga describiendo algo cierto, porque una regla que ya no encaja con la topología es peor que ninguna regla. Anota qué capa bloqueaba en realidad y qué evidencia lo mostró. Si no, la siguiente persona que abra la página de administración repetirá cada paso de este recorrido desde el principio.