LocalSubnet in einer SMB-Firewallregel deckt keine VPN-Clients ab

Office-Desktops erreichen die Freigabe, VPN-Nutzer laufen in einen Timeout, und dasselbe Konto funktioniert von einem Handy-Hotspot. Die Freigabeberechtigungen sind selten der Unterschied; die Adresse, die am Dateiserver ankommt, ist es meistens. Eine Regel, die auf LocalSubnet beschränkt ist, lässt die eigenen angeschlossenen Subnetze des Servers zu, und ein separat gerouteter VPN-Pool gehört nicht dazu. Zwei Designs schließen die Lücke, und sie hinterlassen sehr unterschiedliche Aufzeichnungen.

Zwei Designs, ein Symptom

Das erste Design fügt den VPN-Pool der Bedingung für die Remote-Adresse der Regel hinzu. Der Server sieht dann die Tunneladresse jedes Clients, sodass seine Protokolle einen entfernten Benutzer von einem anderen unterscheiden können. Das zweite Design leitet VPN-Verkehr über ein Gateway, das ihn in eine LAN-Adresse übersetzt, bevor der Server ihn sieht. Das stellt die Verbindung wieder her und beseitigt die Unterscheidung im selben Schritt.

Die Tabelle beschreibt Rollen statt Adressen, und Ihre eigenen Präfixe entscheiden, welche Zeile gilt. Drucken Sie die tatsächlichen Werte des Servers aus, statt ein Beispiel aus einem Blogbeitrag zu kopieren:

Get-NetIPAddress -AddressFamily IPv4 | Select-Object InterfaceAlias, IPAddress, PrefixLength

Die Tabelle ist eine Entscheidungshilfe, keine Aussage über jede Bereitstellung. Ein Host mit zusätzlichen Schnittstellen, einer zweiten Standortverbindung oder einer anderen Maske hat einen anderen lokalen Satz.

Die Referenz zu New-NetFirewallRule von Microsoft dokumentiert die Bedingungen für die Remote-Adresse und das Schlüsselwort LocalSubnet. Lesen Sie sie, bevor Sie entscheiden, dass das Schlüsselwort alle privaten Adressen bedeutet, denn das tut es nicht.

Vergleichen Sie, was der Server tatsächlich empfängt

Lesen Sie die effektive Regel statt der, von der jemand glaubt, sie erstellt zu haben. Prüfen Sie, ob sie aktiviert ist, ob sie für das aktive Profil gilt und ob ihre Bedingung für die Remote-Adresse zur Quelle passt, die der Server sieht. Eine nur im Domänenprofil aktivierte Regel bewirkt nichts, wenn der Adapter nach einer Netzwerkänderung in das öffentliche Profil gerutscht ist.

Get-NetFirewallRule -DisplayGroup 'File and Printer Sharing' | Get-NetFirewallAddressFilter
Get-NetFirewallProfile | Select-Object Name,Enabled,DefaultInboundAction

Der erste Befehl gibt die Adressfilter aus, die an den Dateifreigaberegeln hängen, und der zweite zeigt, welche Profile aktiv sind und wie nicht passender eingehender Verkehr behandelt wird. Suchen Sie auch nach einer Blockierregel und nach zentral verwalteter Richtlinie. Blockierregeln haben Vorrang vor Zulassungsregeln, und eine Richtlinie, die das Zusammenführen lokaler Regeln deaktiviert, kann eine neue lokale Ausnahme wirkungslos machen.

Das ist der Fall, in dem die Regel in der Konsole korrekt aussieht und keine Wirkung auf den Verkehr hat. Prüfen Sie gleichzeitig die Profilzuordnung, denn ein Laptop, der einem anderen Netzwerk beigetreten ist, kann in das öffentliche Profil wechseln, ohne dass jemand die Firewall anfasst.

Testen Sie den Transport vor der Anmeldung

Trennen Sie Erreichbarkeit von Authentifizierung. Ein Listener auf TCP 445 beweist, dass ein Dienst an den Port gebunden ist; er beweist nicht, dass ein entferntes Paket ihn erreichen kann. Eine abgeschlossene TCP-Verbindung wiederum sagt noch nichts über den Aufbau einer SMB-Sitzung oder über Freigabeberechtigungen aus. Testen Sie den Handshake von beiden Seiten, bevor Sie eine Regel bearbeiten.

Test-NetConnection -ComputerName files.corp.example -Port 445
Test-NetConnection -ComputerName files.corp.example -Port 445 -InformationLevel Detailed

Der erste Befehl meldet, ob ein TCP-Handshake von dem Rechner aus gelingt, auf dem Sie ihn ausführen, und der zweite ergänzt die aufgelöste Adresse und Schnittstellendetails. Führen Sie ihn vom VPN-Client und von einem Office-Desktop aus und vergleichen Sie dann. Ping beantwortet keine der beiden Fragen, denn ICMP kann blockiert sein, während SMB offen ist, oder erlaubt sein, während die Firewall 445 verwirft.

Wenn der Handshake nur über das VPN fehlschlägt, ist der Quellbereich der Hauptverdächtige. Wenn er gelingt und die Freigabe Sie weiterhin abweist, gehen Sie zur Diagnose von SMB-Sitzung und Berechtigungen über, statt Firewallregeln zu bearbeiten.

Wenn Quell-NAT die Unterscheidung entfernt

Mit Übersetzung im Pfad kann der Server einzelne VPN-Clients nicht anhand der Adresse unterscheiden. Jeder entfernte Benutzer kommt als das Gateway an. Jede Autorisierung, die von ihrer Unterscheidung abhängt, muss dort durchgesetzt werden, wo ihre Identitäten noch sichtbar sind, was meist den VPN-Konzentrator oder einen authentifizierenden Proxy bedeutet. Die Firewallregel kann Verkehr zulassen; sie kann eine Unterscheidung nicht wiederherstellen, die die Übersetzung beseitigt hat.

Sobald diese Gateway-Adresse zugelassen ist, wird jeder entfernte Benutzer unter einer einzigen Adresse erfasst, sodass die Regel den gesamten Pool jedem gewährt, der das Gateway erreichen kann. Wenn eine Entscheidung pro Benutzer zählt, halten Sie die ursprünglichen Adressen sichtbar oder verlagern Sie die Entscheidung auf eine Ebene, die den Benutzer noch kennt. Andernfalls erbt jeder entfernte Benutzer die Berechtigungen der einen Adresse, die der Server sehen kann, und der Prüfpfad kann sie danach nicht mehr unterscheiden. Das ist eine Designentscheidung, kein Firewall-Detail.

Wählen Sie bewusst zwischen den beiden Designs. Beschränken Sie die Regel auf den echten VPN-Pool, wenn der Server sehen muss, wer verbunden war, und akzeptieren Sie den übersetzten Pfad nur, wenn der Server diese Information wirklich nicht braucht. Notieren Sie den gewählten Quellbereich neben der Regel, denn die nächste Person, die das debuggt, wird zuerst die Adresstabelle ansehen.