Tras un cambio de IP do servidor, a regra SNAT segue nomeando a antiga

O servidor mudouse a un enderezo novo, os clientes seguen conectándose e nada do que envían chega a internet. Esa división é a pista: o socket de escoita e o redireccionamento de portos sobreviviron á mudanza, así que o túnel sobe, mentres que a tradución de orixe aplicada aos paquetes reenviados segue nomeando un enderezo que o host xa non posúe. As respostas a eses paquetes reescritos van a unha máquina que xa non está.

Conectar e reenviar fallan en lugares distintos

O establecemento depende do extremo que os clientes xa coñecen: o enderezo público, o redireccionamento de portos diante del e o oínte de dentro. O tráfico reenviado depende dunha segunda decisión tomada despois de que o paquete entre no túnel, cando o host reescribe a súa orixe para que as respostas atopen o camiño de volta.

Un cambio de enderezo só rompe a segunda decisión, e por iso o síntoma se le como "conectado pero sen internet". Tamén explica por que as comprobacións habituais do lado do cliente parecen sanas: o aperto de mans complétase, o cliente recibe un enderezo e ata un ping ao enderezo do túnel do servidor pode responder. Pérdense horas no cliente por unha avaría que vive no outro lado, e por iso a táboa de regras é o primeiro lugar onde mirar.

Le a regra e os seus contadores antes de editar

Enumera as regras de tradución con contadores e compara a orixe configurada cos enderezos que o host ten realmente. Unha regra reescrita a un enderezo morto adoita mostrar tráfico de entrada, porque os paquetes chegan a ela e tradúcense, e nada de volta.

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

Comproba tres campos mentres estás aí: o conxunto da coincidencia de orixe, a interface de saída se a regra nomea unha, e a exclusión que evita que o tráfico entre túneles se reescriba. Esa exclusión pérdese facilmente durante unha edición, e perdela fai que o tráfico entre pares pareza funcionar mentres as súas respostas toman un camiño estraño.

Se os contadores quedan en cero, os paquetes nunca chegan a esta regra e o enderezo non é o problema actual. Busca unha regra competidora máis arriba na cadea, que é o que ocorre cando alguén engade unha substitución en lugar de editar o orixinal. Compara os números de regra coa saída que anotaches hai un minuto. A orde forma parte da configuración, non é un detalle cosmético.

Substitúe a orixe, ou deixa de nomear unha

Cando o host ten un enderezo estable, substitúe a regra no seu sitio en lugar de engadir outra. Substituír por número de regra conserva a orde da que depende o resto da cadea.

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

Cando o enderezo se asigna de forma dinámica, non nomees ningunha orixe e deixa que o núcleo escolla a actual desde a interface de saída. Esa variante sobrevive á seguinte mudanza sen edición, a cambio de ocultar que enderezo se usou.

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 o reenvío IPv4 segue habilitado mediante configuración xestionada e despois fai a regra permanente co mecanismo propio da distribución. Un cambio feito só no núcleo en execución volve co seguinte reinicio, normalmente durante unha xanela de mantemento que ninguén relaciona co cambio.

Dúas formas de equivocar a substitución

Traducir o conxunto ao enderezo do túnel do servidor en lugar do seu enderezo LAN envía as respostas directamente de volta ao túnel, onde se encamiñan cara a un cliente que nunca as pediu. A conexión atasca dun xeito que parece un bucle de encamiñamento, porque o é.

Apilar unha segunda tradución encima da antiga é o outro erro. Gaña a primeira regra que coincide, así que a entrada obsoleta segue xestionando paquetes ata que se borra, e os contadores da regra nova quedan en cero mentres todos culpan a substitución. Borra o duplicado antes de engadir nada novo. Despois le a lista unha vez máis e confirma que exactamente unha tradución coincide co conxunto.

Se o túnel tamén transporta IPv6, repite toda a revisión na outra pila. Unha ruta predeterminada IPv6 sen tradución e sen prefixo encamiñado falla igual de silenciosamente, e é fácil esquecelo porque todo o que está por riba parece idéntico.

Os servizos de entrada necesitan a tradución oposta

Un servizo nun cliente VPN que debe ser accesible desde fóra necesita tradución de destino, non de orixe: o porto público reescríbese ao enderezo do túnel do cliente antes de entrar. A ruta de reenvío necesita entón unha regra 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 traduzas o porto que transporta o propio túnel, porque esa reescritura interrompe a conexión que mantén o servizo accesible. Mantén o porto do túnel completamente fóra das regras de destino. Verifícao despois desde ambos os extremos: contadores na regra nova, unha captura breve no dispositivo do túnel e unha petición a un enderezo dentro do túnel antes de probar a pública.