Trys OpenVPN perjungimo pfSense sistemose tipai, trys mechanizmai
Atsarginis WAN, alternatyvus nuotolinis taškas ar kitas aktyvus tunelis: kiekvienai klaidai reikia kito pfSense nustatymo, stebėjimo ir būsenos sprendimo. Pirmiausia įvardykite savąjį.
„OpenVPN failover“ pfSense aplinkoje apima bent tris nesusijusius sprendimus, ir kiekvienam iš jų reikia kito mechanizmo. Tunelio palaikymas gyvo per atsarginę interneto liniją, prisijungimas iš naujo prie kito serverio ir LAN srauto nukreipimas į kitą jau sukurtą tunelį nėra vienos funkcijos variantai. Pasirinkite gedimą, nuo kurio ginatės, prieš statydami šliuzo grupę. Grupė, kuri išsprendžia vieną iš jų, nieko nedaro kitiems dviem.
Įvardykite gedimą prieš statydami grupę
Užrašykite sakinį, kurį norite matyti teisingą pertraukos metu. „Tunelis vėl prisijungia per atsarginį WAN“ ir „filialas vis dar pasiekia programą per kitą tunelį“ yra skirtingi sakiniai. Tik pirmasis susijęs su transportu.
Tada susiekite jį su mechanizmu. Vietinio WAN praradimas yra sąsajos pasirinkimo problema, miręs nuotolinis galinis taškas yra jungčių sąrašo problema, o netinkamas kelias jau sukurtame tunele yra maršrutizavimo ir politikos problema.
Vietinis WAN: perkelti transportą
pfSense OpenVPN klientui palaikomas kelių WAN išdėstymas parenka tinkamą šliuzo grupę kaip sąsają, prie kurios klientas prisiriša. Būtent tai leidžia išorinei jungčiai išeiti per atsarginę liniją, kai pirminė sugenda. Savaime tai nekeičia, kaip maršrutizuojamas vidinis srautas.
Tos pačios konstrukcijos serverio pusė yra atskira. OpenVPN serveriui, kuris turi būti pasiekiamas keliais viešais adresais, reikia klausytojo ir įeinančios politikos kiekvienam iš tų įrašų, o ne tik kliento, galinčio skambinti per dvi linijas. Vienas veikiantis viešas įrašas nėra įrodymas, kad antrasis sukonfigūruotas.
Politika pagrįsta maršrutizavimo taisyklė persiunčiamiems LAN paketams nėra tas nustatymas, kuris perkelia vietoje sugeneruotą VPN transporto jungtį. Tai du skirtingi ieškojimai, ir vieno pakeitimas nekeičia kito.
Nuotolinis galinis taškas: kitas serveris
Alternatyvus nuotolinis taškas yra jungčių sąrašo funkcija. Klientas bando kitą įrašą, kai dabartinis neatsako, o tai naudinga, kai konkretus mazgas neveikia, o ne kai neveikia jūsų paties išėjimo linija. Abu gedimai nuo naudotojo darbo stalo atrodo panašiai ir reikalauja skirtingų taisymų.
Kiekvienas kandidatas turi būti tikras pakaitalas: suderinamas autentifikavimas, suderinama kliento politika ir prieiga prie tų pačių privačių išteklių. Antras mazgo vardas, kuris sprendžiasi į tą pačią sugedusią infrastruktūrą, nėra atsarginė kopija. Serveris be reikiamo maršruto taip pat nėra, kad ir kaip sveikai atrodytų jo rankos paspaudimas.
Šis mechanizmas taip pat neleidžia dviem tuneliams persiųsti vienu metu. Jis pakeičia vieną jungtį kita, nuosekliai, ir tarpas tarp jų matomas viskam, kas veikė.
Tunelio kelias: pasirinkti kitą išėjimą
Kai du tuneliai jau pakelti ir srautas turi naudoti sveikesnį, mechanizmas yra priskirta VPN sąsaja su savo šliuzu, plius aiški politikos taisyklė, kuri siunčia teisingą srautą į ją. Šliuzo grupė per tas priskirtas sąsajas gali išreikšti prioritetą ir stebėjimą.
Ta konstrukcija yra apie pasirinkimą, o ne apie atkūrimą. Naujų jungčių perkėlimas į antrą tunelį nieko nesako apie sesijas, jau sukurtas pirmame, ir nieko apie tai, ar priešinga pusė priims naują šaltinio adresą. Traktuoti tai kaip atkūrimo mechanizmą reiškia nustatyti per didelius lūkesčius.
Jei reikalavimas yra, kad esamos sesijos išliktų, pasakykite tai aiškiai. Dauguma realizacijų neperkelia gyvo srauto tarp tunelių, o projektavimas taip, tarsi jos tai darytų, sukuria perjungimą, kuris atrodo teisingai schemoje ir praktiškai numeta kiekvieną atvirą jungtį.
Monitoriai, NAT ir fail-closed taisyklė
Monitorius turėtų tikrinti tai, ką tunelis turėtų tiekti. Taikinys, kuris atsako iš tunelio partnerio, bet ne iš už jo esančio programų tinklo, praneš sveiką būseną, nors naudotojai nieko nemato. Nepasiekiamas diagnostikos taikinys praneš mirusią būseną, nors kelias tvarkingas. Pasirinkite adresą sąmoningai ir patvirtinkite, kad jis pasiekiamas tik per numatytą tunelį.
Patikrinkite išeinantį NAT abiem išėjimams. Veikiantis vertimas pagrindiniame neaprašo atsarginio šaltinio adreso, o nuotoliniam privačiam tinklui reikia grįžimo maršruto, atitinkančio tą šaltinį, kurį pateikiate. Vertimas, kuris teisingas viename kelyje, kitame gali būti tyliai neteisingas.
Tada nuspręskite, kas nutinka srautui, kuris niekada neturi naudoti WAN. pfSense turi apibrėžtą elgseną taisyklėms, kurių pasirinktas šliuzas neveikia, o vėlesnė plati leidimo taisyklė ar numatytasis maršrutas gali panaikinti jūsų ketinimą. Užrašykite užblokuotą rezultatą kaip reikalavimą ir patikrinkite jį išjungdami kelią.
Tikrinkite praradimą ir atkūrimą atskirai, su srautu, kurį leidžiama generuoti, ir stebėkite tris dalykus vienu metu: WAN, kuris neša išorinę jungtį, tunelį, kuris neša programos užklausą, ir kelią, kurį pasirenka atsakymas. Pora žalių šliuzo indikatorių nėra vienas iš tų trijų. Netgate kelių WAN vadovas aprašo transporto susiejimą ir eksportuotas kliento alternatyvas, kuriomis tai grindžiama.