Sortie séparée : pool VPN sur usb0, trafic de la passerelle sur eth0

Les clients se connectent et s’authentifient, puis leur trafic sort par le mauvais lien montant, car la seule route par défaut de la machine appartient à la passerelle elle-même. Remplacer cette route par défaut casserait les mises à jour et l’accès d’administration de la machine, la sélection doit donc être plus étroite que « tout le trafic ». La forme qui fonctionne est une règle de politique basée sur l’adresse source interne du pool de clients, pointant vers une seconde table de routage qui possède le WAN alternatif. À partir de là, la liste de contrôle porte sur la complétude et le comportement en cas de panne, pas sur la règle elle-même.

Vérifiez que l’adresse source survit jusqu’à la décision de routage

Une règle de politique qui correspond à une plage source ne se déclenche que si le paquet porte encore cette source au moment de la consultation. Le trafic de clients transféré le fait, tant que rien en amont ne l’a réécrit avant le routage. Le trafic généré par la passerelle ne le fait pas, et c’est précisément pourquoi sa propre route par défaut peut rester où elle est.

C’est ici que les tests locaux trompent. Un curl lancé sur la passerelle est un flux généré localement avec l’adresse de la passerelle, il prend donc la table principale et ne prouve rien sur le chemin du client. Testez depuis un client connecté, ou générez du trafic avec une source qui appartient réellement au pool.

Commencez par écrire les valeurs réelles : le préfixe du pool, l’interface de tunnel qui le porte, l’adresse et le prochain saut du second WAN, et le numéro de table que vous comptez utiliser. Effacez les anciennes règles de toute tentative précédente avant d’en ajouter de nouvelles, car des règles dupliquées à des priorités différentes produisent des pannes qui semblent aléatoires.

Construisez une table sélectionnée complète

Une table n’est pas une route par défaut avec un ami. Elle a besoin d’assez de routes pour que chaque consultation se résolve en son sein, y compris la route connectée du sous-réseau WAN pour que le prochain saut soit joignable. Pour un pool 10.77.0.0/24 sur tun1, une adresse WAN 203.0.113.20/24 avec prochain saut 203.0.113.1, et la table 600 :

ip -4 route replace 203.0.113.0/24 dev usb0 src 203.0.113.20 table 600
ip -4 route replace 10.77.0.0/24 dev tun1 table 600
ip -4 route replace default via 203.0.113.1 dev usb0 table 600
ip -4 rule add priority 1500 from 10.77.0.0/24 lookup 600

La règle se place à une priorité inférieure à toute règle fourre-tout existante, de sorte que les clients correspondants atteignent d’abord la table 600 et que tout le reste retombe sur la table principale. La référence ip-rule décrit entièrement le modèle de consultation ordonnée et la syntaxe du sélecteur.

Pensez ensuite à ce que la table ne contient pas. Une destination qui n’a de route que dans la table principale, comme un sous-réseau d’administration joignable par eth0, ne sera pas trouvée dans la table 600 et ne retombera pas sur la principale dès qu’une route par défaut y existe. Si ces chemins comptent, ajoutez-les explicitement à la table sélectionnée, ce qui est généralement la bonne réponse pour une table de sortie VPN.

Gardez le trafic propre de l’écouteur hors de la politique

L’écouteur OpenVPN a sa propre connexion externe, portée par le lien montant par lequel le client l’a atteint. Ce trafic doit conserver le chemin de retour avec lequel il est arrivé, et une règle large couvrant l’adresse publique du serveur ou toute l’interface de tunnel peut l’entraîner dans la table alternative. Limitez la règle au pool interne et à rien d’autre.

Le filtrage du chemin inverse mérite un coup d’œil pour la même raison. Lorsque les réponses aux clients sortent par usb0 alors que la requête est arrivée par un autre lien, un réglage rp_filter strict peut rejeter des paquets que la politique de routage considère comme valides. Vérifiez les valeurs sysctl effectives sur les deux interfaces avant de conclure que la règle a échoué.

L’ordre compte aussi par rapport à tout le reste sur la machine. Les ponts Docker, un second VPN et toute règle préexistante d’une image de fournisseur ajoutent des priorités, donc lisez la liste complète des règles au lieu de supposer que la priorité 100 est seule.

Faites concorder le transfert et la traduction avec la route

Le routage choisit un lien montant ; il n’accorde pas la permission de transférer. Le noyau doit avoir le transfert IPv4 activé, et le pare-feu doit accepter la direction du client vers le WAN et le trafic de retour. Une table correcte avec une chaîne FORWARD qui rejette le flux produit le même symptôme qu’une route absente, c’est pourquoi les deux sont vérifiés dans la même passe.

Si le second WAN n’achemine pas un pool privé vers vous, traduisez la source sur cette sortie. Pour une interface à adresse dynamique, le choix habituel est une règle masquerade étroite limitée au pool et à l’interface :

iptables -t nat -A POSTROUTING -s 10.77.0.0/24 -o usb0 -j MASQUERADE

La portée compte ici plus que la cible. Une règle masquerade qui correspond à n’importe quelle interface sortante réécrira aussi le trafic qui sort correctement par eth0, ce qui masque les erreurs de routage au lieu de les corriger. La traduction s’exécute après la décision de routage, elle ne peut donc jamais réparer un paquet envoyé sur le mauvais lien montant.

La surcharge du tunnel demande aussi attention dès que les chemins diffèrent. Si les clients négocient un MSS TCP élevé et que le WAN alternatif a une MTU plus faible ou un tunnel à l’intérieur, les grands segments se bloquent tandis que les petits fonctionnent. Limiter le MSS sur le chemin de transfert transforme cela en comportement prévisible plutôt qu’en blocage intermittent.

Décidez de ce qui se passe quand usb0 disparaît

Une table vide n’est pas un état de fermeture en cas de panne. Si la route correspondante disparaît, la consultation continue vers la règle suivante, atteint la table principale et prend la route par défaut d’eth0. Le trafic censé sortir par le second WAN sort discrètement par le premier, ce qui, dans un déploiement routé par politique, est généralement le résultat que vous voulez le moins.

Là où ce repli est inacceptable, ajoutez une route terminale explicite dans la table 600, comme une route par défaut blackhole, ou supprimez le pool dans le pare-feu tant que l’interface est hors service. L’un ou l’autre est une décision que vous pouvez écrire ; le silence ne l’est pas.

La persistance est le dernier point. Celui qui possède les deux liens, que ce soit le gestionnaire de réseau, un script de répartiteur ou le cycle de vie de la connexion, doit recréer les routes et la règle à chaque reconnexion sans ajouter de doublons. Vérifiez avec une requête depuis un client réel et une requête distincte depuis la passerelle, confirmez la sortie observée sur les deux, puis retirez le second WAN et regardez lequel des deux résultats que vous avez conçus se produit réellement. IPv6 a besoin de sa propre table, règle et traduction ; la règle IPv4 ci-dessus n’en dit rien.