OpenVPN TAP sous macOS : vérifiez le client avant de déboguer

Un ancien profil arrive sur un Mac récent, le client l’importe sans se plaindre, et la connexion tombe ou ne fait jamais passer de trafic. Avant de passer un après-midi sur les certificats, lisez la ligne de périphérique du profil. Si elle indique dev tap, vous demandez au client une interface de type Ethernet, et sous macOS c’est précisément sur cette demande que se terminent la plupart de ces sessions.

Étape 1 : confirmez que le profil demande bien TAP

Les profils sont renommés, remballés et réexportés, alors vérifiez le fichier que vous avez réellement importé. Cherchez la directive de périphérique et tout include susceptible de la remplacer. Deux lignes de sortie tranchent la question dans la plupart des cas. Quand dev et dev-type apparaissent tous les deux, la directive la plus tardive l’emporte, et c’est exactement le genre de détail qu’un profil copié dissimule.

grep -nE "^[[:space:]]*(dev|dev-type)[[:space:]]" client.ovpn
ls -l ~/Library/Application\ Support/ 2>/dev/null

Si le fichier contient dev tap ou dev tap0, le client doit implémenter une interface TAP. S’il contient dev tun, le reste de cet article ne s’applique pas et la panne est ailleurs.

Notez le nom et la version du client, la version de macOS et l’origine du profil. Ces trois faits déterminent laquelle des deux voies ci-dessous est seulement possible.

Étape 2 : sachez ce que le mode périphérique change réellement

Une interface TUN transporte des paquets IP. Le client lit et écrit des paquets adressés à un pair IP, et le système d’exploitation les achemine comme n’importe quelle autre interface.

Une interface TAP transporte des trames Ethernet, y compris la diffusion et ARP. C’est ce qui permet à un serveur ponté de distribuer des adresses via DHCP et à un client de découvrir des appareils en criant, et c’est pourquoi certains anciens designs en dépendent.

Le prix à payer est que TAP a besoin d’un pilote qui présente une interface Ethernet au système. Apple a déprécié le modèle d’extension du noyau sur lequel reposaient les anciens pilotes TAP pour Mac, et son API de remplacement n’apparaît pas par magie dans des clients qui n’ont jamais été mis à jour pour l’utiliser. Une capacité de plateforme et un produit livré sont deux choses différentes.

Étape 3 : choisissez entre un client compatible et une migration

Il existe deux voies honnêtes. La première est un client dont l’éditeur déclare, pour votre version de macOS et votre matériel, qu’il prend en charge la configuration TAP dont vous avez besoin. Pas un message de forum d’il y a quatre ans, ni un installateur archivé : une déclaration actuelle plus une connexion de test.

La seconde consiste à déplacer le service vers TUN, ce qui est autant un changement de serveur qu’un changement de client. Il faut une topologie routée, un pool d’adresses, des routes poussées pour les réseaux distants et un chemin de retour de ces réseaux vers le pool.

Ce qui ne fonctionne pas, c’est de modifier tap en tun dans votre copie locale en espérant que ça passe. Le serveur fait toujours pont, le client parle désormais IP, et rien ne s’accorde.

Étape 4 : rassemblez les faits avant de changer un service qui fonctionne

Laissez le profil d’origine intact et faites une copie pour les expériences. Un fichier que vous pouvez restaurer en une minute vaut plus qu’un dossier bien rangé. Une fois le remplacement fonctionnel, supprimez la copie volontairement plutôt que de laisser deux profils qui se ressemblent dans une liste. Cette seule habitude évite l’essentiel de la confusion qui suit une migration ratée. Consignez le comportement actuel pour pouvoir prouver ce qui a changé : le tunnel monte-t-il, obtient-il une adresse, atteignez-vous un hôte connu, et la résolution de noms fonctionne-t-elle.

Posez trois questions au propriétaire de la passerelle. Le serveur utilise-t-il une topologie pontée ou routée ? Quels préfixes distants doivent être joignables ? Et existe-t-il une fenêtre de maintenance pour modifier la configuration, ou cela doit-il fonctionner sans toucher au serveur ?

Les réponses déterminent si vous réglez un problème de client cet après-midi ou si vous planifiez un changement de réseau la semaine prochaine.

Étape 5 : vérifiez la migration aux deux extrémités

Une fois que le serveur dispose d’une configuration routée et que vous avez un profil correspondant, testez dans cet ordre : le tunnel s’établit, le client reçoit une adresse du nouveau pool, un hôte côté distant répond, et un nom se résout via le paramètre DNS poussé.

Testez ensuite ce qui dépendait auparavant du comportement Ethernet. Si une application découvrait des appareils par diffusion, elle ne les trouvera pas via un tunnel routé, et aucune configuration client ne rétablit cela. Cette application a besoin d’une adresse connue, d’un hôte auxiliaire local ou d’une autre méthode de découverte.

Terminez en vous reconnectant et en redémarrant une fois, car un profil qui ne fonctionne qu’à la première tentative signifie généralement que les routes poussées ou le paramètre DNS ne sont pas appliqués à la reconnexion.

Quand cela échoue encore, lisez la première erreur

Un client qui ne peut pas créer l’interface le dit dans son journal, généralement dans les premières lignes. Un client qui la crée puis échoue à s’authentifier a depuis longtemps dépassé la question du périphérique, et continuer à courir après TAP gaspille la session.

Conservez le profil d’origine et la configuration qui fonctionne jusqu’à ce que le remplacement soit prouvé. Annuler une modification client est rapide ; reconstruire un réseau ponté que quelqu’un a démonté sur une intuition ne l’est pas.