Router als SMB-Client oder als Paketweiterleiter: Was passt
SMB-Verkehr weiterzuleiten und ihn einzubinden sind getrennte Rollen. Prüfen Sie Anmeldedaten, Kernel-Unterstützung und Fehlerbehandlung, bevor der Router zum Client wird.
SMB-Verkehr weiterzuleiten ist nicht dieselbe Aufgabe wie ihn zu beenden, und ein Router, der eines davon tut, beherrscht das andere vielleicht nicht. Weiterleiten heißt, der Router bewegt Pakete, deren Inhalt er nie auswertet. Einbinden heißt, der Router wird zum Dateiclient, mit Software, die er vielleicht nicht mitbringt, Anmeldedaten, die er schützen muss, und Fehlermodi, die er nun besitzt. Die Entscheidung zwischen beidem ist eine Frage, wo die Dateien gebraucht werden, nicht, wozu man die Routingplattform überreden kann, es zu installieren.
Weiterleiten und Beenden sind verschiedene Aufgaben
In der Weiterleitungsrolle hat der Router eine Verantwortung: Pakete zwischen Client und Server zuzustellen und dabei die Richtlinie anzuwenden, die der Pfad verlangt. Er authentifiziert sich nicht an der Freigabe, speichert keine Dateidaten zwischen und es ist ihm egal, ob der Server SMB2 oder SMB3 spricht, weil er nie so tief in den Strom liest. Wird die Freigabe unerreichbar, sieht der Nutzer einen Fehler, und der Router routet weiter.
In der Clientrolle tritt der Router in das Gespräch des Protokolls ein. Er handelt einen Dialekt aus, authentifiziert sich, löst Namen auf, hält einen Einhängepunkt und zeigt allem, was darüber läuft, eine lokale Dateisystemansicht. Das ist ein echter Dienst mit Lebenszyklus, und er macht das Gateway zu einer Abhängigkeit des Datei-Workflows. Er übernimmt auch jeden Fehlermodus dieser Abhängigkeit, einschließlich Wartezeiten beim Start und veralteter Anmeldedaten.
Der Vergleich dreht sich nicht nur um Fähigkeit. Eine Plattform, die eine Freigabe einbinden kann, ist nicht automatisch eine Plattform, die es tun sollte, und eine Plattform, die keine einbinden kann, kann trotzdem der richtige Ort sein, um den Verkehr zu routen.
Was ein CIFS-Mount im Kernel wirklich braucht
Auf einem Linux-basierten Gerät sind der CIFS-Client im Kernel und ein Client im Userspace getrennte Fähigkeiten, und kleine Images enthalten oft keine von beiden. Kernel-Unterstützung muss im laufenden Image vorhanden sein, der Einhängehelfer muss existieren, und der mit dem Server ausgehandelte SMB-Dialekt muss einer sein, den beide Seiten akzeptieren. Das beschreibt der Leitfaden zum Linux-CIFS-Client, der die Kernel-Einrichtung und ihre Einhängeoptionen erläutert, und das ist die richtige Referenz, bevor Sie annehmen, ein Herstellerbuild enthalte sie.
Prüfen Sie die Fähigkeit, bevor Sie darum herum planen, und prüfen Sie die Version statt der Anwesenheit eines Befehlsnamens. Ein Modulname in einer Paketliste ist nicht dasselbe wie ein funktionierender Client.
lsmod | grep -w cifs
modinfo cifs | head -5
mount.cifs --version
smbclient -L //fs02.corp.internal -U svc-router -m SMB3Ein Kernelmodul, das sich laden lässt, und ein Userspace-Werkzeug, das eine Version meldet, garantieren noch nicht, dass ein Mount einen VPN-Schlüsselwechsel übersteht, also behandeln Sie die Probe als Ausgangsbedingung, nicht als Beweis. Wenn das Image nur SMB1-Unterstützung mitbringt, ist das ein Grund aufzuhören, nicht ein Grund, es auf dem Server zu aktivieren.
Anmeldedaten und Quellidentität unterscheiden sich von denen eines Laptops
Eine weitergeleitete Anfrage trägt die Identität des Laptops durch den Tunnel, während eine auf dem Router erzeugte Anfrage dessen eigene Quelladresse, seinen Resolverpfad und seine Ausgangsfilterung trägt. Diese können in einer anderen Firewall-Regel, einer anderen DNS-Ansicht und einer anderen serverseitigen Positivliste landen. Eine Kopie, die von einer Workstation funktioniert, beweist daher nichts über den eigenen Mount des Routers. Testen Sie den Mount aus der Shell des Routers selbst, nicht von einer Workstation dahinter.
Geben Sie dem Router eine eng autorisierte Dienstidentität, wenn die Rolle überhaupt genehmigt wird. Setzen Sie niemals ein Passwort direkt in die Mount-Kommandozeile, denn es bleibt in der Shell-Historie und erscheint in der Prozesstabelle, solange der Mount läuft.
Speichern Sie die Anmeldedaten über den geschützten Mechanismus der Plattform und lesen Sie sie aus einer Datei mit restriktiven Rechten. Diese Datei sollte für jedes Konto außer dem, das den Mount ausführt, unlesbar sein.
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,roWem gehört der Fehler, wenn die Freigabe verschwindet
Ein fehlendes entferntes Dateisystem verhält sich anders als eine fehlende Route. Ein Mount kann Prozesse blockieren, die ihn berühren, er kann beim Start scheitern, bevor der Tunnel existiert, und ein Schreibvorgang, der für den Server gedacht war, kann am falschen Ort landen, wenn ein lokales Verzeichnis unter dem Einhängepunkt liegt. Das sind Speicherfehler, die nun dem Netzwerkteam gehören, ob es sie wollte oder nicht. Niemand hat dieser Zuständigkeit zugestimmt, aber sie kommt mit dem Mount.
Entwerfen Sie Startreihenfolge und Einhängeoptionen um diese Realität herum. Ein schreibgeschützter Mount mit kurzem Timeout und dokumentiertem Wiederherstellungsschritt ist leichter zu verteidigen als ein beschreibbarer Mount, von dem alles andere abhängt. Bestätigen Sie, dass der Tunnel steht, bevor irgendetwas einzuhängen versucht, sonst hängt der erste Start nach einem Stromausfall.
Für umfangreiche Dateiverarbeitung oder für alles, was die Daten weiter re-exportiert, gibt ein separater Host meist eine klarere Eigentumsgrenze. Der Router routet weiter, und der Datei-Workflow bekommt eine Maschine, die neu gestartet werden kann, ohne das Netzwerk mitzunehmen.
Prüfen Sie die Entscheidung an der tatsächlichen Aufgabe
Notieren Sie, welche Aufgabe die Dateien braucht und wo diese Aufgabe läuft. Wenn die Antwort eine Workstation ist, routen Sie die Freigabe und hören dort auf. Wenn die Antwort ein Dienst auf dem Gerät ist, bestätigen Sie Clientfähigkeit, unterstützten Dialekt und Anmeldedatenpfad vor dem ersten Mount und entscheiden Sie dann, ob das Gerät wirklich der richtige Host ist.
Prüfen Sie die eingebundene Ansicht und den freien Platz vom Router selbst aus, denn dort wird die Arbeitslast sie sehen. Wiederholen Sie die Prüfung nach einem Reconnect, nicht nur nach einem sauberen Start.
findmnt -t cifs -o TARGET,SOURCE,OPTIONS
df -h /mnt/reports
ls -l /mnt/reports | headEin Mount, der Dateien auflistet, aber ein volles oder schreibgeschütztes Dateisystem meldet, hat Ihnen schon gesagt, welchem Fehler Sie um 2 Uhr nachts begegnen. Bestätigen Sie auch den Wiederherstellungspfad: sauber aushängen, den Tunnel herunterfahren, wieder hochfahren und erneut einhängen, ohne das Gerät neu zu starten. Wenn diese Abfolge jedes Mal einen Supportfall braucht, ist der Router der falsche Ort für die Clientrolle.