Lokale Samba-Freigabe verschwand, nachdem OpenVPN DNS übertragen hat
Ein übertragener Resolver antwortet auf Namen, die er nicht besitzt, und Samba glaubt ihm. Prüfen Sie Resolver, Suchreihenfolge und Suffix in dieser Reihenfolge.
Samba verliert lokale Freigaben in dem Moment, in dem sich OpenVPN verbindet, und der Tunnel ist fast nie die Ursache. Der Mount ist in Ordnung, das NAS läuft, und der vom Tunnel installierte Resolver beantwortet Fragen zu einem Namen, den er nie gesehen hat. Samba fragt diesen Resolver früh in seiner Suchreihenfolge, glaubt der Antwort und verbindet sich mit einer Adresse, an der nichts lauscht. Die Freigabe zu reparieren heißt, die Antwort zu reparieren, nicht den Mount.
Fünf Prüfungen, in der Reihenfolge, die pro Schritt die meisten Möglichkeiten ausschließt.
Wer antwortet für den Kurznamen
Fragen Sie das Betriebssystem, nicht den Dateimanager. resolvectl status zeigt die DNS-Server, die an jede Verbindung gebunden sind, und markiert, welche Verbindung die Standardroute ist, und eine Abfrage des Kurznamens meldet den Server, der geantwortet hat. Führen Sie es einmal für den NAS-Namen aus und einmal für einen Namen, von dem Sie wissen, dass er in der Bürodomäne existiert. Wenn die beiden Antworten von verschiedenen Servern kommen, haben Sie die Teilung gefunden.
Prüfen Sie, ob die Antwort eine negative Antwort oder eine Adresse war. Eine negative Antwort bedeutet, dass Samba zu einem anderen Mechanismus hätte übergehen müssen, und der Fehler liegt woanders. Eine Adresse bedeutet, dass Samba sich mit einem echten Ort verbunden hat und nichts zurückbekam.
Warum Samba einer falschen Antwort glaubt
Samba löst Namen über eine feste Reihenfolge auf, die durch name resolve order festgelegt wird. Auf den meisten Distributionen enthält der Standard host, was DNS bedeutet, und das läuft vor den Nur-LAN-Mechanismen wie NetBIOS-Broadcast. Ein Tunnel, der einen Resolver überträgt, bekommt daher die erste Ablehnung für jeden Freigabenamen, einschließlich einteiliger Namen, die das Gebäude nie verlassen sollten.
Normalerweise liefert ein unbekannter Name eine negative Antwort, und der nächste Mechanismus kommt an die Reihe. Manche Resolver, besonders die von Verbraucher-ISPs und öffentliche, antworten auf unbekannte Namen stattdessen mit einer Suchseite oder einer Werbeadresse. Diese Antwort sieht für die Resolver-Bibliothek wie Erfolg aus, also hört Samba auf zu suchen und wählt eine Adresse, die nichts mit Ihrem Netzwerk zu tun hat.
Das Ergebnis ist eine Freigabe, die ohne Fehlerdialog verschwindet. Nichts in dieser Reihenfolge ist ein VPN-Routingfehler, weshalb Ping auf das NAS noch funktioniert, während das Durchsuchen nicht funktioniert.
Zwei Reparaturen mit unterschiedlicher Reichweite
Die enge Reparatur behält den übertragenen Resolver und ändert, wonach Samba ihn fragen darf. Fügen Sie zwei Zeilen zur Samba-Konfiguration hinzu, die der Daemon tatsächlich liest, und starten Sie dann den Dienst neu:
[global]
name resolve order = wins lmhosts bcast
dns proxy = noOhne host in dieser Liste ist DNS aus dem Pfad für Freigabensuchen heraus, und einteilige Namen bleiben im lokalen Segment. Büronamen werden für jedes andere Programm weiterhin normal aufgelöst, weil dies nur Samba ändert. Der Preis ist, dass Samba DNS überhaupt nicht mehr nutzen kann, sodass eine Freigabe, die über einen vollqualifizierten Büronamen adressiert wird, zum Problem wird.
Die breite Reparatur beseitigt die Ursache: Hören Sie auf, einen Resolver zu übertragen, der Namen beantwortet, die er nicht besitzt, oder übertragen Sie eine Split-DNS-Richtlinie, sodass nur Büro-Suffixe den Büro-Resolver erreichen. Das ist die bessere langfristige Antwort in einem verwalteten Netzwerk, weil sie auch den Browser und den Paketmanager schützt, aber sie erfordert administrativen Zugriff auf der Serverseite und einen Client, der die übertragenen Einstellungen befolgt.
Wählen Sie bewusst eine. Eine Resolver-Änderung verändert die Namensauflösung für jede Anwendung auf einmal, was ein Änderungsdatensatz ist, keine Bearbeitung für einen Support-Anruf.
Das Suffix kann alles erklären
Wenn der Client auch ein Suchsuffix überträgt, wird ein kurzer lokaler Name in die Bürodomäne umgeschrieben, bevor er abgefragt wird. Dann lügt der Resolver überhaupt nicht: Er wurde fair nach einem Büronamen gefragt und gab eine korrekte Antwort. Lesen Sie den abgefragten Namen in der Ausgabe des Resolvers, um dies vom Fall der Werbeadresse zu unterscheiden, denn im Dateimanager sehen die beiden Fehler identisch aus.
Die Lösung ist hier entweder der vollqualifizierte lokale Name oder eine Split-DNS-Regel, die das lokale Suffix besitzt. Keines davon erfordert es, Samba anzufassen.
Beweisen Sie es nach einer Wiederverbindung
Testen Sie drei Namen in einer Sitzung: die lokale Freigabe per Kurznamen, einen Büro-Host per Namen und eine gewöhnliche Website. Wenn der erste funktioniert und der zweite bricht, hat die Reparatur den Fehler verschoben statt beseitigt. Wenn der dritte bricht, ist die Resolver-Änderung weiter gegangen als beabsichtigt, und jede Suche ist jetzt verdächtig.
Trennen Sie dann den Tunnel und verbinden Sie ihn erneut, und wiederholen Sie alle drei. Übertragene Optionen werden bei jeder Verbindung erneut angewendet, sodass eine Reparatur, die nur zur Laufzeit existierte, verschwinden kann, ohne dass sich eine Konfigurationsdatei ändert. Notieren Sie den Resolver, dem jedes Suffix gehört, und die geltende Suchreihenfolge, und notieren Sie das Datum, denn das nächste Client-Update ist der offensichtliche Verdächtige, wenn dies zurückkehrt.
Wenn die Freigabe nach allen fünf Prüfungen weiterhin fehlschlägt, erfassen Sie die genaue Abfrage und die genaue Antwort, bevor Sie etwas anderes ändern. Dieses Zeilenpaar unterscheidet einen Resolver-Fehler von einem Namen, der wirklich nicht existiert, und es ist die schnellste Übergabenotiz, die Sie schreiben können.