Après un changement d'IP du serveur, la règle SNAT désigne encore l'ancienne

Le serveur a déménagé vers une nouvelle adresse, les clients se connectent toujours, et rien de ce qu'ils envoient n'atteint Internet. Cette séparation est l'indice : le socket d'écoute et la redirection de port ont survécu au déménagement, donc le tunnel monte, tandis que la traduction de source appliquée aux paquets transférés désigne encore une adresse que l'hôte ne possède plus. Les réponses à ces paquets réécrits partent vers une machine qui n'existe plus.

La connexion et le transfert échouent à des endroits différents

L'établissement dépend du point de terminaison que les clients connaissent déjà : l'adresse publique, la redirection de port devant elle et l'écouteur à l'intérieur. Le trafic transféré dépend d'une seconde décision prise après l'entrée du paquet dans le tunnel, lorsque l'hôte réécrit sa source pour que les réponses retrouvent le chemin du retour.

Un changement d'adresse ne casse que la seconde décision, et c'est pourquoi le symptôme se lit comme "connecté mais sans Internet". Cela explique aussi pourquoi les vérifications habituelles côté client semblent saines : le handshake s'achève, le client reçoit une adresse, et même un ping vers l'adresse tunnel du serveur peut répondre. Des heures sont perdues côté client pour une panne qui vit de l'autre côté, et c'est pourquoi la table des règles est le premier endroit où regarder.

Lisez la règle et ses compteurs avant de modifier

Listez les règles de traduction avec leurs compteurs et comparez la source configurée aux adresses que l'hôte détient réellement. Une règle réécrite vers une adresse morte montre généralement du trafic à l'aller, parce que les paquets l'atteignent et sont traduits, et rien au retour.

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

Vérifiez trois champs pendant que vous y êtes : le pool dans la correspondance de source, l'interface de sortie si la règle en nomme une, et l'exclusion qui empêche le trafic entre tunnels d'être réécrit. Cette exclusion se perd facilement lors d'une modification, et la perdre fait croire que le trafic entre pairs fonctionne alors que ses réponses prennent un chemin étrange.

Si les compteurs restent à zéro, les paquets n'atteignent jamais cette règle et l'adresse n'est pas le problème actuel. Cherchez une règle concurrente plus haut dans la chaîne, ce qui arrive quand quelqu'un ajoute un remplacement au lieu de modifier l'original. Comparez les numéros de règle à la sortie que vous avez notée il y a une minute. L'ordre fait partie de la configuration, ce n'est pas un détail cosmétique.

Remplacez la source, ou cessez d'en nommer une

Quand l'hôte a une adresse stable, remplacez la règle sur place plutôt que d'en ajouter une autre. Le remplacement par numéro de règle conserve l'ordre dont dépend le reste de la chaîne.

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

Quand l'adresse est attribuée dynamiquement, ne nommez aucune source et laissez le noyau choisir l'actuelle depuis l'interface de sortie. Cette variante survit au déménagement suivant sans modification, au prix de cacher quelle adresse a été utilisée.

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

Confirmez que le transfert IPv4 est toujours activé via une configuration gérée, puis rendez la règle persistante avec le mécanisme propre de la distribution. Une modification faite uniquement dans le noyau en cours revient au prochain redémarrage, généralement pendant une fenêtre de maintenance que personne ne relie au changement.

Deux façons de rater le remplacement

Traduire le pool vers l'adresse tunnel du serveur au lieu de son adresse LAN renvoie les réponses directement dans le tunnel, où elles sont routées vers un client qui ne les a jamais demandées. La connexion se bloque d'une manière qui ressemble à une boucle de routage, parce que c'en est une.

Empiler une seconde traduction au-dessus de l'ancienne est l'autre erreur. La première règle correspondante l'emporte, donc l'entrée périmée continue de traiter les paquets jusqu'à sa suppression, et les compteurs de la nouvelle règle restent à zéro pendant que tout le monde accuse le remplacement. Supprimez le doublon avant d'ajouter quoi que ce soit. Relisez ensuite la liste et confirmez qu'exactement une traduction correspond au pool.

Si le tunnel transporte aussi IPv6, répétez toute la revue sur l'autre pile. Une route par défaut IPv6 sans traduction et sans préfixe routé échoue tout aussi silencieusement, et il est facile de l'oublier parce que tout ce qui est au-dessus semble identique.

Les services entrants ont besoin de la traduction inverse

Un service sur un client VPN qui doit être joignable de l'extérieur a besoin d'une traduction de destination, pas de source : le port public est réécrit vers l'adresse tunnel du client avant d'entrer. Le chemin de transfert a alors besoin d'une règle explicite autorisant ce trafic.

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

Ne traduisez jamais le port qui porte le tunnel lui-même, car cette réécriture interrompt la connexion qui maintient le service joignable. Gardez le port du tunnel entièrement hors des règles de destination. Vérifiez ensuite des deux extrémités : compteurs sur la nouvelle règle, une courte capture sur l'interface du tunnel et une requête vers une adresse à l'intérieur du tunnel avant d'essayer la publique.