Pourquoi le VPN de votre Mac tombe quand vous branchez un iPhone en USB

Vous branchez un iPhone pour le charger et, une minute plus tard, le VPN de votre Mac cesse de faire passer le trafic. Réglages Système affiche un nouveau service nommé iPhone USB, et le geste évident est de le supprimer. Ce geste est souvent une erreur. Le service peut être le point d’accès personnel du téléphone, ou une liaison que Xcode et les outils d’appareils utilisent pour parler au téléphone, et les deux se comportent assez différemment pour que l’identification précède la suppression.

Étape 1 : Lisez le service que le téléphone a réellement créé

Ouvrez Réglages Système, puis Réseau, et comparez la liste des services avec le téléphone débranché et branché. Sur macOS actuel, le service apparaît sous le nom iPhone USB. Notez s’il est actif, où il se situe dans l’ordre des services et si le Mac l’utilise pour la route par défaut. L’ordre des services compte, car macOS choisit le service actif le plus haut capable d’atteindre une destination, pas celui dont vous reconnaissez le nom.

Le guide d’Apple sur le point d’accès personnel décrit le mécanisme : tant que le point d’accès personnel est activé sur le téléphone, le brancher en USB peut amener le Mac à utiliser la connexion cellulaire du téléphone, même quand vous vouliez seulement le charger. Ce n’est pas un défaut du client VPN ; la table de routage suit un service monté avant le Wi-Fi.

Si le service existe mais reste inactif avec le téléphone branché, vous regardez très probablement une connexion de charge seule ou une liaison d’appareil, pas un point d’accès. Gardez cette distinction, car les deux étapes suivantes la testent au lieu de la deviner à partir de l’icône.

Étape 2 : Vérifiez quelle route utilise le point de terminaison du VPN

Lisez la route vers l’adresse résolue du serveur VPN, pas vers un site web. route -n get est en lecture seule et affiche l’interface et la passerelle que le noyau utiliserait, et les deux lignes comptent.

scutil --dns | head -20
route -n get 203.0.113.10

L’adresse ci-dessus est un espace réservé de documentation. Remplacez-la par le point de terminaison que votre client affiche, et utilisez route -n get -inet6 pour un point de terminaison IPv6. Comparez la sortie avec le téléphone débranché et branché, et n’ajoutez ni ne retirez de routes entre les deux lectures. Si l’interface passe de en0 à l’interface iPhone USB, la route du point d’accès a gagné la recherche et la connexion extérieure du VPN passe maintenant par le réseau cellulaire.

Un changement de route n’explique pas toutes les pannes. Le client peut encore atteindre le serveur et échouer plus tard sur le trafic intérieur du tunnel, parce que le nouveau chemin a un MTU différent ou que l’opérateur bloque le protocole. Lisez l’erreur propre au client avant de changer quoi que ce soit : un délai de poignée de main extérieur pointe vers l’accessibilité, tandis qu’un tunnel établi qui cesse de faire passer du trafic pointe vers le MTU, le DNS ou une politique.

Étape 3 : Séparez un point d’accès d’une liaison de communication avec l’appareil

Xcode 15 et les versions ultérieures parlent à un appareil branché en USB par un canal réseau qui inclut de l’IPv6 de lien local, donc un Mac de développement peut afficher une interface supplémentaire qui n’a rien à voir avec l’accès à internet. La note technique TN3158 d’Apple documente ce comportement et avertit que le VPN ou le filtrage de sécurité peut interférer avec lui. C’est l’inverse du problème du point d’accès : le VPN ne casse pas parce que le téléphone offre internet ; la connexion de l’appareil casse parce que le VPN la capture.

Deux observations séparent les cas sans capture de paquets. D’abord, vérifiez si l’interface a une adresse routable et une route par défaut, ou seulement une adresse fe80:: de lien local ; lien local seul signifie qu’il n’y a pas de chemin vers internet. Ensuite, fermez le VPN et voyez si Xcode peut de nouveau atteindre l’appareil. S’il le peut, les routes ou le filtre de contenu du VPN capturent le trafic de lien local, et la correction appartient à la configuration du tunnel divisé ou du filtre, pas au panneau Réseau.

ifconfig | grep -A4 -E '^en[0-9]+:'
netstat -rn -f inet6 | head

Ne jugez pas au seul nom de l’interface. macOS crée et détruit ces interfaces au fil des branchements d’appareils, et le numéro en est attribué à l’exécution, donc le même Mac peut afficher un numéro différent après un redémarrage ou un changement de câble.

Étape 4 : Reproduisez la panne avec une seule variable à la fois

Une fois que vous savez quel service est en jeu, reproduisez le problème dans un ordre fixe. Commencez avec le téléphone débranché et le VPN connecté. Branchez le téléphone avec le point d’accès personnel désactivé, attendez que la liste Réseau se stabilise et relancez la requête de route. Débranchez, activez le point d’accès personnel, rebranchez et répétez. Notez l’interface, la passerelle et l’erreur du client pour chacun des trois états, et vous avez une comparaison au lieu d’un souvenir.

Si le VPN ne tombe que dans l’état point d’accès, gardez le téléphone hors de ce chemin : désactivez le point d’accès personnel pendant la charge, ou déplacez le service iPhone USB sous le Wi-Fi dans l’ordre des services. S’il tombe dans chaque état branché, y compris avec le point d’accès désactivé, regardez comment le client gère une transition réseau. Certains clients démontent le tunnel quand le service principal change et exigent une reconnexion ; c’est le comportement du client, pas un défaut du téléphone.

Changez une seule chose par essai. Supprimer le service, réinitialiser la configuration du VPN et réinstaller le client dans la même minute vous laisse un Mac qui fonctionne et aucune idée de l’action qui l’a réparé.

Étape 5 : Décidez ce que vous gardez et ce que vous vérifiez

Laissez la liaison d’appareil tranquille. Retirer une interface que Xcode utilise ne répare pas une route VPN, et cela casse le déploiement sur appareil jusqu’au prochain branchement. Si le service de point d’accès est vraiment indésirable, désactivez d’abord le point d’accès personnel sur le téléphone ; c’est le réglage documenté et il survit à un redémarrage.

Si vous retirez tout de même un service, retirez celui que vous avez identifié, puis vérifiez deux choses : la route vers le point de terminaison du VPN est revenue sur l’interface attendue, et le tunnel fait passer du trafic vers une adresse interne, pas seulement vers internet. Notez l’ordre des services et la version du client, car une mise à jour de macOS peut changer l’apparence du téléphone.

Classez ensuite la panne que vous avez réellement vue. Un délai de poignée de main, un blocage du MTU après la montée du tunnel et des réponses DNS venant de l’opérateur sont trois problèmes différents avec trois corrections différentes. Le service USB est le déclencheur dans les trois ; la cause, rarement.