iPhone Always On VPN: dos túnels poden compartir una IP virtual

En un iPhone supervisat amb un perfil Always On gestionat, el telèfon manté un túnel per a cada interfície IP activa, de manera que la xarxa mòbil i el Wi-Fi en tenen cadascun el seu. El servidor llista llavors dues associacions de seguretat IKE per a un sol dispositiu, sovint compartint una adreça virtual, i el primer instint és anomenar-ho bucle de rekey i començar a canviar temporitzadors. Aquest instint sol ser equivocat. Seguiu els passos de sota en l’ordre en què l’evidència apareix al servidor i deixeu la configuració del telèfon tranquil·la fins que el servidor us digui quin cas teniu.

Comenceu amb les dues files que el servidor ja té

Llisteu les associacions amb swanctl --list-sas i llegiu quatre camps en totes dues entrades: l’adreça remota, la identitat autenticada, la IP virtual assignada i l’hora de creació. Dues adreces externes diferents amb una identitat i una IP virtual és la forma que va iniciar aquesta pregunta, i val la pena anotar-la abans de qualsevol canvi. Després reviseu les associacions filles adjuntes a cadascuna, perquè els selectors de trànsit decideixen si una consulta de destinació podria distingir mai els dos túnels. Una parella que apareix i desapareix en segons és un animal diferent d’una parella que totes dues viuen hores.

Ordeneu la llista per hora de creació abans de treure cap conclusió. L’adjacència a la sortida no significa res, i un llistat tabular convida exactament a aquest error.

Decidiu quin solapament esteu mirant

El rekey IKEv2 i la reautenticació make-before-break creen un solapament breu a propòsit, establint la nova associació abans d’esborrar la vella. Les marques de temps resolen el cas, perquè una SA vella que desapareix un segon o dos després que aparegui la nova és renovació fent la seva feina. Els túnels independents per interfície no s’assemblen mai a això, ja que cadascun persisteix mentre la seva interfície està activa i esborrar-ne un no es deriva de crear l’altre.

El comportament gestionat d’Always On d’Apple és per interfície, i per això un dispositiu supervisat pot semblar legítimament més ocupat que un perfil configurat a mà. L’interruptor de connexió automàtica d’una app de proveïdor no implica el mateix, i una regla on-demand ordinària tampoc. La visió general de desplegament d’Apple descriu el model per interfície; compareu les vostres dues files amb ella abans de suposar un bucle. Totes dues formes també beuen del mateix pool del servidor, així que el solapament és el vostre únic senyal primerenc.

Vegeu per què una adreça virtual per a dos túnels trenca les respostes

Una resposta al telèfon s’adreça a l’adreça interna, i el nucli tria un túnel de sortida per destinació i política, no per la interfície que va usar el telèfon. Dues associacions concurrents que tenen la mateixa IP virtual amb polítiques coincidents deixen la decisió d’encaminament sense manera de dir a quina sessió pertany una resposta. Algunes respostes agafen el túnel equivocat, i el telèfon mostra una connexió que funciona en un sentit o mor quan apareix el Wi-Fi. Dues sortides de comandes proven l’estat: swanctl --list-sas mostrant la mateixa IP virtual a totes dues SA, i ip xfrm policy mostrant dos selectors idèntics.

Aquesta parella de sortides és també el que enganxeu al registre de canvis. Cap de les dues sola no és convincent, perquè qualsevol pot semblar plausible per si mateixa.

Això és adreçament i política al costat del servidor, no mal comportament del telèfon, i cap ajust del client separa dues adreces internes idèntiques. El pool va lliurar el mateix valor dues vegades i l’instal·lador de polítiques el va acceptar. Llegiu el resultat des del costat del servidor abans de culpar el client.

Canvieu el pool o el model de concurrència, no el temporitzador de rekey

A la configuració de swanctl, la unicitat és una política explícita a la connexió: unique = replace elimina una connexió més antiga quan se n’estableix una de nova, i unique = keep rebutja la nouvinguda. Tots dos valors actuen quan es configura una connexió, no sobre les SA filles que conté.

connections {
  ios-alwayson {
    unique = replace
  }
}

Cap dels dos valors és neutre per a un client per interfície. keep restaura una pantalla d’estat endreçada rebutjant el segon túnel i trenca el disseny gestionat, mentre que replace enderroca el túnel més antic i és el mateix compromís en l’altre sentit. Si tots dos túnels són realment necessaris, el backend del pool ha d’emetre concessions diferents per a una identitat, i la seva clau de concessió ha de distingir les peticions. Una taula estàtica identitat-adreça tornarà alegrement la mateixa adreça dues vegades i reproduirà el problema original amb més configuració. Comproveu com el backend assigna les claus de concessió abans d’afegir un segon mapatge estàtic.

Proveu les transicions que realment desplegueu

Sortiu de l’abast del Wi-Fi amb una sessió activa, torneu-hi, i comproveu que les respostes arriben en tots dos sentits. Feu-ho dues vegades, perquè la segona transició és on sol aparèixer una política obsoleta. Proveu-ho amb un servei que respongui a la connexió que vau obrir, i repetiu la sortida mentre el túnel porta trànsit en lloc d’estar aturat. Un telèfon que pot enviar però no rebre sembla sa en un registre d’handshake i trencat en un navegador.

Una pantalla d’estat reduïda a una fila no és evidència d’un disseny funcional, només evidència que un túnel ha desaparegut. Tots dos sentits han de funcionar abans que una transició passi. Anoteu què heu observat, juntament amb les dues sortides de la comprovació de solapament, perquè el següent enginyer pugui comparar en lloc de repetir el passeig.