Korleis byggje ein VPN-failoverpolitikk på rutaren utan lekkasjar

Failoveren fungerte nøyaktig som konfigurert, og det var nettopp problemet. Då den primære tunnelen fall, flytta rutaren standardruta til kabelmodemet, berbare datamaskiner heldt fram med å surfe, og ingen ringde. To dagar seinare la nokon merke til at finansmappa hadde vore tilgjengeleg over den opne internettvegen i seks timar. Ein VPN-failoverpolitikk på rutaren er ikkje eit rutetriks; det er ei avgjerd om kva trafikken skal gjere når den føretrekte vegen er borte, og den avgjerda må finnast før vegen forsvinn.

Avgjer utfallet før du vel detektoren

Vanlegvis er det tre utfall på bordet: senda råka klientar gjennom ein reserve-tunnel, la dei bruke vanleg WAN, eller blokkere dei heilt. Skriv ned kva som gjeld for kva VLAN, SSID eller einingklasse. Éin flat “byt til WAN”-regel er grunnen til at finansmappa ovanfor hamna på ein open veg.

Dei tre er ikkje utskiftbare. WAN-fallback held ein støttedisk i gang med å ta telefonar medan han eksponerer interne namn for den lokale resolvaren. Ein reserve-tunnel bevarer politikken, men kan lande på ei utgangsadresse som den andre sida ikkje godtek. Blokkering er rett for ein løn-VLAN og feil for eit gjestenettverk som aldri har brukt tunnelen.

Tilpass detektoren til feilen du faktisk fryktar

Handtrykkstatus, grensesnittstatus og brukbar vidaresending er tre ulike signal, og berre det siste betyr noko for ein brukar. Ein WireGuard-peer kan vise eit nyleg handtrykk medan oppstraumen hjå leverandøren kastar pakkar i eit svart hol. OpenVPN klienten kan bli ståande på “tilkopla” etter at ruta han dytta ut slutta å bli løyst opp.

På pfSense er den praktiske ordninga ei gateway-gruppe som blir fôra av dpinger, som testar ei overvakingsadresse og merkjer ei gateway som nede når tap eller latens kryssar tersklane. Retta den overvakinga mot noko utanfor tunnelen, til dømes ein vert på det fjerne LANet eller ei open adresse du når gjennom han. Å retta henne mot peer-adressa til sjølve tunnelen måler den delen du alt veit er levande.

Bygg gruppa slik at reserve-tunnelen blir den siste utvegen

Bruk nivå i staden for éi flat medlemsliste. Primær i nivå 1, reserve-tunnel i nivå 2, WAN i nivå 3 berre for dei VLAN-a der politikken tillèt det. I pfSense ligg dette under System > Routing > Gateway Groups: legg til båe gatewayane, gje dei ulike nivå, set Trigger Level til member down plus packet loss, lagre, og bruk så gruppa som grensesnittstandard eller i Gateway-feltet i brannmurreglane som treng henne.

For ein OpenVPN-klientinstans på pfSense 2.5 og nyare avgjer Default Gateway-innstillinga til instansen om tunnelen i det heile erstattar systemets standardrute. Policyrutering etter regel oppfører seg som venta berre når ruta du føreset finst, faktisk er installert. Kontroller Status > Gateways etter endringa i staden for å stole på tunnelstatusikonet.

To innstillingar skaper mesteparten av flagringa. Den eine er eit probeintervall som er kortare enn leverandøren si eiga rekonvergens. Den andre er ei gruppe der primær og reserve deler nivå, slik at båe blir verande kvalifiserte heile tida. Legg til hysterese via tersklar for tap og latens før brukarane dine kjenner overgangane i staden for deg.

Lat att vegane tunnelen aldri åtte

Fyrst DNS-lekkasjar. Resolvaren held fram med å svare på WAN og vidaresende ut derfrå, så namn held fram med å bli løyst opp gjennom ISP-en medan trafikken er fest til tunnelen. Avgrense dei utgåande grensesnitta til resolvaren, dytt den interne resolvaren til klientane, og blokker port 53 for alt anna på berre-VPN-VLAN-a.

IPv6 treng si eiga avgjerd. Eit dual-stack-LAN kan miste tunnelen og halde på ei fungerande global IPv6-standardrute, så nettlesarar føretrekk IPv6 og går ut via WAN medan IPv4 ser perfekt inneslutta ut. Anten ruter du IPv6 inn i tunnelen, eller du sluttar å annonsere eit globalt prefiks medan tunnelen er nede. Ein halv politikk er verre enn ingen, fordi han ser ut til å verke.

Så returvegen. Viss reserve-utgangen brukar ei anna kjeldeadresse, må den andre sida vite korleis trafikken skal sendast attende, og kvar tilstand knytt til den gamle adressa er alt død. Økter som var opne då primæren fall, migrerer ikkje; dei står til dei går ut, og applikasjonen avgjer kva han gjer med det.

Test fallet, flagringa og vegen attende

Trekk ut primæren med harmlaus trafikk køyrande, og les så fire ting: Status > Gateways for medlemstilstandane i gruppa, pfctl -ss for tilstandar som framleis er feste til den gamle gatewayen, ein traceroute frå ein klient for utgangsvegen og ein resolvarførespurnad for å sjå kva server som svara.

Flagre han no. Ta primæren opp i tretti sekund, ned i tretti, to gonger. Viss trafikken jagar kvar overgang, er tersklane for stramme eller nivåa feil. Fiks det etter din tidsplan, for elles gjer ein leverandør det etter sin.

Stadfest til slutt at du framleis kan administrere rutaren. Hald ein ut-av-band-veg som ein konsollkabel, eit administrasjons-VLAN eller eit mobilt modem. Ein failovertest som låser deg ute, er ein test du ikkje kan fullføre, og ein utilgjengeleg rutar kan ikkje falle attende av seg sjølv.

Før du kallar politikken ferdig, bør du kunne svare på fire spørsmål utan å opne ein terminal: kva VLAN som kan bruke WAN medan tunnelen er nede, kva detektoren overvakar og kor lenge han ventar, kva namneservarar og IPv6-ruter som flyttar seg med vegen, og korleis du kjem inn att viss reserve-tunnelen også feilar. Viss noko svar er “kva standarden no var”, høyrer politikken framleis til rutaren og ikkje til deg.