Cómo sortear la CGNAT con un túnel WireGuard y un VPS de puente

La desaparición del port forwarding tradicional en las redes domésticas ha obligado a reconfigurar las estrategias de autoalojamiento. La culpa la tiene la escasez de IPv4: los proveedores utilizan la NAT de grado de operador (CGNAT), una capa de traducción dentro de la red del ISP que hace que la IP pública pertenezca al operador y no al usuario final. El resultado práctico es que las reglas de reenvío de puertos en el router doméstico dejan de ser efectivas para el tráfico entrante externo.

Topología con VPS de puente

Para resolver este bloqueo, la solución descrita en el artículo original utiliza un servidor virtual (VPS) barato ubicado en un centro de datos en Francia como punto de entrada. Este VPS actúa como un puente que aloja los servicios y se conecta al homelab situado en el sótano del autor en el norte de España mediante un túnel bidireccional de WireGuard.

El truco técnico reside en que el túnel de WireGuard lo inicia el homelab, no el VPS. Esto elimina la necesidad de tener una IP pública estática en casa, ya que el nodo doméstico puede establecer la conexión saliente hacia el VPS aunque esté tras una NAT agresiva. El coste operativo es un RTT de 39 milisegundos añadido a la latencia de la conexión.

La configuración en el VPS es lo que permite la exposición externa. Mediante reglas de iptables en el hook PostUp, se realiza un DNAT que redirige todo el tráfico entrante hacia la dirección privada del homelab (10.0.0.2). Se excluyen explícitamente los puertos 2222 (SSH del puente) y 51820 (WireGuard) para evitar bucles. La clave está en que se reescribe el destino pero no la fuente, permitiendo que el servidor doméstico vea las IPs reales de los clientes, una propiedad crítica para el registro de logs y la seguridad.

En el lado del homelab, la configuración de red es más compleja. Se crea una tabla de routing separada que fuerza a las respuestas salientes a volver por el túnel de WireGuard, mientras que el tráfico propio del hogar sigue saliendo por el router doméstico normal. Esto garantiza que, por ejemplo, una conexión SSH hacia el dominio del autor en el puerto 22 caiga directamente en el homelab, mientras que el puerto 2222 del VPS permanece accesible para la administración del nodo intermedio.

Resiliencia y mantenimiento

El autor detalla un plan de contingencia para los tres puntos de fallo posibles. Si el homelab se colapsa, un cronjob detecta la caída de SSH y reinicia la máquina. Si el VPS falla, recomienda mantener un punto de entrada de respaldo directo al homelab, como un túnel de Cloudflare o Tailscale. Las caídas breves del túnel se resuelven solas por el re-handshake de WireGuard.

Esta configuración está pensada para quien necesita el control total sobre su infraestructura y no quiere depender de las políticas de los grandes hyperscalers. Permite exponer servicios al internet público manteniendo el hardware en casa, algo que la CGNAT había vuelto prácticamente inviable sin contratar IPs estáticas de pago, que en España rondan los 20 euros mensuales. El código fuente completo de estas configuraciones está disponible en GitHub para quien quiera replicar la topología.