Kelluva VPN-varareitti ei ota vastuuta: vikasietokytkennän tarkistuslista

Kelluva VPN-reittisi on määritetty, varareitin etäisyys on suurempi kuin ensisijaisen, eikä mikään koskaan siirry. Tai se siirtyy ja vaihtuu takaisin minuutteja myöhemmin, kun langaton linkki on vielä alhaalla. Molemmissa tapauksissa jokin muu kuin se vika, josta välität, päättää reitin kelpoisuudesta.

Tee nämä tarkistukset järjestyksessä. Jokaisella on pysäytys­ehto, eikä epäonnistunutta tarkistusta voi pelastaa seuraavilla. Esimerkit käyttävät RouterOS-syntaksia, koska etäisyys, yhdyskäytävän tavoitettavuus ja rekursiivinen seuraava hyppy ovat siellä kokoonpanossa näkyvissä, mutta järjestys pätee mihin tahansa reitittimeen, jossa on seurattuja staattisia reittejä.

Nimeä vika, jonka varaosan on katettava

«Ensisijainen on alhaalla» on neljä eri havaintoa. Radio, joka menettää parinsa, käyttöliittymä, joka menettää kantoaaltonsa, etäinen yhdyskäytävä, joka lakkaa vastaamasta, ja sovellus, joka lakkaa toimimasta, näyttävät kaikki erilaisilta reitittimen paikalta. Kirjoita ylös, mille niistä suunnittelu on tarkoitettu, ennen kuin kukaan muuttaa etäisyysarvoa.

Tarkista sitten riippumattomuus. Jos VPN:n ulompi kuljetus kulkee samaa langatonta polkua tai saman ylävirran jakavaa liityntälinkkiä pitkin, varaosa ei ole toinen vikavyöhyke ja on alhaalla juuri silloin, kun tarvitset sitä. Vedä ensisijainen kaapeli paperilla: jos tunnelin oma kuljetus kuolee sen mukana, kelluva reitti kattaa vain kokoonpanovirheet, ei katkoksia.

Lopeta etäisyyden pyytäminen havaitsemaan mitään

Suurempi etäisyys tekee reitistä vähemmän suositun. Se on koko työ. Niin kauan kuin ensisijainen staattinen reitti pysyy kelpoisena, kelluva reitti pysyy passiivisena, ja se on oikeaa käyttäytymistä eikä vika. Vika tulee näkyväksi vasta, kun ensisijainen vedetään pois tai merkitään tavoittamattomaksi.

Staattisille reiteille se vaatii nimenomaisen seuraajan:

/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

Lue, mitä se testaa: seuraavaa hyppyä, ei kohdetta. Radio, joka vastaa vielä paikallisella puolellaan, mutta jonka edelleen välitys on rikki, pitää ensisijaisen reitin aktiivisena. Se on hiljainen tapaus, eikä etäisyys plus yhdyskäytävän tarkistus nappaa sitä. Jos tämä tapaus on tärkeä, havaitsemisen on tultava jostakin, joka havainnoi kaukaista puolta: reititysprotokollan naapuruus tai koetin, jonka polun ja tulossäännön olet itse määritellyt.

Jäljitä, minne koettimen omat paketit menevät

Terveyskoettimella on myös reitti. Kun dataliikenne siirtyy VPN:ään, rajoittamaton koetin samaan etäosoitteeseen voi seurata sitä, onnistua ja tulla luetuksi todisteena siitä, että ensisijainen palautui. Liikenne palaa rikkinäiselle polulle ja sykli toistuu.

Kiinnitä koetin polulle, jota sen on määrä arvioida. RouterOS:ssa tavallinen tapa on isäntäreitti valvontakohteeseen ensisijaisen yhdyskäytävän kautta, laajuudella, joka on tarpeeksi pieni, ettei mikään muu reitti voi ratkaista sitä, ja juuri sen rakentaa rekursiivisen vikasietokytkennän esimerkki RouterOS-käsikirjassa. Vahvista se live-taulussa varan ollessa aktiivinen, ei kokoonpanon kommentista:

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

Määritä, mitä koettimen tulos tarkoittaa, ennen kuin lisäät kohteita

Yksi kohde, joka hylkää ICMP:n tai siirtyy huoltoon, näyttää täsmälleen polun vialta, ja kolme kohdetta ilman sääntöä antavat sinulle vain kolme mielipidettä. Päätä sääntö ensin ja toteuta se sitten: esimerkiksi ensisijainen lasketaan alas, kun kaksi kolmesta kohteesta epäonnistuu kahden peräkkäisen välin ajan, kirjoitettuna käyttöohjeeseen, josta seuraava henkilö löytää sen.

Aseta vika- ja palautumiskynnykset niin, ettei yksi kadonnut paketti siirrä kohdetta. Hystereesi maksaa hieman havainnointiaikaa ja ostaa vakautta takaisin. Valitse väli siitä, kuinka kauan katkos on siedettävä, ei siitä, kuinka nopeasti koetin voi toimia, ja pidä paluu hitaampana kuin vikasietokytkentä, jotta ensisijaisen on todistettava itsensä ennen kuin se saa liikenteen takaisin.

Tarkista paluupolku ja istuntojen tarina

Vikasietokytkentä, joka toimii vain ulospäin, on puolikas suunnittelua. Etätila tarvitsee paluureitin lähdeverkkoosi VPN:n kautta, tai paluuliikenne saapuu odottamattomasta osoitteesta ja osuu palomuurin tilaan, joka ei enää vastaa. Nykyiset istunnot katkeavat, vaikka uudet yhteydet toimisivat, joten laita se hyväksymiskriteereihin sen sijaan, että lupaat siirron säilyvän.

Pidä hallintakäyttö poissa testattavalta polulta. Jos ainoa sisäänkäyntisi on ensisijaisen kautta, vikasietotesti lukitsee sinut ulos laitteesta, joka käyttäytyy väärin.

Suorita hyväksymisjärjestys

Kolme testiä kattaa suurimman osan: ensisijaisen fyysinen menetys, hiljainen välitysvika käyttöliittymän ollessa vielä ylhäällä ja ensisijaisen palautus. Kirjaa kullekin koettimen lähde ja seuraava hyppy, aktiivinen kohdereitti ja tuore sallittu sovellusvaihto molempiin suuntiin.

Hiljainen tapaus on se, joka erottaa suunnittelut. Jos varaosa ei ota siellä vastuuta, olet rakentanut linkin monitorin etkä polun monitoria. Päätä, onko se hyväksyttävää, ja kirjoita rajoitus sinne, missä päivystävä insinööri lukee sen. Toinen yhdistetty tunneli ei itsessään ole valmis varasuunnitelma.