Sådan bygger du en VPN-failoverpolitik på routeren uden lækager

Failoveren virkede præcis som konfigureret, og det var netop problemet. Da den primære tunnel faldt, flyttede routeren standardruten til kabelmodemmet, bærbare computere blev ved med at browse, og ingen ringede. To dage senere bemærkede nogen, at økonomimappen havde været tilgængelig over den åbne internetvej i seks timer. En VPN-failoverpolitik på routeren er ikke et routingtrick; det er en beslutning om, hvad trafikken skal gøre, når den foretrukne vej er væk, og den beslutning skal findes, før vejen forsvinder.

Beslut resultatet, før du vælger detektoren

Der er normalt tre resultater på bordet: send berørte klienter gennem en backup-tunnel, lad dem bruge den almindelige WAN, eller bloker dem helt. Skriv ned, hvilket der gælder for hvilken VLAN, SSID eller enhedsklasse. En enkelt flad “skift til WAN”-regel er, hvordan økonomimappen ovenfor endte på en offentlig vej.

De tre er ikke udskiftelige. WAN-fallback holder en supportdesk i gang med at tage telefoner, mens den blotlægger interne navne for den lokale resolver. En backup-tunnel bevarer politikken, men kan lande på en udgangsadresse, som den anden side ikke accepterer. Blokering er rigtigt for en løn-VLAN og forkert for et gæstenetværk, der aldrig har brugt tunnelen.

Tilpas detektoren til det svigt, du faktisk frygter

Håndtryksstatus, interfacestatus og brugbar videresendelse er tre forskellige signaler, og kun det sidste betyder noget for en bruger. En WireGuard-peer kan vise et nyligt håndtryk, mens udbyderens upstream smider pakker i et sort hul. OpenVPN klienten kan stå på “forbundet”, efter at den rute, den skubbede, holdt op med at slå op.

På pfSense er den praktiske opsætning en gateway-gruppe, der fodres af dpinger, som tester en overvågningsadresse og markerer en gateway som nede, når tab eller latenstid krydser dens tærskler. Ret den overvågning mod noget uden for tunnelen, for eksempel en vært på det fjerne LAN eller en offentlig adresse, du når gennem den. At rette den mod tunnelens egen peer-adresse måler den del, du allerede ved er levende.

Byg gruppen, så backupen forbliver den sidste udvej

Brug niveauer i stedet for en flad medlemsliste. Primær i niveau 1, backup-tunnel i niveau 2, WAN i niveau 3 kun for de VLAN'er, hvis politik tillader det. I pfSense findes dette under System > Routing > Gateway Groups: tilføj begge gateways, giv dem forskellige niveauer, sæt Trigger Level til member down plus packet loss, gem, og anvend derefter gruppen som interface-standard eller i Gateway-feltet i de firewallregler, der har brug for det.

For en OpenVPN-klientinstans på pfSense 2.5 og nyere afgør instansens Default Gateway-indstilling, om tunnelen overhovedet erstatter systemets standardrute. Policy routing efter regel opfører sig kun, som du forventer, når den rute, du antager eksisterer, faktisk er installeret. Kontroller Status > Gateways efter ændringen i stedet for at stole på tunnelstatusikonet.

To indstillinger forårsager det meste af flagringen. Den ene er et probeinterval, der er kortere end udbyderens egen rekonvergens. Den anden er en gruppe, hvor primær og backup deler niveau, så begge forbliver kvalificerede hele tiden. Tilføj hysterese via tærskler for tab og latenstid, før dine brugere mærker overgangene i stedet for dig.

Luk de veje, som tunnelen aldrig ejede

Først DNS-lækager. Resolveren bliver ved med at svare på WAN og videresende ud ad den, så navne bliver ved med at slå op gennem udbyderen, mens trafikken er fastlåst til tunnelen. Begræns resolverens udgående interfaces, skub den interne resolver ud til klienterne, og bloker port 53 for alt andet på kun-VPN-VLAN'erne.

IPv6 har brug for sin egen beslutning. Et dual-stack-LAN kan miste tunnelen og beholde en fungerende global IPv6-standardrute, så browsere foretrækker IPv6 og forlader netværket via WAN, mens IPv4 ser perfekt inddæmmet ud. Enten rut IPv6 ind i tunnelen, eller stop med at annoncere et globalt præfiks, mens tunnelen er nede. En halv politik er værre end ingen, fordi den ser ud til at virke.

Så returvejen. Hvis backup-udgangen bruger en anden kildeadresse, skal den anden side vide, hvordan trafikken sendes tilbage, og hver tilstand, der er knyttet til den gamle adresse, er allerede død. Sessioner, der var åbne, da den primære faldt, migrerer ikke; de står stille, indtil de udløber, og applikationen beslutter, hvad den gør ved det.

Test faldet, flagringen og vejen tilbage ind

Træk den primære ud med harmløs trafik kørende, og læs derefter fire ting: Status > Gateways for gruppens medlemstilstande, pfctl -ss for tilstande, der stadig er låst til den gamle gateway, en traceroute fra en klient for udgangsvejen og en resolver-forespørgsel for at se, hvilken server der svarede.

Flagr den nu. Tag den primære op i tredive sekunder, ned i tredive, to gange. Hvis trafikken jager hver overgang, er tærsklerne for stramme, eller niveauerne er forkerte. Ret det efter din tidsplan, for ellers gør en udbyder det efter sin.

Bekræft til sidst, at du stadig kan administrere routeren. Hold en out-of-band-vej som et konsolkabel, et management-VLAN eller et mobilt modem. En failovertest, der låser dig ude, er en test, du ikke kan gøre færdig, og en utilgængelig router kan ikke falde tilbage af sig selv.

Før du kalder politikken færdig, bør du kunne svare på fire spørgsmål uden at åbne en terminal: hvilke VLAN'er må bruge WAN, mens tunnelen er nede, hvad detektoren overvåger, og hvor længe den venter, hvilke navneservere og IPv6-ruter der flytter med vejen, og hvordan du kommer ind igen, hvis backupen også fejler. Hvis noget svar er “hvad standarden nu var”, tilhører politikken stadig routeren og ikke dig.