Contexte
Dans notre environnement, nous avons un login script qui s'exécute pour connecter les utilisateurs aux partages du réseau. Cela fonctionnait parfaitement jusqu'à ce que certains Macs soient mis à niveau vers MacOS Sierra, lorsque nous avons soudainement été incapables de nous connecter à l'un des partages SMB en utilisant l'adresse IP du serveur.
Il y a trois serveurs Windows auxquels les Macs doivent se connecter lors de la connexion - un avec l'adresse IP 192.168.65.3, un avec l'adresse IP 192.168.65.30, et le dernier avec l'adresse IP 192.168.65.25 (ce dernier se connecte en utilisant Acronis Access Connect et AFP).
Le premier partage SMB de 192.168.65.3 se connecte sans problème, puis, lorsqu'il tente de se connecter au second partage SMB - 192.168.65.30 - le Mac ne parvient pas à se connecter. Enfin, le Mac termine le script de connexion en se connectant avec succès au partage AFP - 192.168.65.25.
Ce que j'ai fait
J'ai découvert qu'il n'y a pas de problème lorsque l'on tente de se connecter au nom d'hôte du deuxième serveur SMB - server2. En utilisant la chaîne de connexion smb://server2/share_name fonctionne parfaitement là où smb://192.168.65.30/share_name ne fonctionne pas du tout.
J'ai ensuite essayé de capturer les paquets à l'aide de Wireshark - j'ai réglé le filtre sur ip.src == 192.168.65.30 or ip.dst == 192.168.65.30 mais lorsque j'ai tenté de me connecter au partage, aucun paquet n'a été envoyé depuis/vers cette adresse IP.
J'ai donc enlevé le filtre et essayé de me connecter à nouveau - j'ai pu voir que des paquets étaient envoyés à l'adresse réseau 192.168.65.255 pour résoudre l'adresse IP 192.168.65.30 en un nom d'hôte à l'aide du NetBIOS Name Service (NBNS) au lieu de la traiter comme une adresse IP. Lorsqu'il n'a pas réussi à résoudre l'IP en une autre IP, le processus de connexion a échoué.
TLDR
Sierra pense qu'une adresse IP est en fait un nom d'hôte pendant la connexion SMB et tente de la résoudre en adresse IP, ce qui ne réussit évidemment pas. Il ne traite pas toutes les adresses IP de cette manière, car une autre adresse IP sur le même sous-réseau se connecte avec succès.
Ce problème se produit sur tous les Macs mis à niveau vers Sierra.
Donc...
Pourquoi MacOS traite-t-il cette adresse IP comme un nom d'hôte ? Y a-t-il un moyen de la forcer à la traiter comme une adresse IP normale ?
Mise à jour
J'ai remarqué qu'après un certain temps (peut-être 10 minutes ?) pendant lequel les machines sont allumées et connectées, elles se connectent avec succès à l'adresse IP qui a causé des problèmes.
Mise à jour 2
J'ai donc remarqué que je pouvais me connecter à la deuxième adresse IP - 192.168.65.30 - si je n'étais pas connecté à la première adresse IP - 192.168.65.3 - et vice-versa.
Lors de la deuxième connexion, il tente de se connecter au nom de partage du premier serveur auquel il s'est connecté. Par exemple, si je me connecte à smb://192.168.65.3/share_1 puis tente de se connecter à smb://192.168.65.30/share_2 les paquets indiquent qu'il tente effectivement de se connecter à smb://192.168.65.3/share_2 qui n'existe pas, et donc la connexion n'est pas établie.
En fait, j'ai constaté que toute deuxième tentative de connexion SMB échoue ! Cela peut être reproduit en mettant à jour vers Sierra et en essayant de se connecter à deux partages SMB différents.
Mise à jour 3
La résolution du nom était une fausse piste - je sais maintenant que ce problème est lié à l'ouverture d'une connexion à un deuxième serveur SMB. Sierra tentera d'utiliser la même adresse IP que celle utilisée pour la première connexion, et le nom de partage spécifié dans la seconde connexion. Une solution de contournement consisterait à utiliser le nom d'hôte, mais cela pose des problèmes lorsque nous nous connectons depuis l'extérieur du bureau à l'aide d'un réseau privé virtuel (VPN).
