Plovoucí záložní trasa VPN nepřebírá provoz: kontrolní seznam přepnutí

Vaše plovoucí trasa VPN je nakonfigurovaná, vzdálenost zálohy je vyšší než u primární, a přesto se nikdy nic nepřepne. Nebo se přepne a za pár minut se vrátí zpět, zatímco bezdrátové spojení je stále mimo provoz. V obou případech rozhoduje o způsobilosti trasy něco jiného než porucha, která vás zajímá.

Proveďte tyto kontroly v pořadí. Každá má podmínku zastavení a neúspěšnou kontrolu nelze zachránit těmi následujícími. Příklady používají syntaxi RouterOS, protože vzdálenost, dostupnost brány a rekurzivní další skok jsou tam v konfiguraci vidět, ale pořadí platí pro každý router se sledovanými statickými trasami.

Pojmenujte poruchu, kterou má záloha pokrýt

„Primární je mimo provoz“ jsou čtyři různá pozorování. Rádio, které ztratí svůj protějšek, rozhraní, které ztratí nosič, vzdálená brána, která přestane odpovídat, a aplikace, která přestane fungovat, vypadají z pohledu routeru různě. Zapište, pro kterou z nich je návrh určen, než někdo změní hodnotu vzdálenosti.

Poté zkontrolujte nezávislost. Pokud vnější transport VPN běží po stejné bezdrátové cestě nebo po přístupovém spoji se stejným upstreamem, záloha není druhou doménou poruchy a bude mimo provoz přesně tehdy, kdy ji potřebujete. Vytáhněte primární kabel na papíře: pokud s ním zemře i vlastní transport tunelu, plovoucí trasa pokrývá jen chyby konfigurace, ne výpadky.

Přestaňte po vzdálenosti chtít, aby něco detekovala

Vyšší vzdálenost dělá trasu méně preferovanou. To je celá práce. Dokud primární statická trasa zůstává způsobilá, plovoucí trasa zůstává neaktivní, a to je správné chování, ne chyba. Porucha se projeví až když je primární stažena nebo označena jako nedostupná.

U statických tras to vyžaduje explicitní sledovač:

/ip route
add dst-address=10.20.0.0/24 gateway=192.0.2.1 distance=1 check-gateway=ping
add dst-address=10.20.0.0/24 gateway=wg-backup distance=10

Přečtěte si, co to testuje: další skok, ne cíl. Rádio, které stále odpovídá na své lokální straně, ale přeposílání dál je rozbité, udržuje primární trasu aktivní. To je tichý případ a vzdálenost plus kontrola brány ho nezachytí. Pokud na tomto případě záleží, detekce musí přijít z něčeho, co pozoruje vzdálenou stranu: sousedství směrovacího protokolu, nebo sonda, jejíž cestu a pravidlo výsledku jste definovali sami.

Vysledujte, kam jdou vlastní pakety sondy

Sonda zdraví má také trasu. Jakmile se datový provoz přesune na VPN, neomezená sonda na stejnou vzdálenou adresu ji může následovat, uspět a být přečtena jako důkaz, že se primární obnovila. Provoz se vrací na rozbitou cestu a cyklus se opakuje.

Připněte sondu k cestě, kterou má posuzovat. V RouterOS je obvyklým způsobem hostitelská trasa k cíli monitorování přes primární bránu s rozsahem dostatečně malým, aby ji žádná jiná trasa nemohla vyřešit, což je to, co staví příklad rekurzivního přepnutí v manuálu RouterOS. Potvrďte to v živé tabulce s aktivní zálohou, ne z komentáře v konfiguraci:

/ip route print detail where dst-address=203.0.113.10
# gateway should still be the primary next hop

Než přidáte cíle, definujte, co výsledek sondy znamená

Jeden cíl, který odmítá ICMP nebo jde do údržby, vypadá přesně jako porucha cesty, a tři cíle bez pravidla vám dají jen tři názory. Nejprve rozhodněte pravidlo, pak ho zaveďte: například primární se počítá jako mimo provoz, když dva ze tří cílů selžou po dvě po sobě jdoucí intervaly, zapsané do provozní příručky, kde to najde další člověk.

Nastavte prahy poruchy a obnovy tak, aby jeden ztracený paket nepohnul lokalitou. Hystereze stojí trochu času na detekci a kupuje zpět stabilitu. Interval vyberte podle toho, jak dlouhý výpadek je únosný, ne podle toho, jak rychle může sonda běžet, a držte návrat pomalejší než přepnutí, aby primární musela prokázat sama sebe, než dostane provoz zpět.

Zkontrolujte zpáteční cestu a příběh relací

Přepnutí, které funguje jen směrem ven, je polovina návrhu. Vzdálená lokalita potřebuje zpáteční trasu k vašemu rozsahu zdrojů přes VPN, jinak zpáteční provoz přichází z neočekávané adresy a narazí na stav firewallu, který už neodpovídá. Stávající relace se přeruší, i když nová spojení fungují, takže to dejte do akceptačních kritérií místo slibování přežití přenosu.

Držte administrativní přístup mimo testovanou cestu. Pokud je váš jediný vstup přes primární, test přepnutí vás zamkne mimo zařízení, které se chová špatně.

Proveďte akceptační sekvenci

Tři testy pokrývají většinu terénu: fyzická ztráta primární, tichá porucha přeposílání se stále zapnutým rozhraním a obnova primární. Pro každý zaznamenejte zdroj a další skok sondy, aktivní trasu cíle a čerstvou povolenou výměnu aplikace v obou směrech.

Tichý případ je ten, který odděluje návrhy. Pokud tam záloha nepřevezme, postavili jste monitor spoje, ne monitor cesty. Rozhodněte, zda je to přijatelné, a napište omezení tam, kde si ho přečte pohotovostní inženýr. Druhý připojený tunel sám o sobě není hotová záložní politika.