Por qué IKEv2 falla en Android con un puerto UDP no estándar

La puerta de enlace responde a IKEv2 en el UDP 4443 por algún motivo, el perfil tiene un campo llamado Server, usted escribe el nombre de host y el puerto, y el teléfono informa de que no puede alcanzar el servidor o no puede resolver la dirección. No se está bloqueando nada. El formulario nativo de Android espera un host, y lo mismo ocurre en Windows. Un puerto personalizado es una capacidad del cliente antes que un ajuste del servidor, y solo algunos clientes le dejan expresarlo. Recorra las tres partes en orden: qué puede decir el cliente, en qué escucha el servidor y si ambos extremos entraman los paquetes de la misma forma.

Qué envió realmente el teléfono

Una cadena host:port en un campo pensado para un nombre se resuelve como un nombre. El resolutor no devuelve nada para vpn.example.net:4443, y el error que ve es un fallo de resolución de nombres o de accesibilidad, no un tiempo de espera agotado en un puerto. Esa distinción importa, porque reintentar con un nombre más corto o con otra red nunca arreglará una cadena que el formulario no puede analizar.

El perfil nativo de IKEv2 en Android, igual que el cliente VPN integrado de Windows, está fijado a los puertos IKE estándar. Ninguno de los dos expone un campo de puerto, y ninguna cantidad de edición del perfil añade uno. Si el oyente del operador está realmente en el 4443, el cliente integrado es la herramienta equivocada, no una mal configurada.

Use un cliente que exponga el puerto

El cliente strongSwan para Android documenta un puerto de servidor configurable en los ajustes avanzados del perfil, por eso aparece en casi todas las recetas que funcionan para este diseño. Ese soporte pertenece a ese cliente: otra aplicación IKEv2, o una bifurcación de proveedor de la misma aplicación, puede no exponer el mismo campo aunque el demonio strongSwan subyacente lo admita.

Pida al operador el conjunto completo de una vez: nombre de la puerta de enlace, puerto UDP, método de autenticación y la identidad del servidor que el cliente debe esperar. Un puerto personalizado no es motivo para desactivar la comprobación de certificados ni para cambiar de protocolo. Introduzca el puerto donde el cliente instalado lo espera, y si ese cliente no tiene tal campo, la respuesta es otro cliente aprobado y no una solución improvisada.

El servidor tiene dos puertos, y ambos deben coincidir

IKE empieza en el UDP 500, y el tránsito NAT suele mover IKE y el ESP encapsulado al UDP 4500. Son ajustes separados en strongSwan, así que un servidor trasladado a un único puerto personalizado debe cambiar ambos al mismo valor:

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

Con un solo puerto para ambos papeles, el demonio tiene que distinguir IKE de ESP-dentro-de-UDP en el mismo socket, lo que hace mediante el marcador de cuatro bytes que no es ESP y que precede a un mensaje IKE. Por eso un cliente no puede negociar en el puerto personalizado y luego continuar en silencio por el 4500, y por eso la frase “solo hay que cambiar el puerto” esconde un requisito de entramado.

Un reenvío no es un oyente

Reenviar el 4443 a un oyente IKE corriente es el modo de fallo que parece casi un éxito. El primer intercambio llega, el servidor responde, y entonces la conexión se detiene o regenera claves hacia la nada, porque la respuesta sale por otro puerto y el tráfico encapsulado posterior nunca coincide con el estado que crearon los dos extremos. Una regla que reescribe el puerto de destino sin mover el oyente produce exactamente este resultado entreabierto.

La ruta también tiene que permitir UDP de extremo a extremo. Que el TCP 443 pase por una red de hotel o de operador no dice nada sobre IKEv2 en un puerto UDP, ni siquiera con el mismo número. Donde solo se permite el TCP 443, un puerto UDP personalizado no convierte IKEv2 en HTTPS, y la respuesta correcta puede ser otra ruta de acceso en lugar de otro experimento con puertos.

Separe las tres etapas al probar

Capture en el servidor mientras el cliente lo intenta una vez. Una petición que nunca llega es una cuestión de extremo o de cortafuegos; una petición que llega sin respuesta es una cuestión de oyente o de política; una respuesta seguida de silencio es la cuestión del entramado o de la identidad.

tcpdump -ni eth0 -vv udp port 4443

Después lea el mensaje del cliente en lugar de su indicador giratorio. Un error de propuesta significa que los algoritmos no coinciden, un fallo de autenticación significa que las identidades o los certificados no coinciden, y las retransmisiones repetidas sin respuesta significan que nada responde en ese puerto. Pruebe una etapa a la vez y cambie un solo campo entre intentos; la documentación de strongSwan sobre el tránsito NAT describe el marcador y el comportamiento del puerto que la captura le está mostrando.