Kako napraviti politiku prebacivanja VPN-a na routeru bez curenja
Odlučite šta saobraćaj treba da radi kada omiljeni tunel padne: rezervni tunel, običan WAN ili blokada. Zatim to napravite i testirajte na routeru.
Prebacivanje je radilo tačno onako kako je konfigurisano, i to je bio problem. Kada je glavni tunel pao, ruter je premestio podrazumevanu rutu na kablovski modem, laptopovi su nastavili da pregledaju, i niko nije pozvao. Dva dana kasnije neko je primetio da je finansijski deljeni direktorijum bio dostupan preko otvorene internet putanje šest sati. Politika prebacivanja VPN-a na ruteru nije trik rutiranja; to je odluka o tome šta saobraćaj treba da radi kada omiljena putanja nestane, a ta odluka mora postojati pre nego što putanja nestane.
Odlučite o ishodu pre nego što izaberete detektor
Obično su tri ishoda na stolu: poslati pogođene klijente kroz rezervni tunel, pustiti ih da koriste običan WAN ili ih potpuno blokirati. Zapišite koji važi za koji VLAN, SSID ili klasu uređaja. Jedno ravno pravilo „prebaci na WAN” je razlog zašto je gornji finansijski direktorijum završio na javnoj putanji.
Ta tri nisu zamenljiva. Povratak na WAN drži podršku da odgovara na telefone, ali izlaže interna imena lokalnom resolveru. Rezervni tunel čuva politiku, ali može sleteti na izlaznu adresu koju druga strana ne prihvata. Blokada je ispravna za VLAN obračuna plata i pogrešna za gostujuću mrežu koja nikada nije koristila tunel.
| Outcome | Right for | What breaks |
|---|---|---|
| Backup tunnel | Policy must hold, remote access required | New exit address, return route, slower rekey |
| Plain WAN | Guest or public-only traffic | Internal names, DNS and IPv6 exposure |
| Block | Payroll, admin, anything VPN-only | Users lose all access and call you |
Uparite detektor sa kvarom kog se zaista plašite
Stanje rukovanja, stanje interfejsa i upotrebljivo prosleđivanje su tri različita signala, a korisniku je važan samo poslednji. WireGuard peer može pokazivati sveže rukovanje dok upstream provajdera odbacuje pakete. OpenVPN klijent može ostati na „povezano” nakon što ruta koju je gurnuo prestane da se rešava.
Na pfSense praktično rešenje je grupa gejtveja koju napaja dpinger, koji ispituje adresu za nadzor i označava gejtvej kao nedostupan kada gubitak ili kašnjenje pređu pragove. Usmerite taj nadzor na nešto izvan tunela, kao što je host u udaljenom LAN-u ili javna adresa do koje stižete kroz njega. Usmeravanje na sopstvenu adresu peera tunela meri deo za koji već znate da je živ.
Napravite grupu tako da rezerva ostane poslednje sredstvo
Koristite slojeve, a ne jednu ravnu listu članova. Glavni na sloju 1, rezervni tunel na sloju 2, WAN na sloju 3 samo za VLAN-ove čija politika to dozvoljava. U pfSense-u to stoji pod System > Routing > Gateway Groups: dodajte oba gejtveja, dajte im različite slojeve, postavite Trigger Level na nedostupnost člana plus gubitak paketa, sačuvajte, pa primenite grupu kao podrazumevani gejtvej interfejsa ili u polju Gateway pravila firewall-a kojima je potrebna.
Za instancu OpenVPN klijenta na pfSense 2.5 i novijem, podešavanje Default Gateway instance odlučuje da li tunel uopšte zamenjuje sistemsku podrazumevanu rutu. Rutiranje po pravilima ponaša se onako kako očekujete samo kada je ruta koju pretpostavljate zaista instalirana. Posle izmene proverite Status > Gateways umesto da verujete ikoni stanja tunela.
Dve postavke izazivaju većinu treperenja. Jedna je interval ispitivanja kraći od sopstvene rekonvergencije provajdera. Druga je grupa u kojoj glavni i rezervni dele sloj, pa oba ostaju podobna sve vreme. Dodajte histerezu kroz pragove gubitka i kašnjenja pre nego što korisnici sami osete prelaske.
Zatvorite putanje koje tunel nikada nije držao
Prvo curenja DNS-a. Resolver nastavlja da odgovara na WAN-u i prosleđuje kroz njega, pa se imena i dalje rešavaju kroz ISP dok je saobraćaj prikovan za tunel. Ograničite izlazne interfejse resolvera, progurajte interni resolver do klijenata i blokirajte port 53 za sve ostalo na VLAN-ovima samo sa VPN-om.
IPv6 traži sopstvenu odluku. Dual-stack LAN može izgubiti tunel i zadržati ispravnu globalnu IPv6 podrazumevanu rutu, pa pretraživači preferiraju IPv6 i izlaze kroz WAN dok IPv4 izgleda savršeno zatvoren. Ili rutirajte IPv6 u tunel, ili prestanite da oglašavate globalni prefiks dok je tunel pao. 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 na nju, a svako stanje vezano za staru adresu je već mrtvo. Sesije otvorene kada je glavni pao ne migriraju; stoje dok ne isteknu i aplikacija ne odluči šta će s njima.
Testirajte pad, treperenje i put nazad
Izvucite glavni dok radi 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 izazovite treperenje. Podignite glavni na trideset sekundi, spustite na trideset, dva puta. Ako saobraćaj juri svaki prelaz, pragovi su preuski ili su slojevi pogrešni. Popravite to po svom rasporedu, jer će inače provajder to uraditi po svom.
Na kraju potvrdite da još možete da administrirate ruter. Držite putanju van opsega, kao što je konzolni kabl, upravljački VLAN ili mobilni modem. Test prebacivanja koji vas zaključa napolju je test koji ne možete da završite, a ruter do kog se ne može doći ne može sam da se vrati.
Pre nego što proglasite politiku gotovom, treba da možete da odgovorite na četiri pitanja bez otvaranja terminala: koji VLAN-ovi smeju da koriste WAN dok je tunel pao, šta detektor posmatra i koliko čeka, koji serveri imena i IPv6 rute se sele sa putanjom, i kako se vraćate ako i rezerva padne. Ako je bilo koji odgovor „šta god je bilo podrazumevano”, politika još pripada ruteru, a ne vama.