L'interface utun de la VPN du Mac est active mais le trafic échoue ? Vérifiez ifconfig

Vous avez connecté la VPN, exécuté ifconfig et trouvé une entrée utun4 avec une adresse dessus. Le site dont vous aviez besoin expire toujours. Cet écart est normal : la liste prouve qu'une interface virtuelle existe, pas que votre client la possède, que la route qui vous intéresse la sélectionne ou que des paquets la traversent. J'ai cessé de faire confiance au nom de l'interface après un après-midi passé à accuser le mauvais tunnel sur un portable qui avait déjà trois entrées utun avant que j'installe quoi que ce soit.

Ce que contient réellement une ligne utun

Exécutez ifconfig -a quand vous voulez l'image complète. Appelé sans argument, ifconfig n'affiche que les interfaces actuellement actives, et c'est pourquoi un tunnel qui n'a pas démarré peut manquer dans la sortie que les gens collent dans les tickets. ifconfig -l ne renvoie que les noms, et c'est le moyen le plus rapide de voir si un nouvel utun est apparu après votre connexion.

C'est en lisant une seule interface que se trouvent les détails utiles. Un tunnel connecté ressemble généralement à ceci :

utun4: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> mtu 1380
    inet 10.8.0.6 --> 10.8.0.5 netmask 0xffffffff
    inet6 fe80::ce81:b1c:bd2c:69e%utun4 prefixlen 64 scopeid 0x15

Trois champs portent la réponse. UP et RUNNING disent que le noyau est prêt à utiliser l'interface. POINTOPOINT plus l'adresse du pair --> est la signature d'un tunnel et non d'une liaison physique. La valeur mtu explique toute une classe de rapports « se connecte puis se fige », car les interfaces utun montent généralement avec une MTU réduite, 1380 dans plusieurs versions de macOS, et le client peut la remplacer. La liste des champs est assez courte pour être parcourue une fois dans le manuel d'ifconfig fourni par Apple.

Trouvez le processus derrière l'interface

ifconfig n'a aucune notion d'application propriétaire. Deux clients VPN, un service système et un tunnel oublié de la semaine dernière produisent tous des entrées qui semblent identiques à ce niveau. Sur mon propre Mac, utun0 à utun3 existaient avant que je configure quoi que ce soit ; Continuity et iCloud Private Relay utilisent aussi des tunnels, et aucun n'est la connexion que vous diagnostiquez.

Pour les tunnels qui enregistrent une configuration auprès du système, scutil --nc list est la corrélation la plus rapide. Il affiche chaque configuration avec son état et son identifiant de service, et celle qui est connectée est marquée ainsi :

scutil --nc list
* (Connected)   5F2A9C10-...   VPN  Work IKEv2

Les clients qui exécutent leur propre processus de tunnel au lieu d'enregistrer une configuration n'y apparaissent jamais. Tunnelblick et une instance openvpn en ligne de commande font partie de ce groupe, alors vérifiez aussi la table des processus : ps -Ao pid,comm | grep -i openvpn. Une fois qu'un processus possède le tunnel, le numéro utun appartient à ce processus et à personne d'autre.

Testez l'adresse avant de tester la route

Une interface peut être active sans adresse utilisable. Un profil IPv6 uniquement affiche une entrée fe80:: locale au lien et rien sur la ligne inet, et un client qui n'a pas réussi à appliquer une adresse poussée laisse exactement la même forme. Si votre destination est en IPv4 et que le tunnel n'a pas d'adresse IPv4, la question du routage est déjà tranchée.

La MTU mérite une vérification séparée, car la panne ne ressemble pas à un problème de taille. Elle ressemble à une connexion qui s'authentifie puis se tait dès qu'un gros transfert commence. Envoyez une sonde qui ne doit pas être fragmentée, dimensionnée pour que le paquet corresponde à la MTU de l'interface ; pour une MTU de 1400, la charge utile est de 1372 octets :

ping -D -s 1372 10.8.0.5

Une réponse signifie que des paquets de cette taille traversent le tunnel. Le silence alors que de petits pings réussissent pointe vers la MTU ou vers quelque chose qui jette ICMP en chemin, pas vers l'authentification, qui était déjà terminée avant même que vous ayez une interface.

Prouvez que la destination choisit le tunnel

La question qui compte n'est pas de savoir si utun4 existe, mais si le trafic vers une adresse précise sort par lui. route -n get y répond pour une seule destination et affiche la passerelle et l'interface qu'il utiliserait :

route -n get 203.0.113.20
  gateway: 10.8.0.5
  interface: utun4

Si la même commande signale en0, votre configuration de tunnel divisé fait ce qu'on lui a dit et aucune inspection d'interface n'y changera rien. Utilisez netstat -rn -f inet quand vous avez besoin de la route par défaut et de toute la table en une seule vue.

Les compteurs tranchent la question de savoir si les paquets bougent réellement. netstat -ib indique les totaux de paquets et d'octets par interface, entrées utun comprises ; les chiffres sont cumulatifs, alors lisez-les deux fois avec un intervalle et comparez :

netstat -ib | grep utun4

Des compteurs figés pendant que l'application réessaie signifient que le noyau n'a jamais remis de paquet à l'interface. Des compteurs qui grimpent dans les deux sens alors que l'application échoue encore déplacent l'enquête à l'autre extrémité du tunnel.

Quand aucun utun n'apparaît

Une liste d'interfaces vide après une connexion qui semblait réussie signifie généralement que le tunnel n'a jamais démarré, pas que ifconfig le cache. Vérifiez l'état du client lui-même, puis celui du système : une extension réseau jamais approuvée, ou désactivée par macOS après une mise à jour, ne laisse aucune interface derrière elle. L'approbation se trouve dans Réglages Système, sous Login Items & Extensions, et une entrée obsolète à cet endroit mérite d'être rebasculée avant de réinstaller quoi que ce soit.

La numérotation utun n'est pas stable d'une reconnexion à l'autre. Vous pouvez obtenir utun5 là où utun4 existait il y a dix minutes, car l'ancienne interface est démontée et le noyau attribue l'index libre suivant. Les scripts qui codent un nom en dur cassent silencieusement à ce moment-là ; faites plutôt correspondre l'adresse ou la route.

Gardez le côté lecture en lecture seule. sudo ifconfig utun4 down interrompt le tunnel, et sur un profil de tunnel complet il emporte votre session distante avec lui, ce qui est un mauvais échange quand vous cherchiez seulement à réunir des preuves. Rien de ce dont vous avez besoin ici n'exige root : lire les indicateurs, les adresses et les compteurs fonctionne avec votre utilisateur normal.

Déroulez les vérifications dans l'ordre la prochaine fois qu'un tunnel Mac se comporte mal : confirmez qu'un utun est apparu avec ifconfig -l, lisez ses indicateurs, ses adresses et sa MTU, attribuez-le à un processus, demandez à route -n get quelle interface la destination utilise, puis regardez netstat -ib bouger. Chaque étape élimine une couche différente, et la première qui revient fausse est l'endroit de la correction.