Tre sorters OpenVPN-failover på pfSense, tre mekanismer

»OpenVPN-failover« på pfSense omfattar minst tre oberoende konstruktioner, och var och en kräver en annan mekanism. Att hålla en tunnel vid liv över en reservanslutning till internet, att återansluta till en annan server och att styra LAN-trafik in i en annan etablerad tunnel är inte varianter av en och samma funktion. Välj det fel du försvarar dig mot innan du bygger en gateway-grupp. En grupp som löser ett av dem gör ingenting för de andra två.

Namnge felet innan du bygger en grupp

Skriv meningen du vill ska vara sann under ett avbrott. »Tunneln återansluter över reserv-WAN:et« och »filialen når fortfarande applikationen genom den andra tunneln« är olika meningar. Bara den första handlar om transporten.

Koppla den sedan till en mekanism. Förlust av det lokala WAN:et är ett problem med gränssnittsval, en död fjärrändpunkt är ett problem med anslutningslistan, och en oanvändbar väg inne i en etablerad tunnel är ett problem med routing och policy.

Lokalt WAN: flytta transporten

För en pfSense-OpenVPN-klient väljer det stödda multi-WAN-arrangemanget en lämplig gateway-grupp som det gränssnitt klienten binder till. Det är detta som låter den yttre anslutningen lämna över reservlänken när den primära fallerar. Det ändrar i sig inte hur den inre trafiken routas.

Serversidan av samma konstruktion är separat. En OpenVPN-server som ska nås på flera publika adresser behöver en lyssnare och en ingående policy för var och en av dessa poster, inte bara en klient som kan ringa ut över två länkar. En fungerande publik post är inget bevis för att den andra är konfigurerad.

En policy-routing-regel för vidarebefordrade LAN-paket är inte inställningen som flyttar en lokalt genererad VPN-transportanslutning. Det är två olika uppslag, och att ändra det ena ändrar inte det andra.

Fjärrändpunkt: en annan server

En alternativ remote är en funktion i anslutningslistan. Klienten provar nästa post när den nuvarande inte svarar, vilket är användbart när en specifik värd ligger nere och inte när din egen upplänk gör det. De två felen ser lika ut från en användares skrivbord och kräver olika åtgärder.

Varje kandidat måste vara en riktig ersättare: kompatibel autentisering, kompatibel klientpolicy och åtkomst till samma privata resurser. Ett andra värdnamn som pekar på samma trasiga infrastruktur är ingen reserv. En server utan den nödvändiga rutten är det inte heller, hur frisk handskakningen än ser ut.

Den här mekanismen får inte heller två tunnlar att vidarebefordra samtidigt. Den ersätter en anslutning med en annan, sekventiellt, och gapet mellan dem syns för allt som körde.

Tunnelväg: välj en annan utgång

När två tunnlar redan är uppe och trafiken ska använda den friskare, är mekanismen ett tilldelat VPN-gränssnitt med egen gateway plus en uttrycklig policyregel som skickar rätt trafik dit. En gateway-grupp över dessa tilldelade gränssnitt kan uttrycka prioritet och övervakning.

Den konstruktionen handlar om urval, inte om återställning. Att flytta nya anslutningar till den andra tunneln säger ingenting om sessioner som redan är etablerade på den första, och ingenting om huruvida andra sidan accepterar den nya källadressen. Att behandla det som en återställningsmekanism är hur förväntningarna sätts för högt.

Om kravet är att befintliga sessioner överlever, säg det uttryckligen. De flesta implementationer migrerar inte ett levande flöde mellan tunnlar, och att konstruera som om de gör det ger en failover som ser korrekt ut i ett diagram och tappar varje öppen anslutning i praktiken.

Monitorer, NAT och fail-closed-regeln

En monitor bör testa något som tunneln är tänkt att leverera. Ett mål som svarar från tunnelpeeren men inte från applikationsnätet bortom det rapporterar frisk medan användarna inte ser något. Ett oåtkomligt diagnostikmål rapporterar dött medan vägen är okej. Välj adressen medvetet och bekräfta att den bara nås genom den avsedda tunneln.

Kontrollera den utgående NAT:en för båda utgångarna. En fungerande översättning på den primära beskriver inte reservens källadress, och det privata nätet på andra sidan behöver en returväg som matchar den källa du presenterar. En översättning som är korrekt på en väg kan vara tyst fel på den andra.

Bestäm sedan vad som händer med den trafik som aldrig får använda WAN:et. pfSense har definierat beteende för regler vars valda gateway ligger nere, och en senare bred pass-regel eller en standardrutt kan upphäva din avsikt. Skriv ner det blockerade utfallet som ett krav och verifiera det genom att ta ner vägen.

Testa förlust och återställning separat, med trafik du har tillstånd att generera, och håll ögonen på tre saker samtidigt: WAN:et som bär den yttre anslutningen, tunneln som bär applikationsbegäran och vägen som svaret tar. Ett par gröna gateway-indikatorer är inte en av de tre. Netgate-guiden för multi-WAN beskriver transportbindningen och de exporterade klientalternativen som detta bygger på.