Tatlong uri ng OpenVPN failover sa pfSense, tatlong mekanismo

Sa pfSense, ang „OpenVPN failover“ ay sumasaklaw sa hindi bababa sa tatlong magkaibang disenyo, at bawat isa ay nangangailangan ng ibang mekanismo. Ang pagpapanatiling buhay ng tunnel sa isang backup na internet link, ang muling pagkonekta sa ibang server at ang paghila ng LAN traffic papasok sa isa pang naitatag na tunnel ay hindi mga baryante ng isang feature. Piliin ang pagkabigong ipinagtatanggol mo bago magtayo ng gateway group. Ang grupong nag-aayos ng isa sa kanila ay walang ginagawa para sa dalawa pa.

Pangalanan ang pagkabigo bago magtayo ng grupo

Isulat ang pangungusap na gusto mong maging totoo habang may outage. „Muling kumokonekta ang tunnel sa backup na WAN“ at „nakakarating pa rin ang sangay sa application sa kabilang tunnel“ ay magkaibang pangungusap. Ang una lamang ang tungkol sa transport.

Pagkatapos, itugma ito sa isang mekanismo. Ang pagkawala ng lokal na WAN ay problema sa pagpili ng interface, ang patay na malayong endpoint ay problema sa listahan ng koneksyon, at ang hindi magamit na landas sa loob ng naitatag na tunnel ay problema sa routing at patakaran.

Lokal na WAN: ilipat ang transport

Para sa isang pfSense OpenVPN client, pinipili ng sinusuportahang multi-WAN na kaayusan ang angkop na gateway group bilang interface na kinakabit ng client. Ito ang nagpapahintulot sa panlabas na koneksyon na lumabas sa backup na link kapag bumagsak ang primary. Sa sarili nito ay hindi nito binabago kung paano niruruta ang panloob na traffic.

Ang panig ng server ng parehong disenyo ay hiwalay. Ang OpenVPN server na dapat maabot sa maraming pampublikong address ay nangangailangan ng listener at papasok na patakaran para sa bawat isa sa mga entry na iyon, hindi lamang client na marunong mag-dial sa dalawang link. Ang isang gumaganang pampublikong entry ay hindi patunay na ang pangalawa ay naka-configure.

Ang panuntunan sa routing na batay sa patakaran para sa ipinapadalang LAN packet ay hindi ang setting na naglilipat ng lokal na nilikhang VPN transport koneksyon. Iyon ay dalawang magkaibang paghahanap, at ang pagbabago sa isa ay hindi nagbabago sa isa pa.

Malayong endpoint: ibang server

Ang alternatibong remote ay feature ng listahan ng koneksyon. Sinusubukan ng client ang susunod na entry kapag hindi tumugon ang kasalukuyan, na kapaki-pakinabang kapag bumagsak ang isang partikular na host at hindi kapag bumagsak ang sarili mong uplink. Magkatulad ang itsura ng dalawang pagkabigo mula sa mesa ng gumagamit at nangangailangan ng magkaibang pagwawasto.

Bawat kandidato ay dapat maging tunay na kapalit: tugmang authentication, tugmang patakaran ng client at pag-access sa parehong pribadong resource. Ang ikalawang hostname na nagre-resolve sa parehong sirang imprastruktura ay hindi backup. Ang server na walang kinakailangang ruta ay hindi rin, gaano man kaganda ang itsura ng handshake nito.

Hindi rin pinapadalang sabay ng mekanismong ito ang dalawang tunnel. Pinapalitan nito ang isang koneksyon ng isa pa, nang sunud-sunod, at ang agwat sa pagitan nila ay nakikita ng anumang tumatakbo.

Landas ng tunnel: pumili ng ibang labasan

Kapag nakatayo na ang dalawang tunnel at dapat gamitin ng traffic ang mas malusog, ang mekanismo ay isang itinalagang VPN interface na may sariling gateway, kasama ang malinaw na panuntunan sa patakaran na nagpapadala ng tamang traffic doon. Ang gateway group sa mga itinalagang interface na iyon ay maaaring magpahayag ng priyoridad at pagsubaybay.

Ang disenyong iyon ay tungkol sa pagpili, hindi sa pagbawi. Ang paglilipat ng mga bagong koneksyon sa ikalawang tunnel ay walang sinasabi tungkol sa mga session na naitatag na sa una, at walang sinasabi tungkol sa kung tatanggapin ng kabilang panig ang bagong source address. Ang ituring itong mekanismo ng pagbawi ay ang paraan ng paglalagay ng masyadong mataas na inaasahan.

Kung ang pangangailangan ay dapat mabuhay ang mga umiiral na session, sabihin ito nang malinaw. Karamihan sa mga implementasyon ay hindi naglilipat ng buhay na daloy sa pagitan ng mga tunnel, at ang pagdidisenyo na parang ginagawa nila ay nagbubunga ng failover na mukhang tama sa diagram at sa praktika ay inihuhulog ang bawat bukas na koneksyon.

Mga monitor, NAT at ang fail-closed na panuntunan

Dapat subukan ng monitor ang isang bagay na dapat ihatid ng tunnel. Ang target na tumutugon mula sa kapareha ng tunnel ngunit hindi mula sa application network sa likod nito ay mag-uulat na malusog habang wala namang nakikita ang mga gumagamit. Ang hindi maabot na diagnostic target ay mag-uulat na patay habang maayos ang landas. Piliin ang address nang sadya at kumpirmahin na maabot lamang ito sa nilalayong tunnel.

Suriin ang palabas na NAT para sa dalawang labasan. Ang gumaganang pagsasalin sa primary ay hindi naglalarawan ng source address ng backup, at ang malayong pribadong network ay nangangailangan ng pabalik na ruta na tumutugma sa source na inihaharap mo. Ang pagsasaling tama sa isang landas ay maaaring tahimik na mali sa isa pa.

Pagkatapos, magpasya kung ano ang mangyayari sa traffic na hindi dapat gumamit ng WAN. May tinukoy na pag-uugali ang pfSense para sa mga panuntunang bagsak ang piniling gateway, at ang mas huling malawak na panuntunan sa pagpapadaan o default na ruta ay maaaring sumira sa layunin mo. Isulat ang naka-block na kinalabasan bilang pangangailangan, pagkatapos ay i-verify ito sa pamamagitan ng pagbaba ng landas.

Subukan nang hiwalay ang pagkawala at pagbawi, gamit ang traffic na awtorisado kang likhain, at panoorin ang tatlong bagay nang sabay: ang WAN na nagdadala ng panlabas na koneksyon, ang tunnel na nagdadala ng kahilingan ng application at ang landas na tinatahak ng tugon. Ang isang pares ng berdeng gateway indicator ay hindi isa sa tatlong iyon. Ang gabay ng Netgate sa multi-WAN ay naglalarawan ng pagbuhol ng transport at ng mga inilabas na alternatibo ng client na pinagbabatayan nito.