sfondo
Nel nostro ambiente abbiamo uno script di accesso che viene eseguito per connettere gli utenti alle condivisioni di rete. Questo ha funzionato perfettamente fino a quando alcuni Mac non sono stati aggiornati a macOS Sierra, quando all'improvviso non siamo stati in grado di connetterci a una delle condivisioni SMB utilizzando l'indirizzo IP del server.
Esistono tre server Windows a cui i Mac devono connettersi al momento dell'accesso: 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 collega tramite 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. Alla fine i Mac completano lo script di accesso collegandosi correttamente alla condivisione AFP - 192.168.65.25.
Quello che ho fatto
Ho scoperto che non c'è nessun problema quando si tenta di connettersi al nome host del secondo server SMB - server2. L'uso 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.
Quindi ho rimosso il filtro e ho provato a connettermi di nuovo - Ho potuto vedere che c'erano pacchetti inviati all'indirizzo di rete 192.168.65.255 per risolvere l'indirizzo IP 192.168.65.30 a un nome host utilizzando il NetBIOS Name Service (NBNS) invece di trattarlo come indirizzo IP. Quando non è riuscito a risolvere l'IP in un altro IP, il processo di connessione non è riuscito.
TLDR
Sierra pensa che un indirizzo IP sia in realtà un nome host durante la connessione SMB e sta tentando di risolverlo in un indirizzo IP, che ovviamente non ha successo. Non tratta tutti gli indirizzi IP in questo modo come un altro IP sulla stessa sottorete si collega correttamente.
Ciò si verifica su tutti i Mac che vengono aggiornati a Sierra.
Così...
Perché macOS tratta questo indirizzo IP come un nome host? C'è un modo per forzarlo a trattarlo come un normale indirizzo IP?
Aggiornare
Ho notato che dopo un po '(forse 10 minuti?) Delle macchine accese e connesse, in realtà si collegherà correttamente 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 era connesso. Ad esempio, se mi connetto per smb://192.168.65.3/share_1
primo, quindi provo a connettermi smb://192.168.65.30/share_2
, i pacchetti dicono che in realtà tenta di connettersi a smb://192.168.65.3/share_2
, che non esiste, e quindi la connessione non viene stabilita.
In effetti, ho scoperto che ogni secondo tentativo di connessione SMB fallisce! Questo è riproducibile eseguendo l'aggiornamento a Sierra e quindi solo tentando di connettersi a due diverse condivisioni SMB.
Aggiornamento 3
La risoluzione dei nomi era un'aringa rossa: ora so che questo problema è legato 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 di condivisione specificato nella seconda connessione. Una soluzione alternativa sarebbe utilizzare il nome host, tuttavia ci sono problemi associati a questo quando ci connettiamo dall'esterno dell'ufficio tramite VPN.