Per què IKEv2 falla a Android en un port UDP no estàndard

La passarel·la respon a IKEv2 a l’UDP 4443 per algun motiu, el perfil té un camp anomenat Server, hi escriviu el nom d’amfitrió i el port, i el telèfon informa que no pot arribar al servidor o que no pot resoldre l’adreça. No s’hi bloqueja res. El formulari natiu d’Android espera un amfitrió, i el mateix passa a Windows. Un port personalitzat és una capacitat del client abans que un paràmetre del servidor, i només alguns clients us deixen expressar-lo. Recorreu les tres parts en ordre: què pot dir el client, a què escolta el servidor i si tots dos extrems emmarquen els paquets de la mateixa manera.

Què va enviar realment el telèfon

Una cadena host:port en un camp pensat per a un nom es resol com un nom. El resolutor no retorna res per a vpn.example.net:4443, i l’error que veieu és una fallada de resolució de nom o d’inabastabilitat, no un temps d’espera esgotat en un port. Aquesta distinció importa, perquè reintentar amb un nom més curt o una altra xarxa no arreglarà mai una cadena que el formulari no pot analitzar.

El perfil natiu d’IKEv2 a Android, igual que el client VPN integrat de Windows, està fixat als ports IKE estàndard. Cap dels dos exposa un camp de port, i cap quantitat d’edició del perfil n’afegeix un. Si l’oient de l’operador és realment al 4443, el client integrat és l’eina equivocada, no una eina mal configurada.

Feu servir un client que exposi el port

El client strongSwan per a Android documenta un port de servidor configurable a la configuració avançada del perfil, i per això apareix en gairebé tota recepta que funciona per a aquest disseny. Aquest suport pertany a aquest client: una altra aplicació IKEv2, o una bifurcació de proveïdor de la mateixa aplicació, pot no exposar el mateix camp encara que el dimoni strongSwan subjacent el suporti.

Demaneu a l’operador el conjunt sencer alhora: nom de la passarel·la, port UDP, mètode d’autenticació i la identitat del servidor que el client ha d’esperar. Un port personalitzat no és motiu per desactivar la comprovació de certificats ni per canviar de protocol. Introduïu el port on el client instal·lat l’espera, i si aquest client no té aquest camp, la resposta és un altre client aprovat i no una solució improvisada.

El servidor té dos ports, i tots dos han de coincidir

IKE comença a l’UDP 500, i el trànsit NAT sol moure IKE i l’ESP encapsulat a l’UDP 4500. Són paràmetres separats a strongSwan, així que un servidor traslladat a un sol port personalitzat ha de canviar tots dos al mateix valor:

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

Amb un sol port per a tots dos papers, el dimoni ha de distingir IKE d’ESP-dins-d’UDP al mateix sòcol, cosa que fa amb el marcador de quatre bytes que no és ESP i que precedeix un missatge IKE. Per això un client no pot negociar al port personalitzat i després continuar en silenci al 4500, i per això la frase “només cal canviar el port” amaga un requisit d’emmarcament.

Un reenviament no és un oient

Reenviar el 4443 a un oient IKE corrent és el mode de fallada que sembla gairebé un èxit. El primer intercanvi arriba, el servidor respon, i llavors la connexió s’atura o regenera claus fins a no res, perquè la resposta surt d’un port diferent i el trànsit encapsulat posterior no encaixa mai amb l’estat que han creat els dos extrems. Una regla que reescriu el port de destinació sense moure l’oient produeix exactament aquest resultat mig obert.

El camí també ha de permetre UDP d’extrem a extrem. Que el TCP 443 passi per una xarxa d’hotel o d’operadora no diu res sobre IKEv2 en un port UDP, ni tan sols amb el mateix número. On només es permet el TCP 443, un port UDP personalitzat no converteix IKEv2 en HTTPS, i la resposta correcta pot ser un altre camí d’accés i no un altre experiment de port.

Separeu les tres etapes quan proveu

Captureu al servidor mentre el client ho intenta una vegada. Una petició que no arriba mai és una qüestió d’extrem o de tallafoc; una petició que arriba sense resposta és una qüestió d’oient o de política; una resposta seguida de silenci és la qüestió d’emmarcament o d’identitat.

tcpdump -ni eth0 -vv udp port 4443

Després llegiu el missatge del client i no el seu indicador giratori. Un error de proposta vol dir que els algorismes no coincideixen, una fallada d’autenticació vol dir que les identitats o els certificats no coincideixen, i retransmissions repetides sense resposta volen dir que no hi ha res que contesti en aquell port. Proveu una etapa alhora i canvieu un sol camp entre intents; la documentació de strongSwan sobre el trànsit NAT descriu el marcador i el comportament del port que la captura us està mostrant.