Tras un cambio de IP del servidor, la regla SNAT sigue nombrando la antigua

El servidor se mudó a una dirección nueva, los clientes siguen conectándose y nada de lo que envían llega a internet. Esa división es la pista: el socket de escucha y la redirección de puertos sobrevivieron a la mudanza, así que el túnel sube, mientras que la traducción de origen aplicada a los paquetes reenviados sigue nombrando una dirección que el host ya no posee. Las respuestas a esos paquetes reescritos van a una máquina que ya no está.

Conectar y reenviar fallan en lugares distintos

El establecimiento depende del extremo que los clientes ya conocen: la dirección pública, la redirección de puertos delante de ella y el oyente de dentro. El tráfico reenviado depende de una segunda decisión que se toma después de que el paquete entra en el túnel, cuando el host reescribe su origen para que las respuestas encuentren el camino de vuelta.

Un cambio de dirección solo rompe la segunda decisión, y por eso el síntoma se lee como "conectado pero sin internet". También explica por qué las comprobaciones habituales del lado del cliente parecen sanas: el handshake se completa, el cliente recibe una dirección y hasta un ping a la dirección del túnel del servidor puede responder. Se pierden horas en el cliente por una avería que vive al otro lado, y por eso la tabla de reglas es el primer lugar donde mirar.

Lee la regla y sus contadores antes de editar

Enumera las reglas de traducción con contadores y compara el origen configurado con las direcciones que el host realmente tiene. Una regla reescrita a una dirección muerta suele mostrar tráfico de entrada, porque los paquetes llegan a ella y se traducen, y nada de vuelta.

sudo iptables -t nat -L POSTROUTING -n -v --line-numbers
ip -4 addr show

Comprueba tres campos mientras estás ahí: el conjunto de la coincidencia de origen, la interfaz de salida si la regla nombra una, y la exclusión que evita que el tráfico entre túneles se reescriba. Esa exclusión se pierde fácilmente durante una edición, y perderla hace que el tráfico entre pares parezca funcionar mientras sus respuestas toman un camino extraño.

Si los contadores se quedan en cero, los paquetes nunca llegan a esta regla y la dirección no es el problema actual. Busca una regla competidora más arriba en la cadena, que es lo que ocurre cuando alguien añade un reemplazo en lugar de editar el original. Compara los números de regla con la salida que anotaste hace un minuto. El orden es parte de la configuración, no un detalle cosmético.

Sustituye el origen, o deja de nombrar uno

Cuando el host tiene una dirección estable, sustituye la regla en su sitio en lugar de añadir otra. Sustituir por número de regla conserva el orden del que depende el resto de la cadena.

sudo iptables -t nat -R POSTROUTING 1 -s 10.8.0.0/24 ! -d 10.8.0.0/24 -j SNAT --to-source 10.151.0.40

Cuando la dirección se asigna de forma dinámica, no nombres ningún origen y deja que el núcleo elija el actual desde la interfaz de salida. Esa variante sobrevive a la siguiente mudanza sin edición, a cambio de ocultar qué dirección se usó.

sudo iptables -t nat -R POSTROUTING 1 -s 10.8.0.0/24 ! -d 10.8.0.0/24 -o eth0 -j MASQUERADE

Confirma que el reenvío IPv4 sigue habilitado mediante configuración gestionada y después haz la regla permanente con el mecanismo propio de la distribución. Un cambio hecho solo en el núcleo en ejecución vuelve con el siguiente reinicio, normalmente durante una ventana de mantenimiento que nadie relaciona con el cambio.

Dos formas de equivocar la sustitución

Traducir el conjunto a la dirección del túnel del servidor en lugar de a su dirección LAN envía las respuestas directamente de vuelta al túnel, donde se enrutan hacia un cliente que nunca las pidió. La conexión se atasca de una forma que parece un bucle de enrutamiento, porque lo es.

Apilar una segunda traducción encima de la antigua es el otro error. Gana la primera regla que coincide, así que la entrada obsoleta sigue gestionando paquetes hasta que se borra, y los contadores de la regla nueva se quedan en cero mientras todos culpan a la sustitución. Borra el duplicado antes de añadir nada nuevo. Después lee la lista una vez más y confirma que exactamente una traducción coincide con el conjunto.

Si el túnel también transporta IPv6, repite toda la revisión en la otra pila. Una ruta predeterminada IPv6 sin traducción y sin prefijo enrutado falla igual de silenciosamente, y es fácil olvidarlo porque todo lo que está por encima parece idéntico.

Los servicios entrantes necesitan la traducción opuesta

Un servicio en un cliente VPN que debe ser accesible desde fuera necesita traducción de destino, no de origen: el puerto público se reescribe a la dirección del túnel del cliente antes de entrar. La ruta de reenvío necesita entonces una regla explícita que permita ese tráfico.

sudo iptables -t nat -A PREROUTING -p tcp --dport 8080 -j DNAT --to-destination 10.9.8.2:8080

Nunca traduzcas el puerto que transporta el propio túnel, porque esa reescritura interrumpe la conexión que mantiene accesible el servicio. Mantén el puerto del túnel completamente fuera de las reglas de destino. Verifícalo después desde ambos extremos: contadores en la regla nueva, una captura breve en el dispositivo del túnel y una petición a una dirección dentro del túnel antes de probar la pública.