Warum Ihr VPN-Adapter im öffentlichen Firewallprofil bleibt

Der Tunnel steht, das Konto wurde gegenüber der Domäne authentifiziert, und Windows kennzeichnet die Verbindung weiterhin als Öffentlich. Eine Firewallregel, die für das Domänenprofil geschrieben wurde, greift daher nicht, und die Dateifreigabe bleibt unerreichbar. Der übliche Reparaturversuch besteht darin, den Adapter auf Privat zu setzen; das ändert, welche Regeln gelten, ohne irgendetwas an der Authentifizierung zu ändern. Sowohl die Kennzeichnung als auch die Reparatur werden weithin missverstanden, und ihre Trennung erfordert drei Befehle.

Das Konto, das sich eingewählt hat, ist nicht die Kategorie des Netzwerks

Während einer VPN-Verbindung fallen zwei verschiedene Entscheidungen, und sie sind leicht zu verwechseln. Das Gateway entscheidet, ob sich das Konto verbinden darf. Windows entscheidet, wie das resultierende Netzwerk klassifiziert wird, und diese Klassifizierung bestimmt, welche Firewallregeln für die Schnittstelle gelten.

Eine erfolgreiche Domänenauthentifizierung am Gateway ist ein Beleg über das Konto. Sie ist kein Beleg dafür, dass der Endpunkt das Netzwerk gegenüber einem Domänencontroller authentifiziert hat, und genau das stellt die Domänenkategorie dar.

Deshalb kann ein Rechner domänenangebunden sein, sich mit einem Domänenkonto verbinden und trotzdem Öffentlich anzeigen. Die Klassifizierung ist eine lokale Feststellung über das Netzwerk, keine Aussage über die Anmeldeinformationen, die den Tunnel geöffnet haben. Das Konto kann völlig gültig sein, während die Kennzeichnung dort bleibt, wo sie begonnen hat.

Drei Kategorien, von denen Sie eine nicht setzen können

Windows bietet drei Kategorien, und nur zwei davon kann ein Administrator zuweisen. Die dritte bestimmt das Betriebssystem, nachdem es das Netzwerk erfolgreich gegenüber einem Domänencontroller authentifiziert hat.

Get-NetConnectionProfile | Select-Object Name,InterfaceAlias,NetworkCategory,IPv4Connectivity
Set-NetConnectionProfile -InterfaceAlias 'Corp VPN' -NetworkCategory Private
Set-NetConnectionProfile -InterfaceAlias 'Corp VPN' -NetworkCategory DomainAuthenticated

Der dritte Befehl schlägt fehl, und das ist das dokumentierte Verhalten und kein Berechtigungsproblem. Die Referenz des Cmdlets selbst führt aus, dass die Domänenkategorie so nicht zugewiesen werden kann, weil Windows sie aus der Domänenauthentifizierung ableitet. Den Fehler zu sehen ist eine nützliche Bestätigung, dass die Kategorie eine Folge und keine Einstellung ist.

Lesen Sie den ersten Befehl auf dem Endpunkt, dessen Datenverkehr blockiert wird. Die eigene Schnittstellenklassifizierung eines Gateways sagt Ihnen nichts darüber, wie jede verbindende Arbeitsstation ihren Tunnel klassifiziert hat.

Regeln folgen dem Profil, für das sie geschrieben wurden

Sobald Sie die Kategorie kennen, erklärt sich der fehlende Zugriff meist von selbst. Jede Windows-Firewallregel trägt einen Profilbereich, und eine auf Domäne beschränkte Regel gilt nicht, wenn die Schnittstelle öffentlich ist. Drei Befehle machen daraus eine Antwort statt einer Theorie, und der dritte fängt den Fall ab, in dem das Profil nie das Problem war:

(Get-NetFirewallRule -DisplayName 'Allow File Share').Profile
Get-NetFirewallRule -DisplayName 'Allow File Share' | Get-NetFirewallAddressFilter
Get-NetFirewallProfile | Select-Object Name,Enabled,DefaultInboundAction

Der zweite Befehl ist derjenige, der einen vagen Bericht in eine Lösung verwandelt. Ist die Regel auf einen Bereich entfernter Adressen beschränkt, der den VPN-Pool nicht enthält, hilft auch eine Profiländerung nicht.

Prüfen Sie auch die Standardaktion für eingehenden Verkehr. Auf einem Rechner, auf dem eingehender Verkehr standardmäßig blockiert wird, erzeugt eine fehlende Zulassungsregel Stille statt einer Ablehnung. Aus Client-Sicht sieht das identisch zu einem Routingfehler aus, weshalb so viele dieser Tickets mit der falschen Annahme beginnen.

Finden Sie heraus, welcher Rechner die Regel durchsetzt

Bevor Sie eine Kategorie ändern, stellen Sie fest, wo die Blockade stattfindet. Der Server, der die Freigabe hostet, kann eine eigene Firewall haben, und ihre Regeln gelten für den Verkehr aus dem VPN-Pool, unabhängig davon, wie der Client seinen Adapter benannt hat. Eine Ablehnung dort ist für jeden lokalen Befehl, den Sie ausführen, unsichtbar, und die Client-Seite meldet nur, dass die Ressource nicht verfügbar ist. Testen Sie die eigenen Regeln des Ziels, bevor Sie die Klassifizierung des Clients anfassen.

Testen Sie vom Client zum konkreten Port und vergleichen Sie dann mit einem Test von einem anderen Host im selben VPN. Scheitern beide, liegt das Problem am Ziel oder auf dem Pfad. Scheitert nur einer, ist der Unterschied lokal auf diesem Rechner, und die Profilkategorie wird zu einer plausiblen Ursache.

Behalten Sie auch die Richtung im Blick. Eine Regel, die eingehendes SMB erlaubt, bewirkt nichts für einen Client, dessen eigene ausgehende Regel denselben Verkehr blockiert. Aus einem Dateiexplorer-Fenster sind die beiden Fehler nicht unterscheidbar, also testen Sie jede Richtung getrennt, bevor Sie etwas bearbeiten.

Was Sie tun sollten, statt alles umzubenennen

Ein nicht identifiziertes Netzwerk privat zu machen, um eine breite Regel zu erfüllen, ist eine echte Änderung mit echten Folgen. Das private Profil erlaubt typischerweise mehr Erkennung und mehr eingehenden Verkehr als das öffentliche.

Wenn das Ziel ist, einem bestimmten Dienst den Zugang zu den VPN-Clients zu ermöglichen, beschränken Sie die Regel nach entfernter Adresse statt nach Profil. Das drückt die Absicht präzise aus, funktioniert unabhängig von der Klassifizierung und hängt nicht davon ab, dass Windows einen virtuellen Adapter richtig errät. Sie übersteht auch ein Client-Update, das die Schnittstelle neu klassifiziert. Schreiben Sie den Pool in die Regel, und die nächste Person kann die Absicht lesen, ohne zu fragen.

Wenn die Domänenkategorie tatsächlich erwartet wird und nie erscheint, ist das eine getrennte Untersuchung. Prüfen Sie, ob der Rechner domänenangebunden ist, ob er über den Tunnel einen Domänencontroller erreicht und ob der sichere Kanal gesund ist. Diese drei Befehle beantworten das ohne eine einzige Registrierungsänderung:

Get-CimInstance Win32_ComputerSystem | Select-Object PartOfDomain,Domain
Test-ComputerSecureChannel -Verbose
nltest /dsgetdc:corp.example.com

Diese drei beantworten, ob der Endpunkt das Netzwerk überhaupt hätte authentifizieren können. Wenn er keinen Controller erreicht, wird die Domänenkategorie nie zugewiesen, egal wie oft der Adapter zurückgesetzt wird. Die Firewallregel, der Sie nachjagten, war nie das eigentliche Problem, und die Kennzeichnung war ein Symptom eines gestörten Pfads, keine Ursache.