Pourquoi IKEv2 échoue sur Android avec un port UDP non standard

Le formulaire IKEv2 natif attend une adresse, pas un port. Vérifiez que le client le prend en charge, définissez les deux ports du serveur, puis examinez le tramage et les journaux.

La passerelle répond à IKEv2 sur l’UDP 4443 pour une raison, le profil comporte un champ nommé Server, vous saisissez le nom d’hôte et le port, et le téléphone signale qu’il ne peut pas joindre le serveur ou résoudre l’adresse. Rien n’est bloqué. Le formulaire natif d’Android attend un hôte, et il en va de même sous Windows. Un port personnalisé est une capacité du client avant d’être un réglage du serveur, et seuls certains clients vous laissent l’exprimer. Parcourez les trois parties dans l’ordre : ce que le client peut dire, ce sur quoi le serveur écoute et si les deux extrémités trament les paquets de la même manière.

Ce que le téléphone a réellement envoyé

Une chaîne host:port dans un champ prévu pour un nom est résolue comme un nom. Le résolveur ne renvoie rien pour vpn.example.net:4443, et l’erreur que vous voyez est un échec de résolution de nom ou d’accessibilité, non un délai expiré sur un port. Cette distinction compte, car réessayer avec un nom plus court ou un autre réseau ne réparera jamais une chaîne que le formulaire ne sait pas analyser.

Le profil IKEv2 natif d’Android, comme le client VPN intégré de Windows, est figé sur les ports IKE standard. Aucun des deux n’expose de champ de port, et aucune édition de profil n’en ajoute un. Si l’écoute de l’opérateur se trouve réellement sur 4443, le client intégré est le mauvais outil, pas un outil mal configuré.

Utilisez un client qui expose le port

Le client strongSwan pour Android documente un port de serveur configurable dans les réglages avancés du profil, c’est pourquoi il figure dans presque toutes les recettes qui fonctionnent pour cette conception. Ce support appartient à ce client : une autre application IKEv2, ou un fork fournisseur de la même application, peut ne pas exposer le même champ alors que le démon strongSwan sous-jacent le prend en charge.

Demandez à l’opérateur l’ensemble complet d’un coup : nom de la passerelle, port UDP, méthode d’authentification et l’identité du serveur que le client doit attendre. Un port personnalisé n’est pas une raison de désactiver la vérification des certificats ni de changer de protocole. Saisissez le port là où le client installé l’attend, et si ce client n’a pas un tel champ, la réponse est un autre client approuvé et non un contournement deviné.

Le serveur a deux ports, et les deux doivent correspondre

IKE démarre sur l’UDP 500, et la traversée NAT déplace généralement IKE et l’ESP encapsulé vers l’UDP 4500. Ce sont des réglages distincts dans strongSwan, donc un serveur déplacé sur un seul port personnalisé doit modifier les deux vers la même valeur :

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

Avec un seul port pour les deux rôles, le démon doit distinguer IKE de l’ESP-dans-UDP sur la même socket, ce qu’il fait grâce au marqueur de quatre octets qui n’est pas ESP et qui précède un message IKE. C’est pourquoi un client ne peut pas négocier sur le port personnalisé puis continuer silencieusement sur 4500, et pourquoi la phrase « changez simplement le port » cache une exigence de tramage.

Une redirection n’est pas une écoute

Rediriger 4443 vers une écoute IKE ordinaire est le mode de défaillance qui paraît presque réussi. Le premier échange arrive, le serveur répond, puis la connexion se bloque ou renégocie ses clés vers rien, parce que la réponse part d’un autre port et que le trafic encapsulé ultérieur ne correspond jamais à l’état créé par les deux extrémités. Une règle qui réécrit le port de destination sans déplacer l’écoute produit exactement ce résultat à moitié ouvert.

Le chemin doit aussi autoriser l’UDP de bout en bout. Que le TCP 443 passe par un réseau d’hôtel ou d’opérateur ne dit rien d’IKEv2 sur un port UDP, même avec le même numéro. Là où seul le TCP 443 est autorisé, un port UDP personnalisé ne transforme pas IKEv2 en HTTPS, et la bonne réponse peut être un autre chemin d’accès plutôt qu’une nouvelle expérience de port.

Séparez les trois étapes lors des tests

Capturez sur le serveur pendant que le client essaie une fois. Une requête qui n’arrive jamais est une question de point d’extrémité ou de pare-feu ; une requête qui arrive sans réponse est une question d’écoute ou de politique ; une réponse suivie de silence est la question du tramage ou de l’identité.

tcpdump -ni eth0 -vv udp port 4443

Lisez ensuite le message du client plutôt que son indicateur tournant. Une erreur de proposition signifie que les algorithmes ne concordent pas, un échec d’authentification signifie que les identités ou les certificats ne concordent pas, et des retransmissions répétées sans réponse signifient que rien ne répond sur ce port. Testez une étape à la fois et changez un seul champ entre les tentatives ; la documentation strongSwan sur la traversée NAT décrit le marqueur et le comportement de port que la capture vous montre.

Articles similaires