Slik bygger du en VPN-failoverpolicy på ruteren uten lekkasjer

Failoveren fungerte nøyaktig som konfigurert, og det var nettopp problemet. Da den primære tunnelen falt, flyttet ruteren standardruten til kabelmodemet, bærbare datamaskiner fortsatte å surfe, og ingen ringte. To dager senere la noen merke til at finansmappen hadde vært tilgjengelig over den åpne internettveien i seks timer. En VPN-failoverpolicy på ruteren er ikke et rutingtriks; det er en beslutning om hva trafikken skal gjøre når den foretrukne veien er borte, og den beslutningen må finnes før veien forsvinner.

Bestem utfallet før du velger detektoren

Vanligvis er det tre utfall på bordet: sende berørte klienter gjennom en backup-tunnel, la dem bruke vanlig WAN, eller blokkere dem helt. Skriv ned hvilket som gjelder for hvilken VLAN, SSID eller enhetsklasse. En enkelt flat “bytt til WAN”-regel er grunnen til at finansmappen ovenfor havnet på en offentlig vei.

De tre er ikke utskiftbare. WAN-fallback holder en supportdesk i gang med å ta telefoner mens den eksponerer interne navn for den lokale resolveren. En backup-tunnel bevarer policyen, men kan lande på en utgangsadresse som den andre siden ikke godtar. Blokkering er riktig for en lønns-VLAN og feil for et gjestenettverk som aldri har brukt tunnelen.

Tilpass detektoren til feilen du faktisk frykter

Håndtrykkstatus, grensesnittstatus og brukbar videresending er tre forskjellige signaler, og bare det siste betyr noe for en bruker. En WireGuard-peer kan vise et nylig håndtrykk mens leverandørens oppstrøm kaster pakker i et svart hull. OpenVPN klienten kan bli stående på “tilkoblet” etter at ruten den dyttet ut sluttet å løses opp.

På pfSense er den praktiske ordningen en gateway-gruppe som fôres av dpinger, som tester en overvåkingsadresse og markerer en gateway som nede når tap eller latens krysser tersklene. Rett den overvåkingen mot noe utenfor tunnelen, for eksempel en vert på det fjerne LAN-et eller en offentlig adresse du når gjennom den. Å rette den mot tunnelens egen peer-adresse måler den delen du allerede vet er levende.

Bygg gruppen slik at backupen forblir den siste utveien

Bruk nivåer i stedet for én flat medlemsliste. Primær i nivå 1, backup-tunnel i nivå 2, WAN i nivå 3 bare for de VLAN-ene der policyen tillater det. I pfSense ligger dette under System > Routing > Gateway Groups: legg til begge gatewayene, gi dem ulike nivåer, sett Trigger Level til member down plus packet loss, lagre, og bruk deretter gruppen som grensesnittstandard eller i Gateway-feltet i brannmurreglene som trenger den.

For en OpenVPN-klientinstans på pfSense 2.5 og nyere avgjør instansens Default Gateway-innstilling om tunnelen i det hele tatt erstatter systemets standardrute. Policyrutering etter regel oppfører seg som forventet bare når ruten du antar finnes, faktisk er installert. Kontroller Status > Gateways etter endringen i stedet for å stole på tunnelstatusikonet.

To innstillinger forårsaker mesteparten av flagringen. Den ene er et probeintervall som er kortere enn leverandørens egen rekonvergens. Den andre er en gruppe der primær og backup deler nivå, slik at begge forblir kvalifiserte hele tiden. Legg til hysterese via terskler for tap og latens før brukerne dine merker overgangene i stedet for deg.

Lukk veiene tunnelen aldri eide

Først DNS-lekkasjer. Resolveren fortsetter å svare på WAN og videresende ut derfra, så navn fortsetter å løses opp gjennom ISP-en mens trafikken er festet til tunnelen. Begrens resolverens utgående grensesnitt, dytt den interne resolveren til klientene, og blokker port 53 for alt annet på bare-VPN-VLAN-ene.

IPv6 trenger sin egen beslutning. Et dual-stack-LAN kan miste tunnelen og beholde en fungerende global IPv6-standardrute, så nettlesere foretrekker IPv6 og går ut via WAN mens IPv4 ser perfekt innesluttet ut. Enten ruter du IPv6 inn i tunnelen, eller du slutter å annonsere et globalt prefiks mens tunnelen er nede. En halv policy er verre enn ingen, fordi den ser ut til å virke.

Så returveien. Hvis backup-utgangen bruker en annen kildeadresse, må den andre siden vite hvordan trafikken skal sendes tilbake, og hver tilstand knyttet til den gamle adressen er allerede død. Økter som var åpne da primæren falt, migrerer ikke; de står til de utløper, og applikasjonen bestemmer hva den gjør med det.

Test fallet, flagringen og veien tilbake

Trekk ut primæren med harmløs trafikk kjørende, og les deretter fire ting: Status > Gateways for gruppens medlemstilstander, pfctl -ss for tilstander som fortsatt er festet til den gamle gatewayen, en traceroute fra en klient for utgangsveien og en resolverforespørsel for å se hvilken server som svarte.

Flagre den nå. Ta primæren opp i tretti sekunder, ned i tretti, to ganger. Hvis trafikken jager hver overgang, er tersklene for stramme eller nivåene feil. Fiks det etter din tidsplan, for ellers gjør en leverandør det etter sin.

Bekreft til slutt at du fortsatt kan administrere ruteren. Hold en ut-av-bånd-vei som en konsollkabel, et administrasjons-VLAN eller et mobilt modem. En failovertest som låser deg ute, er en test du ikke kan fullføre, og en utilgjengelig ruter kan ikke falle tilbake av seg selv.

Før du kaller policyen ferdig, bør du kunne svare på fire spørsmål uten å åpne en terminal: hvilke VLAN-er som kan bruke WAN mens tunnelen er nede, hva detektoren overvåker og hvor lenge den venter, hvilke navneservere og IPv6-ruter som flytter seg med veien, og hvordan du kommer inn igjen hvis backupen også feiler. Hvis noe svar er “hva standarden nå var”, tilhører policyen fortsatt ruteren og ikke deg.