La deuxième entrée VPN WAN échoue alors que la principale fonctionne toujours

Le tunnel principal reste actif, les utilisateurs continuent de travailler et le second circuit FAI reste inactif quoi que vous changiez. Vous avez publié une adresse pour le circuit de secours, pointé un nom dessus, peut-être ajouté une entrée de secours au client, et le client soit ne l'essaie jamais, soit s'authentifie puis meurt. Dans les cas que j'ai suivis, la fonction de basculement était généralement correcte ; ce qui manquait était l'une des cinq choses qui rendent une entrée utilisable. Un nom peut se résoudre vers l'adresse de secours alors que rien n'écoute sur cette interface, et un écouteur peut accepter une connexion alors que la réponse sort par la principale. Traitez chaque WAN comme une entrée distincte avec son propre contrat et la panne cesse de ressembler à un bug du client.

Chaque WAN a besoin de son propre contrat d'entrée

Notez cinq champs par WAN : le nom et l'adresse publics, le transport et le port, l'interface ou le contexte qui le termine, l'identité du pair qu'il doit présenter et par où sort la réponse. Deux circuits signifient deux ensembles complets. Si le second ensemble n'a pas d'interface de terminaison ni de chemin de retour, vous n'avez pas d'entrée de secours ; vous avez un enregistrement DNS qui décrit une intention.

L'équipement et sa version doivent aussi prendre en charge cette disposition. Un enregistrement DNS ne peut pas ouvrir un service sur une autre interface, et sur de nombreuses plateformes l'écouteur se configure par adresse plutôt que par appareil. L'IPsec basé sur l'interface sur un ASA lie les cartes cryptographiques et les groupes de tunnel à l'interface extérieure, donc un second lien montant a besoin d'une politique là où ces paquets arrivent réellement. Les conceptions basées sur les routes se comportent différemment : l'écouteur peut se lier à toutes les adresses ou à une adresse nommée, et ce choix décide si le FAI B peut répondre du tout.

Vérifiez que le second WAN répond vraiment

Testez depuis l'extérieur des deux circuits, pas depuis une machine derrière la passerelle, et testez exactement le nom qu'utilise le profil du client. Pour un écouteur TLS, le contrôle rapide est openssl s_client -connect ADDRESS:443 -servername vpn.example.com -showcerts exécuté depuis un hôte hors de votre réseau. Vous voulez une poignée de main terminée dont la chaîne correspond au nom du profil, pas simplement un port TCP qui accepte une connexion.

RFC 9525 explique ce que le client vérifie : l'identité qu'il comptait atteindre, comparée au certificat que le service présente. Une deuxième entrée qui renvoie le certificat de l'entrée principale, ou un certificat par défaut qui ne liste aucun des deux noms, échoue à ce test même si le port est ouvert et que le pare-feu l'autorise.

Deux schémas expliquent la plupart des échecs ici. Une connexion qui reste suspendue signifie généralement aucun écouteur sur cette interface, une règle d'accès qui n'autorise que les sous-réseaux principaux, ou un équipement opérateur devant le second circuit qui jette le port. Une poignée de main qui se termine avec la mauvaise identité signifie généralement un autre trustpoint, un hôte virtuel par défaut, ou une configuration copiée de la principale sans ajuster l'identité.

Suivez la réponse, pas seulement la requête

Le second WAN casse généralement au retour. Une requête arrive par le FAI B, l'équipement répond, et la réponse sort par la route par défaut du FAI A avec une adresse source que le client n'a jamais demandée. La traduction à état aggrave les choses : si le mappage a été construit pour l'interface principale, le paquet de retour manque la traduction ou porte une source que le pare-feu du client rejette. Les fournisseurs jettent aussi les adresses source qui n'appartiennent pas au circuit qu'ils vous ont fourni, et c'est pourquoi cela ressemble à un trou noir unidirectionnel plutôt qu'à une erreur de protocole nette.

Vérifiez la décision de routage pour le trafic issu de la deuxième entrée. La réponse doit sortir par l'interface par laquelle la requête est arrivée, ou au moins porter une adresse que le côté distant accepte comme appartenant à ce chemin. Sur les plateformes de routage par politique, cela signifie une règle liée à l'interface entrante ou à la source traduite, plus une instruction de traduction liée à chaque interface extérieure. Capturez simultanément sur les deux interfaces pendant que le client se connecte ; un SYN arrivant par le FAI B et le SYN-ACK sortant par le FAI A tranchent la question en une seule passe.

Donnez au client un moyen de connaître la deuxième entrée

Le basculement est une décision côté client, et chaque famille de clients découvre les alternatives différemment. Sur un ASA, la liste des serveurs de secours est fournie via les attributs webvpn de la politique de groupe, tandis que d'autres clients attendent une liste dans le profil ou un second profil manuel choisi par l'utilisateur. Le guide des politiques de connexion de Cisco décrit à la fois les informations configurées dans le client et celles fournies par la passerelle, et ces détails propres au protocole ne doivent pas être généralisés à chaque client ou mode de tunnel. Confirmez quel mécanisme le client déployé implémente avant de construire la deuxième entrée autour du mauvais.

Quel que soit le mécanisme, le client doit pouvoir résoudre le nom alternatif avant de perdre le chemin principal. C'est cette dépendance que les gens oublient : si le nom de secours est résolu par un résolveur accessible uniquement par le tunnel qui vient d'échouer, le repli ne peut même pas commencer. Publiez le second nom dans un résolveur qui répond localement ou par internet. Attendez-vous à une nouvelle authentification et à une nouvelle session applicative après le basculement, car le basculement client n'est pas un basculement avec état et les sessions longues n'y survivent pas.

Une adresse chez deux fournisseurs est un autre produit

Maintenir une seule adresse publique joignable par les deux circuits est un service de routage, pas une case à cocher du VPN. Il faut un espace d'adressage que les deux fournisseurs acceptent de porter, annoncé d'une manière que leurs réseaux acceptent, et c'est ce que fournit le multihoming avec un espace indépendant du fournisseur et BGP. Affecter l'adresse du FAI A à l'interface du FAI B n'y mène pas ; le paquet arrive dans un réseau qui n'a jamais annoncé le préfixe et il est jeté en amont.

Vous n'avez besoin d'aucun de ces éléments pour publier deux entrées. Si le client peut garder deux noms et basculer entre eux, deux entrées indépendantes suffisent, et vous évitez un numéro AS, un accord de peering et un préfixe qui doit être accepté partout. N'envisagez l'option d'adresse portable que lorsque vous avez vraiment besoin d'un point d'entrée stable que les clients ne peuvent pas reconfigurer pour le remplacer, ou lorsque le basculement par DNS avec son délai TTL est trop lent pour la panne contre laquelle vous concevez.

Que vérifier ensuite

Travaillez de l'entrée défaillante vers l'extérieur dans cet ordre : la seconde adresse répond-elle depuis l'extérieur, présente-t-elle l'identité attendue par le client, la réponse sort-elle par le chemin emprunté par la requête, et le client peut-il apprendre le nom avant d'en avoir besoin. Là où la réponse est non, corrigez cette couche et retestez avec le profil déployé plutôt qu'avec un hôte de test, car une poignée de main de laboratoire prouve moins qu'une connexion terminée du vrai client.

Tenez une fiche courte par WAN, avec adresse, port, interface de terminaison, nom du certificat, chemin de retour et règle de traduction, et revérifiez-la chaque fois qu'un circuit, un équipement NAT ou une version de client change. Les chemins de secours inactifs pourrissent en silence : rien n'alerte sur l'entrée que personne n'utilise jusqu'au jour où tout le monde en dépend.