Després d'un canvi d'IP del servidor, la regla SNAT encara nomena l'antiga

El servidor s'ha traslladat a una adreça nova, els clients encara es connecten i res del que envien arriba a internet. Aquesta separació és la pista: el sòcol d'escolta i el reenviament de port van sobreviure al trasllat, així que el túnel s'aixeca, mentre que la traducció d'origen aplicada als paquets reenviats encara nomena una adreça que l'amfitrió ja no posseeix. Les respostes a aquests paquets reescrits van a una màquina que ja no hi és.

La connexió i el reenviament fallen en llocs diferents

L'establiment depèn del punt final que els clients ja coneixen: l'adreça pública, el reenviament de port al davant i l'oient de dins. El trànsit reenviat depèn d'una segona decisió presa després que el paquet entri al túnel, quan l'amfitrió reescriu l'origen perquè les respostes puguin trobar el camí de tornada.

Un canvi d'adreça només trenca la segona decisió, i per això el símptoma es llegeix com "connectat però sense internet". També explica per què les comprovacions habituals al costat del client semblen sanes: l'encaixada de mans es completa, el client rep una adreça i fins i tot pot respondre un ping a l'adreça del túnel del servidor. S'hi perden hores al client per una avaria que viu a l'altre costat, i per això la taula de regles és el primer lloc on mirar.

Llegeix la regla i els seus comptadors abans d'editar

Llista les regles de traducció amb comptadors i compara l'origen configurat amb les adreces que l'amfitrió té realment. Una regla reescrita cap a una adreça morta normalment mostra trànsit d'entrada, perquè els paquets hi arriben i es tradueixen, i res de tornada.

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

Comprova tres camps mentre hi ets: el conjunt de la coincidència d'origen, la interfície de sortida si la regla en nomena una, i l'exclusió que evita que el trànsit entre túnels es reescrigui. Aquesta exclusió es perd fàcilment durant una edició, i perdre-la fa que el trànsit entre iguals sembli funcionar mentre les seves respostes prenen un camí estrany.

Si els comptadors es queden a zero, els paquets no arriben mai a aquesta regla i l'adreça no és el problema actual. Busca una regla competidora més amunt de la cadena, que és el que passa quan algú afegeix una substitució en lloc d'editar l'original. Compara els números de regla amb la sortida que vas anotar fa un minut. L'ordre forma part de la configuració, no és un detall cosmètic.

Substitueix l'origen o deixa de nomenar-ne un

Quan l'amfitrió té una adreça estable, substitueix la regla al seu lloc en lloc d'afegir-ne una altra. Substituir pel número de regla conserva l'ordre del qual depèn la resta 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

Quan l'adreça s'assigna dinàmicament, no nomenis cap origen i deixa que el nucli triï l'actual des de la interfície de sortida. Aquesta variant sobreviu al trasllat següent sense cap edició, a canvi d'amagar quina adreça s'ha fet servir.

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 reenviament IPv4 encara està activat mitjançant configuració gestionada i després fes la regla permanent amb el mecanisme propi de la distribució. Un canvi fet només al nucli en execució torna amb el proper reinici, normalment durant una finestra de manteniment que ningú no relaciona amb el canvi.

Dues maneres d'equivocar la substitució

Traduir el conjunt a l'adreça del túnel del servidor en lloc de la seva adreça LAN envia les respostes directament cap al túnel, on es dirigeixen a un client que no les havia demanat mai. La connexió s'atura d'una manera que sembla un bucle d'encaminament, perquè ho és.

Apilar una segona traducció damunt de l'antiga és l'altre error. Guanya la primera regla que coincideix, així que l'entrada obsoleta continua gestionant paquets fins que s'esborra, i els comptadors de la regla nova es queden a zero mentre tothom culpa la substitució. Esborra el duplicat abans d'afegir res de nou. Després llegeix la llista una vegada més i confirma que exactament una traducció coincideix amb el conjunt.

Si el túnel també porta IPv6, repeteix tota la revisió a l'altra pila. Una ruta per defecte IPv6 sense traducció i sense prefix encaminat falla igual de silenciosament, i és fàcil oblidar-ho perquè tot el que hi ha a sobre sembla idèntic.

Els serveis d'entrada necessiten la traducció oposada

Un servei en un client VPN que ha de ser accessible des de fora necessita traducció de destí, no d'origen: el port públic es reescriu a l'adreça del túnel del client abans d'entrar. El camí de reenviament necessita llavors una regla explícita que permeti aquest trànsit.

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

No tradueixis mai el port que porta el túnel mateix, perquè aquesta reescriptura interromp la connexió que manté el servei accessible. Mantén el port del túnel completament fora de les regles de destí. Verifica-ho després des dels dos extrems: comptadors a la regla nova, una captura curta al dispositiu del túnel i una petició a una adreça dins del túnel abans de provar la pública.