Si të ndërtosh një politikë VPN failover në router pa rrjedhje

Failover-i funksionoi saktësisht siç ishte konfiguruar, dhe ky ishte problemi. Kur tuneli kryesor ra, router-i e zhvendosi rrugën e paracaktuar te modemi kabllor, laptopët vazhduan të shfletonin dhe askush nuk telefonoi. Dy ditë më vonë dikush vuri re se ndarja financiare kishte qenë e arritshme përmes rrugës së hapur të internetit për gjashtë orë. Një politikë failover VPN në router nuk është një truk rrugëtimi; është një vendim për atë që duhet të bëjë trafiku kur rruga e preferuar zhduket, dhe ky vendim duhet të ekzistojë para se rruga të zhduket.

Vendos rezultatin para se të zgjedhësh detektorin

Zakonisht janë tre rezultate në tryezë: dërgimi i klientëve të prekur përmes një tuneli rezervë, lënia e tyre të përdorin WAN-in e zakonshëm ose bllokimi i tyre plotësisht. Shkruaj cili vlen për cilën VLAN, SSID ose klasë pajisjeje. Një rregull i vetëm i sheshtë «kalo në WAN» është arsyeja pse ndarja financiare më lart përfundoi në një rrugë publike.

Këta të tre nuk janë të këmbyeshëm. Kthimi në WAN e mban mbështetjen duke u përgjigjur në telefon, por zbulon emrat e brendshëm te zgjidhësi lokal. Një tunel rezervë e ruan politikën, por mund të përfundojë në një adresë dalëse që pala e largët nuk e pranon. Bllokimi është i saktë për një VLAN pagash dhe i gabuar për një rrjet mysafirësh që nuk e përdori kurrë tunelin.

Përputh detektorin me dështimin nga i cili vërtet frikësohesh

Gjendja e handshake-ut, gjendja e ndërfaqes dhe përcjellja e përdorshme janë tre sinjale të ndryshme, dhe vetëm i fundit ka rëndësi për përdoruesin. Një peer WireGuard mund të tregojë një handshake të freskët ndërsa rrjeti i sipërm i ofruesit hedh paketa. Një klient OpenVPN mund të qëndrojë në «i lidhur» pasi rruga që shtyu nuk zgjidhet më.

Në pfSense, rregullimi praktik është një grup gateway-sh i ushqyer nga dpinger, i cili provon një adresë monitorimi dhe e shënon një gateway si jashtë kur humbja ose vonesa kalojnë pragjet. Ktheje atë monitor drejt diçkaje përtej tunelit, si një host në LAN-in e largët ose një adresë publike që arrin përmes tij. Kthimi drejt adresës së peer-it të vetë tunelit mat pjesën që tashmë e di se është e gjallë.

Ndërto grupin që rezerva të mbetet zgjidhja e fundit

Përdor nivele në vend të një liste të sheshtë anëtarësh. Kryesori në nivelin 1, tuneli rezervë në nivelin 2, WAN në nivelin 3 vetëm për VLAN-et që politika e lejon. Në pfSense kjo ndodhet në System > Routing > Gateway Groups: shto të dy gateway-t, jepu nivele të ndryshme, vendos Trigger Level në anëtar jashtë plus humbje paketash, ruaj dhe pastaj apliko grupin si paracaktim i ndërfaqes ose në fushën Gateway të rregullave të firewall-it që e kanë nevojë.

Për një instancë klienti OpenVPN në pfSense 2.5 e më vonë, cilësimi Default Gateway i instancës vendos nëse tuneli e zëvendëson fare rrugën e paracaktuar të sistemit. Rrugëtimi me rregulla sillet ashtu siç pret vetëm kur rruga që supozon ekziston vërtet e instaluar. Pas ndryshimit kontrollo Status > Gateways në vend që t'i besosh ikonës së statusit të tunelit.

Dy cilësime shkaktojnë pjesën më të madhe të dridhjeve. Njëri është një interval prove më i shkurtër se rikonvergjenca e vetë ofruesit. Tjetri është një grup ku kryesori dhe rezerva ndajnë një nivel, kështu që të dy mbeten të përshtatshëm gjatë gjithë kohës. Shto histerezë përmes pragjeve të humbjes dhe vonesës përpara se përdoruesit t'i ndjejnë vetë kalimet.

Mbyll rrugët që tuneli nuk i zotëroi kurrë

Së pari rrjedhjet e DNS. Zgjidhësi vazhdon të përgjigjet në WAN dhe të përcjellë prej saj, kështu që emrat vazhdojnë të zgjidhen përmes ISP-së ndërsa trafiku është i gozhduar te tuneli. Kufizo ndërfaqet dalëse të zgjidhësit, shtyj zgjidhësin e brendshëm te klientët dhe blloko portën 53 për gjithçka tjetër në VLAN-et vetëm me VPN.

IPv6 kërkon vendimin e vet. Një LAN me dy stack mund të humbasë tunelin dhe të mbajë një rrugë të paracaktuar globale IPv6 që funksionon, kështu që shfletuesit preferojnë IPv6 dhe dalin përmes WAN ndërsa IPv4 duket plotësisht i përmbajtur. Ose rrugëto IPv6 në tunel, ose ndalo shpalljen e një prefiksi global ndërsa tuneli është jashtë. Gjysmë politike është më keq se asnjë, sepse duket sikur funksionon.

Pastaj rruga e kthimit. Nëse dalja rezervë përdor një adresë burimore të ndryshme, pala e largët duhet të dijë si të dërgojë trafikun përsëri tek ajo, dhe çdo gjendje e lidhur me adresën e vjetër tashmë është e vdekur. Sesionet e hapura kur ra kryesori nuk migrojnë; ngecin derisa të skadojnë dhe aplikacioni të vendosë çfarë të bëjë.

Testo rënien, dridhjen dhe rrugën e kthimit

Hiq kryesorin me trafik të padëmshëm në punë, pastaj lexo katër gjëra: Status > Gateways për gjendjet e anëtarëve të grupit, pfctl -ss për gjendjet ende të gozhduara te gateway-i i vjetër, një traceroute nga një klient për rrugën dalëse dhe një pyetje zgjidhësi për të parë cili server u përgjigj.

Tani shkakto dridhje. Ngrije kryesorin tridhjetë sekonda, ule tridhjetë, dy herë. Nëse trafiku ndjek çdo kalim, pragjet janë shumë të ngushta ose nivelet janë të gabuara. Rregulloji sipas orarit tënd, sepse përndryshe një ofrues do ta bëjë sipas të vetit.

Së fundi, konfirmo se ende mund ta administrosh router-in. Mbaj një rrugë jashtë brezit, si një kabllo konsol, një VLAN menaxhimi ose një modem celular. Një test failover që të mbyll jashtë është një test që nuk mund ta përfundosh, dhe një router i paarritshëm nuk mund të kthehet vetë.

Para se ta shpallësh politikën të përfunduar, duhet të jesh në gjendje t'u përgjigjesh katër pyetjeve pa hapur një terminal: cilat VLAN mund të përdorin WAN ndërsa tuneli është jashtë, çfarë vëzhgon detektori dhe sa pret, cilët serverë emrash dhe rrugë IPv6 lëvizin me rrugën, dhe si rihyn nëse edhe rezerva dështon. Nëse ndonjë përgjigje është «çfarëdo që ishte parazgjedhur», politika ende i përket router-it dhe jo ty.