Tre slags OpenVPN-failover på pfSense, tre mekanismer

»OpenVPN-failover« på pfSense dækker mindst tre uafhængige design, og hvert af dem kræver en anden mekanisme. At holde en tunnel i live over en backup-internetforbindelse, at genoprette forbindelsen til en anden server og at styre LAN-trafik ind i en anden etableret tunnel er ikke varianter af én funktion. Vælg den fejl, du forsvarer dig imod, før du bygger en gateway-gruppe. En gruppe, der løser én af dem, gør intet for de to andre.

Navngiv fejlen, før du bygger en gruppe

Skriv den sætning, du vil have sand under en afbrydelse. »Tunnelen genopretter forbindelsen over backup-WAN'et« og »filialen når stadig applikationen gennem den anden tunnel« er forskellige sætninger. Kun den første handler om transporten.

Kobl den derefter til en mekanisme. Tab af det lokale WAN er et problem med interfacevalg, et dødt remote-endpoint er et problem med forbindelseslisten, og en ubrugelig vej inde i en etableret tunnel er et problem med routing og politik.

Lokalt WAN: flyt transporten

For en pfSense-OpenVPN-klient vælger det understøttede multi-WAN-arrangement en passende gateway-gruppe som det interface, klienten binder til. Det er det, der lader den ydre forbindelse forlade over backup-linket, når den primære svigter. Det ændrer ikke i sig selv, hvordan den indre trafik routes.

Serversiden af samme design er adskilt. En OpenVPN-server, der skal kunne nås på flere offentlige adresser, har brug for en listener og en indgående politik for hver af disse indgange, ikke bare en klient, der kan ringe ud over to links. Én fungerende offentlig indgang er ikke bevis for, at den anden er konfigureret.

En policy-routing-regel for videresendte LAN-pakker er ikke den indstilling, der flytter en lokalt genereret VPN-transportforbindelse. Det er to forskellige opslag, og ændring af det ene ændrer ikke det andet.

Remote-endpoint: en anden server

En alternativ remote er en funktion i forbindelseslisten. Klienten prøver den næste indgang, når den nuværende ikke svarer, hvilket er nyttigt, når en bestemt host er nede, og ikke når din egen uplink er det. De to fejl ligner hinanden fra en brugers skrivebord og kræver forskellige rettelser.

Hver kandidat skal være en reel erstatning: kompatibel autentificering, kompatibel klientpolitik og adgang til de samme private ressourcer. Et andet hostnavn, der peger på den samme nedbrudte infrastruktur, er ikke en backup. En server uden den krævede rute er det heller ikke, hvor sundt håndtrykket end ser ud.

Denne mekanisme får heller ikke to tunneler til at videresende samtidig. Den erstatter den ene forbindelse med en anden, sekventielt, og hullet imellem er synligt for alt, hvad der kørte.

Tunnelsti: vælg en anden udgang

Når to tunneler allerede er oppe, og trafikken skal bruge den sundeste, er mekanismen et tildelt VPN-interface med sin egen gateway plus en udtrykkelig politikregel, der sender den rigtige trafik derhen. En gateway-gruppe over disse tildelte interfaces kan udtrykke prioritet og overvågning.

Det design handler om udvælgelse, ikke om genopretning. At flytte nye forbindelser til den anden tunnel siger intet om sessioner, der allerede er etableret på den første, og intet om, hvorvidt den anden side accepterer den nye kildeadresse. At behandle det som en genopretningsmekanisme er måden at sætte forventningerne for højt.

Hvis kravet er, at eksisterende sessioner overlever, så sig det udtrykkeligt. De fleste implementeringer migrerer ikke et levende flow mellem tunneler, og at designe, som om de gør, giver en failover, der ser korrekt ud i et diagram og dropper hver åben forbindelse i praksis.

Monitorer, NAT og fail-closed-reglen

En monitor skal teste noget, som tunnelen er ment at levere. Et mål, der svarer fra tunnelpeeren men ikke fra applikationsnettet bagved, rapporterer sundt, mens brugerne intet ser. Et uopnåeligt diagnostisk mål rapporterer dødt, mens vejen er fin. Vælg adressen med vilje, og bekræft, at den kun kan nås gennem den tilsigtede tunnel.

Kontrollér den udgående NAT for begge udgange. En fungerende oversættelse på den primære beskriver ikke backupens kildeadresse, og det private netværk i den anden ende har brug for en returrute, der matcher den kilde, du præsenterer. En oversættelse, der er korrekt på den ene vej, kan være stille forkert på den anden.

Beslut derefter, hvad der sker med den trafik, der aldrig må bruge WAN'et. pfSense har defineret adfærd for regler, hvis valgte gateway er nede, og en senere bred pass-regel eller en standardrute kan ophæve din hensigt. Skriv det blokerede resultat ned som et krav, og verificér det ved at tage vejen ned.

Test tab og genopretning hver for sig, med trafik du har tilladelse til at generere, og hold øje med tre ting på én gang: det WAN, der bærer den ydre forbindelse, den tunnel, der bærer applikationsanmodningen, og den vej, svaret tager. Et par grønne gateway-indikatorer er ikke en af de tre. Netgate multi-WAN-guiden beskriver transportbindingen og de eksporterede klientalternativer, som dette afhænger af.