Deux passerelles IPsec sans IP partagée : ce que fait vraiment le basculement

Tuez la passerelle A pendant une réunion et regardez le tunnel revenir par B une minute plus tard ; la connexion fonctionne, l’appel vidéo peut-être pas. C’est la forme honnête du basculement à froid entre deux passerelles IPsec à adresses indépendantes. Le client choisit à nouveau un point de terminaison et construit une nouvelle relation, ce qui rétablit l’accessibilité sans transférer l’état cryptographique de l’ancienne session. Parcourir la séquence rend évidentes les promesses que la conception peut tenir.

Posons le décor : deux adresses, aucune IP flottante

La passerelle A répond à une adresse accessible et la passerelle B à une autre. Le client dispose d’un moyen approuvé de choisir B lorsque A a disparu, et aucune adresse extérieure partagée n’est revendiquée par les deux passerelles. Dans cette conception, une IP virtuelle désigne ce point d’entrée partagé, et non l’adresse interne attribuée à un client d’accès distant.

Cette définition compte parce que les deux idées se mélangent dans les tickets, et la correction de l’une n’est pas celle de l’autre. Un rapport indiquant que l’entrée partagée n’a pas suivi la passerelle décrit une conception. Un rapport indiquant que l’ordinateur portable a perdu son adresse interne décrit le bail du client. Propriétaires différents, journaux différents, réparations différentes.

Parcourons la panne : détecter, puis resélectionner

D’abord, quelque chose remarque que A a cessé de répondre. Cela peut être la détection de pair mort au niveau du tunnel, un protocole de routage qui retire un chemin, ou un délai d’application qui finit par forcer une reconnexion. Chacun a une échelle de temps différente, et le plus lent détermine généralement combien de temps les utilisateurs attendent.

Ensuite, le client sélectionne B par le mécanisme que le déploiement prend en charge : un second distant configuré, un nom DNS résolu vers une adresse saine, ou un routage qui préfère désormais un autre chemin. La sélection est une étape de politique, et elle doit exister avant la panne, sinon elle se produira par accident.

Ce que B peut hériter et ce qu’il ne peut pas

B peut partager avec A un modèle de configuration, une autorité de certification et une politique d’authentification. Il ne peut pas hériter des associations de sécurité actives. Les clés de session, les indices de paramètres de sécurité et l’état de séquence appartiennent à la relation qu’ont établie A et le client, et B n’en possède aucun.

Déplacer cet état entre passerelles est un vrai problème d’ingénierie, c’est pourquoi la documentation de haute disponibilité de strongSwan le traite comme une conception de cluster et non comme un indicateur de configuration. Une recette de cluster particulière n’est pas une réponse générique pour un réseau cloud, et la copier sans l’infrastructure de support achète de la complexité au lieu de la continuité.

Établir une nouvelle relation

B étant choisie, le client effectue un nouvel échange IKE : nouveaux nonces, nouvelles valeurs Diffie-Hellman, nouveaux identifiants pour les associations résultantes. L’authentification a de nouveau lieu chez B. Si la conception repose sur des identifiants de machine, la reconnexion peut être sans surveillance ; si elle exige un facteur humain, quelqu’un doit être présent pour que le basculement aboutisse.

Définissez cette expérience utilisateur avant la panne, pas pendant. Dites clairement ce que le client fera, combien de temps il essaiera et ce qu’il affichera lorsqu’il abandonnera, car la différence entre une minute de reconnexion et un appel au support est généralement de la documentation et un profil testé.

Conserver la même adresse interne aide les applications qui attendent une identité locale stable, et ne conserve pas leurs sessions. Les liaisons NAT expirent, les connexions TCP sont réinitialisées, et tout ce qui a son propre délai décide seul de réessayer.

Deux tunnels en parallèle sont une autre conception

Faire tourner les deux tunnels en même temps est un modèle valable lorsque les deux passerelles et la conception du routage le permettent. La sélection de route choisit alors le chemin actif, et le chemin de retour doit s’accorder, sinon le trafic sort par une passerelle et revient par l’autre sans état pour l’apparier.

Des politiques de tunnel qui se chevauchent ne créent pas à elles seules un basculement ordonné. Elles créent deux candidats, et quelque chose doit décider entre eux de manière déterministe, qu’il s’agisse d’une métrique de routage, d’une priorité de politique ou d’une préférence explicite dans le client.

Quelle que soit la forme choisie, écrivez le contrat : comment la panne est détectée, comment l’alternative est sélectionnée, quelle authentification elle exige et combien de temps la reconnexion devrait prendre. Une IP partagée peut simplifier la découverte, mais elle n’est pas synonyme d’état continu, et la disponibilité est une conception dans tous les cas.