Jak postavit politiku přepnutí VPN na routeru bez úniků
Rozhodněte, co má provoz dělat, když preferovaný tunel vypadne: záložní tunel, běžný WAN, nebo blokace. Potom to na routeru postavte a otestujte.
Přepnutí fungovalo přesně tak, jak bylo nastaveno, a právě to byl problém. Když primární tunel vypadl, router přesunul výchozí trasu na kabelový modem, notebooky dál prohlížely web a nikdo nezavolal. O dva dny později si někdo všiml, že finanční sdílená složka byla šest hodin dostupná přes otevřenou internetovou cestu. Politika přepnutí VPN na routeru není trik s routováním; je to rozhodnutí, co má provoz dělat, když preferovaná cesta zmizí, a toto rozhodnutí musí existovat dřív, než cesta zmizí.
Rozhodněte výsledek dřív, než vyberete detektor
Obvykle jsou ve hře tři výsledky: poslat postižené klienty přes záložní tunel, nechat je používat běžný WAN, nebo je úplně zablokovat. Zapište, který platí pro kterou VLAN, SSID nebo třídu zařízení. Jediné ploché pravidlo “přepni na WAN” je důvod, proč výše zmíněná finanční složka skončila na veřejné cestě.
Ty tři nejsou zaměnitelné. Záloha přes WAN drží podporu u telefonů, ale vystavuje interní názvy místnímu resolveru. Záložní tunel zachová politiku, ale může přistát na výstupní adrese, kterou druhá strana nepřijímá. Blokace je správná pro mzdovou VLAN a špatná pro hostovskou síť, která tunel nikdy nepoužívala.
| Výsledek | Pro koho je vhodný | Co se rozbije |
|---|---|---|
| Záložní tunel | Politika musí platit, je nutný vzdálený přístup | Nová výstupní adresa, zpětná trasa, pomalejší obnova klíče |
| Běžný WAN | Hostovský nebo jen veřejný provoz | Interní názvy, expozice DNS a IPv6 |
| Blokace | Mzdy, správa, cokoli jen-VPN | Uživatelé ztratí veškerý přístup a volají vám |
Přizpůsobte detektor poruše, které se skutečně bojíte
Stav handshake, stav rozhraní a použitelné předávání jsou tři různé signály a pro uživatele je důležitý jen ten poslední. Peer WireGuardu může ukazovat nedávný handshake, zatímco upstream poskytovatele hází pakety do černé díry. OpenVPN klient může zůstat na “připojeno” poté, co trasa, kterou protlačil, přestala být resolvována.
V pfSense je praktickým řešením skupina bran napájená dpingerem, který sonduje monitorovací adresu a označí bránu jako nedostupnou, když ztráta nebo latence překročí její prahy. Namiřte toto monitorování na něco za tunelem, například na hostitele ve vzdálené LAN nebo na veřejnou adresu, ke které se přes něj dostanete. Míření na vlastní peer adresu tunelu měří část, o které už víte, že je živá.
Postavte skupinu tak, aby záloha zůstala poslední možností
Používejte úrovně místo jednoho plochého seznamu členů. Primární v úrovni 1, záložní tunel v úrovni 2, WAN v úrovni 3 jen pro VLAN, jejichž politika to dovoluje. V pfSense to najdete v System > Routing > Gateway Groups: přidejte obě brány, dejte jim různé úrovně, nastavte Trigger Level na member down plus packet loss, uložte a potom skupinu použijte jako výchozí pro rozhraní nebo v poli Gateway pravidel firewallu, která ji potřebují.
U klientské instance OpenVPN na pfSense 2.5 a novějším nastavení Default Gateway instance rozhoduje, zda tunel vůbec nahradí systémovou výchozí trasu. Politické směrování podle pravidla se chová podle očekávání jen tehdy, když je trasa, kterou předpokládáte, skutečně nainstalovaná. Po změně zkontrolujte Status > Gateways místo toho, abyste věřili ikoně stavu tunelu.
Většinu kmitání způsobují dvě nastavení. Jedno je interval sondy kratší než vlastní rekonvergence poskytovatele. Druhé je skupina, kde primární a záložní sdílejí úroveň, takže oba zůstávají způsobilí po celou dobu. Přidejte hysterezi přes prahy ztráty a latence, než vaši uživatelé pocítí přechody za vás.
Zavřete cesty, které tunel nikdy nevlastnil
Nejprve úniky DNS. Resolver dál odpovídá na WAN a přeposílá přes něj, takže názvy se dál resolvují přes ISP, zatímco provoz je připoután k tunelu. Omezte odchozí rozhraní resolveru, protlačte interní resolver klientům a zablokujte port 53 všemu ostatnímu na VLAN jen-VPN.
IPv6 potřebuje vlastní rozhodnutí. Dual-stack LAN může ztratit tunel a udržet funkční globální výchozí trasu IPv6, takže prohlížeče dávají přednost IPv6 a odcházejí přes WAN, zatímco IPv4 vypadá dokonale uzavřené. Buď směrujte IPv6 do tunelu, nebo přestaňte inzerovat globální prefix, dokud je tunel dole. Polovina politiky je horší než žádná, protože vypadá, že funguje.
Pak zpětná cesta. Pokud záložní výstup používá jinou zdrojovou adresu, druhá strana musí vědět, jak tam provoz poslat zpět, a každý stav navázaný na starou adresu je už mrtvý. Relace otevřené při výpadku primárního nemigrují; stojí, dokud nevyprší, a aplikace rozhodne, co s tím.
Otestujte výpadek, kmitání a cestu zpět
Vytáhněte primární s neškodným provozem, pak přečtěte čtyři věci: Status > Gateways pro stavy členů skupiny, pfctl -ss pro stavy ještě připoutané ke staré bráně, traceroute z klienta pro výstupní cestu a dotaz na resolver, který server odpověděl.
Teď s ním zakmitejte. Zvedněte primární na třicet sekund, na třicet dolů, dvakrát. Pokud provoz honí každý přechod, prahy jsou příliš těsné nebo jsou úrovně špatné. Opravte to podle svého rozvrhu, protože jinak to poskytovatel udělá podle svého.
Nakonec ověřte, že router ještě můžete spravovat. Držte mimopásmovou cestu, například konzolový kabel, správcovskou VLAN nebo mobilní modem. Test přepnutí, který vás zamkne ven, je test, který nemůžete dokončit, a nedostupný router se sám nevrátí.
Než politiku prohlásíte za hotovou, měli byste umět bez otevření terminálu odpovědět na čtyři otázky: které VLAN smějí používat WAN, dokud je tunel dole, co detektor sleduje a jak dlouho čeká, které názvové servery a trasy IPv6 se pohybují s cestou, a jak se dostanete zpět, když záloha také selže. Pokud je některá odpověď “co bylo výchozí”, politika stále patří routeru, ne vám.