Le partage du Mac apparaît sur le VPN : l'arrêter ou le masquer ?

Les listes de navigation se construisent à partir d'annonces, et une annonce n'est pas une autorisation d'accès. Quelqu'un voit le nom de votre portable dans une liste distante parce qu'une requête multicast a franchi une limite qui l'arrête normalement au routeur. Ce franchissement explique à la fois pourquoi l'entrée apparaît et pourquoi la retirer n'est pas la même chose que fermer le service. Déterminez auquel des deux vous vous opposez réellement avant de changer quoi que ce soit.

Ce qu'est réellement l'entrée de navigation

Un répondeur mDNS sur le Mac répond aux requêtes concernant les types de service qu'il héberge, et la réponse porte un nom, un port et quelques enregistrements texte. Le client qui a demandé affiche ensuite ce nom dans une liste. Rien dans l'échange ne prouve qu'une connexion réussirait, et rien n'y accorde de permission : la liste est une affirmation sur un nom, pas sur l'accès. C'est cette distinction qui détermine s'il faut éteindre quelque chose ou cesser de le publier.

Différents services s'enregistrent séparément, donc la disparition d'une entrée ne signifie pas que toutes les annonces ont cessé. Le partage de fichiers enregistre un type, le partage d'écran un autre, et les imprimantes, les médiathèques et les outils de développement enregistrent chacun le leur. Avant de traiter un seul interrupteur comme le contrôle principal, listez ce qui est enregistré et quel processus le possède :

dns-sd -B _smb._tcp
lsof -nP -iUDP:5353

Le multicast reste local sauf si quelque chose le pont

Le DNS multicast envoie vers un groupe local au lien sur UDP 5353, et les routeurs ne transmettent pas ce groupe par défaut. Un tunnel qui route le trafic unicast laisse donc la découverte derrière lui, et c'est pourquoi un Mac sur un VPN routé est généralement invisible pour le site distant. Un tunnel ponté, ou un relais configuré exprès, change cela en plaçant les deux extrémités dans un même domaine de diffusion. Lequel des deux vous avez est une propriété du tunnel, pas du nom de protocole imprimé dessus.

Inspectez la configuration du serveur pour voir s'il ponte une interface ou route un sous-réseau, car les deux se comportent différemment pour chaque protocole dépendant de la diffusion. Si le tunnel est ponté, attendez-vous à ce que plus d'un type d'annonce fuite, y compris des choses que personne ne comptait publier. S'il est routé, une entrée dans une liste distante est probablement arrivée par un relais ou par une découverte fondée sur le DNS unicast plutôt que par le groupe multicast. Ces chemins ont des correctifs différents, et bloquer le port multicast n'en ferme qu'un.

Arrêter le service est la frontière la plus propre

Si le Mac n'a rien à faire en matière de fichiers, désactivez le partage via son contrôle pris en charge au lieu de chercher à masquer son annonce. On ne peut ni se connecter à un service arrêté, ni le deviner, ni l'atteindre avec un vieux client qui se souvenait du nom. Cette propriété en fait le contrôle le plus fort, et il ne demande aucune coopération du réseau.

Le guide du partage de fichiers d'Apple décrit le modèle d'autorisations pour les dossiers partagés, les utilisateurs autorisés et l'accès invité, et le panneau de partage montre l'état actuel. Passez ces trois points en revue lorsque le service est vraiment nécessaire, car un partage qui doit exister est un partage qu'il faut encadrer. L'accès invité mérite un examen propre, puisqu'il peut autoriser une connexion sans la moindre information d'identification. Vérifiez ensuite sur quelles interfaces le service écoute, car un partage offert sur toutes les interfaces est aussi offert sur le tunnel.

Quand vous avez besoin du service, mais pas du public

Parfois le partage est légitime et le public ne l'est pas. Restreindre le service à des sources approuvées, en laissant la découverte comme contrôle distinct et moindre, est l'arrangement honnête. Les règles de pare-feu, les autorisations par utilisateur et l'écoute sur la bonne interface resserrent l'accès d'une manière qu'une annonce cachée ne peut pas.

Supprimer la découverte est cosmétique au sens strict : le service répond toujours à quiconque connaît le nom. Si la publication elle-même est le problème, limitez-la dans la couche qui la transporte. Sur un réseau que vous administrez, cela signifie décider quels types de service doivent franchir la frontière et configurer le pont, le relais ou le filtre en conséquence. Copier une commande de filtre de pont depuis un forum ne fonctionne que si votre serveur exécute exactement cette pile et ce mode de tunnel, et sur un réseau que vous n'administrez pas, la réponse honnête est que vous ne pouvez pas contrôler ce dont un client distant se souvient.

Regardez depuis le côté distant

Testez depuis le côté distant plutôt que depuis le réseau propre du Mac, et testez une navigation fraîche plutôt qu'une liste en cache. Tentez ensuite une connexion directe au service par nom et par adresse, car les deux résultats répondent à des questions différentes. Une entrée absente avec une connexion réussie signifie que vous avez masqué une étiquette, tandis qu'une connexion échouée signifie que vous avez fermé un service. Le cache fait mentir les deux tests si vous sautez l'actualisation, alors relancez le client.

Notez ce que vous avez changé et auquel des trois contrôles cela appartient : service arrêté, accès restreint ou découverte limitée. Quand quelqu'un signale que le Mac apparaît encore, cette note vous dit si le signalement est périmé ou si un autre service s'annonce. La plupart des surprises ici sont un second enregistrement que personne ne se rappelait avoir activé, pas un contrôle cassé.

Revérifiez les enregistrements restants avant de conclure que le changement a échoué. Une courte liste d'inventaire vaut mieux qu'une nouvelle série de suppositions.