UNC-Zugriff in Windows-Containern: zuerst der Name, dann die Identität

Ein Windows-Container, der eine Freigabe auf der anderen Seite Ihres Tunnels benötigt, scheitert auf zwei voneinander unabhängige Arten, und der Explorer des Hosts beweist keine davon. Der Container hat einen eigenen Netzwerkendpunkt und eine eigene Prozessidentität. Ein Name, der auf dem Desktop aufgelöst wird, und eine Sitzung, die der Dateiserver dort annimmt, beschreiben den Desktop, nicht die Arbeitslast.

Der Explorer des Hosts ist kein Beweis

Beim Öffnen der Freigabe auf dem Host werden der DNS-Client des Hosts, die Routing-Tabelle des Hosts und das auf dem Host angemeldete Konto verwendet. Ein Containerprozess erbt nichts davon automatisch, selbst wenn der Container auf derselben Maschine läuft und der VPN-Client dort ebenfalls läuft. Die erste Grenze ist der Netzwerkpfad: Kann der Container den Namen auflösen, und kann er eine TCP-Sitzung zum SMB-Port öffnen. Die zweite ist die Identität: Nimmt der Dateiserver das an, was der Container vorweist, mit den Berechtigungen, die die Arbeitslast braucht.

Behandelt man beides als ein Problem, entsteht die vertraute Schleife, Firewallregeln zu erweitern, um das zu beheben, was tatsächlich eine Antwort über verweigerten Zugriff von der Freigabe ist.

Folgen Sie der Anfrage des Containers selbst

Die Netzwerkanbindung von Windows-Containern verwaltet der Host Networking Service, der Endpunkte mit eigenem Netzwerk-Namespace erzeugt. Der gewählte Modus entscheidet, ob der Endpunkt übersetzt, überbrückt oder an ein mit dem Host geteiltes Netzwerk angebunden wird. Diese Entscheidung ändert zwei Dinge zugleich: was der Container auflösen kann und welche Quelladresse der Dateiserver sieht.

Bestätigen Sie, was der Container selbst beobachtet, bevor Sie etwas ändern. Ein Name, der außerhalb aufgelöst wird, kann innen scheitern, weil die DNS-Konfiguration des Containers nicht die des Hosts ist, und ein übersetzter Endpunkt kann eine Quelle vorweisen, die die Regeln des Dateiservers nicht erwarten.

docker exec -it app powershell -Command "Resolve-DnsName files.corp.example"
docker exec -it app powershell -Command "Test-NetConnection files.corp.example -Port 445"
docker exec -it app powershell -Command "Get-NetIPConfiguration"

Wenn die Auflösung scheitert, korrigieren Sie DNS in der Netzwerkkonfiguration, statt eine Adresse zu ersetzen. Den Namen durch eine IP zu ersetzen kann das Verhalten von Authentifizierung und Serveridentität ändern, was aus einem Problem zwei macht. Die eigene Richtlinie des VPN-Clients ist das Nächste, was zu prüfen ist, denn sie kann Hostprozesse und vom Container ausgehenden Datenverkehr unterschiedlich behandeln.

Identität ist eine eigene Entscheidung

Ein von einem interaktiven Benutzer zugeordneter Laufwerksbuchstabe ist keine Anwendungsschnittstelle. Er existiert in einer Anmeldesitzung, und ein Containerprozess ist nicht Teil davon. Verwenden Sie den UNC-Pfad und geben Sie der Arbeitslast eine Identität, die das Bereitstellungsmodell unterstützt. Wo die Domäne es unterstützt, stellt ein gruppenverwaltetes Dienstkonto (gMSA) eine verwaltete Identität über eine Anmeldeinformationsspezifikation bereit.

Die gMSA-Anleitung für Container von Microsoft beschreibt diese Anordnung mit Anmeldeinformationsspezifikation und ihre Voraussetzungen, zu denen Domänenmitgliedschaft und ein Host gehören, der die Anmeldeinformationen abrufen kann. Konto, Abruf, Prozessidentität im Container und Freigabeberechtigungen müssen alle zusammenpassen. Eine VPN-Anmeldung ist diese Identität nicht, und ein Passwort in ein Image einzubacken, um die Sitzung des Hostbenutzers nachzubilden, erzeugt eine dauerhafte Angriffsfläche.

Halten Sie die fehlschlagende Stufe sichtbar

Eine fehlgeschlagene Auflösung, eine abgelehnte Verbindung und ein verweigerter Zugriff brauchen unterschiedliche Belege. Sie sind jeweils eine DNS-Frage, eine Routing- oder Filterfrage und eine Authentifizierungs- oder Berechtigungsfrage. Lesen Sie die Antwort, die der Container erhalten hat, statt der allgemeinen Fehlermeldung der Anwendung.

Testen Sie mit der eigenen Identität der Arbeitslast und testen Sie auch eine Verweigerung.

Planen Sie die Wiederverbindung ein

VPN-Pfade brechen ab. Wenn der Tunnel zurückkehrt, kann ein Endpunkt mit einer anderen übersetzten Adresse zurückkommen, und eine bestehende SMB-Sitzung kann tot sein, ohne dass die Anwendung es bemerkt. Behandeln Sie das in der Anwendung: Stellen Sie Pfad und Identität wieder her, wiederholen Sie den Vorgang und gleichen Sie einen Dateivorgang mit unbekanntem Ergebnis ab, statt anzunehmen, es sei nichts passiert.

Halten Sie Netzwerkmodus, DNS-Quelle und Identitätsanordnung in den Bereitstellungsnotizen fest. Genau diese drei Fakten werden Gegenstand des nächsten Fehlers sein.