Ugyanaz az IKEv2-identitás két iPhone-on? Felváltva kapcsolódnak

Két telefon, egy profil és egy minta, amely természetfelettinek tűnik, amíg valaki rá nem néz az átjáróra. Az egyik eszköz tartja az alagutat, a második csatlakozik, és az első másodperceken belül elveszíti. Az első újracsatlakozik, a második kiesik. Az akkumulátor-takarékosságot, a Wi-Fi barangolást és az operátor NAT-ját okolják, miközben a valódi ok egy szövegmezőben ül, amelyet minden mással együtt másoltak. Az IKEv2 egy peert név alapján azonosít, és mindkét telefon ugyanazt a nevet mutatja.

Az identitás az a kulcs, amely alatt a kiszolgáló téged tárol

Egy IKEv2-csere során mindkét fél kijelenti, ki ő: a kezdeményező helyi azonosítót küld, a válaszadó a sajátjával válaszol, és a válaszadó a kezdeményező által állított identitást is ellenőrzi a szabályzat ellen. Az átjáró állapotát identitás szerint tartja, nem eszköz szerint, mert az eszköz nem valami, amit láthat. Ezért két telefon egy azonosítóval egyetlen peer-ként érkezik, és a második cserének felül kell írnia az elsőt. A probléma csak akkor jelenik meg, amikor mindkettő használatban van, ezért az egytelefonos teszt soha nem reprodukálja.

Ebből semmi nem hiba a kliensben. A kliens pontosan azt küldte, amit a profil mondott neki.

Hogyan néz ki az ütközés az átjáró felől

Nézze a peer-listát, amíg mindkét telefon ébren van és használatban. Egy ütközés egyetlen bejegyzést mutat, amelynek címe változik, ahogy a telefonok váltják egymást, az aktív munkamenetek számlálója pedig soha nem éri el a kettőt. Az igény szerinti bontás másképp néz ki, és megkülönböztetésük egy megfigyelést igényel, nem egy elméletet.

Jegyezze fel mindkét eseményt időbélyeggel, miközben megtörténik. A másik készülék csatlakozásával egybeeső kiesés az azonosítóra mutat, a legutolsó csomag utáni egy tétlenségi intervallummal érkező kiesés pedig egy időzítőre.

Honnan jönnek a duplikátumok

Egy működő konfiguráció exportálása és csak a kiszolgáló címének szerkesztése egy második fájlt hoz létre, amelyben még mindig benne van az első fájl identitása. Ez a szokásos út ehhez a hibához, és általában egy kis csoport sietős bevezetésekor történik.

A mezőnevek megkönnyítik az elnézését. A távoli azonosító azt az átjárót nevezi meg, amelyet a telefon vár, és ennek másolása helyes. A helyi azonosító nevezi meg ezt a készüléket az átjáró felé, és ennek az értéknek a másolása az egész probléma.

Adjon ki értéket eszközönként

Használjon valamit, ami egyedi a készülékre és stabil az élettartama alatt, például a leltárból származó eszközazonosítót vagy egy értéket, amelyet a felügyeleti rendszere minden regisztrációhoz generál. Egy részlegcímke, egy megosztott szolgáltatásfiók-név vagy a felhasználó e-mail-címe mind ütközik, amint annak a személynek második eszköze lesz.

Eszközönként állítsa elő a hasznos terhelést, ahelyett hogy egy fájlt osztana szét. Jegyezze fel, melyik érték melyik készülékhez tartozik, hogy a csere ne állítsa vissza a régi profilt, és ne lökje az új telefont egyenesen ugyanabba az ütközésbe.

Ellenőrizze a kiszolgáló oldalát is. Egy átjáró, amely az identitást fix alagútcímhez rendeli, még mindig ütközhet, ha két különböző azonosító ugyanazt a hozzárendelést kapja, ezért erősítse meg, hogy a poolban van hely, és a hozzárendelések nincsenek felhasználónként rögzítve.

Ellenőrizze mindkét telefon ébren léte mellett

Csatlakoztassa az elsőt, érjen el egy privát erőforrást, majd csatlakoztassa a másodikat, és hagyja mindkettőt egy percig tétlenül. Mindkét munkamenetnek fenn kell maradnia, és a peer-listának két identitást kell mutatnia. Ezután zárja és nyissa ki mindkét telefont, hogy megerősítse, a tétlenségi eset továbbra is jól viselkedik.

Ha egyetlen munkamenet továbbra is naponta egyszer kiesik, miközben semmi más nem csatlakozik, az identitás már nem gyanús. Térjen át a tétlenségi időzítőkre és a kiszolgáló munkamenet-korlátaira, ahelyett hogy újra szerkesztené a profilt.