Perché Samba rifiuta i client VPN che raggiungono il server

Un client VPN esegue il ping del file server, ne risolve il nome e comunque non riesce ad aprire una condivisione. La politica degli host di Samba è una delle quattro parti che possono rifiutare quella connessione, ed è quella che le persone modificano per ultima. L’elenco degli autorizzati viene valutato rispetto all’indirizzo di origine che smbd riceve davvero, che potrebbe non essere quello che il client crede di avere. Individuare correttamente quella origine trasforma un vago problema di permessi in una modifica di configurazione di una riga.

Quattro livelli che falliscono con lo stesso messaggio

Un rifiuto può arrivare dalla rotta, dal firewall dell’host, dalla politica degli host di Samba o dall’identità SMB. Ogni livello produce sul client un messaggio che dice più o meno la stessa cosa, per questo indovinare costa un pomeriggio. Ordinare i controlli dalla rete verso l’interno elimina la maggior parte delle congetture.

Partite dal trasporto. Se la porta 445 non raggiunge mai il server, nessuna impostazione di Samba conta, e una cattura sull’interfaccia del server lo risolve in pochi secondi. Poi viene il firewall dell’host sul server stesso, che può scartare un’origine consentita prima che smbd la veda. Solo dopo che questi due passano, l’elenco degli autorizzati diventa un candidato. L’autenticazione viene per ultima, perché un accesso fallito e un rifiuto dell’host appaiono diversi nel registro del server, anche quando il client li riporta entrambi come accesso negato. L’ordine conta più degli strumenti, perché ogni livello ha un comando che gli risponde.

Trovate l’indirizzo di origine che smbd vede davvero

Con accesso instradato il server di solito vede l’indirizzo del client dal pool VPN. Con la traduzione dell’origine sul gateway vede invece l’indirizzo LAN del gateway, e ogni client dietro quel gateway diventa indistinguibile.

Questa differenza decide se una voce dell’elenco degli autorizzati è una politica o un buco. Consentire un indirizzo di gateway tradotto ammette tutti quelli dietro, cosa che una regola per singolo client raramente voleva esprimere. Leggete l’origine dal server e non dall’idea che il client ha del proprio indirizzo. Una cattura sull’interfaccia del server è il modo più economico per vederla, e la stessa cattura dimostra se il pacchetto è arrivato. Limitate la cattura con un conteggio di pacchetti e aggiungete un filtro host quando sapete quale client state seguendo. La tabella delle sessioni di Samba è l’altra metà della risposta: in smbstatus -b la colonna client di ogni riga di sessione è il peer che smbd ha registrato, ed è la conferma più rapida dell’indirizzo che ha davvero raggiunto il servizio.

sudo tcpdump -ni any -c 20 'tcp port 445'
sudo smbstatus -b
ss -tnp | grep ':445'

Leggete l’elenco degli autorizzati come lo legge Samba

L’impostazione hosts allow accetta un elenco di indirizzi, reti o nomi, e può comparire a livello globale o dentro una condivisione. Due voci che a voi sembrano equivalenti potrebbero non esserlo per il parser, quindi la configurazione effettiva è ciò che va ispezionato. Questo significa la vista unita e non il file che avete modificato per caso.

Una coppia illustrativa di prefissi somiglia alla riga qui sotto, ed è un esempio e non una sostituzione delle voci già presenti. Conservate i client amministrativi e applicativi che oggi si collegano legittimamente, e leggete qualsiasi elenco di divieti nella stessa passata. Che un host sia ammesso dipende dalla politica nel suo insieme, quindi provate il client esatto invece di ragionare sulla precedenza. Il permesso dell’host non dice nulla nemmeno sui permessi di condivisione o sui modi del filesystem, che sono porte separate. Un successo degli strumenti di prova significa che la politica degli host ammette quell’origine, e niente di più.

hosts allow = 192.168.50.0/24 10.90.0.0/24
testparm -s
testparm -s /etc/samba/smb.conf client.example 10.90.0.14

Modificate il file che sopravvive a un riavvio

Su un normale host Linux il percorso di configurazione è fisso e il servizio lo rilegge al riavvio. Su un router o un apparato lo smb.conf in esecuzione viene spesso generato all’avvio, e una modifica manuale scompare al riavvio successivo. Usate il meccanismo di personalizzazione supportato dall’apparato, che di solito è un file di configurazione proprio.

La tentazione a questo punto è flashare un firmware alternativo perché un thread ha riferito che funzionava. È un cambiamento grande per un piccolo problema di politica, e porta il dispositivo fuori dal suo stato supportato. Individuate prima il controllo supportato, dato che la maggior parte degli apparati espone l’elenco degli autorizzati tramite la propria interfaccia. Se davvero non lo fanno, quel limite è un argomento per un altro hardware e non per una build non supportata.

Annotate quale file avete modificato e cosa lo rigenera, così la persona successiva non ripete la diagnosi.

Provate un client autorizzato e uno escluso

Provate entrambi gli esiti, non solo quello che volevate. Un client autorizzato che si collega dimostra che la modifica funziona; un client escluso che resta rifiutato dimostra che la regola non ha semplicemente aperto tutto.

smbclient -L //fileserver -U alice
sudo testparm -s /etc/samba/smb.conf alice-laptop 10.90.0.14
sudo tail -n 40 /var/log/samba/log.smbd

Quando la connessione non raggiunge mai smbd, la risposta è nell’instradamento o nel firewall del server. Se l’host è ammesso e l’accesso fallisce, il problema è l’identità e ampliare l’elenco degli autorizzati non aiuterà. Mantenete privato l’output di diagnostica, perché un registro Samba dettagliato può esporre percorsi di condivisione e nomi di account. Cambiate un livello per tentativo, altrimenti il risultato successivo non vi dirà nulla.