Hoe om 'n VPN-oornamebeleid op die roeteerder sonder lekkasies te bou

Die oorname het presies gewerk soos opgestel, en dit was die probleem. Toe die primêre tonnel weggeval het, het die roeteerder die verstekroete na die kabelmodem geskuif, skootrekenaars het aanhou webblaai, en niemand het gebel nie. Twee dae later het iemand opgemerk dat die finansiële gedeelde gids ses uur lank oor die oop internetpad bereikbaar was. 'n VPN-oornamebeleid op 'n roeteerder is nie 'n truuk met roetes nie; dit is 'n besluit oor wat verkeer moet doen wanneer die voorkeurpad weg is, en daardie besluit moet daar wees voordat die pad verdwyn.

Bepaal die uitkoms voordat jy die detektor kies

Drie uitkomste is gewoonlik op die tafel: stuur geraakte kliënte deur 'n rugsteuntonnel, laat hulle die gewone WAN gebruik, of blokkeer hulle heeltemal. Skryf neer watter een op watter VLAN, SSID of toestelklas van toepassing is. 'n Enkele plat “fail over to WAN”-reël is hoe die finansiële gids hierbo op 'n openbare pad beland het.

Die drie is nie uitruilbaar nie. WAN-terugval hou 'n ondersteuningsdesk aan die telefoon terwyl dit interne name aan die plaaslike oplosser blootstel. 'n Rugsteuntonnel behou die beleid, maar kan op 'n uitgangsadres beland wat die ander kant nie aanvaar nie. Blokkering is reg vir 'n betaalstaat-VLAN en verkeerd vir 'n gasnetwerk wat nooit die tonnel gebruik het nie.

Pas die detektor aan by die fout wat jy werklik vrees

Handskudtoestand, koppelvlaktoestand en bruikbare aanstuur is drie verskillende seine, en net die laaste een maak saak vir 'n gebruiker. 'n WireGuard-eweknie kan 'n onlangse handskud wys terwyl die diensverskaffer se opstroom pakkette weggooi. OpenVPN kliënt kan op “gekoppel” sit nadat die roete wat dit gestoot het, opgehou werk het.

Op pfSense is die praktiese reëling 'n poortgroep wat deur dpinger gevoed word, wat 'n monitoradres toets en 'n poort afmerk wanneer verlies of latensie sy drumpels oorskry. Rig daardie monitor op iets anderkant die tonnel, soos 'n gasheer op die verre LAN of 'n openbare adres wat jy daardeur bereik. Om dit op die tonnel se eie eweknie-adres te rig, meet die deel wat jy al weet leef.

Bou die groep so dat die rugsteun die laaste uitweg bly

Gebruik vlakke eerder as een plat ledelys. Primêr in vlak 1, rugsteuntonnel in vlak 2, WAN in vlak 3 net vir die VLAN's wie se beleid dit toelaat. In pfSense woon dit onder System > Routing > Gateway Groups: voeg albei poorte by, gee hulle verskillende vlakke, stel Trigger Level op member down plus packet loss, stoor, en pas dan die groep toe as die koppelvlak-verstek of in die Gateway-veld van die firewallreëls wat dit nodig het.

Vir 'n OpenVPN-kliëntinstansie op pfSense 2.5 en later bepaal die instansie se Default Gateway-instelling of die tonnel hoegenaamd die stelsel se verstekroete vervang. Beleidsroetering per reël werk net soos jy verwag wanneer die roete wat jy aanvaar bestaan, werklik geïnstalleer is. Kyk Status > Gateways ná die verandering eerder as om die tonnelstatus-ikoon te vertrou.

Twee instellings veroorsaak die meeste van die wapper. Een is 'n toetsinterval korter as die diensverskaffer se eie herkonvergensie. Die ander is 'n groep waar primêr en rugsteun 'n vlak deel, sodat albei te alle tye in aanmerking bly. Voeg histerese by deur verlies- en latensiedrumpels voordat jou gebruikers die oorgange vir jou voel.

Sluit die paaie wat die tonnel nooit besit het nie

Eerstens DNS-lekkasies. Die oplosser hou aan antwoord op die WAN en stuur daaruit vorentoe, so name bly deur die ISP oplos terwyl verkeer aan die tonnel vasgepen is. Beperk die oplosser se uitgaande koppelvlakke, stoot die interne oplosser na kliënte, en blokkeer poort 53 vir alles anders op die slegs-VPN-VLAN's.

IPv6 het sy eie besluit nodig. 'n Dubbelstapel-LAN kan die tonnel verloor en 'n werkende globale IPv6-verstekroete behou, so blaaiers verkies IPv6 en verlaat deur die WAN terwyl IPv4 heeltemal ingeperk lyk. Roet IPv6 óf in die tonnel in óf stop om 'n globale voorvoegsel te adverteer terwyl die tonnel af is. 'n Halwe beleid is slegter as geen, want dit lyk of dit werk.

Dan die terugpad. As die rugsteunuitgang 'n ander bronadres gebruik, moet die ander kant weet hoe om verkeer terug te stuur, en elke toestand wat aan die ou adres gekoppel is, is al dood. Sessies wat oopgemaak is toe die primêre een weggeval het, migreer nie; hulle staak totdat hulle uittyd en die toepassing besluit wat om daaromtrent te doen.

Toets die val, die wapper en die pad terug in

Trek die primêre een uit met skadelose verkeer aan die gang, en lees dan vier dinge: Status > Gateways vir die groep se ledestate, pfctl -ss vir toestande wat nog aan die ou poort vasgepen is, 'n traceroute vanaf 'n kliënt vir die uitgangspad, en 'n oplosser-navraag om te sien watter bediener geantwoord het.

Laat dit nou wapper. Bring die primêre een dertig sekondes op, dertig af, twee keer. As verkeer elke oorgang agtervolg, is die drumpels te styf of die vlakke verkeerd. Maak dit op jou skedule reg, want anders sal 'n diensverskaffer dit op syne doen.

Laat laastens bevestig dat jy die roeteerder nog kan administreer. Hou 'n buiteband-pad soos 'n konsolekabel, 'n bestuurs-VLAN of 'n sellulêre modem. 'n Oornametoets wat jou uitsluit, is 'n toets wat jy nie kan klaarmaak nie, en 'n onbereikbare roeteerder kan nie op sy eie terugval nie.

Voordat jy die beleid klaar noem, moet jy vier vrae kan antwoord sonder om 'n terminaal oop te maak: watter VLAN's mag die WAN gebruik terwyl die tonnel af is, wat die detektor dophou en hoe lank hy wag, watter naambediener en IPv6-roetes saam met die pad beweeg, en hoe jy weer inkom as die rugsteun ook faal. As enige antwoord “wat die verstek ook al was” is, behoort die beleid nog aan die roeteerder eerder as aan jou.