Sfondo
Nel nostro ambiente abbiamo uno script di accesso che viene eseguito per connettere gli utenti alle condivisioni di rete. Ciò ha funzionato perfettamente fino a quando alcuni Mac non sono stati aggiornati a macOS Sierra, quando improvvisamente non ci siamo potuti connettere a una delle condivisioni SMB usando l'indirizzo IP del server.
Ci sono tre server Windows a cui i Mac devono connettersi per accedere - uno con indirizzo IP 192.168.65.3, uno con indirizzo IP 192.168.65.30 e l'ultimo con indirizzo IP 192.168.65.25 (questo si connette usando Acronis Access Connect e AFP).
La prima condivisione SMB da 192.168.65.3 si collega correttamente senza problemi, quindi quando si tenta di connettersi alla seconda condivisione SMB - 192.168.65.30 - il Mac non riesce a connettersi. Finalmente i Mac completano lo script di login connettendosi con successo alla condivisione AFP - 192.168.65.25.
Cosa ho fatto
Ho scoperto che non vi è alcun problema quando si tenta di connettersi al nome host del secondo server SMB - server2. L'utilizzo della stringa di connessione smb://server2/share_name funziona perfettamente dove smb://192.168.65.30/share_name non funziona affatto.
Successivamente ho tentato di acquisire i pacchetti utilizzando Wireshark - ho impostato il filtro su ip.src == 192.168.65.30 or ip.dst == 192.168.65.30 ma quando ho tentato di connettermi alla condivisione non c'erano pacchetti inviati da / a quell'indirizzo IP.
Così ho rimosso il filtro e ho provato a connettermi di nuovo - ho visto che c'erano pacchetti inviati all'indirizzo di rete 192.168.65.255 per risolvere l'indirizzo IP 192.168.65.30 in un hostname usando il NetBIOS Name Service (NBNS) di trattarlo come un indirizzo IP. Quando non è riuscito a risolvere l'IP su un altro IP, il processo di connessione è fallito.
TLDR
Sierra ritiene che un indirizzo IP sia effettivamente un nome host durante la connessione SMB e stia tentando di risolverlo su un indirizzo IP, che ovviamente non ha successo. Non tratta tutti gli indirizzi IP in questo modo poiché un altro IP sulla stessa subnet si collega correttamente.
Ciò si verifica su tutti i Mac che vengono aggiornati a Sierra.
Quindi ...
Perché macOS considera questo indirizzo IP come un nome host? C'è un modo in cui posso forzarlo a considerarlo come un normale indirizzo IP?
Aggiorna
Ho notato che dopo un po '(forse 10 minuti?) delle macchine attive e connesse, si collegherà effettivamente all'indirizzo IP che ha causato problemi.
Aggiornamento 2
Quindi, ho notato che sono in grado di connettermi al secondo indirizzo IP - 192.168.65.30 - se attualmente non sono connesso al primo indirizzo IP - 192.168.65.3 - e viceversa.
Sulla seconda connessione tenta di connettersi al nome della condivisione sul primo server a cui è stata collegata. Ad esempio, se mi collego prima a smb://192.168.65.3/share_1 , allora provo a connetterti a smb://192.168.65.30/share_2 , i pacchetti dicono che effettivamente tenta di connettersi a smb://192.168.65.3/share_2 , che non esiste, e quindi la connessione non riesce a essere stabilita.
In effetti, ho trovato che ogni secondo tentativo di connessione SMB fallisce! Questo è riproducibile eseguendo l'aggiornamento a Sierra e quindi tentando solo di connettersi a due diverse condivisioni SMB.
Aggiornamento 3
La risoluzione del nome era un'aringa rossa: ora so che questo problema è correlato all'apertura di una connessione a un secondo server SMB. Sierra tenterà di utilizzare lo stesso indirizzo IP utilizzato per la prima connessione e il nome della condivisione specificato nella seconda connessione. Una soluzione alternativa sarebbe usare il nome host, tuttavia ci sono problemi associati a questo per noi quando ci si connette da fuori dall'ufficio usando VPN.