Tre slag OpenVPN-failover på pfSense, tre mekanismar

«OpenVPN-failover» på pfSense dekkjer minst tre uavhengige design, og kvart av dei krev ein annan mekanisme. Å halde ein tunnel i live over ei backup-internettforbinding, å kople til ein annan server på nytt og å styre LAN-trafikk inn i ein annan etablert tunnel er ikkje variantar av éin funksjon. Vel feilen du forsvarar deg mot før du byggjer ei gateway-gruppe. Ei gruppe som løyser éin av dei, gjer ingenting for dei to andre.

Namngi feilen før du byggjer ei gruppe

Skriv setninga du vil ha sann under eit avbrot. «Tunnelen koplar til på nytt over backup-WAN-et» og «filialen når framleis applikasjonen gjennom den andre tunnelen» er ulike setningar. Berre den første handlar om transporten.

Kople henne deretter til ein mekanisme. Tap av det lokale WAN-et er eit problem med grensesnittval, eit daudt remote-endepunkt er eit problem med tilkoplingslista, og ein ubrukeleg veg inne i ein etablert tunnel er eit problem med ruting og policy.

Lokalt WAN: flytt transporten

For ein pfSense-OpenVPN-klient vel det støtta multi-WAN-oppsettet ei passande gateway-gruppe som grensesnittet klienten bind seg til. Det er dette som lèt den ytre tilkoplinga gå ut over backup-lenka når den primære sviktar. Det endrar ikkje i seg sjølv korleis den indre trafikken blir ruta.

Serversida av same design er separat. Ein OpenVPN-server som skal kunne nåast på fleire offentlege adresser, treng ein lyttar og ein inngåande policy for kvar av desse oppføringane, ikkje berre ein klient som kan ringje ut over to lenker. Éi fungerande offentleg oppføring er ikkje prov på at den andre er konfigurert.

Ein policy-ruting-regel for videresende LAN-pakkar er ikkje innstillinga som flyttar ei lokalt generert VPN-transporttilkopling. Det er to ulike oppslag, og å endre det eine endrar ikkje det andre.

Remote-endepunkt: ein annan server

Ein alternativ remote er ein funksjon i tilkoplingslista. Klienten prøver neste oppføring når den noverande ikkje svarar, noko som er nyttig når ein bestemd vert er nede og ikkje når din eigen uplink er det. Dei to feila ser like ut frå skrivebordet til ein brukar og krev ulike rettingar.

Kvar kandidat må vere ein reell erstatning: kompatibel autentisering, kompatibel klientpolicy og tilgang til dei same private ressursane. Eit andre vertsnamn som peikar på den same øydelagde infrastrukturen, er ingen backup. Ein server utan den påkravde ruta er det heller ikkje, uansett kor sunn handtrykket ser ut.

Denne mekanismen får heller ikkje to tunnelskip til å videresende samtidig. Han erstattar éi tilkopling med ei anna, sekvensielt, og gapet mellom dei er synleg for alt som køyrde.

Tunnelsti: vel ein annan utgang

Når to tunnelskip alt er oppe og trafikken skal bruke den sunnaste, er mekanismen eit tilordna VPN-grensesnitt med eigen gateway, pluss ein uttrykkeleg policyregel som sender rett trafikk dit. Ei gateway-gruppe over desse tilordna grensesnitta kan uttrykkje prioritet og overvaking.

Det designet handlar om utveling, ikkje om gjenoppretting. Å flytte nye tilkoplingar til den andre tunnelen seier ingenting om økter som alt er etablerte på den første, og ingenting om korvidt den andre sida godtek den nye kjeldadressa. Å handsame det som ein gjenopprettingsmekanisme er korleis forventningane blir sette for høgt.

Viss kravet er at eksisterande økter skal overleve, sei det uttrykkeleg. Dei fleste implementasjonar migrerer ikkje ein levande flyt mellom tunnelskip, og å designe som om dei gjer det gir ein failover som ser korrekt ut i eit diagram og droppar kvar open tilkopling i praksis.

Monitorar, NAT og fail-closed-regelen

Ein monitor bør teste noko tunnelen er meint å levere. Eit mål som svarar frå tunnelpeeren men ikkje frå applikasjonsnettet bak han, rapporterer sunt medan brukarane ikkje ser noko. Eit uoppnåeleg diagnostisk mål rapporterer daudt medan vegen er i orden. Vel adressa med vilje, og stadfest at ho berre er nåeleg gjennom den tiltenkte tunnelen.

Kontroller den utgåande NAT-en for begge utgangane. Ei fungerande omsetjing på den primære skildrar ikkje kjeldadressa til backupen, og det private nettet i den andre enden treng ei returrute som passar med kjelda du presenterer. Ei omsetjing som er korrekt på éin veg, kan vere stille feil på den andre.

Avgjer deretter kva som skjer med den trafikken som aldri skal bruke WAN-et. pfSense har definert åtferd for reglar der den valde gatewayen er nede, og ein seinare brei pass-regel eller ei standardrute kan oppheve hensikta di. Skriv ned det blokkerte utfallet som eit krav, og verifiser det ved å ta ned vegen.

Test tap og gjenoppretting kvar for seg, med trafikk du har løyve til å generere, og følg med på tre ting samtidig: WAN-et som ber den ytre tilkoplinga, tunnelen som ber applikasjonsførespurnaden, og vegen svaret tek. Eit par grøne gateway-indikatorar er ikkje ein av dei tre. Netgate-guiden for multi-WAN skildrar transportbindinga og dei eksporterte klientalternativa som dette byggjer på.