iPhone Always On VPN: dois túneis podem partilhar um IP virtual

Num iPhone supervisionado com um perfil Always On gerido, o telefone mantém um túnel por cada interface IP ativa, pelo que a rede móvel e o Wi-Fi têm cada um o seu. O servidor lista então duas associações de segurança IKE para um único dispositivo, muitas vezes partilhando um endereço virtual, e o primeiro instinto é chamar a isso ciclo de rekey e começar a alterar temporizadores. Esse instinto costuma estar errado. Percorra os passos abaixo na ordem em que as provas aparecem no servidor, e deixe as definições do telefone em paz até o servidor lhe dizer qual é o caso.

Comece pelas duas linhas que o servidor já tem

Liste as associações com swanctl --list-sas e leia quatro campos nas duas entradas: o endereço remoto, a identidade autenticada, o IP virtual atribuído e a hora de criação. Dois endereços externos diferentes com uma identidade e um IP virtual é a forma que iniciou esta pergunta, e vale a pena registá-la antes de qualquer alteração. Depois verifique as associações filhas ligadas a cada uma, porque os seletores de tráfego decidem se uma procura de destino poderia alguma vez distinguir os dois túneis. Um par que aparece e desaparece em segundos é um animal diferente de um par em que ambos vivem horas.

Ordene a lista por hora de criação antes de tirar uma conclusão. A adjacência na saída não significa nada, e uma listagem tabular convida exatamente a esse erro.

Decida qual sobreposição está a observar

O rekey IKEv2 e a reautenticação make-before-break criam de propósito uma sobreposição breve, estabelecendo a nova associação antes de eliminar a antiga. As marcas temporais resolvem o caso, porque uma SA antiga que desaparece um ou dois segundos depois de a nova aparecer é renovação a fazer o seu trabalho. Os túneis independentes por interface nunca se parecem com isso, já que cada um persiste enquanto a sua interface está ativa e eliminar um não decorre de criar o outro.

O comportamento Always On gerido da Apple é por interface, e é por isso que um dispositivo supervisionado pode parecer legitimamente mais ocupado do que um perfil configurado à mão. O botão de ligação automática de uma aplicação de fornecedor não implica o mesmo, e uma regra on-demand comum também não. A visão geral de implementação da Apple descreve o modelo por interface; compare as suas duas linhas com ela antes de assumir um ciclo. Ambas as formas também bebem do mesmo pool do servidor, pelo que a sobreposição é o seu único sinal precoce.

Veja porque é que um endereço virtual para dois túneis quebra as respostas

Uma resposta ao telefone é endereçada ao endereço interno, e o núcleo escolhe um túnel de saída por destino e política, não pela interface que o telefone usou. Duas associações simultâneas que detêm o mesmo IP virtual com políticas coincidentes deixam a decisão de encaminhamento sem forma de dizer a que sessão pertence uma resposta. Algumas respostas tomam o túnel errado, e o telefone mostra uma ligação que funciona num sentido ou morre quando o Wi-Fi aparece. Duas saídas de comando provam o estado: swanctl --list-sas a mostrar o mesmo IP virtual nas duas SA, e ip xfrm policy a mostrar dois seletores idênticos.

É precisamente esse par de saídas que cola no registo de alterações. Nenhuma delas sozinha é convincente, porque qualquer uma pode parecer plausível isolada.

Isto é endereçamento e política do lado do servidor, não mau comportamento do telefone, e nenhuma definição do cliente separa dois endereços internos idênticos. O pool entregou o mesmo valor duas vezes e o instalador de políticas aceitou-o. Leia o resultado do lado do servidor antes de culpar o cliente.

Altere o pool ou o modelo de concorrência, não o temporizador de rekey

Na configuração do swanctl, a unicidade é uma política explícita na ligação: unique = replace remove uma ligação mais antiga quando uma nova se estabelece, e unique = keep rejeita a recém-chegada. Ambos os valores atuam quando uma ligação é montada, não nas SA filhas dentro dela.

connections {
  ios-alwayson {
    unique = replace
  }
}

Nenhum dos valores é neutro para um cliente por interface. keep restaura um ecrã de estado arrumado ao rejeitar o segundo túnel e quebra o desenho gerido, enquanto replace derruba o túnel mais antigo e é o mesmo compromisso no sentido oposto. Se ambos os túneis são realmente necessários, o backend do pool tem de emitir concessões distintas para uma identidade, e a sua chave de concessão tem de distinguir os pedidos. Uma tabela estática identidade-para-endereço devolverá alegremente o mesmo endereço duas vezes e reproduzirá o problema original com mais configuração. Verifique como o backend gera as chaves de concessão antes de acrescentar um segundo mapeamento estático.

Teste as transições que realmente implementa

Saia do alcance do Wi-Fi com uma sessão ativa, depois volte a entrar, e confirme que as respostas chegam nos dois sentidos. Faça-o duas vezes, porque é na segunda transição que uma política obsoleta costuma aparecer. Teste com um serviço que responda na ligação que abriu, e repita a saída enquanto o túnel transporta tráfego em vez de estar parado. Um telefone que consegue enviar mas não receber parece saudável num registo de handshake e avariado num navegador.

Um ecrã de estado reduzido a uma linha não é prova de um desenho que funciona, apenas prova de que um túnel desapareceu. Os dois sentidos têm de funcionar antes de uma transição passar. Anote o que observou, juntamente com as duas saídas da verificação de sobreposição, para que o próximo engenheiro possa comparar em vez de repetir o passeio.