Aceeași identitate IKEv2 pe două iPhone? Se conectează pe rând

Două telefoane, un profil și un model care pare supranatural până când cineva se uită la gateway. Un dispozitiv ține tunelul, al doilea se conectează, iar primul îl pierde în câteva secunde. Primul se reconectează, iar al doilea cade. Sunt învinuite economisirea bateriei, roamingul Wi-Fi și NAT-ul operatorului, în timp ce cauza reală stă într-un câmp text copiat împreună cu tot restul. IKEv2 identifică un peer după un nume, iar ambele telefoane prezintă același nume.

Identitatea este cheia sub care serverul te păstrează

Într-un schimb IKEv2 fiecare parte declară cine este: inițiatorul trimite un identificator local, respondenul răspunde cu al său și verifică și identitatea revendicată de inițiator față de politică. Gateway-ul își ține starea pe identitate, nu pe dispozitiv, pentru că un dispozitiv nu este ceva ce poate vedea. Două telefoane cu un singur identificator ajung astfel ca un singur peer, iar al doilea schimb trebuie să îl suprascrie pe primul. Problema apare doar cât timp ambele sunt folosite, motiv pentru care un test cu un singur telefon nu o reproduce niciodată.

Nimic din toate acestea nu este un defect al clientului. Clientul a trimis exact ce i-a spus profilul.

Cum arată coliziunea din perspectiva gateway-ului

Urmăriți lista de peers cât timp ambele telefoane sunt treze și în uz. O coliziune arată o singură intrare a cărei adresă se schimbă pe măsură ce telefoanele alternează, iar contorul sesiunilor active nu ajunge niciodată la două. Deconectarea la cerere arată altfel, iar distingerea lor cere o observație, nu o teorie.

Notați ambele evenimente cu marcaje de timp în timp ce se întâmplă. O cădere care coincide cu conectarea celuilalt aparat indică identificatorul, iar una care sosește la un interval de inactivitate după ultimul pachet indică un temporizator.

De unde vin duplicatele

Exportarea unei configurații funcționale și editarea doar a adresei serverului produce un al doilea fișier în care identitatea primului este încă prezentă. Aceasta este calea obișnuită către această defecțiune și se întâmplă de obicei la integrarea în grabă a unui grup mic.

Numele câmpurilor fac ușor să treci cu vederea. Identificatorul de la distanță numește gateway-ul pe care îl așteaptă telefonul, iar copierea lui este corectă. Identificatorul local numește acest aparat în fața gateway-ului, iar copierea acelei valori este întreaga problemă.

Emiteți o valoare pentru fiecare dispozitiv

Folosiți ceva unic pentru aparat și stabil pe toată durata vieții sale, cum ar fi identificatorul dispozitivului din inventar sau o valoare generată de sistemul de management pentru fiecare înregistrare. O etichetă de departament, un nume de cont de serviciu partajat sau adresa de e-mail a utilizatorului se ciocnesc toate de îndată ce persoana are un al doilea dispozitiv.

Generați payload-ul pentru fiecare dispozitiv în loc să distribuiți un singur fișier. Înregistrați care valoare aparține cărui aparat, astfel încât o înlocuire să nu restaureze profilul vechi și să arunce telefonul nou direct în aceeași coliziune.

Verificați și partea de server. Un gateway care mapează identitatea la o adresă fixă de tunel poate totuși intra în coliziune când două identificatoare diferite primesc aceeași alocare, așa că confirmați că pool-ul are spațiu și că alocările nu sunt fixate pe utilizator.

Verificați cu ambele telefoane treze

Conectați primul, ajungeți la o resursă privată, apoi conectați al doilea și lăsați ambele inactive un minut. Ambele sesiuni ar trebui să persiste, iar lista de peers ar trebui să arate două identități. Apoi blocați și deblocați fiecare telefon pentru a confirma că cazul inactiv se comportă în continuare corect.

Dacă o singură sesiune încă pică o dată pe zi fără ca nimic altceva să se conecteze, identitatea nu mai este suspectul. Treceți la temporizatoarele de inactivitate și la limitele de sesiune ale serverului în loc să editați din nou profilul.