Så bygger du en VPN-failover-policy på routern utan läckor
Bestäm vad trafiken ska göra när den föredragna tunneln faller: reservtunnel, vanlig WAN eller blockering. Bygg och testa sedan policyn på routern.
Failovern fungerade precis som konfigurerat, och det var problemet. När den primära tunneln föll flyttade routern standardrutten till kabelmodemet, laptoparna fortsatte surfa och ingen ringde. Två dagar senare upptäckte någon att ekonomikatalogen hade varit nåbar via den öppna internetvägen i sex timmar. En VPN-failover-policy på routern är inte ett routingtrick; det är ett beslut om vad trafiken ska göra när den föredragna vägen försvinner, och beslutet måste finnas innan vägen försvinner.
Bestäm resultatet innan du väljer detektor
Det finns vanligtvis tre resultat på bordet: skicka berörda klienter genom en reservtunnel, låta dem använda vanlig WAN eller blockera dem helt. Skriv ner vilket som gäller för vilken VLAN, SSID eller enhetsklass. En enda platt regel «växla till WAN» är hur ekonomikatalogen ovan hamnade på en publik väg.
De tre är inte utbytbara. WAN-återfall håller supporten svarande i telefon men exponerar interna namn för den lokala resolvern. En reservtunnel bevarar policyn men kan landa på en utgångsadress som andra sidan inte accepterar. Blockering är rätt för en löne-VLAN och fel för ett gästnätverk som aldrig använde tunneln.
| 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 |
Matcha detektorn mot det fel du faktiskt fruktar
Handskakningsstatus, gränssnittsstatus och användbar vidarebefordran är tre olika signaler, och bara den sista spelar roll för användaren. En WireGuard-peer kan visa en färsk handskakning medan leverantörens uppströms nät kastar paket. En OpenVPN-klient kan stå på «ansluten» efter att rutten den tryckte ut slutat gå att lösa upp.
På pfSense är den praktiska lösningen en gateway-grupp som matas av dpinger, som sonderar en övervakningsadress och markerar en gateway som nere när förlust eller latens passerar trösklarna. Rikta den övervakningen mot något bortom tunneln, till exempel en värd i det avlägsna LAN:et eller en publik adress du når genom den. Att rikta den mot tunnelns egen peer-adress mäter den del du redan vet lever.
Bygg gruppen så att reserven förblir en sista utväg
Använd nivåer i stället för en platt medlemslista. Primär i nivå 1, reservtunnel i nivå 2, WAN i nivå 3 bara för de VLAN vars policy tillåter det. I pfSense ligger detta under System > Routing > Gateway Groups: lägg till båda gatewayerna, ge dem olika nivåer, sätt Trigger Level till medlem nere plus paketförlust, spara och använd sedan gruppen som gränssnittets standard eller i Gateway-fältet för de brandväggsregler som behöver den.
För en OpenVPN-klientinstans på pfSense 2.5 och senare avgör instansens Default Gateway-inställning om tunneln alls ersätter systemets standardrutt. Policyrouting per regel beter sig som du förväntar dig bara när rutten du antar finns faktiskt är installerad. Kontrollera Status > Gateways efter ändringen i stället för att lita på tunnelns statusikon.
Två inställningar orsakar det mesta av fladdret. Den ena är ett sondintervall kortare än leverantörens egen återkonvergens. Den andra är en grupp där primär och reserv delar nivå, så båda förblir kvalificerade hela tiden. Lägg till hysteres via trösklar för förlust och latens innan användarna känner övergångarna åt dig.
Stäng vägarna som tunneln aldrig ägde
Först DNS-läckor. Resolvern fortsätter svara på WAN och vidarebefordra ut genom den, så namn löses fortfarande via ISP medan trafiken är fäst vid tunneln. Begränsa resolverns utgående gränssnitt, tryck ut den interna resolvern till klienterna och blockera port 53 för allt annat på de VPN-only-VLAN:en.
IPv6 behöver sitt eget beslut. Ett dual-stack-LAN kan tappa tunneln och behålla en fungerande global IPv6-standardrutt, så webbläsare föredrar IPv6 och lämnar via WAN medan IPv4 ser perfekt inneslutet ut. Antingen routa IPv6 in i tunneln eller sluta annonsera ett globalt prefix medan tunneln är nere. Halv policy är sämre än ingen, för den ser ut att fungera.
Sedan returvägen. Om reservutgången använder en annan källadress måste andra sidan veta hur trafiken ska skickas tillbaka till den, och varje tillstånd knutet till den gamla adressen är redan dött. Sessioner som öppnades när primären föll migrerar inte; de står stilla tills de timeoutar och applikationen bestämmer vad den ska göra.
Testa fallet, fladdret och vägen tillbaka in
Dra ut primären med ofarlig trafik igång och läs sedan fyra saker: Status > Gateways för gruppens medlemsstatus, pfctl -ss för tillstånd som fortfarande är fästa vid den gamla gatewayen, en traceroute från en klient för utgångsvägen och en resolverfråga för att se vilken server som svarade.
Framkalla nu fladder. Ta upp primären i trettio sekunder, ner i trettio, två gånger. Om trafiken jagar varje övergång är trösklarna för snäva eller nivåerna fel. Fixa det enligt din plan, för annars gör en leverantör det enligt sin.
Till sist, bekräfta att du fortfarande kan administrera routern. Håll en väg utanför bandet, som en konsolkabel, ett hanterings-VLAN eller ett mobilt modem. Ett failover-test som låser ut dig är ett test du inte kan slutföra, och en onåbar router kan inte falla tillbaka själv.
Innan du kallar policyn klar bör du kunna svara på fyra frågor utan att öppna en terminal: vilka VLAN får använda WAN medan tunneln är nere, vad detektorn bevakar och hur länge den väntar, vilka namnservrar och IPv6-rutter som flyttar med vägen, och hur du kommer tillbaka in om reserven också fallerar. Om något svar är «vad standarden än var» tillhör policyn fortfarande routern och inte dig.