Como o MOBIKE mantém uma VPN IKEv2 viva quando a rede muda

Um telemóvel deixa o Wi-Fi e junta-se à rede móvel, um portátil passa de Ethernet para um hotspot, e o túnel IKEv2 sobrevive ou não. O MOBIKE é a extensão que o deixa sobreviver, dizendo ao extremo remoto que o endereço de origem mudou em vez de começar de novo. O que não faz é manter cada aplicação viva durante a mudança. São duas afirmações, e a segunda é a que as pessoas costumam querer dizer.

Percorra a transição por etapas, porque cada etapa falha de forma diferente.

O que a atualização muda de facto

Enquanto a associação de segurança ainda for válida, o iniciador aprende o seu novo endereço e envia uma atualização ao respondedor, que depois usa esse endereço para a mesma associação. Os parâmetros de segurança não são renegociados de raiz. Essa é toda a vantagem: nenhuma nova ronda de autenticação, nenhuma nova troca de chaves, nenhum pedido ao utilizador. Significa também que o estado sobrevivente ainda pertence à sessão antiga.

O MOBIKE também pode passar o tráfego para encapsulamento UDP, e é por isso que um túnel funcional às vezes começa a usar a porta 4500 depois de uma mudança de rede. Essa transição, por si só, não prova que o NAT foi detetado, embora os dois apareçam frequentemente juntos.

O seu perfil ativa-o realmente

Ambos os pares têm de suportar a extensão, e a implementação tem de a ativar. No strongSwan o comportamento é configurável por ligação, e alterações de interface ou de rota podem desencadear uma procura de caminho e uma atualização quando necessário. Inspecione as definições reais da ligação em vez de assumir que todos os perfis IKEv2 a ativam. Um perfil copiado de um guia anterior a esta funcionalidade é uma fonte comum disto.

O estado negociado em ambas as pontas é a autoridade, não a documentação da família de produtos.

Percorra a transição por etapas

Registe o estado da aplicação antes de mudar de rede. Depois mude, e registe o estado do cliente e do servidor em seguida. Um endereço em falta, um par inalcançável e uma aplicação que tem de voltar a ligar a sua própria sessão são três resultados diferentes. Apenas os dois primeiros pertencem à camada VPN; o terceiro pertence ao protocolo que a aplicação fala.

Compare uma mudança de rede com um teste estacionário, para saber que evento desencadeia o problema. Uma medição de débito na rede final não consegue reproduzir uma transição. Mede o destino, não a viagem.

Separe as camadas de falha

Uma sessão TCP de longa duração pode falhar por motivos fora da troca IKEv2. A nova rede pode filtrar, resolver ou encaminhar de forma diferente. O endereço do túnel pode não mudar nada enquanto o caminho por baixo muda. É por isso que uma reconexão da aplicação pode corrigir algo que a VPN nunca quebrou.

Mantenha a política de bloqueio no lugar enquanto recupera, também.

A mobilidade automática e uma regra que impede o tráfego direto são controlos diferentes, e desativar o segundo para que o primeiro funcione é uma má troca. Se a atualização de mobilidade falhar, o bloqueio deve aguentar-se em vez de deixar escapar tráfego à volta do túnel.

O que registar quando se repete

Conserve as marcas temporais e ambos os valores de endereço dos dois lados. Esse registo mostra se a atualização terminou antes de a aplicação perder o contacto, que é a diferença entre um erro de mobilidade e um tempo limite da aplicação. Depois compare a direção da mudança: sair do Wi-Fi para a rede móvel não é simétrico com o contrário. Uma direção pode funcionar enquanto a outra falha.

Essa assimetria é suficientemente comum para ser a primeira coisa a testar.

Com o registo na mão, o incidente deixa de ser mais um ícone desligado e torna-se um evento numa sequência com um proprietário conhecido. E é tudo o que um percurso pode prometer honestamente.