Kako izgraditi VPN failover politiku na ruteru bez curenja
Odredite šta saobraćaj treba da radi kada preferirani tunel padne: rezervni tunel, običan WAN ili blokada. Zatim to izgradite i testirajte na ruteru.
Failover je radio tačno kako je konfigurisan, i upravo je to bio problem. Kada je primarni tunel pao, ruter je premjestio podrazumijevanu rutu na kablovski modem, laptopovi su nastavili da pregledaju, i niko nije nazvao. Dva dana kasnije neko je primijetio da je finansijski dijeljeni direktorij bio dostupan preko otvorene internet putanje šest sati. VPN failover politika na ruteru nije trik sa rutiranjem; to je odluka o tome šta saobraćaj treba da radi kada preferirana putanja nestane, i ta odluka mora postojati prije nego putanja nestane.
Odredite ishod prije nego što odaberete detektor
Obično su na stolu tri ishoda: poslati pogođene klijente kroz rezervni tunel, pustiti ih na običan WAN ili ih potpuno blokirati. Zapišite koji se odnosi na koji VLAN, SSID ili klasu uređaja. Jedno ravno pravilo “prebaci na WAN” je način na koji je finansijski direktorij iznad završio na javnoj putanji.
Ta tri nisu zamjenjiva. WAN rezerva drži podršku da odgovara na telefone dok izlaže interna imena lokalnom resolveru. Rezervni tunel čuva politiku, ali može sletjeti na izlaznu adresu koju druga strana ne prihvata. Blokada je ispravna za VLAN obračuna plata i pogrešna za gostinsku mrežu koja nikada nije koristila tunel.
| Ishod | Za koga je | Šta se kvari |
|---|---|---|
| Rezervni tunel | Politika mora da važi, potreban udaljeni pristup | Nova izlazna adresa, povratna ruta, sporije obnavljanje ključa |
| Običan WAN | Gostinski ili samo javni saobraćaj | Interna imena, izlaganje DNS-a i IPv6 |
| Blokada | Plate, administracija, sve samo-VPN | Korisnici gube svaki pristup i zovu vas |
Uskladite detektor sa kvarom kojeg se zaista plašite
Stanje rukovanja, stanje interfejsa i upotrebljivo prosljeđivanje su tri različita signala, i korisniku je važan samo posljednji. WireGuard peer može pokazivati nedavno rukovanje dok provajderov upstream baca pakete u crnu rupu. OpenVPN klijent može stajati na “povezan” nakon što ruta koju je gurnuo prestane da se razrješava.
Na pfSense praktično rješenje je grupa gejtveja koju hrani dpinger, koji provjerava adresu za monitoring i označava gejtvej kao neispravan kada gubitak ili latencija pređu njegove pragove. Usmjerite taj monitoring na nešto izvan tunela, poput hosta na udaljenom LAN-u ili javne adrese do koje dolazite kroz njega. Usmjeravanje na vlastitu peer adresu tunela mjeri dio za koji već znate da je živ.
Izgradite grupu tako da rezerva ostane posljednje sredstvo
Koristite nivoe umjesto jednog ravnog spiska članova. Primarni na nivou 1, rezervni tunel na nivou 2, WAN na nivou 3 samo za VLAN-ove čija politika to dozvoljava. U pfSense-u to se nalazi pod System > Routing > Gateway Groups: dodajte oba gejtveja, dajte im različite nivoe, postavite Trigger Level na member down plus packet loss, sačuvajte, a zatim primijenite grupu kao zadatu vrijednost interfejsa ili u polje Gateway pravila firewall-a kojima je potrebna.
Za klijentsku instancu OpenVPN-a na pfSense 2.5 i novijem, postavka Default Gateway instance odlučuje da li tunel uopšte zamjenjuje sistemsku podrazumijevanu rutu. Rutiranje politike po pravilu ponaša se onako kako očekujete samo kada je ruta koju pretpostavljate zaista instalirana. Provjerite Status > Gateways nakon promjene umjesto da vjerujete ikoni statusa tunela.
Dvije postavke izazivaju većinu podrhtavanja. Jedna je interval provjere kraći od provajderovog vlastitog rekonvergiranja. Druga je grupa u kojoj primarni i rezervni dijele nivo, pa oba ostaju podobna cijelo vrijeme. Dodajte histerezu kroz pragove gubitka i latencije prije nego što korisnici osjete prelaze umjesto vas.
Zatvorite putanje koje tunel nikada nije posjedovao
Prvo curenja DNS-a. Resolver nastavlja da odgovara na WAN-u i prosljeđuje kroz njega, pa se imena nastavljaju razrješavati kroz provajdera dok je saobraćaj prikovan za tunel. Ograničite izlazne interfejse resolvera, gurnite interni resolver klijentima i blokirajte port 53 za sve ostalo na VLAN-ovima samo-VPN.
IPv6 zahtijeva vlastitu odluku. Dual-stack LAN može izgubiti tunel i zadržati funkcionalnu globalnu podrazumijevanu rutu IPv6, pa pretraživači preferiraju IPv6 i izlaze kroz WAN dok IPv4 izgleda savršeno zatvoren. Ili rutirajte IPv6 u tunel ili prestanite oglašavati globalni prefiks dok je tunel dole. Pola politike je gore od nikakve, jer izgleda kao da radi.
Zatim povratna putanja. Ako rezervni izlaz koristi drugu izvornu adresu, druga strana mora znati kako da pošalje saobraćaj nazad, a svako stanje vezano za staru adresu već je mrtvo. Sesije otvorene kada je primarni pao ne migriraju; stoje dok ne isteknu i aplikacija odluči šta će s tim.
Testirajte pad, podrhtavanje i put nazad
Izvucite primarni uz bezopasan saobraćaj, pa pročitajte četiri stvari: Status > Gateways za stanja članova grupe, pfctl -ss za stanja još prikovana za stari gejtvej, traceroute sa klijenta za izlaznu putanju i upit resolveru da vidite koji je server odgovorio.
Sada ga podrhtajte. Podignite primarni na trideset sekundi, spustite na trideset, dvaput. Ako saobraćaj prati svaki prelaz, pragovi su preuski ili su nivoi pogrešni. Popravite to po svom rasporedu, jer će inače provajder to učiniti po svom.
Na kraju potvrdite da još možete administrirati ruter. Držite vanpojasnu putanju poput konzolnog kabla, VLAN-a za upravljanje ili mobilnog modema. Failover test koji vas zaključa je test koji ne možete završiti, a nedostupan ruter ne može se sam vratiti.
Prije nego što politiku proglasite gotovom, treba da bez otvaranja terminala možete odgovoriti na četiri pitanja: koji VLAN-ovi smiju koristiti WAN dok je tunel dole, šta detektor gleda i koliko čeka, koji se serveri imena i IPv6 rute kreću s putanjom i kako se vraćate ako i rezerva padne. Ako je bilo koji odgovor “šta god je bilo podrazumijevano”, politika još pripada ruteru, a ne vama.