eth0:0 est une étiquette, pas un périphérique : corrigez la règle SNAT

Une règle NAT censée donner à un pool de clients VPN sa propre adresse publique reste à zéro paquet, tandis que le même pool continue de sortir avec la mauvaise source. La règle ne se trompe généralement pas sur l’adresse ; elle se trompe sur l’interface. -o eth0:0 désigne un périphérique qui n’existe pas, car eth0:0 est une étiquette attachée à une adresse sur eth0. Regarder les compteurs est le moyen le plus rapide de le confirmer, et la correction est plus petite que l’enquête ne le suggère.

Vérifiez comment le noyau nomme le périphérique

Lisez les deux vues séparément avant de changer quoi que ce soit :

ip link show
ip address show dev eth0
ip route get 203.0.113.20

La liste des liens montre les interfaces. La liste des adresses peut montrer une seconde adresse IPv4 portant l’étiquette eth0:0, et le périphérique de cette adresse reste eth0. Le manuel des adresses d’iproute2 traite l’étiquette comme un nom de l’adresse, pas comme un second lien, et c’est précisément la distinction sur laquelle repose tout le problème.

L’histoire explique la confusion. L’ancienne ifconfig eth0:0 syntaxe ressemblait vraiment à une nouvelle interface, et les scripts de cette époque y font encore référence. Sur un système actuel, l’alias est une étiquette sur une adresse, et rien dans le chemin de routage ou de netfilter ne le traite comme un point de sortie distinct.

Vérifiez ce que la règle a réellement intercepté

Lisez les compteurs avec la liste des règles plutôt que de mémoire :

iptables -t nat -L POSTROUTING -v -n --line-numbers

Une règle dont le compteur de paquets reste à zéro alors que du trafic correspondant circule n’est pas évaluée, et une condition d’interface de sortie qui nomme eth0:0 est une cause fréquente. Le périphérique de sortie choisi par la route est eth0, donc une condition qui cherche un autre nom ne devient jamais vraie, quelle que soit l’adresse source choisie par le noyau.

Changez la condition pour le vrai périphérique et laissez l’étiquette en dehors. Si vous devez distinguer deux pools de clients qui partagent ce périphérique, distinguez-les par préfixe source, pas par un nom d’interface qui ne peut pas exister. Deux règles avec des correspondances -s qui ne se chevauchent pas sont lisibles et testables ; une règle avec un périphérique fictif n’est ni l’un ni l’autre. Donnez à chaque règle un commentaire qui nomme le pool, car dans six mois le préfixe seul ne dira à personne pourquoi elle est là.

Vérifiez la route qui a choisi le périphérique

Le NAT de postroutage s’exécute après que la route a déjà choisi une interface de sortie, donc l’interface de la règle doit être celle que la route a choisie. Interrogez le noyau directement avec ip route get pour une adresse client représentative et lisez à la fois le périphérique et la source qu’il rapporte.

Si la réponse nomme eth0, la partie interface de la règle est réglée. Si elle nomme un périphérique tunnel, le paquet n’atteint jamais la règle que vous modifiez, et la recherche se déplace vers la table de routage et ses priorités. Une règle qui ne correspond jamais parce que le paquet est parti ailleurs ressemble, dans la sortie des compteurs, à une règle dont le périphérique est mal orthographié. Confirmez lequel des deux vous avez avant de modifier quoi que ce soit, car le second demande un changement de routage et non un changement de texte.

Choisissez la source traduite délibérément

Une fois le périphérique correct, l’adresse source est une décision distincte. Ce n’est qu’un pool IPv4 illustratif et une adresse d’exemple :

iptables -t nat -A POSTROUTING -s 10.8.1.0/24 -o eth0 \
  -j SNAT --to-source 203.0.113.20

Écrire une adresse dans --to-source ne fait pas que quelqu’un la route vers vous. Le fournisseur en amont ou le propriétaire de l’adresse doit livrer les réponses de cette adresse à cet hôte, et l’adresse doit être une que vous êtes autorisé à utiliser. Si ce n’est pas le cas, la règle correspondra et traduira, et les réponses iront quand même ailleurs.

Changer l’adresse source n’est pas la même chose que changer le lien montant. Quand le vrai besoin est un chemin physique différent, la politique de routage doit d’abord sélectionner ce chemin ; SNAT réécrit ensuite la source sur le périphérique que la politique a choisi. Ajouter des étiquettes à eth0 ne fournit ni la route ni l’autorisation.

Vérifiez avec une connexion que vous venez d’ouvrir

Ouvrez une nouvelle connexion client au lieu de réutiliser une connexion existante. Le suivi de connexion conserve la traduction qu’il a enregistrée au démarrage du flux, donc une ancienne session peut continuer d’utiliser l’adresse source précédente et faire paraître cassée une nouvelle règle correcte. Regardez le compteur augmenter, puis observez la source traduite sur le fil ou à l’autre bout.

Pour plusieurs pools qui partagent une interface, donnez à chacun une correspondance source explicite et sa propre adresse de traduction, gardez-les dans la configuration gérée du pare-feu et notez l’ordre dans lequel ils sont évalués. Puis consignez ce que vous avez vérifié : le périphérique issu de ip route get, le compteur qui a bougé et la source vue par le côté distant. Cette consignation répond au prochain rapport sans répéter la confusion de l’alias.