Le routeur comme client SMB ou comme relais de paquets : ce qui convient

Transmettre le trafic SMB n’est pas le même travail que le terminer, et un routeur qui fait l’un ne maîtrise peut-être pas l’autre. Relayer signifie que le routeur déplace des paquets dont il n’analyse jamais le contenu. Monter signifie que le routeur devient un client de fichiers, avec des logiciels qu’il n’embarque peut-être pas, des identifiants qu’il doit protéger et des modes de panne qu’il possède désormais. Choisir entre les deux est une question de savoir où les fichiers sont nécessaires, non de ce qu’on peut convaincre la plateforme de routage d’installer.

Relayer et terminer sont deux tâches différentes

Dans le rôle de relais, le routeur a une responsabilité : livrer les paquets entre le client et le serveur en appliquant la politique qu’exige le chemin. Il ne s’authentifie pas auprès du partage, ne met pas en cache les données de fichiers et ne se soucie pas de savoir si le serveur parle SMB2 ou SMB3, car il ne lit jamais aussi loin dans le flux. Si le partage devient inaccessible, l’utilisateur voit une erreur et le routeur continue de router.

Dans le rôle de client, le routeur rejoint la conversation du protocole. Il négocie un dialecte, s’authentifie, résout les noms, tient un point de montage et présente une vue locale du système de fichiers à tout ce qui s’exécute au-dessus. C’est un vrai service avec un cycle de vie, et il fait de la passerelle une dépendance du flux de travail des fichiers. Il hérite aussi de tous les modes de panne de cette dépendance, y compris les attentes au démarrage et les identifiants périmés.

La comparaison ne porte pas uniquement sur la capacité. Une plateforme qui peut monter un partage n’est pas automatiquement une plateforme qui devrait le faire, et une plateforme qui ne peut pas en monter un peut rester le bon endroit pour router le trafic.

Ce qu’un montage CIFS du noyau exige vraiment

Sur un appareil sous Linux, le client CIFS du noyau et un client en espace utilisateur sont deux capacités distinctes, et les petites images n’en contiennent souvent aucune. La prise en charge du noyau doit être présente dans l’image en cours d’exécution, l’assistant de montage doit exister, et le dialecte SMB négocié avec le serveur doit être accepté des deux côtés. Le décrit le guide du client CIFS de Linux, qui présente l’organisation du noyau et ses options de montage, et c’est la bonne référence avant de supposer qu’une compilation de constructeur l’inclut.

Vérifiez la capacité avant de concevoir autour d’elle, et vérifiez la version plutôt que la présence d’un nom de commande. Un nom de module dans une liste de paquets n’est pas la même chose qu’un client qui fonctionne.

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

Un module du noyau qui se charge et un outil en espace utilisateur qui annonce une version ne garantissent pas encore qu’un montage survive à un renouvellement de clés VPN, alors traitez le test comme une condition de départ et non comme une preuve. Si l’image ne fournit que la prise en charge de SMB1, c’est une raison de s’arrêter, pas une raison de l’activer sur le serveur.

Les identifiants et l’identité source diffèrent de ceux d’un ordinateur portable

Une requête relayée porte l’identité de l’ordinateur portable à travers le tunnel, tandis qu’une requête générée sur le routeur porte sa propre adresse source, le chemin du résolveur et le filtrage de sortie. Elles peuvent atterrir dans une autre règle de pare-feu, une autre vue DNS et une autre liste d’autorisations côté serveur. Une copie qui fonctionne depuis un poste de travail ne prouve donc rien sur le montage propre au routeur. Testez le montage depuis le shell du routeur lui-même, pas depuis un poste de travail situé derrière.

Donnez au routeur une identité de service étroitement autorisée si le rôle est approuvé. Ne placez jamais un mot de passe directement dans la ligne de commande de montage, car il reste dans l’historique du shell et apparaît dans la table des processus pendant l’exécution du montage.

Stockez l’identifiant via le mécanisme protégé de la plateforme et lisez-le dans un fichier aux permissions restrictives. Ce fichier devrait être illisible pour tout compte sauf celui qui exécute le montage.

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

Qui possède la panne lorsque le partage disparaît

Un système de fichiers distant absent se comporte différemment d’une route absente. Un montage peut bloquer les processus qui le touchent, il peut échouer au démarrage avant que le tunnel existe, et une écriture destinée au serveur peut atterrir au mauvais endroit si un répertoire local se trouve sous le point de montage. Ce sont des pannes de stockage dont l’équipe réseau est désormais propriétaire, qu’elle les ait voulues ou non. Personne n’a accepté cette propriété, mais elle arrive avec le montage.

Concevez l’ordre de démarrage et les options de montage autour de cette réalité. Un montage en lecture seule avec un délai court et une étape de reprise documentée se défend plus facilement qu’un montage inscriptible dont tout le reste dépend. Confirmez que le tunnel monte avant que quoi que ce soit tente de monter, sinon le premier démarrage après une coupure de courant se bloquera.

Pour un traitement de fichiers conséquent, ou pour tout ce qui réexporte les données plus loin, un hôte séparé donne généralement une frontière de propriété plus claire. Le routeur continue de router, et le flux de travail des fichiers obtient une machine qui peut être redémarrée sans emporter le réseau.

Vérifiez la décision face à la tâche réelle

Notez quelle tâche a besoin des fichiers et où cette tâche s’exécute. Si la réponse est un poste de travail, routez le partage et arrêtez-vous là. Si la réponse est un service sur l’appareil, confirmez la capacité du client, le dialecte pris en charge et le chemin des identifiants avant le premier montage, puis décidez si l’appareil est vraiment l’hôte approprié.

Vérifiez la vue montée et l’espace libre depuis le routeur lui-même, car c’est là que la charge de travail les verra. Répétez le contrôle après une reconnexion, pas seulement après un démarrage propre.

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

Un montage qui liste des fichiers mais signale un système de fichiers plein ou en lecture seule vous a déjà dit quelle panne vous rencontrerez à 2 heures du matin. Confirmez aussi le chemin de reprise : démontez proprement, coupez le tunnel, remontez-le et montez de nouveau sans redémarrer l’appareil. Si cette séquence exige un dossier de support à chaque fois, le routeur est le mauvais endroit pour le rôle de client.