VPN site à site basé sur les routes ou sur les politiques : ce qui diffère

Les deux conceptions protègent le même trafic avec la même machinerie IPsec, et elles diffèrent par ce qui décide quel paquet entre dans le tunnel. Dans une connexion basée sur les politiques, ce sont les sélecteurs de trafic négociés qui font ce travail ; dans une connexion basée sur les routes, c’est une route pointant vers une interface de tunnel. Confondre les deux produit le fil de support familier où le tunnel se déclare établi alors que l’application n’atteint rien. La distinction compte surtout lorsque vous ajoutez un réseau, exécutez un protocole de routage ou déboguez un chemin qui sort discrètement par la mauvaise sortie.

Deux façons de décider ce qui entre dans le tunnel

Un VPN basé sur les politiques construit une politique de sécurité qui correspond aux préfixes source et destination, puis chiffre tout ce qui correspond. Le pair doit négocier des sélecteurs compatibles, si bien que la portée effective finit par être l’intersection de ce que les deux côtés ont proposé. Rien en dehors de cette intersection n’est protégé, quoi qu’en dise la table de routage.

Un VPN basé sur les routes crée une interface qui représente le tunnel et laisse la table de routage y envoyer le trafic. Le démon IKE installe toujours l’état et la politique par interface, et c’est le détail que l’on saute lorsqu’on décide que les routes ont remplacé le chiffrement. Les deux conceptions chiffrent avec IPsec ; seul le mécanisme de sélection diffère.

Lisez la comparaison ci-dessous comme un ensemble de signatures de panne plutôt qu’un tableau de scores, car aucune colonne ne gagne en soi.

Basé sur les politiques : le sélecteur est le contrat

Les sélecteurs se négocient, ils ne se configurent pas seulement. Proposez 10.10.0.0/16 d’un côté et 10.10.1.0/24 de l’autre, et l’association couvre ce sur quoi la négociation s’est arrêtée tandis que tout autre hôte reste dehors.

Lisez l’état installé plutôt que le fichier de configuration. Sur un pair Linux, les tables du noyau sont la vérité de base, et elles montrent ce qui a survécu à la négociation. Une politique qui nomme les bons préfixes sans état correspondant signifie que l’association ne s’est jamais montée. Un état associé à une politique pour le mauvais préfixe est le problème inverse, et il produit le tunnel qui semble sain alors qu’un sous-réseau n’atteint rien.

sudo ip xfrm state
sudo ip xfrm policy
sudo swanctl --list-sas

Comparez les deux sorties aux préfixes que vous croyez protéger. Cette seule comparaison résout la plupart des signalements de tunnel fonctionnel avec un serveur injoignable. Elle indique aussi quel pair modifier, car l’écart n’est généralement visible que dans un sens.

Basé sur les routes : l’interface est le contrat

Une interface XFRM donne au tunnel un nom et une identité, et le trafic l’atteint parce que la table de routage le dit. Plusieurs préfixes distants deviennent alors un problème de routage plutôt qu’un problème de sélecteur, et un protocole de routage peut les annoncer. C’est le vrai gain, pas le chiffrement.

L’interface ne supprime pas le besoin de politique. Le démon installe des règles par interface liées à l’identité de l’interface, donc un paquet arrivant sur la mauvaise interface échoue quand même. Une adresse source que le pair n’acceptera pas échoue aussi, même avec une route parfaite. Basé sur les routes signifie que la route décide de l’entrée, pas que la politique a disparu.

sudo ip link add xfrm0 type xfrm dev eth0 if_id 42
sudo ip route add 10.20.0.0/16 dev xfrm0
ip -s link show xfrm0
ip route get 10.20.5.10

Surveillez les compteurs de l’interface une fois la route en place. Une route qui existe alors que les compteurs restent à zéro signifie que rien n’est apparié dans le tunnel, ce qui indique généralement un état manquant plutôt qu’une route manquante.

Où les deux conceptions divergent réellement

Ajouter un réseau est le test le plus propre du modèle qui vous convient. Une conception basée sur les routes ajoute une route et élargit au plus une fois le sélecteur, tandis qu’une conception basée sur les politiques modifie des paires de préfixes sur les deux pairs et renégocie. Deux sous-réseaux stables rendent cette modification triviale, et vingt en font un projet.

Aucun des modèles ne remplace un pare-feu, et les comparaisons s’arrêtent généralement avant ce point. Un sélecteur large ou une route large décide de ce qui est chiffré, pas de ce qui est autorisé.

Le comportement MTU diffère aussi en pratique. L’encapsulation réduit la charge utile disponible, et une interface basée sur les routes porte son propre MTU, donc fixer le MSS sur les deux passerelles évite le symptôme du trou noir où les petites réponses arrivent et les grandes disparaissent. Les tunnels basés sur les politiques rencontrent le même mur de l’autre côté, car un sélecteur ne dit rien de la taille des paquets. Réglez la fixation délibérément au lieu de blâmer le pair.

Migrer sans perdre la route de retour

Consignez les paires de préfixes existantes avant de changer quoi que ce soit, puis déplacez un chemin d’application et suivez-le de bout en bout. Un tunnel qui s’établit n’est pas un tunnel qui transfère, et la différence apparaît dans le sens de la réponse.

Lorsque les pairs se connectent mais que les hôtes du LAN n’y arrivent pas, inspectez la route de retour et l’adresse source que l’hôte distant utilisera. Un hôte à deux interfaces peut répondre depuis la mauvaise, et aucun changement de sélecteur ne répare cela. Capturez le trafic aux deux extrémités avant de modifier les algorithmes.

ip route get 10.20.5.10
sudo tcpdump -ni any host 10.20.5.10 and icmp
sudo swanctl --list-conns

Gardez un chemin d’administration qui ne dépend pas du tunnel pendant que vous travaillez. Le retour en arrière est plus facile quand l’accès de la passerelle ne repose pas sur la connexion que vous déboguez.