Plávajúca záložná trasa VPN nepreberá prevádzku: kontrolný zoznam prepnutia

Vaša plávajúca trasa VPN je nakonfigurovaná, vzdialenosť zálohy je vyššia ako pri primárnej, a napriek tomu sa nikdy nič neprepne. Alebo sa prepne a o pár minút sa vráti späť, kým je bezdrôtové spojenie stále mimo prevádzky. V oboch prípadoch rozhoduje o spôsobilosti trasy niečo iné ako porucha, ktorá vás zaujíma.

Vykonajte tieto kontroly v poradí. Každá má podmienku zastavenia a neúspešnú kontrolu nedokážu zachrániť nasledujúce. Príklady používajú syntax RouterOS, pretože vzdialenosť, dostupnosť brány a rekurzívny ďalší skok sú tam v konfigurácii viditeľné, ale poradie platí pre každý router so sledovanými statickými trasami.

Pomenujte poruchu, ktorú má záloha pokryť

„Primárna je mimo prevádzky“ sú štyri rôzne pozorovania. Rádio, ktoré stratí svoj protipól, rozhranie, ktoré stratí nosič, vzdialená brána, ktorá prestane odpovedať, a aplikácia, ktorá prestane fungovať, vyzerajú z pohľadu routera rôzne. Zapíšte, pre ktorú z nich je návrh určený, skôr než niekto zmení hodnotu vzdialenosti.

Potom skontrolujte nezávislosť. Ak vonkajší transport VPN prechádza po tej istej bezdrôtovej ceste alebo po prístupovom spoji so spoločným upstreamom, záloha nie je druhou doménou poruchy a bude mimo prevádzky presne vtedy, keď ju potrebujete. Vytiahnite primárny kábel na papieri: ak s ním zomrie aj vlastný transport tunela, plávajúca trasa pokrýva len chyby konfigurácie, nie výpadky.

Prestaňte od vzdialenosti žiadať, aby niečo detegovala

Vyššia vzdialenosť robí trasu menej preferovanou. To je celá práca. Kým primárna statická trasa zostáva spôsobilá, plávajúca trasa zostáva neaktívna, a to je správne správanie, nie chyba. Porucha sa prejaví až vtedy, keď je primárna stiahnutá alebo označená ako nedostupná.

Pre statické trasy to vyžaduje výslovný 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

Prečítajte si, čo to testuje: ďalší skok, nie cieľ. Rádio, ktoré stále odpovedá na svojej lokálnej strane, ale preposielanie ďalej je rozbité, udržiava primárnu trasu aktívnu. To je tichý prípad a vzdialenosť plus kontrola brány ho nezachytia. Ak na tomto prípade záleží, detekcia musí prísť z niečoho, čo pozoruje vzdialenú stranu: susedstvo smerovacieho protokolu alebo sonda, ktorej cestu a pravidlo výsledku ste definovali sami.

Vysledujte, kam idú vlastné pakety sondy

Sonda zdravia má tiež trasu. Keď sa dátová prevádzka presunie na VPN, neobmedzená sonda na rovnakú vzdialenú adresu ju môže nasledovať, uspieť a byť prečítaná ako dôkaz, že sa primárna obnovila. Prevádzka sa vracia na rozbitú cestu a cyklus sa opakuje.

Pripnite sondu k ceste, ktorú má posudzovať. V RouterOS je obvyklým spôsobom hostiteľská trasa k cieľu monitorovania cez primárnu bránu, s rozsahom dostatočne malým, aby ju žiadna iná trasa nemohla vyriešiť, a to je to, čo stavia príklad rekurzívneho prepnutia v manuáli RouterOS. Potvrďte to v živej tabuľke s aktívnou zálohou, nie z komentára v konfigurácii:

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

Pred pridaním cieľov definujte, čo výsledok sondy znamená

Jeden cieľ, ktorý odmieta ICMP alebo ide do údržby, vyzerá presne ako porucha cesty, a tri ciele bez pravidla vám dajú len tri názory. Najprv rozhodnite pravidlo, potom ho zaveďte: napríklad primárna sa počíta ako mimo prevádzky, keď dva z troch cieľov zlyhajú počas dvoch po sebe nasledujúcich intervalov, zapísané do prevádzkovej príručky, kde to nájde ďalší človek.

Nastavte prahy poruchy a obnovy tak, aby jeden stratený paket nepohol lokalitou. Hysteréza stojí trochu času detekcie a kupuje späť stabilitu. Interval vyberte podľa toho, aký dlhý výpadok je únosný, nie podľa toho, ako rýchlo môže sonda bežať, a držte návrat pomalší než prepnutie, aby primárna musela dokázať seba, než dostane prevádzku späť.

Skontrolujte spätnú cestu a príbeh relácií

Prepnutie, ktoré funguje len smerom von, je polovica návrhu. Vzdialená lokalita potrebuje spätnú trasu k vášmu rozsahu zdrojov cez VPN, inak spätná prevádzka prichádza z neočakávanej adresy a narazí na stav firewallu, ktorý už nezodpovedá. Existujúce relácie sa prerušia, aj keď nové spojenia fungujú, takže to dajte do akceptačných kritérií namiesto sľubovania prežitia prenosu.

Držte administratívny prístup mimo testovanej cesty. Ak je váš jediný vstup cez primárnu, test prepnutia vás zamkne mimo zariadenia, ktoré sa správa nesprávne.

Vykonajte akceptačnú sekvenciu

Tri testy pokrývajú väčšinu terénu: fyzická strata primárnej, tichá porucha preposielania so stále zapnutým rozhraním a obnova primárnej. Pre každý zaznamenajte zdroj a ďalší skok sondy, aktívnu trasu cieľa a čerstvú povolenú výmenu aplikácie v oboch smeroch.

Tichý prípad je ten, ktorý oddeľuje návrhy. Ak tam záloha neprevezme, postavili ste monitor spoja, nie monitor cesty. Rozhodnite, či je to prijateľné, a napíšte obmedzenie tam, kde si ho prečíta pohotovostný inžinier. Druhý pripojený tunel sám o sebe nie je hotová záložná politika.