Ajouter un second sous-réseau à un VPN site à site : deux chemins

Ajouter un second sous-réseau à un tunnel site à site qui fonctionne prend cinq minutes dans un design et presque tout un après-midi dans l’autre. Quand le tunnel installe des routes pour les préfixes que vous nommez, vous ajoutez une route et le trafic la suit. Quand il négocie une paire de sélecteurs fixe, le nouveau préfixe reste sans protection jusqu’à ce que les deux pairs s’accordent sur une paire concordante. Trois choses décident du cas : ce que la configuration de chaque pair décrit vraiment, si le trafic négocié est réduit à la plus petite paire concordante, et à qui appartient la route de retour du nouveau préfixe.

Lisez le noyau, pas l’étiquette d’état

Un tunnel qui annonce une connexion a installé au moins une association enfant, pas forcément celle que vous croyez. Sous Linux, le noyau montre ce qui est appliqué : ip xfrm policy liste les paires de sélecteurs et swanctl --list-sas (ou l’ancien ipsec statusall) montre ce que les pairs ont négocié, sélecteurs de trafic compris dans chaque sens. Si le nouveau préfixe n’apparaît dans aucune, il est sans protection, quoi que dise le fichier de configuration.

Comparez avec la table de routage. Dans un montage basé sur les routes, le périphérique du tunnel est le prochain saut des préfixes protégés. Un montage basé sur les politiques n’a souvent aucune route précise pour le sous-réseau distant, seulement la route par défaut, car la politique choisit le trafic et non la table.

Tunnels basés sur les politiques : les deux pairs doivent lister le nouveau préfixe

En termes strongSwan, le sélecteur vit dans local_ts et remote_ts sous la configuration enfant, successeurs de leftsubnet et rightsubnet. Le nouveau préfixe doit apparaître des deux côtés en miroir : ce que le site A appelle local, le site B l’appelle distant. Un écart produit rarement une erreur nette. Les pairs se réduisent à l’intersection, l’ancien préfixe continue de fonctionner et seul le nouveau échoue en silence.

swanctl --load-conns
swanctl --initiate --child <child-name>
swanctl --list-sas
ip xfrm policy

Sur pfSense ou OPNsense, cela veut dire une seconde entrée Phase 2 associant le nouveau sous-réseau local au nouveau distant, puis une application. Gardez l’ancienne entrée ; la remplacer déplace le sous-réseau d’origine au lieu de l’ajouter. Si une Phase 2 existante couvre déjà un super-réseau comme 0.0.0.0/0 ou une plage résumée, n’ajoutez pas d’entrée plus étroite à côté : des sélecteurs qui se chevauchent installent des politiques concurrentes et l’ordre d’évaluation décide laquelle gagne.

IKEv1 fait de chaque paire de sous-réseaux sa propre Phase 2, et un pair qui accepte une paire par échange abandonne les autres. IKEv2 peut porter plusieurs paires de sélecteurs dans un enfant, mais seulement si les deux implémentations les acceptent. La liste issue de swanctl --list-sas est la vérité ; ce que vous avez saisi est une demande.

Tunnels basés sur les routes : la route est la politique

Une interface XFRM ou un périphérique VTI porte le trafic selon la table de routage. Vous pointez le nouveau préfixe vers le périphérique sur les deux sites, et l’état lié à la transformation de l’interface s’applique. Aucune paire de sélecteurs à synchroniser, d’où une meilleure mise à l’échelle quand les sous-réseaux se multiplient. Le guide de forwarding de strongSwan détaille le côté noyau.

ip route add 192.168.60.0/24 dev xfrm0
ip route get 192.168.60.10

WireGuard pousse l’idée plus loin. AllowedIPs est à la fois la liste blanche cryptographique et, via wg-quick, l’entrée de la table de routage. Ajoutez le préfixe d’un seul côté et vous obtenez une poignée de main, des paquets sortants et du silence, car l’autre côté jette les paquets dont la source n’est pas dans sa liste. La forme wg set remplace toute la liste : redonnez les préfixes qui marchaient déjà, sinon vous les coupez :

wg set wg0 peer <PUBKEY> allowed-ips 192.168.10.0/24,192.168.60.0/24
ip route add 192.168.60.0/24 dev wg0

Cette seconde commande n’est pas facultative quand vous avez utilisé wg set au lieu de wg-quick. Le noyau accepte la nouvelle liste immédiatement, mais rien n’ajoute de route pour elle, donc le trafic généré localement sort toujours par la passerelle par défaut. C’est la raison la plus fréquente pour laquelle un nouveau sous-réseau WireGuard marche depuis l’hôte du tunnel et pas depuis un portable.

La route de retour échoue plus souvent que le tunnel

Les hôtes du nouveau sous-réseau distant doivent renvoyer les réponses par la passerelle VPN. Quand cette passerelle n’est pas leur routeur par défaut, la réponse part vers le routeur du LAN, qui la jette ou la transmet à internet avec une adresse source privée. Testez depuis un hôte de l’autre côté, pas depuis la passerelle : ip route get 10.30.20.15 sous Linux ou Find-NetRoute -RemoteIPAddress 10.30.20.15 sous PowerShell montre le prochain saut réellement utilisé. Si la réponse n’est pas le point de terminaison du tunnel, ajoutez-y une route statique pour le nouveau préfixe.

Le NAT source sur le site qui manque de route de retour est une alternative légitime et la façon dont beaucoup de déploiements hub-and-spoke évitent de toucher chaque serveur. Appliquez-le aussi au nouveau préfixe sur la passerelle du côté destination :

iptables -t nat -A POSTROUTING -s 10.30.20.0/24 -d 192.168.60.0/24 -j MASQUERADE

Le coût est réel. Les journaux distants cessent d’afficher des adresses sources individuelles et les règles de pare-feu liées au sous-réseau d’origine se réduisent à une seule règle pour la passerelle. Choisissez-le délibérément, pas parce qu’une route manquait.

Les pare-feux sont l’autre moitié de la route de retour. Les équipements par zones n’étendent pas automatiquement la zone d’une interface de tunnel existante à un nouveau sous-réseau, et une règle écrite pour l’ancien préfixe ne correspondra pas. Ajoutez le nouveau sous-réseau à la zone ou à la paire de règles dans les deux sens avant d’accuser IPsec.

Décidez en trois questions, puis vérifiez avec le trafic

La version rapide : la configuration du pair nomme-t-elle des préfixes (basé sur les politiques), ou le trafic est-il routé vers une interface (basé sur les routes) ? Les deux extrémités listent-elles le nouveau préfixe ? Existe-t-il un chemin de retour du nouveau sous-réseau vers la plage source d’origine ?

La vérification est le moment où la plupart des changements sont clos trop tôt. Un ping depuis la passerelle prouve peu, car la passerelle émet depuis elle-même et correspond souvent à une politique différente de celle d’un hôte. Pinglez depuis un hôte du nouveau sous-réseau, lancez ensuite l’application qui a motivé le changement et regardez les compteurs, pas une icône d’état.

tcpdump -ni any host 192.168.60.10 and (esp or udp port 4500)
ip xfrm state
wg show

Sur un tunnel basé sur les politiques, les compteurs de ip xfrm state doivent monter dans les deux sens ; des compteurs plats signifient que le paquet est routé mais non sélectionné. Sur WireGuard, wg show indique le transfert par pair, et une poignée de main sans octet reçu désigne la liste de l’autre côté ou sa route de retour.

Terminez en consignant le préfixe, le sélecteur ou la route du pair, la décision sur la route de retour et l’entrée de pare-feu avec le reste de l’inventaire du tunnel. Redémarrez ensuite une passerelle et testez de nouveau : une route ajoutée à la main disparaît, et la personne suivante ne devrait pas avoir à le redécouvrir.