VPN-feladatátvétel: amikor a visszaút a régi alagúton marad

A tartalék alagút feljön, az elsődleges leáll, az alkalmazás pedig továbbra is időtúllépést kap. Mindkét telephelyen egészségesnek látszik az alagút állapota, és éppen ez a zavaró. Az a feladatátvétel, amely a kéréseket a tartalékra viszi, de a válaszokat a régi útvonalon hagyja, nem feladatátvétel. Az alábbi útmutató a visszautat vizsgálja, nem csak a kézfogást.

Először rögzítse az útvonalakat mindkét végén; egyetlen telephely nézete nem mutathat aszimmetrikus útvonalat. Ez az a lépés is, amelyet időnyomás alatt a leggyakrabban kihagynak.

Rögzítse mindkét telephely útvonalait a teszt előtt

Minden védett előtaghoz írja fel az elsődleges útvonalat, a tartalék útvonalat és a köztük választó preferenciát. Vegye bele az egyes VPN-végpontok mögötti LAN-átjárót, mert a végpont ritkán az utolsó ugrás.

A statikus metrikák, a követett útvonalak és a dinamikus útválasztás másképp fejezik ki az alkalmasságot. Tudja, melyiket használja a terve, és mi kell ahhoz, hogy az alternatíva aktívvá váljon. Írja az útvonal mellé a feltételt, például alacsonyabb metrikát, amíg a próba meg nem hibásodik.

Tegye ezt mindkét telephelyen. Az egyik oldalon előnyben részesített, a másikon figyelmen kívül hagyott tartalék pontosan azt az aszimmetriát hozza létre, amelyet el akar kerülni.

Figyelje a kéréseket és a válaszokat minden fázisban

Használjon ártalmatlan, engedélyezett alkalmazást, és figyeljen meg három fázist: normál, az elsődleges útvonal hibája és helyreállítás. Minden fázisban rögzítse, melyik alagút viszi a kérést és melyik a választ. Egy elérhető partner-cím nem bizonyítja, hogy a védett alkalmazás-útvonal működik. Mindkét telephelyen rögzítse, hogy látható legyen az egyirányú forgalom.

Ha a kérések elmozdulnak, a válaszok nem, ellenőrizze a távoli telephely útvonalát az ügyfél előtagjához és a tartalék iránti preferenciáját. Ez útválasztási döntés, nem alagúthiba.

A teszt után állítsa vissza az eredeti állapotot, és erősítse meg, hogy az elsődleges ismét előnyben részesül. A visszaállított elsődleges, amely nem élvez elsőbbséget, befejezetlen feladatátvételi terv.

Kezelje a munkamenet állapotát, amikor az átjáró változik

A tűzfalak és a NAT egy átjárón tarthatják a kapcsolat állapotát, és egy másik átjáróra váltó útvonal nem viszi magával. Egyes alkalmazások maguktól újracsatlakoznak; mások meghibásodnak, amíg a munkamenet helyre nem áll. Ha a tartalék megváltoztatja a nyilvános forrást vagy a lefordított privát címet, a távoli hozzáférési szabályok is reagálhatnak. Dokumentáljon minden várható munkamenet-újraindítást ahelyett, hogy megszakítás nélküli feladatátvételt ígérne.

Tartsa stabilnak a címzést ott, ahol az alkalmazás megköveteli. Az a feladatátvételi terv, amely minden munkamenetnél megváltoztatja a forrás címet, tervezési döntés, és le kell írni. Ez a döntés határozza meg, mennyit észlelnek a felhasználók a kimaradásból.

Teszteljen olyan alkalmazást, amely hosszú munkamenetet tart, ne csak egy új kérést.

Állítsa vissza az elsődlegest, és ellenőrizze a lebegést

Erősítse meg, hogy az útvonal-hirdetések vagy preferenciák oszcillálás nélkül beállnak. A lebegő elsődleges útvonal zavaróbb lehet, mint egy tiszta kimaradás, mert minden átmenet visszaállítja az állapotot.

Tartsa az átjáró adminisztrációját elérhetővé egy helyreállítási útvonalon, hogy a teszt ne zárja ki önt. Rögzítse a fázisokat, a megfigyelt útvonalakat és a helyreállítási időt; ez a feljegyzés teszi kiszámíthatóvá a következő feladatátvételt. A strongSwan továbbítási jegyzetei hasznosak, ha a végpontok Linux-gazdagépek.