Il router come client SMB o come inoltratore di pacchetti: quale si adatta

Inoltrare il traffico SMB non è lo stesso compito che terminarlo, e un router che fa l’uno potrebbe non gestire l’altro. Inoltrare significa che il router sposta pacchetti di cui non analizza mai il contenuto. Montare significa che il router diventa un client di file, con software che forse non include, credenziali che deve proteggere e modalità di guasto che ora possiede. Scegliere tra i due è una questione di dove servono i file, non di cosa si può convincere la piattaforma di routing a installare.

Inoltrare e terminare sono compiti diversi

Nel ruolo di inoltro il router ha una responsabilità: consegnare i pacchetti tra il client e il server applicando la politica che il percorso richiede. Non si autentica sulla condivisione, non memorizza nella cache i dati dei file e non gli importa se il server parla SMB2 o SMB3, perché non legge mai così a fondo nel flusso. Se la condivisione diventa irraggiungibile, l’utente vede un errore e il router continua a instradare.

Nel ruolo di client il router entra nella conversazione del protocollo. Negozia un dialetto, si autentica, risolve i nomi, tiene un punto di mount e presenta una vista locale del file system a tutto ciò che vi gira sopra. È un servizio reale con un ciclo di vita, e trasforma il gateway in una dipendenza del flusso di lavoro dei file. Eredita anche ogni modalità di guasto di quella dipendenza, comprese le attese all’avvio e le credenziali scadute.

Il confronto non riguarda solo la capacità. Una piattaforma che può montare una condivisione non è automaticamente una piattaforma che dovrebbe farlo, e una piattaforma che non può montarne una può restare il posto giusto per instradare il traffico.

Che cosa richiede davvero un mount CIFS del kernel

Su un dispositivo basato su Linux il client CIFS del kernel e un client in spazio utente sono capacità separate, e le immagini piccole spesso non includono nessuna delle due. Il supporto del kernel deve essere presente nell’immagine in esecuzione, l’helper di mount deve esistere, e il dialetto SMB negoziato con il server deve essere uno che entrambe le parti accettano. Lo descrive la guida al client CIFS di Linux, che illustra la struttura del kernel e le sue opzioni di mount, ed è il riferimento giusto prima di dare per scontato che una build del fornitore la includa.

Verificate la capacità prima di progettare intorno a essa, e verificate la versione invece della presenza di un nome di comando. Un nome di modulo in un elenco di pacchetti non è la stessa cosa di un client funzionante.

lsmod | grep -w cifs
modinfo cifs | head -5
mount.cifs --version
smbclient -L //fs02.corp.internal -U svc-router -m SMB3

Un modulo del kernel che si carica e uno strumento in spazio utente che riporta una versione non garantiscono ancora che un mount sopravviva a un rinnovo delle chiavi VPN, quindi trattate il test come una condizione di partenza e non come una prova. Se l’immagine fornisce solo il supporto SMB1, è un motivo per fermarsi, non un motivo per abilitarlo sul server.

Le credenziali e l’identità di origine differiscono da quelle di un portatile

Una richiesta inoltrata porta l’identità del portatile attraverso il tunnel, mentre una richiesta generata sul router porta il proprio indirizzo di origine, il percorso del resolver e il filtraggio in uscita. Possono finire in una regola firewall diversa, una vista DNS diversa e una lista di autorizzati diversa sul lato server. Una copia che funziona da una postazione di lavoro non dimostra quindi nulla sul mount del router stesso. Provate il mount dalla shell del router stesso, non da una postazione di lavoro dietro di esso.

Date al router un’identità di servizio con autorizzazione ristretta se il ruolo è approvato. Non mettete mai una password direttamente nella riga di comando del mount, perché resta nella cronologia della shell e compare nella tabella dei processi mentre il mount è in esecuzione.

Archiviate la credenziale tramite il meccanismo protetto della piattaforma e leggetela da un file con permessi restrittivi. Quel file dovrebbe essere illeggibile per ogni account tranne quello che esegue il mount.

install -m 600 /dev/null /etc/cifs-reports.creds
printf 'username=svc-router\npassword=REPLACE_ME\ndomain=CORP\n' > /etc/cifs-reports.creds
mount -t cifs //fs02.corp.internal/reports /mnt/reports -o credentials=/etc/cifs-reports.creds,vers=3.1.1,ro

Di chi è il guasto quando la condivisione scompare

Un file system remoto assente si comporta diversamente da una rotta assente. Un mount può bloccare i processi che lo toccano, può fallire all’avvio prima che il tunnel esista, e una scrittura destinata al server può finire nel posto sbagliato se sotto il punto di mount c’è una directory locale. Sono guasti di archiviazione che ora appartengono al team di rete, che li volesse o no. Nessuno ha accettato quella proprietà, ma arriva con il mount.

Progettate l’ordine di avvio e le opzioni di mount intorno a questa realtà. Un mount in sola lettura con un timeout breve e un passo di ripristino documentato è più facile da difendere di un mount scrivibile da cui dipende tutto il resto. Confermate che il tunnel salga prima che qualcosa tenti di montare, altrimenti il primo avvio dopo un’interruzione di corrente si bloccherà.

Per un’elaborazione di file consistente, o per qualcosa che riesporta i dati più avanti, un host separato di solito offre un confine di proprietà più chiaro. Il router continua a instradare, e il flusso di lavoro dei file ottiene una macchina che può essere riavviata senza portarsi dietro la rete.

Verificate la decisione rispetto al compito reale

Annotate quale compito ha bisogno dei file e dove viene eseguito. Se la risposta è una postazione di lavoro, instradate la condivisione e fermatevi lì. Se la risposta è un servizio sul dispositivo, confermate la capacità del client, il dialetto supportato e il percorso delle credenziali prima del primo mount, poi decidete se il dispositivo è davvero l’host giusto.

Verificate la vista montata e lo spazio libero dal router stesso, perché è lì che il carico di lavoro li vedrà. Ripetete il controllo dopo una riconnessione, non solo dopo un avvio pulito.

findmnt -t cifs -o TARGET,SOURCE,OPTIONS
df -h /mnt/reports
ls -l /mnt/reports | head

Un mount che elenca file ma segnala un file system pieno o in sola lettura vi ha già detto quale guasto incontrerete alle 2 di notte. Confermate anche il percorso di ripristino: smontate in modo pulito, abbassate il tunnel, riportatelo su e montate di nuovo senza riavviare il dispositivo. Se quella sequenza richiede un caso di supporto ogni volta, il router è il posto sbagliato per il ruolo di client.