Preklop je deloval točno tako, kot je bil nastavljen, in prav to je bila težava. Ko je primarni tunel padel, je usmerjevalnik premaknil privzeto pot na kabelski modem, prenosniki so brskali naprej in nihče ni poklical. Dva dni pozneje je nekdo opazil, da je bila finančna mapa šest ur dosegljiva prek odprte internetne poti. Politika preklopa VPN na usmerjevalniku ni trik usmerjanja; je odločitev o tem, kaj naj promet stori, ko prednostna pot izgine, in ta odločitev mora obstajati, preden pot izgine.

Odločite se o izidu, preden izberete detektor

Običajno so na mizi trije izidi: prizadete odjemalce poslati skozi rezervni tunel, pustiti jim običajen WAN ali jih povsem blokirati. Zapišite, kateri velja za kateri VLAN, SSID ali razred naprav. Eno ravno pravilo »preklopi na WAN« je razlog, da je zgornja finančna mapa pristala na javni poti.

Ti trije niso zamenljivi. Vrnitev na WAN ohrani podporo pri telefonih, a izpostavi notranja imena lokalnemu razreševalniku. Rezervni tunel ohrani politiko, a lahko pristane na izhodnem naslovu, ki ga druga stran ne sprejme. Blokada je pravilna za VLAN plač in napačna za gostujoče omrežje, ki tunela nikoli ni uporabljalo.

OutcomeRight forWhat breaks
Backup tunnelPolicy must hold, remote access requiredNew exit address, return route, slower rekey
Plain WANGuest or public-only trafficInternal names, DNS and IPv6 exposure
BlockPayroll, admin, anything VPN-onlyUsers lose all access and call you

Uskladite detektor z okvaro, ki se je res bojite

Stanje rokovanja, stanje vmesnika in uporabno posredovanje so trije različni signali in uporabniku je pomemben le zadnji. WireGuardov peer lahko kaže sveže rokovanje, medtem ko ponudnikov nadrejeni odsek zavrača pakete. Odjemalec OpenVPN lahko ostane v stanju »povezan«, potem ko se pot, ki jo je potisnil, ne razrešuje več.

V pfSense je praktična rešitev skupina prehodov, ki jo napaja dpinger; ta preverja naslov za nadzor in prehod označi kot nedosegljiv, ko izguba ali zakasnitev preseže pragove. Ta nadzor usmerite v nekaj onkraj tunela, na primer gostitelja v oddaljenem LAN ali javni naslov, dosegljiv skozi tunel. Usmerjanje na lastni naslov peerja tunela meri del, za katerega že veste, da je živ.

Zgradite skupino tako, da rezerva ostane zadnja možnost

Uporabite ravni namesto enega ravnega seznama članov. Primarni na ravni 1, rezervni tunel na ravni 2, WAN na ravni 3 le za VLAN, katerih politika to dovoljuje. V pfSense je to pod System > Routing > Gateway Groups: dodajte oba prehoda, jima dodelite različni ravni, nastavite Trigger Level na nedosegljivost člana in izgubo paketov, shranite in nato skupino uporabite kot privzeti prehod vmesnika ali v polju Gateway pravil požarnega zidu, ki jo potrebujejo.

Za primerek odjemalca OpenVPN v pfSense 2.5 in novejšem nastavitev Default Gateway primerka odloča, ali tunel sploh nadomesti sistemsko privzeto pot. Usmerjanje po pravilih se obnaša tako, kot pričakujete, le kadar je pot, ki jo predpostavljate, res nameščena. Po spremembi preverite Status > Gateways, namesto da bi zaupali ikoni stanja tunela.

Dve nastavitvi povzročata večino utripanja. Ena je interval preverjanja, krajši od ponudnikove lastne ponovne konvergence. Druga je skupina, kjer si primarni in rezervni delita raven, zato ostaneta oba ves čas primerna. Dodajte histerezo prek pragov izgube in zakasnitve, preden uporabniki sami občutijo prehode.

Zaprite poti, ki jih tunel ni nikoli imel

Najprej uhajanja DNS. Razreševalnik še naprej odgovarja na WAN in posreduje skoznjo, zato se imena še vedno razrešujejo prek ponudnika, medtem ko je promet pripet na tunel. Omejite izhodne vmesnike razreševalnika, potisnite notranji razreševalnik do odjemalcev in blokirajte vrata 53 za vse drugo v VLAN samo z VPN.

IPv6 potrebuje svojo odločitev. Dvostacki LAN lahko izgubi tunel in obdrži delujočo globalno privzeto pot IPv6, zato brskalniki raje izberejo IPv6 in odidejo skozi WAN, medtem ko je IPv4 videti popolnoma zaprt. Bodisi usmerite IPv6 v tunel bodisi nehajte oglaševati globalni predpono, dokler je tunel mrtev. Polovica politike je slabša od nobene, ker je videti, kot da deluje.

Nato povratna pot. Če rezervni izhod uporablja drug izvorni naslov, mora druga stran vedeti, kako poslati promet nazaj nanj, in vsako stanje, vezano na stari naslov, je že mrtvo. Seje, odprte ob padcu primarnega, ne migrirajo; obtičijo, dokler ne potečejo in aplikacija ne odloči, kaj z njimi.

Preizkusite padec, utripanje in pot nazaj

Izklopite primarni ob neškodljivem prometu, nato preberite štiri stvari: Status > Gateways za stanja članov skupine, pfctl -ss za stanja, še vedno pripeta na stari prehod, traceroute z odjemalca za izhodno pot in poizvedbo razreševalnika, da vidite, kateri strežnik je odgovoril.

Zdaj povzročite utripanje. Dvignite primarni za trideset sekund, spustite za trideset, dvakrat. Če promet lovi vsak prehod, so pragovi pretesni ali so ravni napačne. Popravite to po svojem urniku, ker bo sicer ponudnik to storil po svojem.

Na koncu potrdite, da usmerjevalnik še vedno lahko upravljate. Ohranite pot zunaj pasovja, na primer konzolni kabel, upravljalni VLAN ali mobilni modem. Preizkus preklopa, ki vas zaklene zunaj, je preizkus, ki ga ne morete dokončati, in nedosegljiv usmerjevalnik se ne more vrniti sam.

Preden politiko razglasite za končano, bi morali znati odgovoriti na štiri vprašanja brez odpiranja terminala: kateri VLAN smejo uporabljati WAN, dokler je tunel mrtev, kaj detektor spremlja in koliko čaka, kateri imenski strežniki in poti IPv6 se premikajo s potjo ter kako pridete nazaj, če tudi rezerva odpove. Če je kateri odgovor »kar je bilo privzeto«, politika še vedno pripada usmerjevalniku in ne vam.

Sorodni članki