Ruta de rezervă VPN flotantă nu preia: listă de verificare pentru comutare

Ruta dvs. VPN flotantă este configurată, distanța rezervei este mai mare decât a celei primare și totuși nimic nu se mișcă vreodată. Sau se mișcă, apoi revine câteva minute mai târziu în timp ce legătura wireless este încă jos. În ambele cazuri, altceva decât defecțiunea care vă interesează decide eligibilitatea rutei.

Efectuați aceste verificări în ordine. Fiecare are o condiție de oprire, iar o verificare eșuată nu poate fi salvată de cele următoare. Exemplele folosesc sintaxa RouterOS pentru că distanța, accesibilitatea gateway-ului și următorul salt recursiv sunt toate vizibile în configurație acolo, dar ordinea se aplică oricărui router cu rute statice urmărite.

Numiți defecțiunea pe care trebuie să o acopere rezerva

„Ruta primară este jos” sunt patru observații diferite. Un radio care își pierde partenerul, o interfață care își pierde purtătoarea, un gateway la distanță care nu mai răspunde și o aplicație care nu mai funcționează arată diferit din locul routerului. Notați pentru care dintre ele este proiectată soluția înainte ca cineva să schimbe o valoare de distanță.

Apoi verificați independența. Dacă transportul exterior al VPN rulează pe aceeași cale wireless sau pe o legătură de acces care partajează același upstream, rezerva nu este un al doilea domeniu de defecțiune și va fi jos exact când aveți nevoie de ea. Trageți cablul primar pe hârtie: dacă transportul tunelului însuși moare odată cu el, ruta flotantă acoperă doar erori de configurare, nu întreruperi.

Încetați să cereți distanței să detecteze ceva

O distanță mai mare face o rută mai puțin preferată. Aceasta este toată treaba. Cât timp ruta statică primară rămâne eligibilă, ruta flotantă rămâne inactivă, iar acesta este comportament corect, nu un defect. Defecțiunea devine vizibilă doar când ruta primară este retrasă sau marcată ca inaccesibilă.

Pentru rutele statice aceasta necesită un urmăritor explicit:

/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

Citiți ce testează: următorul salt, nu destinația. Un radio care încă răspunde pe partea sa locală în timp ce redirecționarea mai departe este ruptă menține ruta primară activă. Acesta este cazul silențios, iar distanța plus o verificare a gateway-ului nu îl vor prinde. Dacă acel caz contează, detectarea trebuie să vină de la ceva ce observă partea îndepărtată: o adiacență de protocol de rutare sau o sondă al cărei drum și regulă de rezultat le-ați definit singur.

Urmăriți unde merg pachetele sondei înseși

O sondă de sănătate are și ea o rută. Odată ce traficul de date trece pe VPN, o sondă fără restricții către aceeași adresă îndepărtată poate să o urmeze, să reușească și să fie citită ca dovadă că ruta primară a revenit. Traficul se întoarce pe o cale ruptă și ciclul se repetă.

Fixați sonda pe calea pe care ar trebui să o judece. În RouterOS modalitatea obișnuită este o rută de host către ținta de monitorizare prin gateway-ul primar, cu un domeniu suficient de mic încât nicio altă rută să nu o poată rezolva, iar aceasta este ceea ce construiește exemplul de comutare recursivă din manualul RouterOS. Confirmați-o în tabelul live cu rezerva activă, nu din comentariul configurației:

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

Definiți ce înseamnă rezultatul unei sonde înainte de a adăuga ținte

O țintă care respinge ICMP sau intră în mentenanță arată exact ca o defecțiune de cale, iar trei ținte fără o regulă vă dau doar trei opinii. Decideți mai întâi regula, apoi implementați-o: de exemplu, ruta primară contează ca jos când două din trei ținte eșuează timp de două intervale consecutive, scris în manualul de operare unde următoarea persoană îl va găsi.

Setați praguri de defectare și revenire astfel încât un pachet pierdut să nu miște locația. Histerezisul costă puțin timp de detectare și cumpără înapoi stabilitate. Alegeți intervalul după cât timp este tolerabilă o întrerupere, nu după cât de repede poate rula sonda, și mențineți revenirea mai lentă decât comutarea, astfel încât ruta primară să trebuiască să se dovedească înainte de a primi traficul înapoi.

Verificați calea de întoarcere și povestea sesiunilor

O comutare care funcționează doar spre exterior este jumătate de proiect. Locația îndepărtată are nevoie de o rută de întoarcere către intervalul dvs. sursă prin VPN, altfel traficul de retur sosește de la o adresă neașteptată și lovește o stare de firewall care nu mai corespunde. Sesiunile existente se vor rupe chiar și când conexiunile noi funcționează, așa că puneți asta în criteriile de acceptare în loc să promiteți supraviețuirea transferului.

Țineți accesul de administrare în afara căii testate. Dacă singura dvs. intrare este prin ruta primară, un test de comutare vă blochează în afara dispozitivului care se comportă greșit.

Executați secvența de acceptare

Trei teste acoperă cea mai mare parte: pierderea fizică a rutei primare, o defecțiune silențioasă de redirecționare cu interfața încă activă și restaurarea rutei primare. Pentru fiecare, înregistrați sursa și următorul salt al sondei, ruta de destinație activă și un schimb de aplicație permis proaspăt în ambele direcții.

Cazul silențios este cel care separă proiectele. Dacă rezerva nu preia acolo, ați construit un monitor de legătură, nu un monitor de cale. Decideți dacă este acceptabil și scrieți limitarea acolo unde inginerul de gardă o va citi. Un al doilea tunel conectat nu este, prin el însuși, o politică de rezervă finalizată.