Trois types de basculement OpenVPN sur pfSense, trois mécanismes

« Failover OpenVPN » sur pfSense recouvre au moins trois conceptions sans rapport entre elles, et chacune demande un mécanisme différent. Maintenir un tunnel en vie à travers une liaison internet de secours, se reconnecter à un autre serveur et diriger le trafic LAN vers un autre tunnel déjà établi ne sont pas des variantes d’une même fonction. Choisissez la panne contre laquelle vous vous protégez avant de construire un groupe de passerelles. Le groupe qui corrige l’une d’elles n’apporte rien pour les deux autres.

Nommez la panne avant de construire un groupe

Écrivez la phrase que vous voulez vraie pendant une panne. « Le tunnel se reconnecte par le WAN de secours » et « l’agence continue d’atteindre l’application par l’autre tunnel » sont deux phrases différentes. Seule la première concerne le transport.

Rapprochez-la ensuite d’un mécanisme. La perte du WAN local est un problème de choix d’interface, un point de terminaison distant mort est un problème de liste de connexions, et un chemin inutilisable à l’intérieur d’un tunnel établi est un problème de routage et de politique.

WAN local : déplacer le transport

Pour un client OpenVPN pfSense, l’agencement multi-WAN pris en charge sélectionne un groupe de passerelles approprié comme interface à laquelle le client se lie. C’est ce qui permet à la connexion extérieure de sortir par la liaison de secours quand la principale tombe. Cela ne change pas en soi la façon dont le trafic intérieur est routé.

Le côté serveur du même montage est distinct. Un serveur OpenVPN qui doit être joignable par plusieurs adresses publiques a besoin d’un écouteur et d’une politique d’entrée pour chacune de ces entrées, pas seulement d’un client capable de composer par deux liaisons. Une entrée publique qui fonctionne ne prouve pas que la seconde est configurée.

Une règle de routage par politique pour les paquets LAN transférés n’est pas le réglage qui déplace une connexion de transport VPN générée localement. Ce sont deux recherches différentes, et modifier l’une ne modifie pas l’autre.

Point de terminaison distant : un autre serveur

Un remote alternatif est une fonction de la liste de connexions. Le client essaie l’entrée suivante quand l’actuelle ne répond pas, ce qui est utile lorsqu’un hôte précis est en panne plutôt que lorsque votre propre liaison montante l’est. Les deux pannes se ressemblent depuis le bureau d’un utilisateur et exigent des corrections différentes.

Chaque candidat doit être un vrai substitut : authentification compatible, politique client compatible et accès aux mêmes ressources privées. Un second nom d’hôte qui résout vers la même infrastructure défaillante n’est pas une sauvegarde. Un serveur sans la route requise ne l’est pas davantage, aussi sain que paraisse son handshake.

Ce mécanisme ne fait pas non plus transmettre deux tunnels en même temps. Il remplace une connexion par une autre, séquentiellement, et l’écart entre les deux est visible pour tout ce qui tournait.

Chemin du tunnel : choisir une autre sortie

Quand deux tunnels sont déjà montés et que le trafic doit emprunter le plus sain, le mécanisme est une interface VPN affectée avec sa propre passerelle, plus une règle de politique explicite qui envoie le bon trafic vers elle. Un groupe de passerelles sur ces interfaces affectées peut exprimer priorité et supervision.

Cette conception relève de la sélection, pas de la reprise. Déplacer de nouvelles connexions vers le second tunnel ne dit rien des sessions déjà établies sur le premier, ni de la question de savoir si le côté distant acceptera la nouvelle adresse source. La traiter comme un mécanisme de reprise, c’est placer les attentes trop haut.

Si l’exigence est que les sessions existantes survivent, dites-le explicitement. La plupart des implémentations ne migrent pas un flux vivant d’un tunnel à l’autre, et concevoir comme si c’était le cas produit un basculement correct sur le schéma qui abandonne chaque connexion ouverte en pratique.

Sondes, NAT et la règle de fermeture par défaut

Une sonde doit tester quelque chose que le tunnel est censé fournir. Une cible qui répond depuis le pair du tunnel mais pas depuis le réseau applicatif au-delà signalera un état sain alors que les utilisateurs ne voient rien. Une cible de diagnostic injoignable signalera un état mort alors que le chemin est bon. Choisissez l’adresse délibérément et confirmez qu’elle n’est joignable que par le tunnel prévu.

Vérifiez le NAT sortant pour les deux sorties. Une traduction qui fonctionne sur la principale ne décrit pas l’adresse source du secours, et le réseau privé distant a besoin d’une route de retour qui corresponde à la source que vous présentez. Une traduction correcte sur un chemin peut être silencieusement fausse sur l’autre.

Décidez ensuite ce qui arrive au trafic qui ne doit jamais emprunter le WAN. pfSense a un comportement défini pour les règles dont la passerelle choisie est en panne, et une règle d’autorisation large plus tardive ou une route par défaut peut défaire votre intention. Écrivez le résultat bloqué comme une exigence, puis vérifiez-le en coupant le chemin.

Testez la perte et la reprise séparément, avec du trafic que vous êtes autorisé à générer, et surveillez trois choses à la fois : le WAN qui porte la connexion extérieure, le tunnel qui porte la requête applicative et le chemin que prend la réponse. Une paire d’indicateurs de passerelle au vert ne fait pas partie de ces trois. Le guide multi-WAN de Netgate décrit la liaison de transport et les alternatives client exportées dont cela dépend.