La mateixa identitat IKEv2 en dos iPhone? S’alternen en connectar-se

Dos telèfons, un perfil i un patró que sembla sobrenatural fins que algú mira la passarel·la. Un dispositiu manté el túnel, el segon es connecta i el primer el perd en qüestió de segons. El primer es reconnecta i el segon cau. S’hi culpen l’estalvi de bateria, l’itinerància Wi-Fi i el NAT de l’operador, mentre que la causa real és en un camp de text que es va copiar amb tota la resta. IKEv2 identifica un peer per un nom, i tots dos telèfons presenten el mateix.

La identitat és la clau sota la qual el servidor et desa

Dins d’un intercanvi IKEv2 cada part declara qui és: l’iniciador envia un identificador local, el responedor respon amb el seu, i el responedor també comprova la identitat que l’iniciador ha reclamat contra la política. La passarel·la guarda el seu estat per identitat i no per dispositiu, perquè un dispositiu no és una cosa que pugui veure. Per tant, dos telèfons amb un identificador arriben com un sol peer, i el segon intercanvi ha de sobreescriure el primer. El problema només apareix mentre tots dos s’utilitzen, i per això una prova amb un sol telèfon no el reprodueix mai.

Res d’això no és un error del client. El client va enviar exactament el que el perfil li va dir que enviés.

Com es veu la col·lisió des de la passarel·la

Mireu la llista de peers mentre tots dos telèfons estan desperts i en ús. Una col·lisió mostra una sola entrada l’adreça de la qual canvia a mesura que els telèfons s’alternen, amb el comptador de sessions actives que mai no arriba a dos. L’enderrocament sota demanda es veu diferent, i distingir-los només requereix una observació, no una teoria.

Anoteu els dos esdeveniments amb marques de temps mentre passen. Una caiguda que coincideix amb la connexió de l’altre terminal apunta a l’identificador, i una caiguda que arriba un interval d’inactivitat després de l’últim paquet apunta a un temporitzador.

D’on venen els duplicats

Exportar una configuració que funciona i editar només l’adreça del servidor produeix un segon fitxer amb la identitat del primer encara a dins. Aquest és el camí habitual cap a aquesta fallada, i normalment passa en incorporar un grup petit amb presses.

Els noms dels camps fan que sigui fàcil passar-ho per alt. L’identificador remot nomena la passarel·la que el telèfon espera, i copiar-lo és correcte. L’identificador local nomena aquest terminal davant la passarel·la, i copiar aquest valor és tot el problema.

Emeteu un valor per dispositiu

Feu servir alguna cosa única per al terminal i estable durant tota la seva vida, com l’identificador del dispositiu de l’inventari o un valor que el vostre sistema de gestió generi per a cada alta. Una etiqueta de departament, un nom de compte de servei compartit o l’adreça de correu de l’usuari xoquen tan bon punt aquesta persona té un segon dispositiu.

Genereu la càrrega útil per dispositiu en lloc de distribuir un sol fitxer. Enregistreu quin valor pertany a quin terminal, perquè una substitució no restauri el perfil antic i torni a posar el telèfon nou directament en la mateixa col·lisió.

Comproveu també el costat del servidor. Una passarel·la que assigna la identitat a una adreça de túnel fixa encara pot col·lisionar quan dos identificadors diferents reben la mateixa assignació, així que confirmeu que la reserva té espai i que les assignacions no estan fixades per usuari.

Verifiqueu amb tots dos telèfons desperts

Connecteu el primer, arribeu a un recurs privat, després connecteu el segon i deixeu tots dos inactius un minut. Les dues sessions haurien de persistir i la llista de peers hauria de mostrar dues identitats. A continuació, bloquegeu i desbloquegeu cada telèfon per confirmar que el cas d’inactivitat encara es comporta bé.

Si una sola sessió encara cau un cop al dia sense res més connectant-se, la identitat ja no és el sospitós. Passeu als temporitzadors d’inactivitat i als límits de sessió del servidor en lloc de tornar a editar el perfil.