Cum să construiești o politică de failover VPN pe router fără scurgeri

Failover-ul a funcționat exact cum a fost configurat, și asta a fost problema. Când tunelul principal a căzut, routerul a mutat ruta implicită către modemul prin cablu, laptopurile au continuat să navigheze și nimeni nu a sunat. Două zile mai târziu cineva a observat că partajarea financiară fusese accesibilă prin calea deschisă a internetului timp de șase ore. O politică de failover VPN pe router nu este un truc de rutare; este o decizie despre ce trebuie să facă traficul când calea preferată dispare, iar decizia trebuie să existe înainte ca calea să dispară.

Decide rezultatul înainte de a alege detectorul

De obicei sunt trei rezultate pe masă: trimite clienții afectați printr-un tunel de rezervă, lasă-i să folosească WAN-ul obișnuit sau blochează-i complet. Notează care se aplică pentru fiecare VLAN, SSID sau clasă de dispozitive. O singură regulă plată „treci pe WAN” este motivul pentru care partajarea financiară de mai sus a ajuns pe o cale publică.

Cele trei nu sunt interschimbabile. Revenirea pe WAN ține un birou de suport la telefon, dar expune numele interne resolverului local. Un tunel de rezervă păstrează politica, dar poate ateriza pe o adresă de ieșire pe care partea îndepărtată nu o acceptă. Blocarea este corectă pentru un VLAN de salarizare și greșită pentru o rețea de oaspeți care nu a folosit niciodată tunelul.

Potrivește detectorul cu defecțiunea de care te temi cu adevărat

Starea handshake-ului, starea interfeței și forwardingul utilizabil sunt trei semnale diferite, iar pentru utilizator contează doar ultimul. Un peer WireGuard poate arăta un handshake recent în timp ce upstreamul furnizorului aruncă pachete. Un client OpenVPN poate sta pe „conectat” după ce ruta pe care a împins-o nu mai poate fi rezolvată.

Pe pfSense, aranjamentul practic este un grup de gateway-uri alimentat de dpinger, care testează o adresă de monitorizare și marchează un gateway ca indisponibil când pierderea sau latența depășesc pragurile. Îndreaptă acel monitor către ceva dincolo de tunel, cum ar fi un host din LAN-ul îndepărtat sau o adresă publică accesibilă prin el. Dacă îl îndrepți spre adresa peerului tunelului, măsori partea despre care știi deja că e vie.

Construiește grupul astfel încât rezerva să rămână ultima opțiune

Folosește niveluri, nu o listă plată de membri. Principalul pe nivelul 1, tunelul de rezervă pe nivelul 2, WAN pe nivelul 3 doar pentru VLAN-urile a căror politică permite asta. În pfSense acest lucru se află sub System > Routing > Gateway Groups: adaugă ambele gateway-uri, dă-le niveluri diferite, setează Trigger Level la membru căzut plus pierdere de pachete, salvează, apoi aplică grupul ca implicit al interfeței sau în câmpul Gateway al regulilor de firewall care au nevoie de el.

Pentru o instanță de client OpenVPN pe pfSense 2.5 și mai nou, setarea Default Gateway a instanței decide dacă tunelul înlocuiește deloc ruta implicită a sistemului. Rutarea după reguli se comportă așa cum te aștepți doar când ruta pe care o presupui există este chiar instalată. Verifică Status > Gateways după modificare în loc să te bazezi pe pictograma de stare a tunelului.

Două setări cauzează cea mai mare parte a flappingului. Una este un interval de sondare mai scurt decât reconvergența proprie a furnizorului. Cealaltă este un grup în care principalul și rezerva împart același nivel, așa că ambele rămân eligibile tot timpul. Adaugă histerezis prin praguri de pierdere și latență înainte ca utilizatorii să simtă tranzițiile pentru tine.

Închide căile pe care tunelul nu le-a controlat niciodată

Mai întâi scurgerile DNS. Resolverul continuă să răspundă pe WAN și să trimită mai departe pe acolo, așa că numele se rezolvă în continuare prin ISP în timp ce traficul este fixat pe tunel. Restrânge interfețele de ieșire ale resolverului, împinge resolverul intern la clienți și blochează portul 53 pentru tot restul din VLAN-urile doar-VPN.

IPv6 are nevoie de propria decizie. Un LAN dual-stack poate pierde tunelul și poate păstra o rută implicită IPv6 globală funcțională, așa că browserele preferă IPv6 și ies prin WAN în timp ce IPv4 pare perfect izolat. Fie rutezi IPv6 în tunel, fie oprești anunțarea unui prefix global cât timp tunelul este căzut. O jumătate de politică este mai rea decât niciuna, pentru că pare că funcționează.

Apoi calea de întoarcere. Dacă ieșirea de rezervă folosește o altă adresă de sursă, partea îndepărtată trebuie să știe cum să trimită traficul înapoi la ea, iar fiecare stare legată de adresa veche este deja moartă. Sesiunile deschise când a căzut principalul nu migrează; stau până expiră și aplicația decide ce face.

Testează căderea, flappingul și calea de întoarcere

Scoate principalul cu trafic inofensiv în rulare, apoi citește patru lucruri: Status > Gateways pentru stările membrilor grupului, pfctl -ss pentru stările încă fixate pe gateway-ul vechi, un traceroute de la un client pentru calea de ieșire și o interogare către resolver ca să vezi ce server a răspuns.

Acum provoacă flapping. Ridică principalul treizeci de secunde, coboară-l treizeci, de două ori. Dacă traficul urmărește fiecare tranziție, pragurile sunt prea strânse sau nivelurile sunt greșite. Repară asta în ritmul tău, pentru că altfel un furnizor o va face în ritmul lui.

În final, confirmă că poți administra în continuare routerul. Păstrează o cale în afara benzii, cum ar fi un cablu de consolă, un VLAN de management sau un modem celular. Un test de failover care te blochează afară este un test pe care nu îl poți termina, iar un router inaccesibil nu poate reveni singur.

Înainte să declari politica gata, ar trebui să poți răspunde la patru întrebări fără să deschizi un terminal: ce VLAN-uri pot folosi WAN-ul cât timp tunelul este căzut, ce urmărește detectorul și cât așteaptă, ce servere de nume și rute IPv6 se mută odată cu calea și cum reintri dacă și rezerva eșuează. Dacă vreun răspuns este „oricare era implicitul”, politica aparține încă routerului, nu ție.