Por que o IKEv2 falha no Android numa porta UDP não padrão
O formulário nativo do IKEv2 aceita um endereço, não uma porta. Confirme que o cliente o suporta, defina as duas portas do servidor e depois observe o enquadramento e os registos.
O gateway responde a IKEv2 na UDP 4443 por algum motivo, o perfil tem um campo chamado Server, você digita o nome do host e a porta, e o telefone relata que não consegue alcançar o servidor ou não consegue resolver o endereço. Nada está a ser bloqueado. O formulário nativo do Android espera um host, e o mesmo vale no Windows. Uma porta personalizada é uma capacidade do cliente antes de ser uma definição do servidor, e só alguns clientes permitem expressá-la. Percorra as três partes por ordem: o que o cliente pode dizer, em que escuta o servidor e se ambos os extremos enquadram os pacotes da mesma forma.
O que o telefone realmente enviou
Uma cadeia host:port num campo pensado para um nome é resolvida como um nome. O resolvedor não devolve nada para vpn.example.net:4443, e o erro que vê é uma falha de resolução de nome ou de acessibilidade, não um tempo limite esgotado numa porta. Essa distinção importa, porque tentar de novo com um nome mais curto ou outra rede nunca vai corrigir uma cadeia que o formulário não consegue analisar.
O perfil nativo do IKEv2 no Android, tal como o cliente VPN integrado do Windows, está fixo nas portas IKE padrão. Nenhum dos dois expõe um campo de porta, e nenhuma edição do perfil acrescenta um. Se o serviço de escuta do operador estiver realmente na 4443, o cliente integrado é a ferramenta errada, não uma mal configurada.
Use um cliente que exponha a porta
O cliente strongSwan para Android documenta uma porta de servidor configurável nas definições avançadas do perfil, por isso aparece em quase todas as receitas que funcionam para este desenho. Esse suporte pertence a esse cliente: outra aplicação IKEv2, ou um fork de fornecedor da mesma aplicação, pode não expor o mesmo campo mesmo que o daemon strongSwan subjacente o suporte.
Peça ao operador o conjunto completo de uma vez: nome do gateway, porta UDP, método de autenticação e a identidade do servidor que o cliente deve esperar. Uma porta personalizada não é motivo para desativar a verificação de certificados nem para mudar de protocolo. Introduza a porta onde o cliente instalado a espera, e se esse cliente não tiver tal campo, a resposta é outro cliente aprovado e não uma solução improvisada.
O servidor tem duas portas, e ambas têm de coincidir
O IKE começa na UDP 500, e o trânsito NAT costuma mover o IKE e o ESP encapsulado para a UDP 4500. São definições separadas no strongSwan, por isso um servidor movido para uma única porta personalizada tem de alterar ambas para o mesmo valor:
plugins {
socket-default {
port = 4443
port_nat_t = 4443
}
}
Com uma só porta para os dois papéis, o daemon tem de distinguir IKE de ESP-dentro-de-UDP no mesmo socket, o que faz através do marcador de quatro bytes que não é ESP e que precede uma mensagem IKE. Por isso um cliente não pode negociar na porta personalizada e depois continuar em silêncio na 4500, e por isso a frase “basta mudar a porta” esconde um requisito de enquadramento.
Um encaminhamento não é um serviço de escuta
Encaminhar a 4443 para um serviço de escuta IKE comum é o modo de falha que parece quase bem-sucedido. A primeira troca chega, o servidor responde, e depois a ligação estagna ou regenera chaves para nada, porque a resposta sai de outra porta e o tráfego encapsulado posterior nunca corresponde ao estado que os dois extremos criaram. Uma regra que reescreve a porta de destino sem mover o serviço de escuta produz exatamente este resultado meio aberto.
O caminho também tem de permitir UDP de ponta a ponta. O TCP 443 passar por uma rede de hotel ou de operadora não diz nada sobre IKEv2 numa porta UDP, nem sequer com o mesmo número. Onde só o TCP 443 é permitido, uma porta UDP personalizada não transforma o IKEv2 em HTTPS, e a resposta correta pode ser outro caminho de acesso em vez de mais uma experiência com portas.
Separe as três fases ao testar
Capture no servidor enquanto o cliente tenta uma vez. Um pedido que nunca chega é uma questão de extremo ou de firewall; um pedido que chega sem resposta é uma questão de serviço de escuta ou de política; uma resposta seguida de silêncio é a questão do enquadramento ou da identidade.
tcpdump -ni eth0 -vv udp port 4443
Depois leia a mensagem do cliente em vez do seu indicador giratório. Um erro de proposta significa que os algoritmos não coincidem, uma falha de autenticação significa que as identidades ou os certificados não coincidem, e retransmissões repetidas sem resposta significam que nada responde nessa porta. Teste uma fase de cada vez e mude um só campo entre tentativas; a documentação do strongSwan sobre o trânsito NAT descreve o marcador e o comportamento da porta que a captura lhe está a mostrar.