Plutajuća VPN pričuvna ruta ne preuzima: kontrolni popis za prebacivanje

Vaša plutajuća VPN ruta je konfigurirana, udaljenost pričuve veća je od primarne, a ništa se nikada ne pomiče. Ili se pomiče pa se vrati nekoliko minuta kasnije dok je bežična veza još uvijek prekinuta. U oba slučaja nešto drugo osim kvara koji vas zanima odlučuje o podobnosti rute.

Provedite ove provjere redom. Svaka ima uvjet zaustavljanja, a neuspjelu provjeru ne mogu spasiti one koje slijede. Primjeri koriste RouterOS sintaksu jer su udaljenost, dostupnost pristupnika i rekurzivni sljedeći skok vidljivi u konfiguraciji tamo, ali redoslijed vrijedi za svaki usmjerivač s praćenim statičkim rutama.

Imenujte kvar koji pričuva mora pokriti

„Primarna je pala“ četiri su različita opažanja. Radio koji izgubi svog partnera, sučelje koje izgubi nositelja, udaljeni pristupnik koji prestane odgovarati i aplikacija koja prestane raditi izgledaju različito iz sjedala usmjerivača. Zapišite za koje je od njih dizajn prije nego itko promijeni vrijednost udaljenosti.

Zatim provjerite neovisnost. Ako vanjski prijevoz VPN-a ide istim bežičnim putem ili preko pristupne veze koja dijeli isti uzvodni kanal, pričuva nije druga domena kvara i bit će pala točno kad vam treba. Povucite primarni kabel na papiru: ako prijevoz samog tunela umre s njim, plutajuća ruta pokriva samo konfiguracijske pogreške, ne prekide.

Prestanite tražiti od udaljenosti da bilo što otkrije

Veća udaljenost čini rutu manje poželjnom. To je cijeli posao. Dok primarna statička ruta ostaje podobna, plutajuća ruta ostaje neaktivna, i to je ispravno ponašanje, a ne pogreška. Kvar postaje vidljiv tek kad primarna bude povučena ili označena kao nedostupna.

Za statičke rute to zahtijeva izričit pratitelj:

/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

Pročitajte što to testira: sljedeći skok, ne odredište. Radio koji još odgovara na svojoj lokalnoj strani dok je prosljeđivanje dalje pokvareno drži primarnu rutu aktivnom. To je tihi slučaj, a udaljenost plus provjera pristupnika neće ga uhvatiti. Ako je taj slučaj važan, otkrivanje mora doći od nečega što promatra dalju stranu: susjedstvo protokola usmjeravanja ili sonda čiji ste put i pravilo rezultata sami definirali.

Pratite kamo idu vlastiti paketi sonde

Sonda zdravlja također ima rutu. Kad podaci prijeđu na VPN, neograničena sonda na istu udaljenu adresu može je slijediti, uspjeti i biti pročitana kao dokaz da se primarna oporavila. Promet se vraća na pokvaren put i ciklus se ponavlja.

Pričvrstite sondu na put koji treba procijeniti. U RouterOS-u uobičajen je način ruta do hosta prema meti nadzora preko primarnog pristupnika, s opsegom dovoljno malim da je nijedna druga ruta ne može razriješiti, što je ono što gradi primjer rekurzivnog prebacivanja u RouterOS priručniku. Potvrdite to u živoj tablici s aktivnom pričuvom, a ne iz komentara u konfiguraciji:

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

Definirajte što rezultat sonde znači prije dodavanja meta

Jedna meta koja odbija ICMP ili odlazi na održavanje izgleda točno kao kvar puta, a tri mete bez pravila daju vam samo tri mišljenja. Prvo odlučite pravilo, pa ga primijenite: na primjer, primarna se računa kao pala kad dvije od tri mete ne uspiju u dva uzastopna intervala, zapisano u operativnom priručniku gdje će ga sljedeća osoba naći.

Postavite pragove kvara i oporavka tako da jedan izgubljeni paket ne pomakne lokaciju. Histereza košta malo vremena otkrivanja i vraća stabilnost. Odaberite interval prema tome koliko je dug prekid prihvatljiv, a ne prema tome koliko brzo sonda može raditi, i držite vraćanje sporijim od prebacivanja kako bi primarna morala dokazati sebe prije nego dobije promet natrag.

Provjerite povratni put i priču o sesijama

Prebacivanje koje radi samo prema van pola je dizajna. Udaljena lokacija treba rutu natrag do vašeg raspona izvora preko VPN-a, inače povratni promet dolazi s neočekivane adrese i udara u stanje vatrozida koje se više ne poklapa. Postojeće sesije prekinut će se čak i kad nove veze rade, zato to stavite u kriterije prihvaćanja umjesto da obećavate opstanak prijenosa.

Držite administrativni pristup izvan puta koji se testira. Ako je vaš jedini ulaz preko primarne, test prebacivanja zaključat će vas izvan uređaja koji se loše ponaša.

Provedite slijed prihvaćanja

Tri testa pokrivaju veći dio terena: fizički gubitak primarne, tihi kvar prosljeđivanja s još podignutim sučeljem i obnova primarne. Za svaki zabilježite izvor i sljedeći skok sonde, aktivnu rutu odredišta i svježu dopuštenu razmjenu aplikacije u oba smjera.

Tihi slučaj je onaj koji razdvaja dizajne. Ako pričuva tamo ne preuzme, napravili ste monitor veze, a ne monitor puta. Odlučite je li to prihvatljivo i zapišite ograničenje tamo gdje će ga dežurni inženjer pročitati. Drugi povezani tunel sam po sebi nije dovršena pričuvna politika.