Tre slags OpenVPN-failover på pfSense, tre mekanismer

«OpenVPN-failover» på pfSense dekker minst tre uavhengige design, og hvert av dem krever en annen mekanisme. Å holde en tunnel i live over en backup-internettforbindelse, å koble til en annen server på nytt og å styre LAN-trafikk inn i en annen etablert tunnel er ikke varianter av én funksjon. Velg feilen du forsvarer deg mot før du bygger en gateway-gruppe. En gruppe som løser én av dem, gjør ingenting for de to andre.

Navngi feilen før du bygger en gruppe

Skriv setningen du vil ha sann under en avbrudd. «Tunnelen kobler til på nytt over backup-WAN-et» og «filialen når fortsatt applikasjonen gjennom den andre tunnelen» er forskjellige setninger. Bare den første handler om transporten.

Koble den deretter til en mekanisme. Tap av det lokale WAN-et er et problem med grensesnittvalg, et dødt remote-endepunkt er et problem med tilkoblingslisten, og en ubrukelig vei inne i en etablert tunnel er et problem med ruting og policy.

Lokalt WAN: flytt transporten

For en pfSense-OpenVPN-klient velger det støttede multi-WAN-oppsettet en passende gateway-gruppe som grensesnittet klienten binder til. Det er dette som lar den ytre tilkoblingen forlate over backup-lenken når den primære svikter. Det endrer ikke i seg selv hvordan den indre trafikken rutes.

Serversiden av samme design er separat. En OpenVPN-server som skal kunne nås på flere offentlige adresser, trenger en lytter og en inngående policy for hver av disse oppføringene, ikke bare en klient som kan ringe ut over to lenker. Én fungerende offentlig oppføring er ikke bevis for at den andre er konfigurert.

En policy-ruting-regel for videresendte LAN-pakker er ikke innstillingen som flytter en lokalt generert VPN-transporttilkobling. Det er to forskjellige oppslag, og å endre det ene endrer ikke det andre.

Remote-endepunkt: en annen server

En alternativ remote er en funksjon i tilkoblingslisten. Klienten prøver neste oppføring når den nåværende ikke svarer, noe som er nyttig når en bestemt vert er nede og ikke når din egen uplink er det. De to feilene ser like ut fra en brukers skrivebord og krever forskjellige rettelser.

Hver kandidat må være en reell erstatning: kompatibel autentisering, kompatibel klientpolicy og tilgang til de samme private ressursene. Et andre vertsnavn som peker på den samme ødelagte infrastrukturen, er ingen backup. En server uten den påkrevde ruten er det heller ikke, uansett hvor sunn håndtrykket ser ut.

Denne mekanismen får heller ikke to tunneler til å videresende samtidig. Den erstatter én tilkobling med en annen, sekvensielt, og gapet mellom dem er synlig for alt som kjørte.

Tunnelsti: velg en annen utgang

Når to tunneler allerede er oppe og trafikken skal bruke den sunneste, er mekanismen et tilordnet VPN-grensesnitt med egen gateway, pluss en uttrykkelig policyregel som sender riktig trafikk dit. En gateway-gruppe over disse tilordnede grensesnittene kan uttrykke prioritet og overvåking.

Det designet handler om utvelgelse, ikke om gjenoppretting. Å flytte nye tilkoblinger til den andre tunnelen sier ingenting om økter som allerede er etablert på den første, og ingenting om hvorvidt den andre siden godtar den nye kildeadressen. Å behandle det som en gjenopprettingsmekanisme er hvordan forventningene settes for høyt.

Hvis kravet er at eksisterende økter skal overleve, si det uttrykkelig. De fleste implementasjoner migrerer ikke en levende flyt mellom tunneler, og å designe som om de gjør det gir en failover som ser korrekt ut i et diagram og dropper hver åpne tilkobling i praksis.

Monitorer, NAT og fail-closed-regelen

En monitor bør teste noe tunnelen er ment å levere. Et mål som svarer fra tunnelpeeren men ikke fra applikasjonsnettet bak den, rapporterer sunt mens brukerne ikke ser noe. Et uoppnåelig diagnostisk mål rapporterer dødt mens veien er i orden. Velg adressen med vilje, og bekreft at den bare er nåbar gjennom den tiltenkte tunnelen.

Kontroller den utgående NAT-en for begge utgangene. En fungerende oversettelse på den primære beskriver ikke backupens kildeadresse, og det private nettet i den andre enden trenger en returrute som passer med kilden du presenterer. En oversettelse som er korrekt på én vei, kan være stille feil på den andre.

Bestem deretter hva som skjer med den trafikken som aldri skal bruke WAN-et. pfSense har definert atferd for regler der den valgte gatewayen er nede, og en senere bred pass-regel eller en standardrute kan oppheve hensikten din. Skriv ned det blokkerte utfallet som et krav, og verifiser det ved å ta ned veien.

Test tap og gjenoppretting hver for seg, med trafikk du har tillatelse til å generere, og følg med på tre ting samtidig: WAN-et som bærer den ytre tilkoblingen, tunnelen som bærer applikasjonsforespørselen, og veien svaret tar. Et par grønne gateway-indikatorer er ikke en av de tre. Netgate-guiden for multi-WAN beskriver transportbindingen og de eksporterte klientalternativene som dette bygger på.