Tri specoj de OpenVPN-failover sur pfSense, tri mekanismoj

„OpenVPN failover“ sur pfSense kovras almenaŭ tri sendependajn dezajnojn, kaj ĉiu el ili bezonas alian mekanismon. Tena viva tunelo trans rezerva interreta ligilo, rekonekto al alia servilo kaj direktado de LAN-trafiko en alian jam establitan tunelon ne estas variantoj de unu funkcio. Elektu la fuŝon, kontraŭ kiu vi defendas, antaŭ ol konstrui pordaran grupon. Grupo, kiu riparas unu el ili, faras nenion por la aliaj du.

Nomu la fuŝon antaŭ ol konstrui grupon

Skribu la frazon, kiun vi volas vidi vera dum interrompo. „La tunelo rekonektas trans la rezerva WAN“ kaj „la filio daŭre atingas la aplikaĵon trans la alia tunelo“ estas malsamaj frazoj. Nur la unua temas pri transporto.

Poste kunigu ĝin al mekanismo. Perdo de la loka WAN estas problemo de interfaca elekto, morta fora finpunkto estas problemo de la konekta listo, kaj neuzebla vojo interne de establita tunelo estas problemo de enkursigado kaj politiko.

Loka WAN: movu la transporton

Por pfSense OpenVPN-kliento la subtenata plur-WAN-aranĝo elektas taŭgan pordaran grupon kiel la interfacon, al kiu la kliento ligiĝas. Tio ebligas al la ekstera konekto eliri trans la rezerva ligilo, kiam la primara fiaskas. Ĝi mem ne ŝanĝas, kiel la interna trafiko estas enkursigata.

La servila flanko de la sama dezajno estas aparta. OpenVPN-servilo, kiu devus esti atingebla trans pluraj publikaj adresoj, bezonas aŭskultanton kaj enirpolitikon por ĉiu el tiuj enskriboj, ne nur klienton kapablan alvoki trans du ligiloj. Unu funkcianta publika enskribo ne pruvas, ke la dua estas agordita.

Regulo de politik-bazita enkursigado por plusenditaj LAN-paketoj ne estas la agordo, kiu movas loke kreitan VPN-transportan konekton. Temas pri du malsamaj serĉoj, kaj ŝanĝo de unu ne ŝanĝas la alian.

Fora finpunkto: alia servilo

Alternativa remote estas funkcio de la konekta listo. La kliento provas la sekvan enskribon, kiam la nuna ne respondas, kio utilas, kiam aparta gastiganto estas malsupre, kaj ne kiam via propra suprenligilo estas. La du fuŝoj aspektas similaj de la skribotablo de uzanto kaj postulas malsamajn riparojn.

Ĉiu kandidato devas esti vera anstataŭanto: kongrua aŭtentikigo, kongrua klienta politiko kaj aliro al la samaj privataj rimedoj. Dua gastigantnomo, kiu solviĝas al la sama difektita infrastrukturo, ne estas rezervo. Servilo sen la bezonata vojo ankaŭ ne, kiel ajn sana aspektas ĝia manpremo.

Ĉi tiu mekanismo ankaŭ ne igas du tunelojn plusendi samtempe. Ĝi anstataŭigas unu konekton per alia, sinsekve, kaj la breĉo inter ili videblas al ĉio, kio kuris.

Tunela vojo: elektu alian eliron

Kiam du tuneloj jam staras kaj la trafiko devas uzi la pli sanan, la mekanismo estas atribuita VPN-interfaco kun propra pordego, plus eksplicita politika regulo, kiu sendas la ĝustan trafikon tien. Pordara grupo super tiuj atribuitaj interfacoj povas esprimi prioritaton kaj monitoradon.

Tiu dezajno temas pri elekto, ne pri restarigo. Movi novajn konektojn al la dua tunelo diras nenion pri sesioj jam establitaj sur la unua, kaj nenion pri tio, ĉu la fora flanko akceptos la novan fontan adreson. Trakti ĝin kiel restarigan mekanismon estas la maniero meti atendojn tro alte.

Se la postulo estas, ke la ekzistantaj sesioj postvivas, diru tion eksplicite. Plej multaj realigoj ne migras vivan fluon inter tuneloj, kaj projektado kvazaŭ ili farus produktas failover, kiu aspektas ĝusta sur diagramo kaj praktike faligas ĉiun malfermitan konekton.

Monitoroj, NAT kaj la fail-closed-regulo

Monitoro devus testi ion, kion la tunelo devus liveri. Celo, kiu respondas de la tunela partnero sed ne de la aplikaĵa reto malantaŭ ĝi, raportos sanan staton, dum uzantoj vidas nenion. Neatingebla diagnoza celo raportos mortan staton, dum la vojo estas en ordo. Elektu la adreson intence kaj konfirmu, ke ĝi estas atingebla nur tra la celita tunelo.

Kontrolu la eliran NAT por ambaŭ eliroj. Funkcianta traduko sur la primara ne priskribas la fontan adreson de la rezervo, kaj la fora privata reto bezonas revenan vojon kongruan kun la fonto, kiun vi prezentas. Traduko ĝusta sur unu vojo povas esti silente malĝusta sur la alia.

Poste decidu, kio okazas al la trafiko, kiu neniam rajtas uzi la WAN. pfSense havas difinitan konduton por reguloj, kies elektita pordego estas malsupre, kaj posta larĝa permesa regulo aŭ implicita vojo povas neniigi vian intencon. Skribu la blokitan rezulton kiel postulon, poste kontrolu ĝin mallevante la vojon.

Testu perdon kaj restarigon aparte, kun trafiko, kiun vi rajtas generi, kaj observu tri aferojn samtempe: la WAN, kiu portas la eksteran konekton, la tunelon, kiu portas la aplikaĵan peton, kaj la vojon, kiun prenas la respondo. Paro da verdaj pordegaj indikiloj ne estas unu el tiuj tri. La plur-WAN-gvidilo de Netgate priskribas la transportan ligadon kaj la eksportitajn klientajn alternativojn, sur kiuj ĉi tio baziĝas.