Antecedentes
En nuestro entorno tenemos un login script que se ejecuta para conectar a los usuarios a los recursos compartidos de red. Esto funcionaba sin problemas hasta que algunos de los Macs se actualizaron a MacOS Sierra, cuando de repente no pudimos conectarnos a uno de los recursos compartidos SMB utilizando la dirección IP del servidor.
Hay tres servidores Windows a los que los Mac deben conectarse al iniciar la sesión: uno con la dirección IP 192.168.65.3, otro con la dirección IP 192.168.65.30 y el último con la dirección IP 192.168.65.25 (éste se conecta utilizando Acronis Access Connect y AFP).
El primer recurso compartido SMB de 192.168.65.3 se conecta con éxito sin problemas, pero al intentar conectarse al segundo recurso compartido SMB - 192.168.65.30 - el Mac no se conecta. Finalmente el Mac completa el login script conectándose con éxito al recurso compartido AFP - 192.168.65.25.
Lo que he hecho
He descubierto que no hay ningún problema al intentar conectarse al nombre de host del segundo servidor SMB - servidor2. Usando 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 con Wireshark: configuré el filtro como 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/hacia esa dirección IP.
Así que quité el filtro e intenté conectarme de nuevo - pude ver que se enviaban 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 utilizando el Servicio de Nombres NetBIOS (NBNS) en lugar de tratarla como una dirección IP. Al no poder 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 e intenta resolverla a una dirección IP, lo que obviamente no tiene éxito. No trata todas las direcciones IP de esta manera ya que otra IP en la misma subred se conecta con éxito.
Esto ocurre en todos los Macs que se actualizan a Sierra.
Así que...
¿Por qué MacOS trata esta dirección IP como un nombre de host? ¿Hay alguna manera de forzarla a tratarla como una dirección IP normal?
Actualización
Me he dado cuenta de que después de un tiempo (¿tal vez 10 minutos?) de que las máquinas estén encendidas y conectadas, realmente se conectará con éxito a la dirección IP que ha estado causando problemas.
Actualización 2
Así pues, me he dado cuenta de que puedo conectarme a la segunda dirección IP -192.168.65.30- si no estoy conectado a la primera dirección IP -192.168.65.3- y viceversa.
En la segunda conexión intenta conectarse al nombre compartido del primer servidor al que se conectó. Por ejemplo, si me conecto a smb://192.168.65.3/share_1 primero y luego intenta conectarse a smb://192.168.65.30/share_2 los paquetes dicen que realmente intenta conectarse a smb://192.168.65.3/share_2 que no existe, y por lo tanto la conexión no se establece.
De hecho, he comprobado que cualquier segundo intento de conexión SMB falla. Esto es reproducible actualizando a Sierra y luego simplemente intentando conectarse a dos recursos compartidos SMB diferentes.
Actualización 3
La resolución de nombres 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á utilizar la misma dirección IP que utilizó para la primera conexión, y el nombre de recurso compartido especificado en la segunda conexión. Una solución sería utilizar el nombre de host, sin embargo, hay problemas asociados con esto para nosotros cuando se conecta desde fuera de la oficina utilizando VPN.
