Nouvelles connexions sur une nouvelle sortie VPN, les anciens flux laissés tranquilles

Un drain planifié ne déplace que les flux non classifiés. Comparez-le à un changement de route, et voyez les marques, les tables et l’état conntrack qui le font tenir.

Deux sorties VPN saines, un long envoi déjà en cours et l’exigence que la connexion suivante utilise l’autre tunnel. Il y a deux façons de satisfaire cela, et une seule est sûre sur une passerelle en production. Échanger la route par défaut déplace chaque paquet, y compris ceux qui appartiennent à l’envoi. Un drain planifié change le choix pour les nouvelles connexions tout en laissant les flux suivis sur le chemin où ils ont commencé.

Deux façons de changer de sortie

L’échange de route est une seule commande et il est réversible en quelques secondes, c’est pourquoi il est utilisé pendant les incidents. Il est aussi sans distinction : les paquets de l’envoi existant sortent soudain par un autre tunnel, avec une autre adresse source publique et un état de traduction séparé.

Si l’extrémité distante suit les flux par adresse source, l’envoi peut simplement cesser d’être reconnu. Le drain évite cela en prenant la décision une fois par connexion et en la stockant, de sorte que l’ancien envoi conserve sa sortie jusqu’à sa fin. C’est toute la valeur de l’exercice : l’extrémité distante ne voit aucun changement qu’elle doive interpréter. Elle continue de recevoir des paquets qui correspondent à la connexion qu’elle connaît déjà.

Le coût est la complexité : deux tables de routage, un classifieur qui s’exécute au bon crochet et des marques qui doivent être coordonnées avec tout ce qui d’autre les utilise sur la machine.

Donnez à chaque sortie sa propre table

Réservez une table de routage par sortie et des valeurs de marque ou des bits distincts pour les deux choix. Chaque table a besoin des routes adaptées à son rôle, pas seulement d’un nom, et elle a besoin d’une issue d’échec délibérée pour le cas manquant. Une table vide qui retombe silencieusement sur la table principale — voilà comment le trafic sort par une sortie que personne n’a choisie.

ip rule add fwmark 0x10/0x10 table 101
ip rule add fwmark 0x20/0x20 table 102
ip route add default via 192.0.2.1 dev wg-a table 101
ip route add default via 198.51.100.1 dev wg-b table 102

Ajoutez une route blackhole à la fin de chaque table pour qu’une recherche sans correspondance échoue bruyamment au lieu de s’échapper vers un défaut que vous n’avez pas choisi.

Choisissez une fois, au premier paquet

Classifiez après que le suivi de connexion existe et avant la recherche de route qui compte. Pour une connexion LAN nouvelle et non classifiée, choisissez la sortie et enregistrez-la dans l’état de la connexion. Sur les paquets suivants, restaurez la valeur enregistrée dans la marque de paquet que lit le routage par politique.

La partie subtile est ce que nouveau signifie. Conntrack peut encore signaler NEW pour les premiers paquets et les retransmissions avant qu’une réponse soit vue, donc un classifieur qui ne se fie qu’à cet état peut écraser un choix qu’il a déjà fait. Vérifiez qu’aucune sortie n’est enregistrée pour la connexion avant d’en attribuer une.

nftables garde séparées les marques de paquet et de connexion, et le guide des métadonnées documente la copie explicite entre elles. Une marque de connexion ne devient pas d’elle-même la marque de paquet à laquelle votre règle correspond, et c’est la raison la plus fréquente pour laquelle un classifieur soigneusement écrit n’a aucun effet.

Limitez la restauration à la direction et au trafic voulus. Appliquer une marque de sortie internet aux paquets de retour peut envoyer les réponses vers la sortie au lieu du LAN, et le symptôme est une connexion unidirectionnelle qui ressemble à un problème de pare-feu. Lisez le chemin de réponse avant de toucher une règle de pare-feu, car le paquet est routé, simplement pas vers l’expéditeur.

Quatre phases d’un drain

  1. Préparez B sans toucher à A : routage, transfert, autorisation, NAT et chemin de retour. Installez sa table et sa politique de sélection via le propriétaire de configuration existant de la passerelle.

  2. Basculez le classifieur pour que les connexions nouvelles et non classifiées choisissent B, en préservant les choix enregistrés. Une transaction nftables atomique évite une fenêtre où l’ancien état doit être effacé.

  3. Laissez A actif pendant que ses flux se terminent. Son interface, sa table, sa sortie distante et ses mappages NAT font encore partie de ces flux, et modifier une règle NAT ne reconstruit pas les liaisons qui existent déjà.

  4. Retirez A lorsque la condition de drain est remplie, jugée d’après l’état des connexions et le comportement de l’application plutôt qu’un seul intervalle calme.

Ce qu’un drain ne peut pas promettre

Une requête de navigateur n’est pas une nouvelle connexion de transport ; le regroupement continue d’envoyer des requêtes sur l’ancienne. À l’inverse, un flux UDP peut vieillir hors de conntrack et un paquet ultérieur est classifié à nouveau. Le drain suit les flux suivis, pas l’idée qu’une application se fait d’une session.

Si A tombe avant que ses flux soient terminés, la marque enregistrée ne les sauve pas. Ils se reconnectent via B, ou ils ne se reconnectent pas du tout. Un drain planifié achète la continuité tant que le chemin d’origine est sain ; ce n’est pas une réplication d’état entre sorties indépendantes.

Vérifiez les deux moitiés

Lancez une connexion autorisée de longue durée avant le changement et une véritablement nouvelle après. Confirmez quel tunnel utilise chacune et quelle adresse source publique voit l’extrémité distante, puis vérifiez que le trafic de retour revient.

Ne videz pas la table conntrack pour faire apparaître le nouveau choix. Cela détruit exactement l’état que le drain est censé préserver, et cela transforme une migration maîtrisée en panne avec un test d’apparence propre.

Articles similaires