Si MOBIKE e mban gjallë një VPN IKEv2 kur ndryshon rrjeti

Një telefon largohet nga Wi-Fi dhe bashkohet me rrjetin celular, një laptop kalon nga Ethernet në një hotspot, dhe tuneli IKEv2 ose mbijeton ose jo. MOBIKE është zgjerimi që e lejon të mbijetojë, duke i thënë skajit të largët se adresa burimore ka ndryshuar në vend që të fillojë nga e para. Ajo që nuk bën është të mbajë çdo aplikacion gjallë gjatë ndryshimit. Këto janë dy pohime, dhe i dyti është ai që njerëzit zakonisht nënkuptojnë.

Kaloni nëpër tranzicion me faza, sepse çdo fazë dështon ndryshe.

Çfarë ndryshon në të vërtetë përditësimi

Për sa kohë shoqata e sigurisë është ende e vlefshme, iniciatori mëson adresën e tij të re dhe i dërgon një përditësim përgjigjësit, i cili më pas përdor atë adresë për të njëjtën shoqatë. Parametrat e sigurisë nuk rinegociohen nga e para. Ky është i gjithë përfitimi: asnjë raund i ri autentikimi, asnjë shkëmbim i ri çelësash, asnjë kërkesë për përdoruesin. Kjo do të thotë gjithashtu se gjendja e mbijetuar ende i përket sesionit të vjetër.

MOBIKE mund gjithashtu ta zhvendosë trafikun në enkapsulim UDP, prandaj një tunel funksional ndonjëherë fillon të përdorë portin 4500 pas një ndryshimi rrjeti. Ai tranzicion nuk provon më vete se NAT u zbulua, edhe pse të dy shfaqen shpesh së bashku.

A e aktivizon vërtet profili juaj

Të dy palët duhet ta mbështesin zgjerimin, dhe vendosja duhet ta aktivizojë. Në strongSwan sjellja është e konfigurueshme për çdo lidhje, dhe ndryshimet e ndërfaqes ose rrugës mund të shkaktojnë kërkim rruge dhe përditësim kur është e nevojshme. Inspektoni cilësimet aktuale të lidhjes në vend që të supozoni se çdo profil IKEv2 e aktivizon. Një profil i kopjuar nga një udhëzues që është më i vjetër se funksioni është një burim i zakonshëm i kësaj.

Gjendja e negociuar në të dy skajet është autoriteti, jo dokumentacioni për familjen e produkteve.

Kaloni nëpër tranzicion me faza

Regjistroni gjendjen e aplikacionit përpara se të ndryshoni rrjetet. Pastaj ndryshoni, dhe regjistroni gjendjen e klientit dhe serverit më pas. Një adresë që mungon, një partner i paarritshëm dhe një aplikacion që duhet të rilidhë vetë sesionin e tij janë tre rezultate të ndryshme. Vetëm dy të parët i përkasin shtresës VPN; i treti i përket protokollit që flet aplikacioni.

Krahasoni një ndryshim rrjeti me një provë të palëvizshme, në mënyrë që të dini cili ngjarje e shkakton problemin. Një matje e qarkullimit në rrjetin përfundimtar nuk mund të riprodhojë një tranzicion. Ajo mat destinacionin, jo udhëtimin.

Ndani shtresat e dështimit

Një sesion TCP jetëgjatë mund të dështojë për arsye jashtë shkëmbimit IKEv2. Rrjeti i ri mund të filtrojë, zgjidhë ose rrugëtojë ndryshe. Adresa e tunelit mund të mos ndryshojë fare ndërsa rruga nën të ndryshon. Kjo është arsyeja pse një rilidhje e aplikacionit mund të rregullojë diçka që VPN nuk e theu kurrë.

Mbani politikën e bllokimit në vend edhe gjatë rikuperimit.

Lëvizshmëria automatike dhe një rregull që pengon trafikun e drejtpërdrejtë janë kontrolle të ndryshme, dhe çaktivizimi i të dytit që i pari të funksionojë është një shkëmbim i keq. Nëse përditësimi i lëvizshmërisë dështon, bllokimi duhet të qëndrojë në vend të rrjedhë trafik rreth tunelit.

Çfarë të regjistroni kur përsëritet

Ruani vulat kohore dhe të dy vlerat e adresave nga të dy anët. Ai regjistër tregon nëse përditësimi përfundoi përpara se aplikacioni të humbiste kontaktin, që është ndryshimi midis një bug-u lëvizshmërie dhe një afati kohor të aplikacionit. Pastaj krahasoni drejtimin e ndryshimit: largimi nga Wi-Fi drejt rrjetit celular nuk është simetrik me të kundërtën. Një drejtim mund të funksionojë ndërsa tjetri dështon.

Ajo asimetri është mjaft e zakonshme për të qenë gjëja e parë që duhet testuar.

Me regjistrin në dorë, incidenti pushon së qeni një ikonë tjetër e shkëputur dhe bëhet një ngjarje në një sekuencë me një pronar të njohur. Dhe kjo është gjithçka që një kalim mund të premtojë sinqerisht.