Por que IKEv2 falla en Android cun porto UDP non estándar

A pasarela responde a IKEv2 no UDP 4443 por algún motivo, o perfil ten un campo chamado Server, vostede escribe o nome de host e o porto, e o teléfono informa de que non pode chegar ao servidor ou non pode resolver o enderezo. Non se está bloqueando nada. O formulario nativo de Android espera un host, e o mesmo ocorre en Windows. Un porto personalizado é unha capacidade do cliente antes que un axuste do servidor, e só algúns clientes lle deixan expresalo. Percorra as tres partes en orde: que pode dicir o cliente, en que escoita o servidor e se ambos os extremos entraman os paquetes do mesmo xeito.

Que enviou realmente o teléfono

Unha cadea host:port nun campo pensado para un nome resólvese como un nome. O resolvedor non devolve nada para vpn.example.net:4443, e o erro que ve é un fallo de resolución de nomes ou de accesibilidade, non un tempo de espera esgotado nun porto. Esa distinción importa, porque reintentar cun nome máis curto ou con outra rede nunca arranxará unha cadea que o formulario non pode analizar.

O perfil nativo de IKEv2 en Android, igual que o cliente VPN integrado de Windows, está fixado aos portos IKE estándar. Ningún dos dous expón un campo de porto, e ningunha cantidade de edición do perfil engade un. Se o oínte do operador está realmente no 4443, o cliente integrado é a ferramenta equivocada, non unha mal configurada.

Use un cliente que expoña o porto

O cliente strongSwan para Android documenta un porto de servidor configurable nos axustes avanzados do perfil, por iso aparece en case todas as receitas que funcionan para este deseño. Ese soporte pertence a ese cliente: outra aplicación IKEv2, ou unha bifurcación de provedor da mesma aplicación, pode non expoñer o mesmo campo aínda que o daemon strongSwan subxacente o admita.

Pida ao operador o conxunto completo de vez: nome da pasarela, porto UDP, método de autenticación e a identidade do servidor que o cliente debe esperar. Un porto personalizado non é motivo para desactivar a comprobación de certificados nin para cambiar de protocolo. Introduza o porto onde o cliente instalado o espera, e se ese cliente non ten tal campo, a resposta é outro cliente aprobado e non unha solución improvisada.

O servidor ten dous portos, e ambos deben coincidir

IKE comeza no UDP 500, e o tránsito NAT adoita mover IKE e o ESP encapsulado ao UDP 4500. Son axustes separados en strongSwan, así que un servidor trasladado a un único porto personalizado debe cambiar ambos ao mesmo valor:

plugins {
  socket-default {
    port = 4443
    port_nat_t = 4443
  }
}

Con un só porto para ambos os papeis, o daemon ten que distinguir IKE de ESP-dentro-de-UDP no mesmo socket, o que fai mediante o marcador de catro bytes que non é ESP e que precede unha mensaxe IKE. Por iso un cliente non pode negociar no porto personalizado e despois continuar en silencio polo 4500, e por iso a frase “só hai que cambiar o porto” agocha un requisito de entramado.

Un reenvío non é un oínte

Reenviar o 4443 a un oínte IKE corrente é o modo de fallo que parece case un éxito. O primeiro intercambio chega, o servidor responde, e entón a conexión detense ou rexenera claves cara a nada, porque a resposta sae por outro porto e o tráfico encapsulado posterior nunca coincide co estado que crearon os dous extremos. Unha regra que reescribe o porto de destino sen mover o oínte produce exactamente este resultado entreaberto.

A ruta tamén ten que permitir UDP de extremo a extremo. Que o TCP 443 pase por unha rede de hotel ou de operador non di nada sobre IKEv2 nun porto UDP, nin sequera co mesmo número. Onde só se permite o TCP 443, un porto UDP personalizado non converte IKEv2 en HTTPS, e a resposta correcta pode ser outra ruta de acceso en lugar doutro experimento con portos.

Separe as tres etapas ao probar

Capture no servidor mentres o cliente o intenta unha vez. Unha petición que nunca chega é unha cuestión de extremo ou de cortafogos; unha petición que chega sen resposta é unha cuestión de oínte ou de política; unha resposta seguida de silencio é a cuestión do entramado ou da identidade.

tcpdump -ni eth0 -vv udp port 4443

Despois lea a mensaxe do cliente en lugar do seu indicador xiratorio. Un erro de proposta significa que os algoritmos non coinciden, un fallo de autenticación significa que as identidades ou os certificados non coinciden, e as retransmisións repetidas sen resposta significan que nada responde nese porto. Probe unha etapa á vez e cambie un só campo entre intentos; a documentación de strongSwan sobre o tránsito NAT describe o marcador e o comportamento do porto que a captura lle está mostrando.