Doble NAT y tu VPN: el cliente funciona, el servidor no

Tu router está detrás de otro router, la dirección WAN es privada y el cliente VPN se conecta igualmente. Esa combinación sorprende a quien espera que el doble NAT rompa los túneles, pero las conexiones salientes son justo lo que la traducción maneja mejor. Alojar un servidor VPN detrás de las mismas dos capas es el caso que suele fallar. Dibuja la dirección de la conexión antes de cambiar nada.

Dibuja primero la dirección de la conexión

Abre la página de estado del router interior y anota su dirección WAN, luego compárala con la dirección que te indica un servicio público. Si las dos difieren, hay al menos un traductor entre tu router e internet. Si la dirección WAN cae dentro de 100.64.0.0/10, el traductor exterior probablemente es de tu proveedor y no lo controlas. Esos dos hechos deciden cuál de los pasos siguientes puede funcionar.

curl -s https://ifconfig.me
ip -brief address
traceroute -n 1.1.1.1

El doble NAT no es una doble VPN. La traducción reescribe direcciones y puertos; no añade un segundo túnel cifrado ni cifra nada. Mantener las dos ideas separadas importa porque las soluciones son completamente distintas, y una de ellas implica una conversación con tu proveedor en lugar de una página de ajustes.

Salida: el cliente pregunta, los traductores asignan

Un túnel de salida empieza con un paquete de tu máquina, así que cada traductor puede crear una asignación y dejar entrar la respuesta. El protocolo, el puerto y los temporizadores de inactividad deciden si esa asignación sobrevive lo suficiente para ser útil. La mayoría de los routers domésticos lo resuelven sin ninguna configuración.

Los fallos que aparecen suelen tener que ver con tiempos de espera y soporte de protocolos, no con el número de routers. Un túnel que cae tras unos minutos de silencio es una asignación que caduca, y un keepalive es la respuesta habitual. IPsec tiene extensiones estándar de NAT-traversal, así que afirmar que no puede atravesar la traducción es sencillamente incorrecto. Si el túnel no se establece nunca, mira el extremo y las credenciales antes de culpar a la topología.

wg show
ping -c3 10.8.0.1

Detente si el túnel de salida funciona desde una red y no desde otra. Esa comparación trata de las redes, no del número de routers.

Entrada: el reenvío solo cubre el equipo que posees

Alojar un servidor es la dirección inversa: una conexión nueva llega desde internet y tiene que alcanzar tu máquina atravesando cada capa. Una regla de reenvío de puerto en el router interior solo ayuda si el traductor exterior también te entrega ese tráfico. Repetir la regla local no otorga control sobre el equipo del proveedor.

nc -vz 203.0.113.10 51820
ss -lunp 'sport = :51820'

Compara la dirección WAN del router interior con la dirección pública que observaste y anota de dónde salió cada valor. Si la dirección WAN es privada o está en el rango compartido, la capa exterior hace una traducción que no puedes configurar. Pregunta al proveedor qué accesibilidad de entrada admite antes de pasar una noche con reglas que no pueden surtir efecto. Quitar un router o desactivar un cortafuegos de forma amplia no es un diagnóstico, y es un mal intercambio por un solo puerto abierto.

Detente si la capa exterior es del proveedor y no reenvía. Entonces las respuestas admitidas son otro método de acceso o un relé, no otra regla por tu parte.

Prueba una variable cada vez

Cambia una cosa por prueba y anota el resultado, porque una ruta con doble NAT tiene más variables que una con un solo router. Mantén el perfil y el dispositivo fijos y compara después otra red de acceso. Fíjate en si falla la negociación, si la sesión cae tras la inactividad o si solo fallan los destinos privados. Esas tres observaciones apuntan a tres capas distintas.

journalctl -u wg-quick@wg0 -n 30 --no-pager
ip route get 10.20.30.40

Las subredes privadas superpuestas son una trampa aparte que ninguna cantidad de traducción arregla. Si tu red doméstica y la red remota usan el mismo rango, aparece un conflicto de rutas sin importar cuántos traductores haya en medio. Renumerar un lado es la única respuesta duradera.

La puerta de enlace remota merece la misma atención, porque sus reglas de reenvío y rutas de retorno pueden ser la pieza que falta. Un túnel que se autentica puede no tener ninguna ruta de aplicación utilizable, y ese fallo se ve idéntico desde el lado del cliente. El recorrido termina cuando puedes decir qué dirección falla y qué capa es responsable.