Quelle connexion a échoué : l’accès eduroam ou le VPN ?
Rejoindre eduroam, c’est s’inscrire sur un réseau d’accès ; rejoindre un VPN est une relation distincte. Déterminez quelle connexion a réellement échoué avant que quiconque ne touche à un port.
Derrière la phrase « le VPN ne fonctionne pas sur eduroam » se trouvent deux connexions, et des équipes différentes en sont responsables. Rejoindre eduroam amène l’appareil sur un réseau d’accès ; rejoindre un VPN construit une seconde relation par-dessus cette connexion. Les deux peuvent être gérées par le même établissement, mais les identifiants, le profil et l’étape où ça casse restent séparés. Déterminez laquelle des deux a réellement échoué avant que quiconque modifie un numéro de port. Tout ce qui suit s’organise autour de cette seule bifurcation.
Un campus où OpenVPN répondait sur l’UDP 1194 relève de l’histoire utile, pas d’une recette pour le suivant.
Prouvez d’abord le côté accès
Coupez le tunnel et chargez une page HTTP simple ou un portail captif. Si elle s’ouvre, le réseau d’accès fait son travail et la question du VPN est réellement ouverte. Si rien ne se charge, la panne se situe dans l’association, le compte ou le profil d’inscription. Aucun changement du VPN ne touchera l’un de ces trois.
Le guide de connexion à eduroam fait de l’établissement d’origine la source de l’identité de l’utilisateur. Quand un assistant de configuration construit un profil, choisir l’établissement visité plutôt que celui d’origine produit une configuration qui ne peut pas s’authentifier. Utilisez ce que publie l’établissement d’origine, et non un paquet de certificats venu d’ailleurs.
Désactiver une vérification de certificat ou d’authentification pour franchir une connexion transforme une mauvaise configuration réparable en défaut permanent. Si le profil installé vient d’une source non approuvée, remplacez-le avant de chercher autre chose.
Qui possède quelle panne
Une fois l’accès fonctionnel, chaque question restante a exactement un propriétaire. Voici toute la répartition :
| Owner | Questions that belong to them |
|---|---|
| VPN operator | Server name, protocol, transport, port, client compatibility, VPN authentication |
| Visited network operator | Which traffic the local arrangement permits, and any observed path problem |
| Device or client administrator | Local policy, client build, server-identity errors |
La ligne du transport est l’endroit où échouent la plupart des tentatives faites soi-même. Ce sur quoi le serveur écoute est fixé dans sa configuration, et modifier le profil du client ne peut pas le changer, donc demandez à l’opérateur le profil actuel au lieu de basculer entre TCP et UDP. Le basculement ne change que la façon dont le client échoue.
Du côté visité, une authentification eduroam réussie ne dit rien sur le fait que ce chemin transporte ou non un transport VPN donné, et un simple délai d’attente n’est pas une preuve de blocage. Les deux affirmations sont faites chaque jour, et chacune a besoin d’une observation derrière elle.
Du côté de l’appareil, une règle de sécurité gérée, une version de client incompatible et une erreur d’identité du serveur sont trois pannes différentes. Les regrouper dans un seul ticket ralentit les trois.
Choisissez la preuve avant la théorie
Là où le profil est à vous pour le tester et où l’opérateur l’a approuvé, une comparaison vaut mieux qu’une discussion : le même profil se connecte-t-il depuis un autre réseau de confiance ? Un « oui » pointe le chemin visité, un « non » pointe le profil, le serveur ou le client. Faites ce test dans les règles qui s’appliquent au compte, et jamais en installant un client que personne n’a approuvé.
Si l’opérateur publie un profil alternatif approuvé, utilisez-le. Inventer un écouteur sur un nouveau port ou assouplir les règles du réseau produit un résultat que personne ne pourra défendre plus tard, et cela masque la panne d’origine.
Écrivez le résultat sous la forme dont les trois propriétaires peuvent se servir, pas sous la forme la plus rapide à taper. Un délai d’attente nu ne dit rien d’utile à l’opérateur du VPN, et un échec d’authentification en dit tout aussi peu à l’opérateur du réseau visité.
Une seule ligne de journal suffit souvent à trancher. TLS Error: TLS key negotiation failed to occur within 60 seconds pointe le chemin ou le port, tandis que AUTH_FAILED signifie que le tunnel a été atteint et que les identifiants ont été refusés.
Écrivez la transmission en cinq lignes
Une transmission concise porte cinq choses : le lieu visité, l’heure de la tentative, la version de client approuvée, le serveur et le transport vers lesquels le profil pointait, et la première erreur informative. Ajoutez si l’accès ordinaire fonctionnait et si une comparaison approuvée entre réseaux a été faite, si vous avez ces deux éléments. Masquez les mots de passe, les jetons et les clés privées avant que cela ne quitte votre bureau.
Si le VPN s’authentifie puis qu’une application privée échoue, transmettez ce résultat ultérieur à part. Les deux questions précédentes sont alors tranchées, et les replier dans un nouveau rapport « toujours cassé » renvoie tout le monde au début.
Cinq lignes, trois propriétaires, une bifurcation : c’est toute la décision, et elle est généralement tranchée avant que quiconque touche à un numéro de port.