Nola eraiki VPN failover politika routerrean ihesik gabe

Failoverrak zehazki konfiguratuta zegoen bezala funtzionatu zuen, eta horixe zen arazoa. Tunel nagusia erori zenean, routerrak bide lehenetsia kable-modemera eraman zuen, eramangarriek nabigatzen jarraitu zuten, eta inork ez zuen deitu. Bi egun geroago norbaitek ohartu zen finantza-karpeta partekatua sei orduz egon zela interneteko bide irekian eskuragarri. Routerreko VPN failover politika ez da bideratze-trikia; erabaki bat da, bide hobetsia desagertzen denean trafikoak zer egin behar duen, eta erabaki hori bidea desagertu aurretik egon behar da.

Erabaki emaitza detektorea aukeratu aurretik

Normalean hiru emaitza daude mahai gainean: kaltetutako bezeroak babes-tunel batetik bidaltzea, WAN arrunta erabiltzen uztea edo erabat blokeatzea. Idatzi zein dagokion zein VLAN, SSID edo gailu-klasi. “WAN-era aldatu” arau lau bakarra da goiko finantza-karpeta bide publiko batera iritsi zeneko arrazoia.

Hiru horiek ez dira trukagarriak. WAN bidezko babesak laguntza-mahaia telefonoetara erantzuten mantentzen du, bide batez barne-izenak tokiko resolverera agerian utziz. Babes-tunelak politika gordetzen du, baina beste aldeak onartzen ez duen irteera-helbide batean lurreratu daiteke. Blokeoa zuzena da nominen VLAN baterako eta okerra tunela inoiz erabili ez zuen gonbidatu-sare baterako.

Egokitu detektorea benetan beldur zaren hutsegitera

Handshake-egoera, interfaze-egoera eta erabilgarri den birbidalketa hiru seinale desberdin dira, eta erabiltzailearentzat azkenak bakarrik du garrantzia. WireGuard peer batek duela gutxiko handshake erakuts dezake hornitzailearen upstreamak paketeak zulo beltzera botatzen dituen bitartean. OpenVPN bezeroak “konektatuta” egon daiteke bultzatu zuen bidea ebazteari utzi ondoren.

pfSense-n konponbide praktikoa dpingerrek elikatutako atebide-talde bat da, monitorizazio-helbide bat probatzen duena eta atebidea behera bezala markatzen duena galera edo latentziak haren atalaseak gainditzen dituenean. Zuzendu monitorizazio hori tunelaz harago dagoen zerbaitetara, hala nola urruneko LANeko ostalari bat edo haren bidez iristen zaren helbide publiko bat. Tunelaren beraren peer helbidera zuzentzeak bizirik dagoela badakizun zatia neurtzen du.

Eraiki taldea babesa azken baliabide izan dadin

Erabili mailak eta ez kide-zerrenda lau bat. Nagusia 1. mailan, babes-tunela 2. mailan, WAN 3. mailan politikak onartzen duten VLANetarako soilik. pfSense-n hau System > Routing > Gateway Groups azpian dago: gehitu bi atebideak, eman maila desberdinak, ezarri Trigger Level member down plus packet loss gisa, gorde eta gero aplikatu taldea interfazearen lehenetsi gisa edo behar duten suebaki-arauen Gateway eremuan.

pfSense 2.5 eta berriagoetan OpenVPN bezero-instantzia baterako, instantziaren Default Gateway ezarpenak erabakitzen du tunelak sistemaren bide lehenetsia ordezten duen ala ez. Arauzko politika-bideratzeak espero duzun bezala jokatzen du uste duzun bidea benetan instalatuta dagoenean soilik. Aldaketaren ondoren egiaztatu Status > Gateways, tunelaren egoera-ikonoan fidatu beharrean.

Bi ezarpenek eragiten dute dardara gehiena. Bat hornitzailearen beraren birkonbergentzia baino proba-tarte laburragoa da. Bestea nagusiak eta babesak maila partekatzen duten taldea da, beraz biak une oro hautagarri izaten dira. Gehitu histeresia galera eta latentzia-atalaseen bidez zure erabiltzaileek trantsizioak zure ordez sentitu aurretik.

Itxi tunelak inoiz izan ez zituen bideak

Lehenik DNS ihesak. Resolverrak WAN-en erantzuten jarraitzen du eta handik aurrera bidaltzen du, beraz izenek ISP bidez ebazten jarraitzen dute trafikoa tunelari lotuta dagoen bitartean. Mugatu resolverraren irteera-interfazeak, bultzatu barne-resolverra bezeroetara eta blokeatu 53 portua gainerako guztiarentzat soilik-VPN VLANetan.

IPv6-k bere erabakia behar du. Pila biko LAN batek tunela gal dezake eta funtzionatzen duen IPv6 bide lehenetsi globala gorde, beraz nabigatzaileek IPv6 nahiago dute eta WAN bidez irteten dira, IPv4 erabat itxita dirudien bitartean. Edo bideratu IPv6 tunelera edo utzi prefijo globala iragartzen tunela behera dagoen bitartean. Politika erdia bat ere ez baino okerragoa da, funtzionatzen duela dirudielako.

Gero itzulera-bidea. Babes-irteerak jatorrizko helbide desberdina erabiltzen badu, beste aldeak jakin behar du nola bidali trafikoa hara, eta helbide zaharrarekin lotutako egoera guztiak hilda daude jada. Nagusia erori zenean irekita zeuden saioak ez dira migratzen; geldirik geratzen dira iraungi arte eta aplikazioak erabakitzen du zer egin.

Probatu erorketa, dardara eta itzulera-bidea

Atera nagusia trafiko kaltegabearekin martxan, eta gero irakurri lau gauza: Status > Gateways taldeko kideen egoeretarako, pfctl -ss atebide zaharrari oraindik lotutako egoeretarako, bezero batetik traceroute bat irteera-biderako eta resolver kontsulta bat zein zerbitzarik erantzun zuen ikusteko.

Orain dardarazi. Igo nagusia hogeita hamar segundo, jaitsi hogeita hamar, bi aldiz. Trafikoak trantsizio bakoitzari jarraitzen badio, atalaseak estuegiak dira edo mailak okerrak. Konpondu zure egutegian, bestela hornitzaile batek berean egingo baitu.

Azkenean, egiaztatu routerra administratzen jarrai dezakezula. Mantendu banda kanpoko bide bat, hala nola kontsola-kablea, kudeaketa-VLAN bat edo modem zelularra. Kanporatzen zaituen failover proba bat ezin duzu amaitu, eta iristezin den routerrak ezin du bere kabuz atzera egin.

Politika amaitutzat eman aurretik, lau galderari erantzun behar zenieke terminala ireki gabe: zein VLANek erabil dezakete WAN tunela behera dagoen bitartean, zer zaintzen duen detektoreak eta zenbat itxaroten duen, zein izen-zerbitzarik eta IPv6 bidek mugitzen diren bidearekin, eta nola sartzen zaren berriro babesak ere huts egiten badu. Erantzunen bat “lehenetsia zena” bada, politika oraindik routerrarena da, ez zure.