Sollte der Windows-VPN-Adapter privat oder öffentlich sein?
Entscheiden Sie mit drei Prüfungen, ob ein Windows-VPN-Adapter zum privaten Profil gehört: vertrauenswürdiger Pfad, stabile Klassifizierung und Regeln, die Sie wirklich brauchen.
Einen Windows-VPN-Adapter auf Privat zu setzen ist für einen Firmentunnel richtig und für einen kommerziellen VPN-Client falsch, und der Unterschied ist nicht kosmetisch. Die Netzwerkkategorie wählt ein Firewallprofil, sodass eine Änderung auf einmal ein ganzes Regelwerk zulässt. Ich habe ein Anmeldeskript gesehen, das jeden nicht identifizierten Adapter auf Privat setzte, was stillschweigend die Dateifreigabe in einem Hotel-WLAN offenlegte. Drei Bedingungen entscheiden die Antwort, und alle müssen gelten, bevor Sie die Einstellung anfassen.
Was die Kategorie tatsächlich entscheidet
Network Location Awareness baut aus dem, was der Adapter melden kann, eine Signatur für jedes verbundene Netzwerk: die Gateway-Adresse und MAC, das DNS-Suffix, ob ein Domänencontroller antwortet und ob das Netzwerk das Internet erreicht. Windows hängt ein Profil an diese Signatur, und die Firewall wendet dann das Regelwerk für dieses Profil an. Öffentlich ist der Rückfall, wenn die Identifizierung scheitert, weshalb ein funktionierender Tunnel weiterhin als nicht identifiziertes Netzwerk bezeichnet werden kann.
Ein TUN- oder TAP-Adapter gibt der Identifizierung meist sehr wenig an die Hand. Der Tunnelpartner ist oft eine einzelne Adresse statt eines Gateways, DNS wird möglicherweise nur innerhalb des Tunnels übertragen, und der Adapter hat keine eigene Standardroute. Das resultierende Etikett beschreibt die Firewall-Eingabe, nicht den Zustand des Tunnels, und deshalb hören Regeln des privaten Profils in dem Moment auf zu passen, in dem sich das VPN verbindet.
Bedingung eins: der Tunnel ist der vertrauenswürdige Pfad
Privat zu wählen behauptet, dass alles, was über diese Schnittstelle erreichbar ist, mindestens so vertrauenswürdig ist wie Ihr eigenes LAN, denn Erkennung und eingehende Regeln behandeln dieses Subnetz als lokal. Für einen Firmentunnel in ein verwaltetes Subnetz mit Dateiservern und Druckern gilt die Behauptung meist. Der Adapter ist eine Tür in ein Netz, das Ihre Organisation kontrolliert, und der Rechner auf der anderen Seite wurde von derselben Richtlinie zugelassen, die Ihren zugelassen hat.
Ein kommerzieller VPN-Ausgang besteht diese Prüfung nicht. Andere Abonnenten teilen das Ausgangssubnetz, und es als Privat zu markieren bringt Netzwerkerkennung, LLMNR und NetBIOS-Namensauflösung in ein Segment voller Fremder. Auch Split-Tunneling kann scheitern: Wenn der Adapter eine einzelne Host-Route zu einer Anwendung trägt, gibt es kein vertrauenswürdiges Subnetz, von dem man sprechen könnte, und die Kategorieänderung bringt Ihnen nichts.
Bedingung zwei: die Klassifizierung überlebt Wiederverbindungen
Ein neues Gateway oder DNS-Suffix erzeugt eine neue Signatur, und Windows trifft dafür eine frische Profilentscheidung. Ein einmaliges Set-NetConnectionProfile hält daher bis zur nächsten Wiederverbindung, nicht ewig. Prüfen Sie das Profil nach einer Wiederverbindung statt nach der ersten Verbindung, denn dann fällt die Einstellung von selbst zurück.
Es gibt drei Wege, das dauerhaft zu machen. Der sauberste ist Richtlinie: Öffnen Sie secpol.msc, gehen Sie zu Network List Manager Policies und legen Sie den Standorttyp für das Netzwerk fest, einschließlich der Richtlinie für nicht identifizierte Netzwerke, damit das Profil per Richtlinie statt per Befehl angewendet wird. Der zweite ist ein Skript pro Verbindung oder eine geplante Aufgabe, die das PowerShell-Cmdlet ausführt, sobald der Tunnel steht. Der dritte ist der altbekannte Routentrick, der der Identifizierung ein Gateway zum Prüfen gibt:
route -p add 0.0.0.0 mask 0.0.0.0 10.8.0.1 metric 50 IF 24
Get-NetConnectionProfileDer Routentrick ist ein Umweg, keine Klassifizierung. Er bricht, wenn sich das Metrikverhältnis ändert oder der VPN-Client bei der Wiederverbindung Routen neu schreibt, und er ändert still die Pfadauswahl für alles, was auf die zweite Standardroute zurückfällt.
Bedingung drei: Sie brauchen das private Regelwerk
Privat trägt üblicherweise Datei- und Druckerfreigabe, Netzwerkerkennung und die Gruppen der Remoteverwaltung. Wenn die Aufgabe darin besteht, eine SMB-Freigabe oder einen Drucker durch den Tunnel zu erreichen, ist das der eigentliche Grund, die Kategorie zu ändern. Wenn die Aufgabe ausgehender Zugriff auf eine Webanwendung ist, ist die Kategorie irrelevant: Schreiben Sie die ausgehende Regel, behalten Sie Öffentlich und hören Sie dort auf.
| Scenario | Category | Why |
|---|---|---|
| Corporate tunnel to a file server or printer | Private | Private rules carry the sharing you need |
| Commercial VPN for privacy | Public | The exit subnet is shared with strangers |
| Split tunnel with a single host route | Public | No trusted subnet and an unstable signature |
| Site-to-site tunnel to a branch LAN | Private | The far subnet is managed like the local one |
| Lab adapter you control end to end | Private | Discovery helps and nothing else is exposed |
Lesen Sie die Tabelle als Ausgangspunkt und prüfen Sie dann, welche privaten Regeln in Ihrem Build tatsächlich aktiv sind. Ein gehärtetes Image hat die Dateifreigabe womöglich ganz aus dem privaten Profil entfernt, und dann bewirkt die Kategorieänderung nichts, bis Sie die Regel wieder hinzufügen. Diese Prüfung kostet einen Befehl und spart einen langen Nachmittag.
Die Änderung ohne Ausweitung alles anderen
Zielen Sie auf den Schnittstellenindex, nicht auf einen Platzhalter, und lesen Sie die Liste vorher und nachher:
Get-NetConnectionProfile
Set-NetConnectionProfile -InterfaceIndex 24 -NetworkCategory Private
Get-NetFirewallProfileGespeicherte Profile liegen unter dem Schlüssel NetworkList in der Registrierung, wo der Wert Category öffentliche, private und Domänennetze trennt. Das Bearbeiten ist möglich und leicht falsch zu machen: Sie müssen den Eintrag ändern, der zur aktuellen Signatur des Adapters passt, nicht einen älteren Eintrag, den eine frühere Adresse hinterlassen hat. Ein veralteter Eintrag sieht im Editor korrekt aus und tut bei der Wiederverbindung nichts.
Was auch immer Sie tun, liefern Sie kein Skript aus, das jeden nicht identifizierten Adapter auf Privat setzt. Das ist die Einzeiler-Version davon, die Erkennung in unsicherem WLAN zu öffnen. Wenn Sie Freigabe nur mit dem Tunnel-Subnetz brauchen, behalten Sie das Profil Öffentlich und fügen Sie begrenzte eingehende Regeln für den entfernten Adressbereich des Tunnels hinzu; die Firewallregel ist enger als die Kategorie.
Prüfen Sie die Freigabe, nicht das Etikett
Testen Sie nach der Änderung die Ressource selbst, statt dem Etikett zu vertrauen:
Test-NetConnection files.corp.example -Port 445
Resolve-DnsName files.corp.exampleWenn die Freigabe weiterhin fehlschlägt, während der Adapter Privat anzeigt, ist die Kategorie nicht mehr Ihr Problem. Namensauflösung, eine fehlende Route oder Freigabeberechtigungen erzeugen dasselbe Symptom, und ein weiterer Profilwechsel kann keines davon reparieren. Verbinden Sie sich einmal neu und führen Sie Get-NetConnectionProfile erneut aus, um zu bestätigen, dass die Einstellung hielt, und bearbeiten Sie dann den verbleibenden Fehler als normales SMB-Problem.
Checkliste: Bestätigen Sie, dass der Tunnel ein verwalteter Pfad ist, dass das Profil eine Wiederverbindung überlebt, dass die benötigten privaten Regeln im Image vorhanden sind und dass die Freigabe sich auflöst und auf Port 445 antwortet. Wenn eine der ersten drei Bedingungen falsch ist, lassen Sie den Adapter auf Öffentlich und lösen Sie das Zugriffsproblem mit einer begrenzten Regel.