AirDrop absent avec un VPN actif ? Vérifiez le routage local

AirDrop fonctionne, puis le VPN se connecte et l’autre Mac ou l’iPhone disparaît de la feuille de partage. Rien dans le journal du VPN ne parle de découverte, car la panne concerne généralement la joignabilité locale et non la cryptographie. La page d’assistance d’Apple reconnaît qu’une configuration VPN qui restreint le réseau local peut gêner Continuity et AirDrop ; c’est un indice utile, pas un diagnostic. Commencez par les vérifications peu coûteuses, lisez ensuite la table de routage, et traitez le commutateur d’accès local comme une décision sur votre vie privée plutôt que comme un réglage par défaut à basculer.

Ce qui casse avant même que le tunnel intervienne

Les deux appareils doivent avoir le Wi-Fi ou le Bluetooth activé, AirDrop doit recevoir des contacts ou de tous dans sa fenêtre de réception, et les deux comptes doivent être détectables l’un par l’autre. Mettre le récepteur sur tous pendant dix minutes est une expérience légitime : si l’autre appareil apparaît, le problème venait des réglages et le tunnel est innocent. Testez avec un destinataire connu au lieu de juger d’après ce que propose la feuille de partage.

Un navigateur qui charge des pages prouve que la voie internet fonctionne, pas que la découverte locale fonctionne. Laissez les deux appareils et l’endroit où vous vous tenez inchangés, puis activez et désactivez le VPN et notez si l’autre appareil ne disparaît que lorsque le tunnel est monté. Si la découverte meurt avec le tunnel et revient sans lui, le tunnel est la variable et le reste de cette liste s’applique. Si elle échoue dans les deux états, les prérequis ont besoin d’un autre passage avant de changer la moindre politique réseau.

La feuille de partage se vide quand la route par défaut bouge

Un client en tunnel complet installe généralement une route par défaut via le tunnel plus deux demi-routes qui capturent la plupart des destinations. Un sous-réseau local ne survit à cette disposition que s’il a une route plus spécifique ; sinon il disparaît dans le tunnel. AirDrop lui-même passe par l’interface pair à pair AWDL, donc un client qui filtre ou route agressivement les interfaces locales peut gêner alors que la voie internet reste parfaite. Quatre commandes couvrent l’interface, les routes, la connexion active et le filtre de paquets.

ifconfig awdl0 | grep -E "status|inet"
netstat -rn | grep -E '^default|^0/1|^128.0/1|awdl'
scutil --nc list
sudo pfctl -s rules | head -40

Lisez d’abord la ligne par défaut : si elle pointe vers une interface utun et qu’aucune route plus spécifique ne couvre votre sous-réseau, le trafic local entre dans le tunnel et la conscience disparaît avec lui. La paire 0/1 et 128.0/1 est une forme courante de tunnel complet, car ces routes battent la vraie route par défaut sans la remplacer. Une ligne awdl0 avec un statut actif et une adresse exclut que l’interface pair à pair soit tombée. Quand les trois semblent normales, la restriction vient de la politique du client ou d’un filtre sur l’hôte, pas de la table de routage.

Une forme mérite d’être signalée, car elle piège les gens sur les réseaux invités, et ce ne sont pas les demi-routes. DHCP installe l’adresse que vous venez de recevoir comme route sur le lien, et cette entrée est plus spécifique que l’une ou l’autre moitié, donc un sous-réseau invité survit au tunnel exactement comme un sous-réseau domestique. Ce qui la retire, c’est la politique et non le routage : une préférence qui bloque le réseau local et installe une règle de rejet, un filtre sur l’hôte qui jette le sous-réseau, ou l’autorisation de réseau local de macOS pour le client. Une table d’apparence normale avec une feuille de partage morte est donc la signature de la section suivante, pas celle de la forme des routes.

Un Mac géré peut ne pas offrir le commutateur d’accès local

Beaucoup de clients exposent une préférence pour autoriser l’accès au réseau local tant que le tunnel est monté, mais cette préférence est appliquée par le client et par le profil de gestion, elle peut donc être verrouillée, masquée ou contournée sur un Mac géré. Une règle de filtre sur l’hôte ou un agent de sécurité peut bloquer le trafic pair à pair indépendamment de ce que propose le client VPN. Cherchez le commutateur avant de conclure qu’il ne fait rien. Ce commutateur vit dans les préférences du client lui-même et non dans les réglages réseau de macOS, ce qui explique qu’un client dont le panneau ne l’affiche pas soit généralement régi par un profil de gestion.

Retirer la gestion ou désactiver chaque filtre pour qu’un destinataire apparaisse échange une configuration maîtrisée contre une configuration inconnue. N’activez l’option d’accès local que lorsqu’elle correspond à la politique sous laquelle vous travaillez, et laissez-la désactivée sur un réseau invité où la découverte locale n’a jamais été souhaitée.

Prouvez-le avec un fichier, pas avec une icône

Après avoir changé le routage ou la politique, envoyez un vrai fichier au destinataire prévu et confirmez que le transfert aboutit. Un nom qui apparaît dans la feuille est une découverte, et le retour de la découverte n’équivaut pas à un transfert terminé.

Si l’appareil n’apparaît toujours pas, comparez une seconde paire d’appareils sur le même réseau pour séparer un problème d’hôte d’un problème à l’échelle du réseau. Cette comparaison est plus rapide que de basculer les options VPN une à une et elle produit un fait pour le ticket. Notez l’interface par défaut, la forme des routes et l’état du commutateur d’accès local tant que la panne est reproductible. Sinon la personne suivante refera les quatre vérifications depuis le début.