Tri vrste preklopa OpenVPN v pfSense, trije mehanizmi

„OpenVPN failover“ v pfSense zajema vsaj tri nepovezane zasnove in vsaka od njih zahteva drugačen mehanizem. Ohranjati tunel živ prek rezervne internetne povezave, se znova povezati z drugim strežnikom in usmerjati promet LAN v drug že vzpostavljen tunel niso različice ene funkcije. Izberite okvaro, pred katero se branite, preden zgradite skupino prehodov. Skupina, ki odpravi eno od njih, ne naredi ničesar za drugi dve.

Poimenujte okvaro, preden zgradite skupino

Napišite stavek, ki ga želite imeti med izpadom resničnega. „Tunel se znova poveže prek rezervnega WAN“ in „podružnica še vedno doseže aplikacijo prek drugega tunela“ sta različna stavka. Samo prvi se nanaša na transport.

Nato ga povežite z mehanizmom. Izguba lokalnega WAN je problem izbire vmesnika, mrtva oddaljena končna točka je problem seznama povezav, neuporabna pot znotraj vzpostavljenega tunela pa je problem usmerjanja in politike.

Lokalni WAN: premakniti transport

Za odjemalca OpenVPN v pfSense podprta razporeditev več WAN izbere ustrezno skupino prehodov kot vmesnik, na katerega se odjemalec veže. To je tisto, kar zunanji povezavi omogoči, da odide po rezervni povezavi, ko primarna odpove. Samo po sebi ne spremeni, kako je usmerjen notranji promet.

Strežniška stran iste zasnove je ločena. Strežnik OpenVPN, ki mora biti dosegljiv prek več javnih naslovov, potrebuje poslušalca in vhodno politiko za vsak od teh vnosov, ne le odjemalca, ki zna klicati prek dveh povezav. En delujoč javni vnos ni dokaz, da je drugi konfiguriran.

Pravilo usmerjanja na podlagi politike za posredovane pakete LAN ni nastavitev, ki premakne lokalno ustvarjeno transportno povezavo VPN. To sta dva različna iskanja in sprememba enega ne spremeni drugega.

Oddaljena končna točka: drug strežnik

Alternativni remote je funkcija seznama povezav. Odjemalec poskusi naslednji vnos, ko trenutni ne odgovori, kar je koristno, ko je dol določen gostitelj in ne, ko je dol lastna odhodna povezava. Obe okvari sta z uporabnikove mize videti podobni in zahtevata različna popravka.

Vsak kandidat mora biti resnična zamenjava: združljiva overitev, združljiva odjemalska politika in dostop do istih zasebnih virov. Drugo ime gostitelja, ki se razreši na isto nedelujočo infrastrukturo, ni varnostna kopija. Strežnik brez zahtevane poti prav tako ne, ne glede na to, kako zdravo je videti njegovo rokovanje.

Ta mehanizem tudi ne naredi, da bi dva tunela posredovala hkrati. Eno povezavo nadomesti z drugo, zaporedno, in vrzel med njima je vidna vsemu, kar je teklo.

Pot tunela: izbrati drug izhod

Ko sta dva tunela že postavljena in naj bi promet uporabljal bolj zdravega, je mehanizem dodeljen vmesnik VPN z lastnim prehodom, plus izrecno pravilo politike, ki pošlje pravi promet tja. Skupina prehodov prek teh dodeljenih vmesnikov lahko izrazi prednost in spremljanje.

Ta zasnova govori o izbiri, ne o obnovitvi. Premikanje novih povezav v drugi tunel ne pove ničesar o sejah, ki so že vzpostavljene na prvem, in ničesar o tem, ali bo druga stran sprejela novi izvorni naslov. Obravnavati to kot mehanizem obnovitve pomeni postaviti pričakovanja previsoko.

Če je zahteva, da obstoječe seje preživijo, recite to izrecno. Večina implementacij ne migrira živega toka med tuneli in načrtovanje, kot da bi ga, da preklop, ki je na diagramu videti pravilen in v praksi spusti vsako odprto povezavo.

Monitors, NAT in pravilo fail-closed

Monitor mora preizkusiti nekaj, kar naj bi tunel zagotavljal. Cilj, ki odgovarja s tunelskega partnerja, ne pa iz aplikacijskega omrežja za njim, bo javil zdravo stanje, medtem ko uporabniki ne vidijo ničesar. Nedosegljiv diagnostični cilj bo javil mrtvo stanje, medtem ko je pot v redu. Naslov izberite namerno in potrdite, da je dosegljiv samo skozi predvideni tunel.

Preverite odhodni NAT za oba izhoda. Delujoče prevajanje na primarnem ne opiše izvornega naslova rezerve, oddaljeno zasebno omrežje pa potrebuje povratno pot, ki se ujema z izvorom, ki ga predstavljate. Prevajanje, ki je pravilno na eni poti, je lahko na drugi tiho napačno.

Nato odločite, kaj se zgodi s prometom, ki nikoli ne sme uporabljati WAN. pfSense ima definirano vedenje za pravila, katerih izbrani prehod je dol, poznejše široko pravilo prepuščanja ali privzeta pot pa lahko razveljavi vaš namen. Zapišite blokirani izid kot zahtevo in ga preverite tako, da pot spustite.

Preizkusite izgubo in obnovitev ločeno, s prometom, ki ga smete ustvarjati, in opazujte tri stvari hkrati: WAN, ki nosi zunanjo povezavo, tunel, ki nosi zahtevo aplikacije, in pot, ki jo vzame odgovor. Par zelenih indikatorjev prehoda ni ena od teh treh. Vodnik Netgate za več WAN opisuje vezavo transporta in izvožene odjemalske alternative, na katerih to temelji.