Netgear OpenVPN : TUN et TAP écoutent sur des ports différents

Un téléphone se connecte au VPN du routeur sans se plaindre, et un ordinateur portable utilisant un profil de la même page de téléchargement expire. Rien n'a changé du côté des certificats entre ces deux tentatives, car le portable n'a jamais atteint le point où les certificats comptent. Le routeur publie des écouteurs distincts pour TUN et TAP, et un profil fonctionnel doit choisir celui qui correspond à son propre type d'appareil.

Décider lequel des trois défauts candidats poursuivre est tout le travail ici : le port, le type d'appareil ou la négociation du chiffrement du canal de données.

Trois choses qui doivent concorder

Le type d'appareil, la ligne d'interface du profil et le port d'écoute forment un seul choix, pas trois. Un profil déclarant dev tun et visant l'écouteur TAP ne peut pas terminer la session, et l'inverse échoue de la même manière. Pour votre modèle et votre micrologiciel, lisez le port sur la page VPN du routeur plutôt que dans un guide, car les numéros bougent d'une version à l'autre. Notez le modèle et la version du micrologiciel à côté de ce numéro pour que la personne suivante puisse le vérifier.

Les rapports de terrain mentionnent une paire comme 12973 pour TUN et 12974 pour TAP sur un micrologiciel, et un numéro différent sur un autre. Lisez-les comme la preuve que les versions diffèrent, non comme des constantes à copier. Le profil a alors besoin du nom d'hôte adapté à la distance : le nom DNS dynamique du routeur plutôt qu'une adresse WAN qui changera.

Après avoir corrigé le port et la ligne d'interface, le profil ressemble à une configuration client normale avec une ligne remote et une ligne dev. Si les deux ne concordent pas, aucune quantité de nouvelles tentatives ne produit de session.

Lisez le journal dans l'ordre où il s'affiche

Un client OpenVPN rapporte les événements dans l'ordre où ils se produisent, donc la dernière ligne avant le silence identifie la couche à inspecter. Quand l'exécution se termine sur TLS Error: TLS key negotiation failed, ou attend simplement une première réponse puis abandonne, la comparaison de certificats n'a jamais eu lieu. Cela pointe vers la joignabilité, vers l'écouteur ou vers un port qui n'a rien derrière. Rien de tout cela ne se répare en remplaçant le fichier CA.

Une exécution qui atteint VERIFY OK puis échoue se situe ailleurs, avec ses propres causes. Trier ces deux issues avant de toucher aux fichiers évite le détour classique par des paquets de certificats qui n'ont jamais été consultés. Une fois la poignée de main terminée mais le tunnel non monté, regardez la négociation du chiffrement plutôt que la joignabilité.

Ajoutez la liste de chiffrements qu'un client moderne attend

Les clients OpenVPN récents refusent les anciennes valeurs par défaut que le micrologiciel grand public propose encore, et le symptôme est un échec de négociation juste après une poignée de main réussie. Le correctif est une ligne de profil nommant ce que le client acceptera : réglez data-ciphers sur AES-256-GCM, AES-128-GCM, CHACHA20-POLY1305 et AES-128-CBC dans cet ordre. Tout algorithme que le routeur n'implémente pas n'est tout simplement jamais choisi, donc une liste plus longue ne coûte qu'une négociation un peu plus longue.

Lister des chiffrements n'apprend pas au routeur celui qu'il n'a pas. Si la négociation échoue encore, vérifiez si la page du routeur a son propre réglage de chiffrement et si ce réglage inclut au moins une entrée que le client accepte. Deux listes sans membre commun produisent exactement le même échec qu'un mauvais port, et c'est pourquoi les deux extrémités méritent un coup d'œil.

Importez une fois au lieu de modifier des copies à la main

Importer le fichier corrigé dans NetworkManager évite un dossier plein de profils légèrement différents : nmcli connection import type openvpn file client.ovpn, puis activez-le par son nom. Gardez le profil importé comme l'unique copie que vous modifiez, et supprimez les doublons qui s'accumulent au fil des téléchargements répétés.

Testez ensuite depuis l'extérieur du LAN. Se connecter depuis le même réseau prouve très peu, car le trafic peut ne jamais traverser le tunnel. Confirmez qu'une requête sort réellement par le routeur, pas seulement que le client affiche un état connecté.

Décidez quoi faire des avertissements

Le micrologiciel grand public forge généralement sa propre autorité de certification, et les clients se plaignent de la vérification d'une manière que le micrologiciel ne peut pas supprimer. Jugez si cette plainte compte pour ce que vous protégez au lieu de traiter chaque avertissement comme fatal, et ne désactivez pas la vérification globalement pour faire taire un seul message. Un avertissement que vous avez évalué est un risque documenté ; un réglage de vérification que vous avez désactivé ne l'est pas.

Quand le micrologiciel n'offre aucun moyen pris en charge de corriger un avertissement qui compte vraiment, cette lacune plaide pour héberger le VPN ailleurs. Choisir entre réparer le profil, accepter l'avertissement et déplacer le point de terminaison est une décision sur la confiance que vous accordez à ce certificat. Prenez-la délibérément et notez l'option choisie, plutôt que de cliquer dans des boîtes de dialogue jusqu'à ce que l'icône passe au vert.