Pourquoi BGP sur un VPN ne contrôle pas votre chemin de sous-couche

Deux sites appairent BGP à travers un tunnel IPsec, apprennent leurs préfixes respectifs, et le schéma est réétiqueté en contrôle de chemin. C’est cette étiquette qui marque le début de la confusion. La session échange bien la joignabilité et applique bien une politique, mais elle n’a pas voix au chapitre sur le fournisseur, le câble ou le routeur qui transporte les paquets chiffrés. J’ai vu une équipe reconstruire un tunnel qui fonctionnait parce qu’elle s’attendait à ce qu’un changement de route BGP déplace le trafic vers un autre chemin de fibre que la session n’aurait jamais pu influencer.

Ce que les gens supposent qu’une session achète

L’essentiel de l’attente vient de l’allure d’un changement de route en laboratoire. Vous annoncez un préfixe par le tunnel, le côté distant l’installe et le trafic se déplace. La même séquence se produit sur un routeur qui dispose réellement de leviers d’ingénierie du trafic, si bien que les deux se confondent. En laboratoire, les deux sites partagent généralement un seul lien d’accès, et c’est exactement pourquoi la différence ne s’y montre jamais.

BGP est un protocole de joignabilité. Il indique à un pair que vous pouvez livrer des paquets pour un préfixe et laisse chaque côté classer les offres qu’il reçoit. C’est réellement utile à travers un tunnel : les préfixes apparaissent et disparaissent au gré des sites, et vous pouvez refuser une plage sans écrire une route statique sur chaque équipement de bord. Ce qu’il ne fait pas, c’est placer les routeurs d’un fournisseur sous votre contrôle.

La sous-couche porte l’en-tête extérieur. Votre extrémité de tunnel envoie des paquets chiffrés vers une adresse de pair, et le réseau entre ces deux adresses les achemine avec les routes que ses opérateurs ont installées. Rien dans la session BGP ne change cette décision, sauf si le même fournisseur expose un service pris en charge qui le fait.

Ce que la session transporte réellement

Le locuteur BGP ouvre une connexion TCP vers le port 179 de son pair, en utilisant les formats de message et les attributs de chemin définis dans RFC 4271. Lorsque l’adresse du pair se trouve à l’intérieur du tunnel, le tunnel doit être monté et cette adresse joignable avant même que la session puisse démarrer. Un échange IKE terminé n’est pas un voisin BGP. Les implémentations IPsec basées sur les routes ne laissent passer le trafic qu’une fois qu’une route de tunnel correspondante existe, et celle basée sur la politique a besoin de l’adresse du pair dans le sélecteur protégé. Inverser cela produit l’état classique où le tunnel est vert et la session reste inactive.

Une fois la session montée, la politique décide de ce qui la traverse. Les listes de préfixes, les filtres AS-path, un plafond de préfixes maximal et une décision explicite sur les routes par défaut constituent le minimum, et ils s’appliquent dans les deux sens. Un pair qui accepte tout ce qu’il reçoit peut vous remettre une route par défaut qui remplace discrètement l’accès Internet local. Les deux sens ont besoin de listes distinctes, car ce que vous acceptez d’un pair et ce que vous lui annoncez sont deux décisions différentes.

router bgp 65010
 neighbor 10.255.0.2 remote-as 65020
 address-family ipv4 unicast
  neighbor 10.255.0.2 prefix-list SITE-B-IN in
  neighbor 10.255.0.2 prefix-list SITE-B-OUT out
  neighbor 10.255.0.2 maximum-prefix 50

Ensuite, le MTU mord. L’encapsulation réduit la charge utile, si bien qu’une grande mise à jour peut bloquer une session qui semble parfaitement établie : le pair reste monté, les préfixes n’arrivent jamais et rien d’évident n’apparaît dans le journal. Limitez le MSS TCP sur l’interface du tunnel, ou fixez un MTU de tunnel avec de la place pour la surcharge, avant d’accuser les filtres.

Où vont encore les paquets extérieurs

Les paquets chiffrés d’un site à l’autre sortent par ce que le routeur local sélectionne pour l’adresse publique du pair. Si les deux sites achètent du transit chez le même fournisseur, traversent la même installation métropolitaine, ou si un côté se trouve derrière un NAT d’opérateur, le tunnel ne survit à une panne du fournisseur que par accident. Compter les icônes de tunnel dans un outil de supervision ne vous dit rien de tout cela.

La sélection de route et l’installation du transfert sont aussi des événements distincts. Un préfixe peut figurer comme le meilleur dans la table BGP et manquer malgré tout dans la table de transfert, parce que le saut suivant n’est pas résoluble ou qu’une route plus spécifique l’emporte. Quand quelqu’un signale que BGP a appris le préfixe mais que le trafic ne circule pas, la question utile est de savoir s’il est installé et vers quel saut suivant il pointe.

La réponse honnête pour une revue de conception est une liste de dépendances partagées : circuit d’accès, fournisseur amont, installation et tout équipement avec état sur le chemin de retour. Une session à travers le tunnel ne peut pas supprimer une dépendance au-dessus de laquelle elle ne se trouve pas.

Trois décisions qu’il vaut la peine de séparer

Quand une conception mélange ces éléments, chaque conversation sur une panne tourne en rond. Séparez-les d’abord sur le papier, puis rattachez chacune à l’équipement qui l’applique réellement.

Chaque ligne a un propriétaire différent. La première est une négociation, la deuxième est de la configuration sur vos équipements, la troisième est surtout le réseau de quelqu’un d’autre. Une demande de changement qui nomme la ligne concernée est bien plus facile à approuver qu’une qui dit problème BGP.

Modes de défaillance pour lesquels il vaut la peine de planifier

Accepter la route de synthèse d’un pair est la blessure auto-infligée la plus courante. Quelqu’un annonce un agrégat court pour simplifier l’échange, le côté distant l’accepte, et le trafic des plages qui ne sont pas derrière le tunnel suit le tunnel et meurt. Filtrez sur les préfixes exactement attendus, ou utilisez une liste de préfixes avec les bonnes bornes, et n’acceptez jamais un agrégat nu parce qu’il donne à la session un air bien tenu.

Le moment du retrait est le second. La détection dépend des temporisateurs de maintien, de BFD si vous l’avez activé, de la détection de pair mort du tunnel et de la rapidité avec laquelle le côté distant cesse d’annoncer. Les sessions existantes sont un problème distinct : une nouvelle route peut rétablir de nouvelles connexions tandis que les sessions TCP établies continuent d’utiliser des adresses périmées, et les pare-feu avec état ou le NAT sur le chemin peuvent conserver des entrées qui ne correspondent plus. Mettez la reprise applicative dans les critères d’acceptation au lieu de supposer qu’un changement de route règle tout.

La troisième est l’asymétrie du chemin de retour. Le trafic peut arriver par le tunnel et revenir par un lien de fournisseur qui n’était pas censé le porter, ce qui se manifeste par de l’audio unidirectionnel, des poignées de main échouées ou un pare-feu qui jette les réponses. Vérifiez les deux sens séparément.

Ce qu’il faut écrire dans le contrat, et comment le vérifier

Demandez par écrit les préfixes autorisés : qui est habilité à originer chaque plage, si une route par défaut est permise et quelles familles d’adresses le service de tunnel prend en charge. La RFC 8212 a fait de la politique explicite d’import et d’export l’attente pour eBGP dans les implémentations qui la suivent, donc un pair qui s’appuie encore sur un comportement implicite d’acceptation totale mérite d’être interrogé.

Vérifiez ensuite depuis l’équipement plutôt que depuis le schéma. Commandes utiles sur des routeurs de style FRR :

show bgp summary
show bgp ipv4 unicast 10.10.0.0/16
show bgp ipv4 unicast neighbors 10.255.0.2 advertised-routes
show ip route 10.10.0.0/16

Ajoutez deux observations que la table de routage ne peut pas vous donner. Capturez sur l’interface extérieure pour confirmer quelle adresse les paquets encapsulés visent réellement, par exemple tcpdump -ni eth0 udp port 51820 pour un tunnel WireGuard, ou un filtre ESP pour IPsec. Puis tracez vers l’adresse publique du pair et comparez les sauts avec une trace à l’intérieur du tunnel ; si les deux suivent la même chaîne de fournisseur, votre redondance vit dans la politique de routage plutôt que dans le réseau.

Enfin, testez un retrait exprès. Coupez le tunnel pendant une fenêtre de maintenance, notez combien de temps le préfixe reste installé, ce qui arrive aux sessions existantes et si le côté distant retombe sur une route que vous accepteriez vraiment. Cet exercice en dit plus sur la conception que n’importe quel schéma.

Une route n’est pas une autorisation. Les préfixes que vous convenez d’échanger ne disent rien sur les utilisateurs qui peuvent atteindre tel service derrière le tunnel, alors gardez l’authentification, les services autorisés et les pare-feu des hôtes exactement là où ils étaient. Un pair joignable n’est pas non plus une permission de transit illimité ni d’originer des adresses arbitraires, et ce type d’autorité relève du contrat comme question commerciale, pas d’une ligne de politique BGP.

• Nommez les préfixes que chaque côté peut originer, et ceux qu’il ne doit jamais accepter.
• Limitez le MSS sur le tunnel et confirmez que les grandes mises à jour arrivent vraiment.
• Listez les dépendances partagées de la sous-couche, pas le nombre de tunnels.
• Chronométrez un retrait réel et notez ce que fait l’application.