A mesma identidade IKEv2 em dois iPhone? Eles se conectam alternadamente

Dois telefones, um perfil e um padrão que parece sobrenatural até alguém olhar para o gateway. Um dispositivo mantém o túnel, o segundo se conecta e o primeiro o perde em segundos. O primeiro se reconecta e o segundo cai. Culpam-se a economia de bateria, o roaming Wi-Fi e o NAT da operadora, enquanto a causa real está num campo de texto copiado junto com todo o resto. O IKEv2 identifica um peer por um nome, e os dois telefones apresentam o mesmo.

A identidade é a chave sob a qual o servidor o guarda

Dentro de uma troca IKEv2 cada lado declara quem é: o iniciador envia um identificador local, o respondedor responde com o seu e também verifica a identidade alegada pelo iniciador contra a política. O gateway guarda o estado por identidade e não por dispositivo, porque um dispositivo não é algo que ele possa ver. Dois telefones com um identificador chegam, portanto, como um único peer, e a segunda troca precisa sobrescrever a primeira. O problema só aparece enquanto os dois estão em uso, e é por isso que um teste com um único telefone nunca o reproduz.

Nada disso é um defeito no cliente. O cliente enviou exatamente o que o perfil mandou.

Como a colisão aparece no gateway

Observe a lista de peers enquanto os dois telefones estão acordados e em uso. Uma colisão mostra uma única entrada cujo endereço muda conforme os telefones se alternam, e o contador de sessões ativas nunca chega a dois. O desligamento sob demanda parece diferente, e distingui-los exige uma observação, não uma teoria.

Anote os dois eventos com carimbos de tempo enquanto acontece. Uma queda que coincide com a conexão do outro aparelho aponta para o identificador, e uma queda que chega um intervalo de inatividade após o último pacote aponta para um temporizador.

De onde vêm as duplicatas

Exportar uma configuração que funciona e editar apenas o endereço do servidor produz um segundo arquivo com a identidade do primeiro ainda dentro. Esse é o caminho comum para essa falha, e costuma acontecer ao integrar um grupo pequeno com pressa.

Os nomes dos campos tornam fácil passar despercebido. O identificador remoto nomeia o gateway que o telefone espera, e copiá-lo é correto. O identificador local nomeia este aparelho perante o gateway, e copiar esse valor é todo o problema.

Emita um valor por dispositivo

Use algo único para o aparelho e estável durante toda a sua vida, como o identificador do dispositivo do inventário ou um valor que o seu sistema de gestão gera por inscrição. Uma etiqueta de departamento, um nome de conta de serviço compartilhada ou o endereço de e-mail do utilizador colidem assim que essa pessoa tem um segundo dispositivo.

Gere a carga útil por dispositivo em vez de distribuir um único arquivo. Registe qual valor pertence a qual aparelho, para que uma substituição não restaure o perfil antigo e devolva o telefone novo diretamente à mesma colisão.

Verifique também o lado do servidor. Um gateway que mapeia a identidade para um endereço de túnel fixo ainda pode colidir quando dois identificadores diferentes recebem a mesma atribuição, por isso confirme que o pool tem espaço e que as atribuições não estão fixadas por utilizador.

Verifique com os dois telefones acordados

Conecte o primeiro, chegue a um recurso privado, depois conecte o segundo e deixe ambos inativos por um minuto. As duas sessões devem persistir e a lista de peers deve mostrar duas identidades. Depois bloqueie e desbloqueie cada telefone para confirmar que o caso de inatividade ainda se comporta bem.

Se uma única sessão ainda cair uma vez por dia sem que nada mais se conecte, a identidade já não é o suspeito. Passe para os temporizadores de inatividade e os limites de sessão do servidor em vez de editar o perfil outra vez.