Hoe je een VPN-failoverbeleid op de router bouwt zonder lekken

De failover werkte precies zoals geconfigureerd, en dat was het probleem. Toen de primaire tunnel wegviel, verplaatste de router de standaardroute naar het kabelmodem, laptops bleven browsen en niemand belde. Twee dagen later merkte iemand dat de financiële gedeelde map zes uur lang bereikbaar was geweest via het open internetpad. Een VPN-failoverbeleid op de router is geen routingtruc; het is een beslissing over wat het verkeer moet doen als het voorkeurspad weg is, en die beslissing moet bestaan voordat het pad verdwijnt.

Bepaal de uitkomst voordat je de detector kiest

Meestal liggen er drie uitkomsten op tafel: betrokken clients via een back-uptunnel sturen, ze de gewone WAN laten gebruiken, of ze helemaal blokkeren. Schrijf op welke geldt voor welke VLAN, SSID of apparaatklasse. Eén platte regel “overstappen op WAN” is de reden dat de financiële map hierboven op een openbaar pad belandde.

De drie zijn niet uitwisselbaar. WAN-fallback houdt een supportdesk aan de telefoon terwijl het interne namen blootlegt aan de lokale resolver. Een back-uptunnel behoudt het beleid, maar kan landen op een uitgangsadres dat de andere kant niet accepteert. Blokkeren is juist voor een loon-VLAN en verkeerd voor een gastnetwerk dat de tunnel nooit heeft gebruikt.

Stem de detector af op de storing die je echt vreest

Handshakestatus, interfacestatus en bruikbare doorsturing zijn drie verschillende signalen, en voor een gebruiker telt alleen het laatste. Een WireGuard-peer kan een recente handshake tonen terwijl de upstream van de provider pakketten in een zwart gat gooit. OpenVPN de client kan op “verbonden” blijven staan nadat de route die hij pushte niet meer opgelost werd.

Op pfSense is de praktische opzet een gatewaygroep die door dpinger wordt gevoed, die een monitoradres test en een gateway als neer markeert wanneer verlies of latency de drempels overschrijdt. Richt die monitoring op iets voorbij de tunnel, zoals een host op de externe LAN of een openbaar adres dat je erdoor bereikt. Hem op het peeradres van de tunnel zelf richten meet het deel waarvan je al weet dat het leeft.

Bouw de groep zodat de back-up de laatste optie blijft

Gebruik niveaus in plaats van één platte ledenlijst. Primair in niveau 1, back-uptunnel in niveau 2, WAN in niveau 3 alleen voor de VLAN's waarvan het beleid dat toestaat. In pfSense staat dit onder System > Routing > Gateway Groups: voeg beide gateways toe, geef ze verschillende niveaus, zet Trigger Level op member down plus packet loss, sla op en pas de groep daarna toe als interfacestandaard of in het Gateway-veld van de firewallregels die hem nodig hebben.

Voor een OpenVPN-clientinstantie op pfSense 2.5 en nieuwer bepaalt de Default Gateway-instelling van de instantie of de tunnel de systeemstandaardroute ueberhaupt vervangt. Policyrouting per regel gedraagt zich pas zoals je verwacht als de route die je aanneemt echt is geïnstalleerd. Controleer Status > Gateways na de wijziging in plaats van het tunnelstatuspictogram te vertrouwen.

Twee instellingen veroorzaken het meeste gefladder. De ene is een testinterval dat korter is dan de eigen herconvergentie van de provider. De andere is een groep waarin primair en back-up een niveau delen, zodat beide altijd in aanmerking blijven. Voeg hysterese toe via verlies- en latencydrempels voordat je gebruikers de overgangen voor jou voelen.

Sluit de paden die de tunnel nooit bezat

Eerst DNS-lekken. De resolver blijft antwoorden op de WAN en daarheen doorsturen, dus namen blijven via de ISP worden opgelost terwijl het verkeer aan de tunnel vastzit. Beperk de uitgaande interfaces van de resolver, duw de interne resolver naar de clients en blokkeer poort 53 voor al het andere op de alleen-VPN-VLAN's.

IPv6 heeft zijn eigen beslissing nodig. Een dual-stack-LAN kan de tunnel verliezen en een werkende globale IPv6-standaardroute houden, dus browsers geven IPv6 voorrang en gaan via de WAN naar buiten terwijl IPv4 volledig ingesloten lijkt. Of je routeert IPv6 de tunnel in, of je stopt met het adverteren van een globale prefix zolang de tunnel neerligt. Een half beleid is slechter dan geen, want het lijkt te werken.

Dan het retourpad. Als de back-upuitgang een ander bronadres gebruikt, moet de andere kant weten hoe het verkeer terug moet, en elke toestand die aan het oude adres vastzit is al dood. Sessies die open waren toen de primaire wegviel, migreren niet; ze blijven hangen tot ze verlopen en de applicatie beslist wat ze doet.

Test de uitval, het gefladder en de weg terug

Trek de primaire eruit terwijl er onschadelijk verkeer loopt, en lees dan vier dingen: Status > Gateways voor de lidstaten van de groep, pfctl -ss voor toestanden die nog aan de oude gateway vastzitten, een traceroute vanaf een client voor het uitgangspad en een resolverquery om te zien welke server antwoordde.

Laat het nu fladderen. Haal de primaire dertig seconden omhoog, dertig omlaag, twee keer. Als het verkeer elke overgang volgt, zijn de drempels te strak of de niveaus verkeerd. Repareer dat volgens je eigen planning, want anders doet een provider het volgens de zijne.

Bevestig tot slot dat je de router nog kunt beheren. Houd een out-of-band-pad aan, zoals een consolekabel, een beheer-VLAN of een mobiel modem. Een failovertest die je buitensluit is een test die je niet kunt afmaken, en een onbereikbare router kan niet vanzelf terugvallen.

Voordat je het beleid klaar noemt, moet je vier vragen kunnen beantwoorden zonder een terminal te openen: welke VLAN's de WAN mogen gebruiken terwijl de tunnel neerligt, wat de detector in de gaten houdt en hoe lang hij wacht, welke nameservers en IPv6-routes met het pad meebewegen, en hoe je weer binnenkomt als de back-up ook faalt. Als een antwoord “wat de standaard ook was” is, hoort het beleid nog bij de router en niet bij jou.