Routes statiques ou protocole de routage sur un VPN site à site ?

Les deux options transportent des paquets entre sites, donc la décision ne porte pas sur le protocole le plus récent, et la taille du tunnel ne la tranche pas non plus. Trois conditions la tranchent : combien de préfixes changent et à quelle fréquence, si la conception a besoin d'un basculement automatique entre chemins, et combien de mécanique de plan de contrôle l'équipe peut exploiter à trois heures du matin. Répondez honnêtement et le choix se fait généralement de lui-même. Le reste de ce texte, c'est ce que coûte chaque réponse.

Trois conditions tranchent

La première condition est la volatilité. Une poignée de sous-réseaux stables avec une propriété claire se maintient à la main pendant des années, et chaque route reste une ligne que quelqu'un peut lire et vérifier. Des dizaines de préfixes qui bougent au gré des projets sont un autre problème, car chaque déplacement doit atteindre chaque équipement qui se souvient encore de l'ancien chemin.

La deuxième est le comportement en cas de panne. Quand un chemin de secours doit devenir actif sans qu'un humain le remarque, quelque chose doit détecter la panne et retirer la route. Le routage statique ne peut le faire que par suivi ou installation conditionnelle, et seulement pour les pannes que vous avez anticipées.

La troisième est l'appétit pour un second plan de contrôle. Un protocole de routage ajoute des sessions, de l'authentification, des filtres et une politique de sélection, et chacun de ces éléments demande de la supervision et un processus de changement. C'est un coût d'exploitation permanent, pas une tâche de configuration ponctuelle.

Le tableau sous le troisième paragraphe est la version courte, et les trois sections qui le suivent expliquent pourquoi chaque ligne se trouve là où elle est. Lisez les lignes face à votre propre nombre de sites avant de choisir, car une décision qui ignore le coût d'exploitation n'est qu'une demi-décision.

Ce que coûte réellement le routage statique

Une route statique doit être correcte des deux côtés du tunnel. Ajouter un sous-réseau signifie modifier la passerelle distante, la passerelle locale et généralement le chemin de retour, et oublier l'une de ces trois choses produit une panne unidirectionnelle qui ressemble à un bug applicatif. L'équipe applicative voit des délais d'attente tandis que l'équipe réseau voit une route présente et apparemment saine. Aucune des deux équipes n'a tort, et c'est pourquoi cette panne met si longtemps à être située.

Une entrée statique reste aussi installée après la disparition du chemin en dessous. À moins que la plateforme ne fournisse un suivi, la route continue de pointer vers un saut suivant qui ne transmet plus, et le trafic disparaît au lieu de basculer. Ce silence est la dépense que vous acceptez en choisissant l'option simple.

Écrivez la méthode de suivi à côté de chaque route, notez quelles pannes elle couvre, et gardez la liste avec la configuration du tunnel. Sinon, la prochaine panne est découverte par un utilisateur plutôt que par le réseau, ce qui est toujours la découverte la plus coûteuse.

Ce que coûte réellement le routage dynamique

Un protocole annonce de nouveaux préfixes, retire ceux qui sont inaccessibles et exprime une préférence entre chemins. C'est réellement utile quand plusieurs sites ou des tunnels redondants exigeraient sinon des modifications coordonnées à chaque changement. C'est aussi la raison pour laquelle le protocole peut vous surprendre au pire moment. Chacune de ces actions est un changement d'état que vous n'avez pas fait vous-même.

Il crée deux états qui peuvent diverger. Le tunnel peut être opérationnel alors que la session de routage est arrêtée, et la session peut être opérationnelle alors que ses annonces omettent le sous-réseau dont l'application a besoin. Les deux ressemblent à un réseau qui fonctionne à moitié, et aucun n'est visible depuis une page d'état du tunnel.

Les filtres et la politique font donc partie de la conception plutôt que d'être une réflexion après coup. Un protocole qui annonce tout finira par annoncer quelque chose de faux, et le mauvais préfixe voyage plus vite que la personne capable de le corriger. Écrivez les filtres avant l'activation de la première session, pour que la première annonce soit déjà délibérée.

Contrôlez ce que la session de routage peut dire

Décidez la liste de préfixes autorisés par pair et appliquez-la en entrée, car un filtre sortant ne peut pas empêcher un pair de vous envoyer une route par défaut. Les routes par défaut et les agrégats sont les erreurs coûteuses ici : ils peuvent remplacer silencieusement des chemins sans rapport par une seule entrée apprise qui paraît légitime. Rejetez-les explicitement, sauf si la conception les veut vraiment.

Écrivez le site propriétaire à côté de chaque réseau avant la montée de la première session, car cette correspondance est la source de la liste de filtres et non un ornement de documentation. Sans elle, la personne qui modifie un filtre doit deviner quel site devrait annoncer le préfixe.

La redistribution entre deux protocoles est l'endroit où les boucles commencent et où le même préfixe arrive deux fois avec des attributs qui ne se comparent pas proprement. Gardez la redistribution hors de la conception jusqu'à ce qu'une exigence précise l'impose, et si elle doit exister, marquez et filtrez les routes à la frontière.

Les interfaces de tunnel basées sur les routes rendent le routage dynamique plus facile à représenter, car le tunnel devient une interface avec des routes au lieu d'une politique qui associe des sélecteurs. Cela ne supprime pas la question du périmètre du pair : les sélecteurs IPsec doivent toujours autoriser le trafic que vous comptez router.

Testez le chemin de panne, pas le chemin heureux

Quoi que vous choisissiez, coupez un lien montant et confirmez que le trafic se déplace, ou qu'il échoue comme vous l'avez documenté. Une conception testée uniquement avec les deux chemins sains est une conception qui n'a pas été testée du tout. Mesurez la détection pendant que vous y êtes, car le chiffre que vous avez mesuré est celui que les utilisateurs vivront.

Confirmez ensuite le chemin de retour indépendamment, car le routage asymétrique sur un VPN est courant et invisible jusqu'à ce qu'un équipement à état rejette les réponses. Un flux qui fonctionne dans un sens ne prouve que la moitié du chemin.

Ordre du travail : comptez les préfixes, décidez comment les pannes doivent être détectées, vérifiez qui peut exploiter le protocole, contrôlez ce qui est annoncé, puis testez une panne de bout en bout. Chaque étape produit un fait dont la suivante a besoin.