Samba su un indirizzo VPN: perché l’ascoltatore scompare

La condivisione funziona tutta la mattina, il tunnel si riconnette a mezzogiorno e lo stesso percorso UNC ora va in timeout mentre il ping al server risponde ancora. Nulla è cambiato nella definizione della condivisione e la VPN è attiva. Ciò che è cambiato è l’indirizzo locale a cui Samba era legato, che non esiste più dopo la ricreazione dell’interfaccia. Quel modo di guasto è un problema del ciclo di vita dell’ascoltatore, non un problema di permessi.

La condivisione funziona finché il tunnel si riavvia

Legare un servizio a un indirizzo vincola il suo socket alla vita di quell’indirizzo. Quando l’interfaccia del tunnel viene distrutta e ricostruita, il vecchio indirizzo scompare e il socket legato ad esso se ne va con lui. Il servizio continua a funzionare, ma nulla ascolta dove vengono instradati i client.

Il ping può ancora riuscire se il nuovo indirizzo risponde a ICMP, ed è per questo che la raggiungibilità sembra a posto mentre la condivisione è morta. Proprio quel singolo successo ingannevole manda le persone verso il firewall.

La raggiungibilità non è un indirizzo di legame

Qui si mescolano tre decisioni. La rotta decide se arriva un pacchetto del client. Il socket in ascolto decide se qualcosa lo accetta all’indirizzo locale. La configurazione della condivisione e i permessi del file system decidono cosa succede dopo. Solo la seconda si rompe quando l’interfaccia viene ricreata.

Neanche un indirizzo del pool VPN è automaticamente un indirizzo di legame locale. Appartiene a un client, non al server di file. Il ping è un cattivo test per un servizio di file.

Tenete separati questi proprietari anche nella documentazione. Un cambiamento futuro al pool VPN non dovrebbe richiedere di modificare Samba, e un cambiamento dei permessi della condivisione non dovrebbe richiedere un riavvio del tunnel.

Legate invece a un indirizzo stabile

Il progetto più stabile tiene Samba su un indirizzo permanente e lascia che la VPN porti lì i client. L’indirizzo del server non cambia quando il tunnel oscilla, quindi l’ascoltatore non deve mai seguire un’interfaccia. L’ammissione è allora applicata dal percorso VPN e dal firewall dell’host, che sono fatti per quel compito.

Se dovete per forza legarvi al tunnel, capite il contratto della versione installata. I parametri interfaces e bind interfaces only non sono la stessa cosa, e la documentazione sul legame avverte sulle interfacce intermittenti. La gestione dinamica dell’ascoltatore esiste su alcune piattaforme, ma è una capacità da verificare, non da dare per scontata. Leggete la tabella prima e dopo un’oscillazione e confrontate i due output.

ss -ltnp | grep ':445'

Provate la riconnessione, non la luce verde

Verificate l’ascoltatore dopo una riconnessione, non solo dopo l’avvio del servizio. Ricreate il tunnel, poi leggete la tabella di ascolto e confermate che il socket esiste all’indirizzo su cui vengono instradati i client. Un indicatore di tunnel verde e un controllo di configurazione superato non dimostrano né l’uno né l’altro.

smbclient -L //files.corp.example -U alice

Poi eseguite un’operazione consentita e un percorso negato da un client, e ripetete dopo una seconda riconnessione. Se la condivisione funziona solo fino alla prima oscillazione, il legame è ancora vincolato alla vita dell’interfaccia e il progetto non è stato corretto. Cambiate il legame o l’indirizzo del servizio, e il sintomo smette di tornare.