Tri lloje failover-i OpenVPN në pfSense, tre mekanizma

„OpenVPN failover“ në pfSense përfshin të paktën tre modele të palidhura, dhe secili prej tyre kërkon një mekanizëm tjetër. Mbajtja e një tuneli gjallë përmes një lidhjeje internet rezervë, rilidhja me një server tjetër dhe drejtimi i trafikut LAN në një tunel tjetër tashmë të krijuar nuk janë variante të një funksioni të vetëm. Zgjidhni defektin nga i cili mbroheni përpara se të ndërtoni një grup portash. Grupi që rregullon një prej tyre nuk bën asgjë për dy të tjerët.

Emërtoni defektin përpara se të ndërtoni një grup

Shkruani fjalinë që dëshironi të jetë e vërtetë gjatë një ndërprerjeje. „Tuneli rilidhet përmes WAN-it rezervë“ dhe „dega vazhdon të arrijë aplikacionin përmes tunelit tjetër“ janë fjali të ndryshme. Vetëm e para ka të bëjë me transportin.

Më pas përputheni atë me një mekanizëm. Humbja e WAN-it lokal është problem i zgjedhjes së ndërfaqes, një pikë fundore e largët e vdekur është problem i listës së lidhjeve, dhe një rrugë e papërdorshme brenda një tuneli të krijuar është problem i rrugëzimit dhe politikës.

WAN lokal: zhvendosni transportin

Për një klient OpenVPN të pfSense, rregullimi i mbështetur me shumë WAN zgjedh një grup portash të përshtatshëm si ndërfaqen me të cilën lidhet klienti. Kjo është ajo që lejon lidhjen e jashtme të dalë përmes lidhjes rezervë kur dështon ajo kryesore. Në vetvete nuk ndryshon mënyrën se si rrugëzohet trafiku i brendshëm.

Ana e serverit e të njëjtit model është e veçantë. Një server OpenVPN që duhet të jetë i arritshëm përmes disa adresave publike ka nevojë për një dëgjues dhe një politikë hyrëse për secilën prej këtyre zërave, jo vetëm për një klient që di të telefonojë përmes dy lidhjeve. Një zë publik që funksionon nuk është provë se i dyti është konfiguruar.

Një rregull rrugëzimi i bazuar në politikë për paketat LAN të përcjella nuk është rregullimi që zhvendos një lidhje transporti VPN të krijuar lokalisht. Këto janë dy kërkime të ndryshme, dhe ndryshimi i njërës nuk ndryshon tjetrën.

Pika fundore e largët: një server tjetër

Një remote alternativ është funksion i listës së lidhjeve. Klienti provon zërin tjetër kur ai aktuali nuk përgjigjet, gjë e dobishme kur një host i caktuar është poshtë dhe jo kur është poshtë lidhja tuaj ngjitëse. Të dyja defektet duken njësoj nga tavolina e një përdoruesi dhe kërkojnë rregullime të ndryshme.

Secili kandidat duhet të jetë një zëvendësues i vërtetë: vërtetim i përputhshëm, politikë klienti e përputhshme dhe akses në të njëjtat burime private. Një emër i dytë host-i që zgjidhet në të njëjtën infrastrukturë të prishur nuk është rezervë. Një server pa rrugën e kërkuar gjithashtu nuk është, sado i shëndetshëm që duket shtrëngimi i duarve i tij.

Ky mekanizëm gjithashtu nuk bën që dy tunele të përcjellin njëkohësisht. Zëvendëson një lidhje me një tjetër, në mënyrë të njëpasnjëshme, dhe hendeku midis tyre është i dukshëm për gjithçka që po punonte.

Rruga e tunelit: zgjidhni një dalje tjetër

Kur dy tunele janë tashmë lart dhe trafiku duhet të përdorë atë më të shëndetshëm, mekanizmi është një ndërfaqe VPN e caktuar me portën e vet, plus një rregull i qartë politike që dërgon atje trafikun e duhur. Një grup portash mbi ato ndërfaqe të caktuara mund të shprehë përparësi dhe monitorim.

Ky model ka të bëjë me zgjedhjen, jo me rikuperimin. Zhvendosja e lidhjeve të reja në tunelin e dytë nuk thotë asgjë për sesionet e krijuara tashmë në të parin, dhe asgjë për atë nëse pala e largët do të pranojë adresën e re burimore. Trajtimi i tij si mekanizëm rikuperimi është mënyra për të vendosur pritshmëri shumë të larta.

Nëse kërkesa është që sesionet ekzistuese të mbijetojnë, thojeni shprehimisht. Shumica e implementimeve nuk migrojnë një rrjedhë të gjallë midis tuneleve, dhe projektimi sikur ta bëjnë prodhon një failover që duket i saktë në një diagram dhe në praktikë lëshon çdo lidhje të hapur.

Monitorë, NAT dhe rregulli fail-closed

Një monitor duhet të testojë diçka që tuneli synon të ofrojë. Një objektiv që përgjigjet nga partneri i tunelit, por jo nga rrjeti i aplikacioneve përtej tij, do të raportojë gjendje të shëndetshme ndërsa përdoruesit nuk shohin asgjë. Një objektiv diagnostik i paarritshëm do të raportojë gjendje të vdekur ndërsa rruga është në rregull. Zgjidhni adresën me qëllim dhe konfirmoni se është e arritshme vetëm përmes tunelit të parashikuar.

Kontrolloni NAT-in dalës për të dyja daljet. Një përkthim që funksionon në atë kryesor nuk përshkruan adresën burimore të rezervës, dhe rrjeti privat i largët ka nevojë për një rrugë kthimi që përputhet me burimin që paraqitni. Një përkthim i saktë në një rrugë mund të jetë në heshtje i gabuar në tjetrën.

Më pas vendosni çfarë ndodh me trafikun që nuk duhet të përdorë kurrë WAN-in. pfSense ka sjellje të përcaktuar për rregullat, porta e zgjedhur e të cilave është poshtë, dhe një rregull i gjerë lejimi i mëvonshëm ose një rrugë e paracaktuar mund të anulojnë qëllimin tuaj. Shkruani rezultatin e bllokuar si kërkesë, më pas verifikoni duke e ulur rrugën.

Testoni humbjen dhe rikuperimin veçmas, me trafik që jeni të autorizuar të gjeneroni, dhe vëzhgoni tre gjëra njëherësh: WAN-in që mban lidhjen e jashtme, tunelin që mban kërkesën e aplikacionit dhe rrugën që merr përgjigjja. Një palë treguesish të gjelbër të portës nuk është një nga ata tre. Udhëzuesi i Netgate për shumë WAN përshkruan lidhjen e transportit dhe alternativat e klientit të eksportuara nga të cilat varet kjo.