Tri vrste OpenVPN failovera na pfSenseu, tri mehanizma

„OpenVPN failover“ na pfSenseu pokriva najmanje tri nepovezana dizajna i svaki od njih traži drukčiji mehanizam. Održavati tunel živim preko rezervne internetske veze, ponovno se spajati na drugi poslužitelj i usmjeravati LAN promet u drugi već uspostavljeni tunel nisu varijante jedne funkcije. Odaberite kvar od kojeg se branite prije nego što izgradite grupu pristupnika. Grupa koja rješava jedan od njih ne radi ništa za druga dva.

Imenujte kvar prije nego što izgradite grupu

Napišite rečenicu koju želite da bude istinita tijekom ispada. „Tunel se ponovno spaja preko rezervnog WAN-a“ i „poslovnica i dalje dolazi do aplikacije preko drugog tunela“ različite su rečenice. Samo prva govori o transportu.

Zatim je povežite s mehanizmom. Gubitak lokalnog WAN-a problem je odabira sučelja, mrtva udaljena krajnja točka problem je popisa veza, a neupotrebljiva putanja unutar uspostavljenog tunela problem je usmjeravanja i politike.

Lokalni WAN: premjestiti transport

Za pfSense OpenVPN klijenta podržani raspored više WAN-ova odabire odgovarajuću grupu pristupnika kao sučelje na koje se klijent veže. To je ono što vanjskoj vezi omogućuje da ode preko rezervne veze kada primarna zakaže. Samo po sebi ne mijenja kako se usmjerava unutarnji promet.

Poslužiteljska strana istog dizajna je odvojena. OpenVPN poslužitelj koji mora biti dostupan preko nekoliko javnih adresa treba slušatelja i ulaznu politiku za svaki od tih unosa, a ne samo klijenta koji zna birati preko dvije veze. Jedan funkcionalan javni unos nije dokaz da je drugi konfiguriran.

Pravilo usmjeravanja prema politici za proslijeđene LAN pakete nije postavka koja premješta lokalno stvorenu VPN transportnu vezu. To su dva različita pretraživanja i promjena jednoga ne mijenja drugo.

Udaljena krajnja točka: drugi poslužitelj

Alternativni remote značajka je popisa veza. Klijent pokušava sljedeći unos kada trenutni ne odgovara, što je korisno kada je pao određeni host, a ne kada je pala vaša vlastita uzlazna veza. Dva kvara sa stola korisnika izgledaju slično i traže različite popravke.

Svaki kandidat mora biti stvarna zamjena: kompatibilna autentifikacija, kompatibilna klijentska politika i pristup istim privatnim resursima. Drugo ime hosta koje se razrješava na istu neispravnu infrastrukturu nije rezerva. Poslužitelj bez potrebne rute također nije, koliko god njegovo rukovanje izgledalo zdravo.

Ovaj mehanizam također ne čini da dva tunela prosljeđuju istodobno. Zamjenjuje jednu vezu drugom, uzastopno, a razmak između njih vidljiv je svemu što je radilo.

Putanja tunela: odabrati drugi izlaz

Kada su dva tunela već podignuta i promet treba koristiti zdraviji, mehanizam je dodijeljeno VPN sučelje s vlastitim pristupnikom, plus izričito pravilo politike koje tamo šalje pravi promet. Grupa pristupnika preko tih dodijeljenih sučelja može izraziti prioritet i nadzor.

Taj dizajn govori o odabiru, a ne o oporavku. Premještanje novih veza na drugi tunel ne govori ništa o sesijama već uspostavljenima na prvome ni o tome hoće li suprotna strana prihvatiti novu izvornu adresu. Tretirati to kao mehanizam oporavka znači postaviti očekivanja previsoko.

Ako je zahtjev da postojeće sesije prežive, recite to izričito. Većina implementacija ne migrira živi tok između tunela, a projektiranje kao da to čine daje prebacivanje koje na dijagramu izgleda ispravno, a u praksi odbacuje svaku otvorenu vezu.

Nadzornici, NAT i pravilo fail-closed

Nadzornik treba testirati nešto što tunel treba dostavljati. Cilj koji odgovara s tunelskog partnera, ali ne iz aplikacijske mreže iza njega, prijavit će zdravo stanje dok korisnici ne vide ništa. Nedostupan dijagnostički cilj prijavit će mrtvo stanje dok je putanja u redu. Odaberite adresu namjerno i potvrdite da je dostupna samo kroz predviđeni tunel.

Provjerite odlazni NAT za oba izlaza. Ispravno prevođenje na primarnome ne opisuje izvornu adresu rezerve, a udaljena privatna mreža treba povratnu rutu koja odgovara izvoru koji predstavljate. Prevođenje ispravno na jednoj putanji može biti tiho pogrešno na drugoj.

Zatim odlučite što se događa s prometom koji nikada ne smije koristiti WAN. pfSense ima definirano ponašanje za pravila čiji je odabrani pristupnik pao, a kasnije široko pravilo propuštanja ili zadana ruta mogu poništiti vašu namjeru. Zapišite blokirani ishod kao zahtjev i provjerite ga tako da spustite putanju.

Testirajte gubitak i oporavak odvojeno, prometom koji smijete generirati, i promatrajte tri stvari odjednom: WAN koji nosi vanjsku vezu, tunel koji nosi zahtjev aplikacije i putanju kojom ide odgovor. Par zelenih pokazatelja pristupnika nije jedna od te tri. Netgateov vodič za više WAN-ova opisuje vezanje transporta i izvezene klijentske alternative na kojima to počiva.