OpenVPN failover mota hiru pfSense-n, mekanismo hiru

pfSense-n „OpenVPN failover“-ek gutxienez hiru diseinu erlaziorik gabeko biltzen ditu, eta bakoitzak mekanismo desberdina behar du. Tunel bat bizirik edukitzea babesko internet lotura baten bidez, beste zerbitzari batera berriro konektatzea eta LAN trafikoa jadanik ezarrita dagoen beste tunel batera bideratzea ez dira funtzio beraren aldaerak. Aukeratu zein hutsegiteren aurka defendatzen zaren atezain talde bat eraiki aurretik. Horietako bat konpontzen duen taldeak ez du ezer egiten beste bietarako.

Izenda ezazu hutsegitea taldea eraiki aurretik

Idatzi etenaldi batean egia izatea nahi duzun esaldia. „Tunela babesko WAN-etik berriro konektatzen da“ eta „sukurtsalak oraindik beste tunelaren bidez lortzen du aplikazioa“ esaldi desberdinak dira. Lehena bakarrik da garraioari buruzkoa.

Ondoren parekatu mekanismo batekin. Tokiko WAN galtzea interfazea hautatzeko arazoa da, urruneko mutur hila konexio zerrendako arazoa da, eta ezarritako tunel baten barruko bide erabilezina bideratze eta politika arazoa da.

Tokiko WAN: mugitu garraioa

pfSense OpenVPN bezeroarentzat, onartutako WAN anitzeko antolamenduak atezain talde egokia hautatzen du bezeroa lotzen zaion interfaze gisa. Horrek uzten dio kanpoko konexioari babesko loturatik irteten lehenengoak huts egiten duenean. Berez ez du aldatzen barneko trafikoa nola bideratzen den.

Diseinu beraren zerbitzari aldea bereizia da. Hainbat helbide publikotatik irisgarria izan behar duen OpenVPN zerbitzari batek entzule bat eta sarrera politika bat behar ditu sarrera horietako bakoitzerako, ez bakarrik bi loturatik deitzeko gai den bezero bat. Funtzionatzen duen sarrera publiko bat ez da bigarrena konfiguratuta dagoen froga.

Birbidalitako LAN paketeentzako politiketan oinarritutako bideratze araua ez da tokian sortutako VPN garraio konexioa mugitzen duen ezarpena. Bi bilaketa desberdin dira, eta bata aldatzeak ez du bestea aldatzen.

Urruneko muturra: beste zerbitzari bat

Remote alternatiboa konexio zerrendaren funtzioa da. Bezeroak hurrengo sarrera probatzen du unekoak erantzuten ez duenean, eta hori erabilgarria da host jakin bat hilda dagoenean, ez zure uplink propioa hilda dagoenean. Bi hutsegiteak berdinak dirudite erabiltzailearen mahaitik eta konponketa desberdinak behar dituzte.

Hautagai bakoitzak ordezko erreala izan behar du: autentifikazio bateragarria, bezero politika bateragarria eta baliabide pribatu berberetarako sarbidea. Infrastruktura hautsitik berbera ebazten duen bigarren host izen bat ez da babeskoa. Behar den biderik ez duen zerbitzari bat ere ez, oso osasuntsu dirudiela ere bere esku-emateak.

Mekanismo honek ez ditu bi tunel aldi berean bidaltzen. Konexio bat beste batekin ordezten du, sekuentzialki, eta bien arteko hutsunea ikusgai da martxan zegoen guztiarentzat.

Tunelaren bidea: aukeratu beste irteera bat

Bi tunel jada zutik daudenean eta trafikoak osasuntsuena erabili behar duenean, mekanismoa bere atezain propioa duen esleitutako VPN interfaze bat da, gehi trafikoa zuzena bertara bidaltzen duen politika arau esplizitu bat. Esleitutako interfaze horien gaineko atezain talde batek lehentasuna eta monitorizazioa adieraz ditzake.

Diseinu hori hautaketari buruzkoa da, ez berreskuratzeari. Konexio berriak bigarren tunelera mugitzeak ez du ezer esaten lehenengoan jadanik ezarrita dauden saioei buruz, ezta urruneko aldeak jatorri helbide berria onartuko duen ere. Berreskuratze mekanismotzat hartzea itxaropenak oso goian jartzeko modua da.

Baldintza existitzen diren saioek bizirautea bada, esan ezazu argi. Inplementazio gehienek ez dute fluxu bizirik tunelen artean migratzen, eta hala egiten dutela pentsatuz diseinatzeak diagraman zuzena dirudien failover bat sortzen du eta praktikan irekitako konexio guztiak erortzen ditu.

Monitoreak, NAT eta fail-closed araua

Monitoreak tunelak eman behar duen zerbait probatu beharko luke. Tunelaren kidearengandik erantzuten duen baina atzean dagoen aplikazio sarearentzat erantzuten ez duen helburu batek osasuntsu jakinaraziko du erabiltzaileek ezer ikusten ez duten bitartean. Helbide ezirisgarriko diagnostiko helburu batek hilda jakinaraziko du bidea ondo dagoenean. Aukeratu helbidea nahita eta berretsi helbide hori aurreikusi den tunelaren bidez bakarrik irisgarria dela.

Egiaztatu irteera NAT bi irteeretarako. Lehenengoaren gainean funtzionatzen duen itzulpenak ez du babeskoaren jatorri helbidea deskribatzen, eta urruneko sare pribatuak aurkezten duzun jatorriari dagokion itzulera bidea behar du. Bide batean zuzena den itzulpena beste bidean isilpean oker egon daiteke.

Ondoren erabaki zer gertatzen zaion trafikoari, inoiz WAN-a erabili behar ez duenari. pfSense-k jokabide definitua du hautatutako atezaina hilda duten arauetarako, eta geroagoko onarpen arau zabal batek edo bide lehenetsi batek zure asmoa baliogabetu dezake. Idatzi blokeatutako emaitza baldintza gisa, eta egiaztatu bidea jaitsiz.

Probatu galera eta berreskurapena bereizita, sortzeko baimena duen trafikoarekin, eta behatu hiru gauza aldi berean: kanpoko konexioa daraman WAN-a, aplikazioaren eskaera daraman tunela eta erantzunak hartzen duen bidea. Atezain adierazle berde pare bat ez da hiru horietako bat. Netgate-ren WAN anitzeko gida garraioaren lotura eta honen oinarri diren bezero alternatiba esportatuak deskribatzen ditu.