Background
En nuestro entorno, tenemos un script de inicio de sesión que se ejecuta para conectar a los usuarios a los recursos compartidos de la red. Esto funcionó a la perfección hasta que algunos de los Mac se actualizaron a macOS Sierra, cuando de repente no pudimos conectarnos a uno de los recursos compartidos de SMB utilizando la dirección IP del servidor.
Hay tres servidores Windows a los que los Mac deben conectarse al iniciar sesión: uno con la dirección IP 192.168.65.3, uno con la dirección IP 192.168.65.30 y el último con la dirección IP 192.168.65.25 (este se conecta mediante Acronis Access Connect y AFP).
El primer recurso compartido SMB de 192.168.65.3 se conecta correctamente sin problemas, luego, cuando se intenta conectarse al segundo recurso compartido SMB, 192.168.65.30, el Mac no se puede conectar. Finalmente, las Mac completan la secuencia de comandos de inicio de sesión al conectarse con éxito al recurso compartido de AFP: 192.168.65.25.
Lo que he hecho
Descubrí que no hay problemas al intentar conectar con el nombre de host del segundo servidor SMB: server2. El uso de la cadena de conexión smb://server2/share_name funciona perfectamente donde smb://192.168.65.30/share_name no funciona en absoluto.
A continuación, intenté capturar los paquetes usando Wireshark. Configuré el filtro en ip.src == 192.168.65.30 or ip.dst == 192.168.65.30 , pero cuando intenté conectarme al recurso compartido no se enviaron paquetes desde / a esa dirección IP.
Así que eliminé el filtro y traté de conectarme de nuevo. Pude ver que se estaban enviando paquetes a la dirección de red 192.168.65.255 para resolver la dirección IP 192.168.65.30 a un nombre de host usando NetBIOS Name Service (NBNS) de tratarlo como una dirección IP. Cuando no se pudo resolver la IP a otra IP, el proceso de conexión falló.
TLDR
Sierra piensa que una dirección IP es en realidad un nombre de host durante la conexión SMB y está intentando resolverla con una dirección IP, lo que obviamente no tiene éxito. No trata a todas las direcciones IP de esta manera, ya que otra IP en la misma subred se conecta correctamente.
Esto ocurre en todos los Mac que se actualizan a Sierra.
Entonces ...
¿Por qué macOS trata esta dirección IP como un nombre de host? ¿Hay alguna forma de forzarlo para que lo trate como una dirección IP normal?
Actualizar
He notado que después de un tiempo (¿quizás 10 minutos?) de las máquinas conectadas y conectadas, realmente se conectará con éxito a la dirección IP que ha estado causando problemas.
Actualización 2
Entonces, me he dado cuenta de que puedo conectarme a la segunda dirección IP, 192.168.65.30, si actualmente no estoy conectado a la primera dirección IP, 192.168.65.3, y viceversa.
En la segunda conexión, intenta conectarse al nombre del recurso compartido en el primer servidor al que se conectó. Por ejemplo, si primero me conecto a smb://192.168.65.3/share_1 y luego intento conectarme a smb://192.168.65.30/share_2 , los paquetes dicen que en realidad intenta conectarse a smb://192.168.65.3/share_2 , que no existe, y por lo tanto, la conexión no se puede establecer.
De hecho, he encontrado que cualquier segundo intento de conexión SMB falla. Esto se puede reproducir actualizando a Sierra y luego simplemente intentando conectarse a dos recursos compartidos SMB diferentes.
Actualización 3
La resolución del nombre era una pista falsa: ahora sé que este problema está relacionado con la apertura de una conexión a un segundo servidor SMB. Sierra intentará usar la misma dirección IP que usó para la primera conexión, y el nombre de recurso compartido especificado en la segunda conexión. Una solución alternativa sería utilizar el nombre de host, sin embargo, existen problemas asociados con esto cuando nos conectamos desde fuera de la oficina mediante VPN.