iPhone Always On VPN: dous túneles poden compartir unha IP virtual

Nun iPhone supervisado cun perfil Always On xestionado, o teléfono mantén un túnel por cada interface IP activa, de modo que a rede móbil e o Wi-Fi teñen cada un o seu. O servidor mostra entón dúas asociacións de seguridade IKE para un só dispositivo, a miúdo compartindo unha dirección virtual, e o primeiro instinto é chamalo bucle de rekey e comezar a cambiar temporizadores. Ese instinto adoita ser erróneo. Percorra os pasos de abaixo na orde en que aparecen as probas no servidor e deixe a configuración do teléfono quieta ata que o servidor lle diga que caso ten.

Empece polas dúas filas que o servidor xa ten

Liste as asociacións con swanctl --list-sas e lea catro campos nas dúas entradas: a dirección remota, a identidade autenticada, a IP virtual asignada e a hora de creación. Dúas direccións externas distintas cunha identidade e unha IP virtual é a forma que iniciou esta pregunta, e paga a pena anotala antes de calquera cambio. Despois revise as asociacións fillas asociadas a cada unha, porque os selectores de tráfico deciden se unha busca de destino podería distinguir algunha vez os dous túneles. Un par que aparece e desaparece en segundos é un animal distinto dun par no que ambos viven horas.

Ordene a lista por hora de creación antes de sacar unha conclusión. A adxacencia na saída non significa nada, e unha listaxe tabular invita exactamente a ese erro.

Decida que solapamento está a mirar

O rekey de IKEv2 e a reautenticación make-before-break crean un solapamento breve a propósito, establecendo a nova asociación antes de borrar a antiga. As marcas de tempo resolven o caso, porque unha SA antiga que desaparece un segundo ou dous despois de que apareza a nova é renovación facendo o seu traballo. Os túneles independentes por interface nunca se ven así, xa que cada un persiste mentres a súa interface está activa e borrar un non se deriva de crear o outro.

O comportamento xestionado de Always On de Apple é por interface, por iso un dispositivo supervisado pode parecer lexitimamente máis ocupado que un perfil configurado a man. O interruptor de conexión automática dunha app de provedor non implica o mesmo, e unha regra on-demand normal tampouco. A descrición xeral do despregamento de Apple describe o modelo por interface; compare as súas dúas filas con ela antes de supoñer un bucle. Ambas as formas tamén beben do mesmo grupo do servidor, así que o solapamento é a súa única sinal temperá.

Vexa por que unha dirección virtual para dous túneles rompe as respostas

Unha resposta ao teléfono diríxese á dirección interna, e o núcleo escolle un túnel de saída por destino e política, non pola interface que usou o teléfono. Dúas asociacións concorrentes que comparten a mesma IP virtual con políticas coincidentes deixan a decisión de encamiñamento sen forma de dicir a que sesión pertence unha resposta. Algunhas respostas toman o túnel equivocado, e o teléfono mostra unha conexión que funciona nun sentido ou morre cando aparece o Wi-Fi. Dúas saídas de comandos demostran o estado: swanctl --list-sas mostrando a mesma IP virtual nas dúas SA, e ip xfrm policy mostrando dous selectores idénticos.

Ese par de saídas é tamén o que pega no rexistro de cambios. Ningunha das dúas por separado é convincente, porque calquera pode parecer plausible soa.

Isto é direccionamento e política do lado do servidor, non un mal comportamento do teléfono, e ningún axuste do cliente separa dúas direccións internas idénticas. O grupo entregou o mesmo valor dúas veces e o instalador de políticas aceptouno. Lea o resultado desde o lado do servidor antes de culpar o cliente.

Cambie o grupo ou o modelo de concorrencia, non o temporizador de rekey

Na configuración de swanctl, a unicidade é unha política explícita na conexión: unique = replace elimina unha conexión anterior cando se establece unha nova, e unique = keep rexeita a recén chegada. Ambos os valores actúan cando se configura unha conexión, non sobre as SA fillas que contén.

connections {
  ios-alwayson {
    unique = replace
  }
}

Ningún dos dous valores é neutro para un cliente por interface. keep restaura unha pantalla de estado ordenada ao rexeitar o segundo túnel e rompe o deseño xestionado, mentres que replace derruba o túnel máis antigo e é o mesmo compromiso no outro sentido. Se de verdade se necesitan ambos os túneles, o backend do grupo ten que emitir concesións distintas para unha identidade, e a súa clave de concesión debe distinguir as peticións. Unha táboa estática de identidade a dirección devolverá alegremente a mesma dirección dúas veces e reproducirá o problema orixinal con máis configuración. Comprobe como o backend asigna as claves de concesión antes de engadir unha segunda asignación estática.

Probe as transicións que realmente despregue

Saia do alcance do Wi-Fi cunha sesión activa, despois volva entrar, e comprobe que as respostas chegan nos dous sentidos. Fágao dúas veces, porque a segunda transición é onde adoita aparecer unha política obsoleta. Probe cun servizo que responda na conexión que abriu, e repita a saída mentres o túnel leva tráfico en lugar de estar parado. Un teléfono que pode enviar pero non recibir parece san nun rexistro de handshake e roto nun navegador.

Unha pantalla de estado reducida a unha fila non é proba dun deseño que funciona, só proba de que un túnel se foi. Ambos os sentidos teñen que funcionar antes de que unha transición pase. Anote o que observou, xunto coas dúas saídas da comprobación de solapamento, para que o seguinte enxeñeiro poida comparar en lugar de repetir o paseo.