A lebegő VPN-tartalékútvonal nem veszi át: feladatátvételi ellenőrzőlista

A lebegő VPN-útvonal be van állítva, a tartalék távolsága nagyobb az elsődlegesénél, és mégsem mozdul semmi. Vagy mozdul, majd percekkel később visszavált, miközben a vezeték nélküli kapcsolat még mindig levan. Mindkét esetben valami más, mint a zavar, ami érdekli, dönt az útvonal alkalmasságáról.

Végezze el ezeket az ellenőrzéseket sorrendben. Mindegyiknek van leállási feltétele, és egy meghiúsult ellenőrzést a következők nem menthetnek meg. A példák RouterOS-szintaxist használnak, mert a távolság, az átjáró elérhetősége és a rekurzív következő ugrás mind látható ott a konfigurációban, de a sorrend minden követett statikus útvonalat használó routerre érvényes.

Nevezze meg a zavart, amelyet a tartaléknak fedeznie kell

Az „az elsődleges levan” négy különböző megfigyelés. Egy rádió, amely elveszíti a partnerét, egy interfész, amely elveszíti a vivőjét, egy távoli átjáró, amely felhagy a válaszadással, és egy alkalmazás, amely felhagy a működéssel, mind másképp néz ki a router helyéből. Írja le, melyikükre készült a terv, mielőtt bárki megváltoztat egy távolságértéket.

Utána ellenőrizze a függetlenséget. Ha a VPN külső szállítása ugyanazon a vezeték nélküli úton vagy ugyanazt a felső folyamot megosztó hozzáférési kapcsolaton fut, a tartalék nem második hibaforgatókönyv-tartomány, és pontosan akkor lesz le, amikor szüksége van rá. Húzza ki a papíron az elsődleges kábelt: ha a barlang saját szállítása vele együtt hal meg, a lebegő útvonal csak konfigurációs hibákat fedez, kimaradásokat nem.

Hagyja abba, hogy a távolságtól bármit is elvárjon

A nagyobb távolság kevésbé előnyössé tesz egy útvonalat. Ez az egész feladat. Amíg az elsődleges statikus útvonal alkalmas marad, a lebegő útvonal inaktív marad, és ez helyes viselkedés, nem hiba. A zavar csak akkor válik láthatóvá, amikor az elsődleges visszavonásra vagy elérhetetlenként megjelölésre kerül.

Statikus útvonalaknál ehhez kifejezett követő kell:

/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

Olvassa el, mit tesztel ez: a következő ugrást, nem a célt. Egy rádió, amely még válaszol a helyi oldalán, miközben a továbbítás azon túl törött, aktívan tartja az elsődleges útvonalat. Ez a csendes eset, és a távolság plusz átjáró-ellenőrzés nem fogja elkapni. Ha ez az eset számít, az észlelésnek olyasvalamiből kell jönnie, ami a távoli oldalt figyeli: útválasztási protokoll szomszédsága, vagy olyan próba, amelynek útvonalát és eredményszabályát Ön maga határozta meg.

Kövesse, hová mennek a próba saját csomagjai

Az állapotpróbának is van útvonala. Amint az adatforgalom átkerül a VPN-re, egy korlátlan próba ugyanarra a távoli címre követheti, sikeres lehet, és úgy olvasható, mint bizonyíték arra, hogy az elsődleges helyreállt. A forgalom visszatér egy törött útra, és a ciklus ismétlődik.

Rögzítse a próbát arra az útra, amelyet meg kell ítélnie. A RouterOS-ban a szokásos mód egy hosztútvonal a felügyeleti célhoz az elsődleges átjárón keresztül, olyan kicsi hatókörrel, hogy más útvonal ne tudja feloldani, és ezt építi a rekurzív feladatátvételi példa a RouterOS kézikönyvben. Erősítse meg az élő táblázatban aktív tartalékkal, nem a konfigurációs megjegyzésből:

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

Határozza meg, mit jelent a próba eredménye, mielőtt célokat ad hozzá

Egy cél, amely elutasítja az ICMP-t vagy karbantartásba kerül, pontosan útvonalhibának látszik, a szabály nélküli három cél pedig csak három véleményt ad. Először döntse el a szabályt, aztán valósítsa meg: például az elsődleges akkor számít le, ha háromból kettő cél két egymást követő intervallumban meghiúsul, leírva az üzemeltetési kézikönyvben, ahol a következő ember megtalálja.

Állítsa be a hiba- és helyreállítási küszöböket úgy, hogy egy elveszett csomag ne mozdítsa el a telephelyet. A hiszterézis egy kis észlelési időbe kerül, és stabilitást ad vissza. Az intervallumot abból válassza, mennyi ideig elfogadható egy kimaradás, nem abból, milyen gyorsan futhat a próba, és tartsa a visszatérést lassabbnak a feladatátvételnél, hogy az elsődlegesnek bizonyítania kelljen magát, mielőtt forgalmat kap vissza.

Ellenőrizze a visszautat és a munkamenetek történetét

A csak kifelé működő feladatátvétel fél terv. A távoli telephelynek visszaútra van szüksége az Ön forrástartományához a VPN-en keresztül, különben a visszatérő forgalom váratlan címről érkezik, és olyan tűzfalállapotba ütközik, amely már nem illeszkedik. A meglévő munkamenetek akkor is megszakadnak, ha az új kapcsolatok működnek, ezért ezt tegye az elfogadási kritériumokba ahelyett, hogy az átvitel túlélését ígérné.

Tartsa a felügyeleti hozzáférést a tesztelt úton kívül. Ha az egyetlen bejárata az elsődlegesen keresztül vezet, egy feladatátvételi teszt kizárja Önt a helytelenül viselkedő eszközből.

Futtassa le az elfogadási sorozatot

Három teszt fedi le a terep nagy részét: az elsődleges fizikai elvesztése, csendes továbbítási hiba a még aktív interfésszel, és az elsődleges helyreállítása. Mindegyiknél rögzítse a próba forrását és következő ugrását, az aktív célútvonalat, és egy friss engedélyezett alkalmazáscserét mindkét irányban.

A csendes eset az, amely elválasztja a terveket. Ha a tartalék ott nem veszi át, kapcsolatfigyelőt épített útvonalfigyelő helyett. Döntse el, hogy ez elfogadható-e, és írja le a korlátot ott, ahol az ügyeletes mérnök olvasni fogja. Egy második csatlakoztatott barlang önmagában nem kész tartalékpolitika.