Deux tunnels IPsec actifs ont encore besoin d’un plan de chemin de retour

Ouvrez un terminal sur un poste de travail d’un site et connectez-vous à un serveur de l’autre. Cette unique conversation TCP doit maintenant traverser quatre passerelles au lieu de deux, et l’intéressant n’est pas de savoir si cela fonctionne un bon jour. L’intéressant, c’est quelle paire de passerelles l’aller a choisie, quelle paire le retour choisit, et qui détient l’état du flux pendant ce temps. Rien dans la table de routage ne décide cela à votre place.

Dessinez quatre passerelles avant de dessiner une route

Une conception doublement active avec deux pare-feu VPN indépendants par site, une paire par fournisseur, vous donne deux chemins utilisables et trois façons de les casser. Notez les adresses avant de configurer quoi que ce soit : le client tel qu’il est vu avant et après chaque passerelle, le serveur de même, le prochain saut aller et le prochain saut retour.

Cette table est la conception. Tout ce qui suit est une question de savoir si les équipements sont d’accord avec la table.

Comment le chemin aller est choisi

Une couche de routage multipath à coût égal répartit les flux sur les prochains sauts en hachant des champs d’en-tête, ce que RFC 2992 décrit en détail. Cette sélection peut être entièrement sans état : elle n’a besoin d’aucune entrée de suivi de connexion, seulement d’un hachage stable sur des champs inchangés. Gardez l’ensemble de chemins et les entrées de hachage constants et chaque paquet du flux choisit le même prochain saut.

La sélection par flux évite le réordonnancement que provoquerait un équilibrage paquet par paquet sur des liens à délais différents. Elle ne promet pas qu’un coût de routage égal signifie une latence mesurée égale, car ce n’est pas le cas. Et lorsque la composition des chemins change, les flux sont remappés, donc la survie de la connexion pendant une panne est une exigence distincte de la sélection de chemin.

Ce dont le chemin de retour a réellement besoin

Ici, la visite cesse d’être symétrique. Un hachage aller stable ne vous dit rien de ce que le site distant fera de la réponse. Si un pare-feu indépendant doit voir les deux directions de la connexion pour maintenir un état utile, une route de retour qui le contourne laisse un trafic qui ne correspond à rien. Deux boîtes avec des jeux de règles similaires ne sont pas un état partagé.

Confirmez le comportement bidirectionnel implémenté, ou écrivez une politique explicite qui maintient les frontières requises cohérentes. Une supposition ici se découvre pendant une panne, par des gens qui n’apprécient pas.

Là où la traduction décide pour vous

NAT est l’autre levier, et il est facultatif plutôt qu’obligatoire. Des identités traduites propres au chemin peuvent renvoyer les réponses vers la passerelle qui détient l’état, ce qui est une conception légitime. Elles ajoutent aussi des mappages, des routes de retour et un propriétaire de cet état, donc n’acceptez la charge que pour une exigence que vous pouvez énoncer à voix haute.

Si l’exigence est simplement que les deux chemins portent du trafic et que l’un ou l’autre survive à la perte d’un fournisseur, le multipath par flux avec un routage de retour cohérent est généralement la conception la plus petite.

Parcourez l’acceptation dans l’ordre

Testez dans cet ordre et consignez les adresses à chaque étape : une nouvelle connexion sur le chemin A et son chemin de réponse, la même chose sur le chemin B, puis la perte d’un fournisseur, puis la restauration. Pour chaque résultat, notez quels flux établis ont bougé, lesquels ont dû se reconnecter et où les nouveaux flux sont allés ensuite. Écrivez d’abord la valeur attendue, puis comparez-la à la capture. Deux tunnels établis ne prouvent rien de tout cela.

La conception est terminée quand la table que vous avez écrite correspond à ce que montre la capture, pas quand les deux tunnels sont montés.