Comment construire une politique de basculement VPN sur le routeur sans fuites

Le basculement a fonctionné exactement comme configuré, et c'était précisément le problème. Quand le tunnel principal est tombé, le routeur a déplacé la route par défaut vers le modem câble, les portables ont continué à naviguer et personne n'a appelé. Deux jours plus tard, quelqu'un a remarqué que le partage finances avait été joignable par le chemin internet ouvert pendant six heures. Une politique de basculement VPN sur le routeur n'est pas une astuce de routage ; c'est une décision sur ce que le trafic doit faire quand le chemin préféré a disparu, et cette décision doit exister avant que le chemin ne disparaisse.

Décidez du résultat avant de choisir le détecteur

Trois résultats sont généralement sur la table : envoyer les clients touchés par un tunnel de secours, les laisser utiliser le WAN ordinaire ou les bloquer purement et simplement. Notez lequel s'applique à quelle VLAN, quel SSID ou quelle classe d'appareils. Une seule règle plate “basculer vers le WAN” explique comment le partage finances ci-dessus a fini sur un chemin public.

Les trois ne sont pas interchangeables. Le repli sur le WAN garde un service d'assistance au téléphone tout en exposant les noms internes au résolveur local. Un tunnel de secours préserve la politique mais peut atterrir sur une adresse de sortie que l'autre côté n'accepte pas. Le blocage est correct pour une VLAN de paie et faux pour un réseau invité qui n'a jamais utilisé le tunnel.

Adaptez le détecteur à la panne que vous craignez vraiment

L'état du handshake, l'état de l'interface et le transfert utilisable sont trois signaux différents, et seul le dernier compte pour un utilisateur. Un pair WireGuard peut afficher un handshake récent pendant que l'amont du fournisseur jette les paquets dans un trou noir. OpenVPN le client peut rester sur “connecté” après que la route qu'il a poussée a cessé de se résoudre.

Sur pfSense, l'agencement pratique est un groupe de passerelles alimenté par dpinger, qui sonde une adresse de surveillance et marque une passerelle comme down quand la perte ou la latence franchit ses seuils. Pointez cette surveillance vers quelque chose au-delà du tunnel, comme un hôte du LAN distant ou une adresse publique que vous atteignez à travers lui. La pointer vers l'adresse de pair du tunnel lui-même mesure la partie dont vous savez déjà qu'elle est vivante.

Construisez le groupe pour que le secours reste le dernier recours

Utilisez des niveaux plutôt qu'une liste plate de membres. Primaire au niveau 1, tunnel de secours au niveau 2, WAN au niveau 3 uniquement pour les VLAN dont la politique l'autorise. Dans pfSense, cela se trouve sous System > Routing > Gateway Groups : ajoutez les deux passerelles, donnez-leur des niveaux différents, réglez Trigger Level sur member down plus packet loss, enregistrez, puis appliquez le groupe comme valeur par défaut de l'interface ou dans le champ Gateway des règles de pare-feu qui en ont besoin.

Pour une instance client OpenVPN sur pfSense 2.5 et ultérieur, le réglage Default Gateway de l'instance décide si le tunnel remplace ou non la route par défaut du système. Le routage de politiques par règle ne se comporte comme prévu que si la route que vous supposez exister est réellement installée. Vérifiez Status > Gateways après le changement au lieu de faire confiance à l'icône d'état du tunnel.

Deux réglages causent l'essentiel du battement. L'un est un intervalle de sonde plus court que la reconvergence du fournisseur lui-même. L'autre est un groupe où primaire et secours partagent un niveau, si bien que les deux restent éligibles en permanence. Ajoutez de l'hystérésis via des seuils de perte et de latence avant que vos utilisateurs ne ressentent les transitions à votre place.

Fermez les chemins que le tunnel n'a jamais possédés

D'abord les fuites DNS. Le résolveur continue de répondre sur le WAN et de transmettre par là, donc les noms continuent de se résoudre via le FAI pendant que le trafic est épinglé au tunnel. Restreignez les interfaces sortantes du résolveur, poussez le résolveur interne vers les clients et bloquez le port 53 pour tout le reste sur les VLAN uniquement-VPN.

IPv6 a besoin de sa propre décision. Un LAN double pile peut perdre le tunnel et conserver une route par défaut IPv6 globale qui fonctionne, si bien que les navigateurs préfèrent IPv6 et sortent par le WAN pendant qu'IPv4 semble parfaitement contenu. Soit vous routez IPv6 dans le tunnel, soit vous arrêtez d'annoncer un préfixe global pendant que le tunnel est en panne. Une demi-politique est pire que rien, parce qu'elle donne l'impression de fonctionner.

Puis le chemin de retour. Si la sortie de secours utilise une adresse source différente, l'autre côté doit savoir comment renvoyer le trafic, et tout état lié à l'ancienne adresse est déjà mort. Les sessions ouvertes quand le primaire est tombé ne migrent pas ; elles restent bloquées jusqu'à expiration et l'application décide quoi faire.

Testez la chute, le battement et le chemin de retour

Retirez le primaire avec du trafic inoffensif en cours, puis lisez quatre choses : Status > Gateways pour les états des membres du groupe, pfctl -ss pour les états encore épinglés à l'ancienne passerelle, un traceroute depuis un client pour le chemin de sortie et une requête au résolveur pour voir quel serveur a répondu.

Maintenant faites-le battre. Montez le primaire trente secondes, descendez-le trente, deux fois. Si le trafic suit chaque transition, les seuils sont trop serrés ou les niveaux sont faux. Corrigez cela selon votre calendrier, car sinon un fournisseur le fera selon le sien.

Enfin, confirmez que vous pouvez encore administrer le routeur. Gardez un chemin hors bande comme un câble console, une VLAN de gestion ou un modem cellulaire. Un test de basculement qui vous enferme dehors est un test que vous ne pouvez pas terminer, et un routeur injoignable ne peut pas revenir tout seul.

Avant de déclarer la politique terminée, vous devriez pouvoir répondre à quatre questions sans ouvrir de terminal : quelles VLAN peuvent utiliser le WAN pendant que le tunnel est en panne, ce que le détecteur surveille et combien de temps il attend, quels serveurs de noms et routes IPv6 bougent avec le chemin, et comment vous rentrez si le secours échoue aussi. Si une réponse est “ce que la valeur par défaut était”, la politique appartient encore au routeur et non à vous.