Hogyan tartja életben a MOBIKE az IKEv2 VPN-t hálózatváltáskor

Egy telefon elhagyja a Wi-Fi-t és csatlakozik a mobilhálózathoz, egy laptop Ethernetről hotspotra vált, és az IKEv2-alagút vagy túléli, vagy nem. A MOBIKE az a kiterjesztés, amely túlélésre készteti, azzal, hogy értesíti a távoli felet a forrás címének megváltozásáról ahelyett, hogy elölről kezdené. Amit viszont nem tesz meg, az az, hogy minden alkalmazást életben tartson a váltás alatt. Ez két állítás, és a második az, amire az emberek általában gondolnak.

Járja végig az átmenetet szakaszokban, mert minden szakasz másképp hibázik.

Mit változtat valójában a frissítés

Amíg a biztonsági társítás még érvényes, a kezdeményező megtudja az új címét, és frissítést küld a válaszolónak, amely ezután ezt a címet használja ugyanahhoz a társításhoz. A biztonsági paramétereket nem tárgyalják újra a nulláról. Ez az egész előny: nincs új hitelesítési kör, nincs új kulcscsere, nincs felhasználói kérés. Ez azt is jelenti, hogy a túlélő állapot továbbra is a régi munkamenethez tartozik.

A MOBIKE a forgalmat UDP-burkolásba is átviheti, ezért egy működő alagút néha 4500-as portot kezd használni egy hálózatváltás után. Ez az átmenet önmagában nem bizonyítja, hogy felismerték a NAT-ot, bár a kettő gyakran együtt jelenik meg.

Valóban engedélyezi a profilja

Mindkét félnek támogatnia kell a kiterjesztést, és a telepítésnek engedélyeznie kell. A strongSwanban a viselkedés kapcsolatonként konfigurálható, és az interfész- vagy útvonalváltozások szükség esetén útvonalkeresést és frissítést válthatnak ki. Ellenőrizze a kapcsolat tényleges beállításait, ahelyett hogy feltételezné, hogy minden IKEv2-profil bekapcsolja. A funkciót megelőző útmutatóból másolt profil ennek gyakori forrása.

A két végén kialkudott állapot a mértékadó, nem a termékcsalád dokumentációja.

Járja végig az átmenetet szakaszokban

Rögzítse az alkalmazás állapotát a hálózatváltás előtt. Ezután váltson, és utána rögzítse a kliens és a kiszolgáló állapotát. A hiányzó cím, az elérhetetlen partner és az az alkalmazás, amelynek saját magának újra kell csatlakoztatnia a munkamenetét, három különböző eredmény. Csak az első kettő tartozik a VPN réteghez; a harmadik ahhoz a protokollhoz, amelyet az alkalmazás beszél.

Hasonlítsa össze a hálózatváltást egy álló helyzetű teszttel, hogy tudja, melyik esemény váltja ki a problémát. Az átviteli sebesség mérése a végső hálózaton nem tudja újra létrehozni az átmenetet. A célt méri, nem az utat.

Válassza szét a hiba rétegeit

Egy hosszú életű TCP-munkamenet az IKEv2-cserén kívüli okokból is meghiúsulhat. Az új hálózat másképp szűrhet, oldhat fel vagy irányíthat. Az alagút címe egyáltalán nem változhat, miközben a mögötte lévő útvonal változik. Ezért az alkalmazás újracsatlakozása helyrehozhat valamit, amit a VPN soha nem tört el.

A helyreállítás alatt is tartsa helyén a blokkolási szabályzatot.

Az automatikus mobilitás és a közvetlen forgalmat megakadályozó szabály különböző vezérlők, és a második kikapcsolása az első működéséért rossz üzlet. Ha a mobilitási frissítés meghiúsul, a blokkolásnak tartania kell, nem pedig forgalmat szivárogtatni az alagút körül.

Mit rögzítsen, amikor megismétlődik

Őrizze meg az időbélyegeket és mindkét fél mindkét címértékét. Ez a feljegyzés megmutatja, hogy a frissítés befejeződött-e, mielőtt az alkalmazás elvesztette a kapcsolatot, ami a különbség a mobilitási hiba és az alkalmazás időtúllépése között. Ezután hasonlítsa össze a váltás irányát: a Wi-Fi elhagyása a mobilhálózatért nem szimmetrikus az ellenkezőjével. Az egyik irány működhet, míg a másik meghiúsul.

Ez az aszimmetria elég gyakori ahhoz, hogy az első dolog legyen, amit tesztel.

A feljegyzéssel a kézben az eset megszűnik újabb leválasztott ikon lenni, és egy ismert tulajdonossal rendelkező sorozat egyetlen eseményévé válik. És ez minden, amit egy végigjárás őszintén ígérhet.