La condivisione Samba locale è sparita dopo che OpenVPN ha imposto DNS

Samba perde le condivisioni locali nel momento in cui OpenVPN si connette, e il tunnel non è quasi mai la causa. Il montaggio è a posto, il NAS è acceso, e il resolver installato dal tunnel risponde a domande su un nome che non ha mai visto. Samba interroga quel resolver presto nel suo ordine di ricerca, crede alla risposta e si connette a un indirizzo dove nulla è in ascolto. Riparare la condivisione significa riparare la risposta, non il montaggio.

Cinque controlli, nell’ordine che elimina più possibilità a ogni passo.

Chi risponde per il nome corto

Chiedete al sistema operativo, non al gestore di file. resolvectl status mostra i server DNS associati a ogni collegamento e indica quale è la rotta predefinita, e una query sul nome corto riporta il server che ha risposto. Eseguitelo una volta per il nome del NAS e una volta per un nome che sapete esistere nel dominio dell’ufficio. Se le due risposte provengono da server diversi, avete trovato la divisione.

Controllate se la risposta era una risposta negativa o un indirizzo. Una risposta negativa significa che Samba avrebbe dovuto passare a un altro meccanismo, e il guasto è altrove. Un indirizzo significa che Samba si è connessa a un luogo reale e non ha ottenuto nulla.

Perché Samba crede a una risposta sbagliata

Samba risolve i nomi tramite una sequenza fissa impostata da name resolve order. Sulla maggior parte delle distribuzioni il valore predefinito include host, cioè DNS, e viene eseguito prima dei meccanismi riservati alla rete locale come la diffusione NetBIOS. Un tunnel che impone un resolver ottiene quindi il primo rifiuto su ogni nome di condivisione, compresi i nomi a etichetta singola che non avrebbero mai dovuto lasciare l’edificio.

Di norma un nome sconosciuto restituisce una risposta negativa e il meccanismo successivo riceve il suo turno. Alcuni resolver, soprattutto quelli dei fornitori di accesso al consumo e quelli pubblici, rispondono ai nomi sconosciuti con una pagina di ricerca o un indirizzo pubblicitario. Quella risposta sembra un successo alla libreria del resolver, quindi Samba smette di cercare e compone un indirizzo che non ha nulla a che fare con la vostra rete.

Il risultato è una condivisione che scompare senza una finestra di errore. Nulla in quella sequenza è un guasto di instradamento VPN, ed è per questo che il ping verso il NAS funziona ancora mentre la navigazione verso di esso non funziona.

Due riparazioni di portata diversa

La riparazione stretta mantiene il resolver imposto e cambia ciò che Samba può chiedergli. Aggiungete due righe alla configurazione Samba che il demone legge davvero, poi riavviate il servizio:

[global]
   name resolve order = wins lmhosts bcast
   dns proxy = no

Senza host in quell’elenco DNS esce dal percorso per le ricerche delle condivisioni, e i nomi a etichetta singola restano sul segmento locale. I nomi dell’ufficio si risolvono ancora normalmente per ogni altro programma, perché questo cambia solo Samba. Il costo è che Samba non può più usare affatto DNS, quindi una condivisione indirizzata con un nome ufficio pienamente qualificato diventa un problema.

La riparazione ampia elimina la causa: smettete di imporre un resolver che risponde a nomi che non possiede, oppure imponete una politica di DNS diviso in modo che solo i suffissi dell’ufficio raggiungano il resolver dell’ufficio. È la risposta migliore a lungo termine su una rete gestita perché protegge anche il browser e il gestore di pacchetti, ma richiede accesso amministrativo sul lato server e un client che obbedisca alle impostazioni imposte.

Sceglietene una deliberatamente. Un cambio di resolver altera la risoluzione dei nomi per ogni applicazione in una volta, il che è un record di modifica, non una modifica per una chiamata al supporto.

Il suffisso può spiegare tutto

Se il client impone anche un suffisso di ricerca, un nome locale corto viene riscritto nel dominio dell’ufficio prima di essere interrogato. Allora il resolver non mente affatto: gli è stata posta una domanda giusta su un nome dell’ufficio e ha dato una risposta corretta. Leggete il nome interrogato nell’output del resolver per distinguere questo caso da quello dell’indirizzo pubblicitario, perché i due guasti sembrano identici nel gestore di file.

La soluzione qui è usare il nome locale pienamente qualificato oppure aggiungere una regola di DNS diviso che possieda il suffisso locale. Nessuna delle due richiede di toccare Samba.

Dimostratelo dopo una riconnessione

Provate tre nomi in una sessione: la condivisione locale per nome corto, un host dell’ufficio per nome e un sito web ordinario. Se il primo funziona e il secondo si rompe, la riparazione ha spostato il guasto invece di eliminarlo. Se si rompe il terzo, il cambio di resolver è andato oltre il previsto e ogni ricerca è ora sospetta.

Poi disconnettete e riconnettete il tunnel e ripetete tutti e tre. Le opzioni imposte vengono riapplicate a ogni connessione, quindi una riparazione che esisteva solo a runtime può sparire senza che cambi alcun file di configurazione. Annotate il resolver che possiede ogni suffisso e l’ordine di ricerca in vigore, e segnate la data, perché il prossimo aggiornamento del client è il sospetto ovvio quando questo torna.

Se la condivisione fallisce ancora dopo tutti e cinque i controlli, catturate la query esatta e la risposta esatta prima di cambiare qualsiasi altra cosa. Quella coppia di righe distingue un guasto del resolver da un nome che davvero non esiste, ed è la nota di passaggio più rapida che possiate scrivere.