Drie soorten OpenVPN-failover op pfSense, drie mechanismen

„OpenVPN-failover” op pfSense omvat minstens drie losstaande ontwerpen, en elk daarvan vraagt een ander mechanisme. Een tunnel in leven houden over een back-up-internetverbinding, opnieuw verbinden met een andere server en LAN-verkeer naar een andere bestaande tunnel sturen zijn geen varianten van één functie. Kies de storing waartegen u zich verdedigt voordat u een gateway-groep bouwt. Een groep die er één oplost, doet niets voor de andere twee.

Benoem de storing voordat u een groep bouwt

Schrijf de zin op die tijdens een storing waar moet zijn. „De tunnel verbindt opnieuw via het back-up-WAN” en „de vestiging blijft de applicatie bereiken via de andere tunnel” zijn verschillende zinnen. Alleen de eerste gaat over het transport.

Koppel die daarna aan een mechanisme. Verlies van het lokale WAN is een probleem van interfacekeuze, een dode remote-endpoint is een probleem van de verbindingslijst, en een onbruikbaar pad binnen een bestaande tunnel is een probleem van routering en beleid.

Lokaal WAN: het transport verplaatsen

Voor een pfSense-OpenVPN-client kiest de ondersteunde multi-WAN-opstelling een passende gateway-groep als de interface waaraan de client zich bindt. Dat is wat de buitenste verbinding via de back-up-link laat vertrekken wanneer de primaire uitvalt. Het verandert op zichzelf niet hoe het binnenverkeer wordt gerouteerd.

De servers kant van hetzelfde ontwerp staat apart. Een OpenVPN-server die via meerdere publieke adressen bereikbaar moet zijn, heeft voor elk van die ingangen een listener en een inkomend beleid nodig, niet alleen een client die via twee links kan bellen. Eén werkende publieke ingang is geen bewijs dat de tweede is geconfigureerd.

Een beleidsrouteringsregel voor doorgestuurde LAN-pakketten is niet de instelling die een lokaal gegenereerde VPN-transportverbinding verplaatst. Dat zijn twee verschillende opzoekingen, en het wijzigen van de ene wijzigt de andere niet.

Remote-endpoint: een andere server

Een alternatieve remote is een functie van de verbindingslijst. De client probeert de volgende ingang wanneer de huidige niet antwoordt, wat nuttig is wanneer een specifieke host plat ligt en niet wanneer uw eigen uplink dat is. De twee storingen lijken vanaf het bureau van een gebruiker op elkaar en vragen verschillende oplossingen.

Elke kandidaat moet een echte vervanger zijn: compatibele authenticatie, compatibel clientbeleid en toegang tot dezelfde private bronnen. Een tweede hostnaam die naar dezelfde uitgevallen infrastructuur verwijst, is geen back-up. Een server zonder de vereiste route is dat evenmin, hoe gezond de handshake er ook uitziet.

Dit mechanisme laat ook niet twee tunnels tegelijk doorsturen. Het vervangt de ene verbinding na elkaar door een andere, en de opening daartussen is zichtbaar voor alles wat liep.

Tunnelpad: een andere uitgang kiezen

Wanneer er al twee tunnels staan en het verkeer de gezondere moet gebruiken, is het mechanisme een toegewezen VPN-interface met een eigen gateway, plus een uitdrukkelijke beleidsregel die het juiste verkeer daarheen stuurt. Een gateway-groep over die toegewezen interfaces kan prioriteit en monitoring uitdrukken.

Dat ontwerp gaat over selectie, niet over herstel. Nieuwe verbindingen naar de tweede tunnel verplaatsen zegt niets over sessies die al op de eerste bestaan, en niets over de vraag of de andere kant het nieuwe bronadres accepteert. Het als herstelmechanisme behandelen zet de verwachtingen te hoog.

Als de eis is dat bestaande sessies overleven, zeg dat dan expliciet. De meeste implementaties migreren een lopende flow niet tussen tunnels, en ontwerpen alsof ze dat wel doen levert een failover op die in een diagram klopt en in de praktijk elke open verbinding laat vallen.

Monitors, NAT en de fail-closed-regel

Een monitor moet iets testen dat de tunnel hoort te leveren. Een doel dat antwoordt vanaf de tunnelpeer maar niet vanuit het applicatienetwerk erachter, meldt gezond terwijl gebruikers niets zien. Een onbereikbaar diagnostisch doel meldt dood terwijl het pad in orde is. Kies het adres bewust en bevestig dat het alleen via de bedoelde tunnel bereikbaar is.

Controleer de uitgaande NAT voor beide uitgangen. Een werkende vertaling op de primaire beschrijft niet het bronadres van de back-up, en het private netwerk aan de andere kant heeft een retourroute nodig die past bij de bron die u presenteert. Een vertaling die op het ene pad correct is, kan op het andere stil fout zijn.

Bepaal daarna wat er gebeurt met het verkeer dat nooit het WAN mag gebruiken. pfSense heeft gedefinieerd gedrag voor regels waarvan de gekozen gateway platligt, en een latere brede pass-regel of een standaardroute kan uw bedoeling tenietdoen. Schrijf de geblokkeerde uitkomst als eis op en verifieer die door het pad weg te nemen.

Test verlies en herstel apart, met verkeer dat u mag genereren, en let tegelijk op drie dingen: het WAN dat de buitenste verbinding draagt, de tunnel die de applicatieaanvraag draagt, en het pad dat het antwoord neemt. Een paar groene gateway-indicatoren hoort niet bij die drie. De multi-WAN-gids van Netgate beschrijft de transportbinding en de geëxporteerde clientalternatieven waarop dit berust.