VPN-Clients werden durch das öffentliche Windows-Firewallprofil blockiert

Ihr Tunnel steht, das Gateway antwortet auf Ping, und die Dateifreigabe läuft trotzdem in eine Zeitüberschreitung. Diese Kombination ist selten ein Routingproblem: Windows hat das Subnetz des VPN-Adapters in das Profil „Öffentlich“ gelegt, und jede Zulassen-Regel, die für „Privat“ oder „Domäne“ geschrieben wurde, kam nie zur Anwendung. Ich habe das auf Laptops erlebt, die das Büro problemlos erreichen, und auf RRAS-Servern, die jeden anderen Client bedienen, und die Reparatur ist kurz, sobald man das beteiligte Profil benennt. Hier ist die Reihenfolge, in der ich arbeite, mit der Prüfung, die Ihnen sagt, wann Sie vor dem nächsten Schritt anhalten sollten.

Ermitteln, auf welchem Profil der Datenverkehr tatsächlich ankommt

Die Windows-Firewall kennt keinen einzigen globalen Modus. Jede verbundene Schnittstelle trägt eine Kategorie, und eingehende Pakete werden gegen die Kategorie der Schnittstelle gefiltert, auf der sie ankommen; damit entscheidet das Profil des VPN-Adapters, was ein Client im Tunnel erreichen kann, und nicht der daneben liegende WLAN- oder Ethernet-Adapter. Lesen Sie beide Fakten, bevor Sie etwas ändern:

Get-NetConnectionProfile | Select-Object Name, InterfaceAlias, NetworkCategory, IPv4Connectivity
Get-NetFirewallProfile -Name Public | Select-Object Name, Enabled, DefaultInboundAction

Bei einer Standardinstallation von OpenVPN oder WireGuard erscheint der VPN-Adapter als nicht identifiziertes Netzwerk und landet in „Öffentlich“, dem Standard für jedes Netzwerk, das Windows nicht einordnen kann: kein Domänencontroller hat darüber geantwortet und kein Gateway-Profil passte. Der Name der Schnittstelle spielt hier keine Rolle, wer den Adapter „VPN“ oder „Firma“ nennt, ändert also nichts. DomainAuthenticated erfordert einen Rechner in der Domäne , der über diese Schnittstelle tatsächlich einen Domänencontroller erreichen kann; ein Split-Tunnel, der nur ein Subnetz führt, erfüllt die Bedingung nicht.

Wenn die benötigte Regel bereits auf den VPN-Pool begrenzt ist und bereits für die Kategorie gilt, die Sie gerade gelesen haben, hören Sie hier auf: Die Filterung ist nicht Ihre Ebene, und die nächste Stelle ist die Dienstkonfiguration. Diese Prüfung dauert zehn Sekunden und spart eine Stunde Regelbearbeitung. Die Kategorienamen und ihre jeweilige Abdeckung sind in der Referenz zu Get-NetConnectionProfile.

Erst die Filterung bestätigen, nicht das Routing, bevor Sie Regeln ändern

Ping ist ein schwacher Test. ICMP kann durchgehen, während der Dienstport verworfen wird, und ein Host kann aus dem LAN antworten, während er dieselbe Anfrage über den Tunnel ablehnt. Testen Sie den Port, den der Client braucht, vom Client aus:

Test-NetConnection 10.8.0.1 -Port 445
Test-NetConnection 10.8.0.1 -Port 3389 -InformationLevel Detailed

Wenn der Porttest fehlschlägt, trennen Sie die beiden Ebenen. Ein Tunnel- oder Routenfehler zeigt sich meist darin, dass gar keine Antwort von der Gateway-Adresse kommt, während eine Firewall-Verwerfung ein Gateway zeigt, das antwortet, und einen Dienstport, der es nicht tut. Auf einem Windows-Server, der den Pool über RRAS bereitstellt, führen Sie denselben Test von einem Client aus und lesen das eigene Profil des Servers: Die RAS-Schnittstelle kann in einer Kategorie sitzen, deren eingehende Regeln den Clientbereich nie erwähnen, weshalb die Maschine ihr LAN bedient und jeden Client im Tunnel abweist.

Wenn das Ergebnis weiterhin unklar ist, protokollieren Sie die Verwerfungen für das beteiligte Profil und lesen Sie sie:

Set-NetFirewallProfile -Name Public -LogBlocked True `
  -LogFileName "$env:systemroot\system32\LogFiles\Firewall\pfirewall.log"

Einträge, die Clientadresse und Port mit DROP nennen, sind beweiskräftig, und sie sagen Ihnen auch, welche Regel fehlte. Ein Protokoll ohne jeden Eintrag, während das SYN des Clients nie erscheint, deutet auf etwas vor dem Host hin; gehen Sie also zurück zum Tunnel, zur NAT-Regel oder zur Pool-Route, bevor Sie ein weiteres Firewallobjekt anfassen.

Eine eingehende Regel auf den Client-Pool begrenzen

Die Reparatur ist eine einzige eingehende Zulassen-Regel, deren Remote-Adresse der Pool ist und nicht die ganze Welt. Aus einer erhöhten Sitzung:

New-NetFirewallRule -DisplayName "VPN clients - SMB 445" `
  -Direction Inbound -Action Allow -Protocol TCP -LocalPort 445 `
  -RemoteAddress 10.8.0.0/24 -Profile Public

Wenn der Dienst aus einer einzigen Binärdatei besteht, bevorzugen Sie eine programmbezogene Regel mit -Program statt einer Portliste; das begrenzt die Ausnahme sowohl auf den Prozess als auch auf den Quellbereich.

Die Profilwahl ist der Punkt, an dem derselbe Fehler in die andere Richtung passiert. -Profile Public genügt, wenn der Adapter Öffentlich ist und Öffentlich bleibt. -Profile Any ist vertretbar, wenn der Dienst funktionieren muss, egal wie Windows den Adapter einstuft, aber nur solange die Remote-Begrenzung bleibt. Was nie vertretbar ist, ist -RemoteAddress Any im Profil Öffentlich: Diese Regel folgt dem Laptop in jedes Café- und Hotelnetz, dem er beitritt, und öffnet den Port für jeden, der sich dieses Subnetz teilt.

Halten Sie den Pool neben der Regel fest. -RemoteAddress 10.8.0.0/24 passt still nicht mehr, sobald der VPN-Pool neu nummeriert wird, und der Fehler sieht genau wie der ursprüngliche Bug aus, weshalb er einen zweiten Nachmittag kostet. Benennen Sie Regeln nach dem Dienst und dem Quellbereich, halten Sie sie zusammen mit -Group, und lesen Sie sie erneut, wann immer sich die Pool-Definition ändert. Ein Regelverzeichnis, das Sie auf einem Bildschirm prüfen können, ist besser als eine korrekte Regel, die niemand findet.

Die Kategorie nur ändern, wenn die Kategorie die Entscheidung ist

Die Schnittstelle auf Privat umzustellen funktioniert ebenfalls, ist aber die falsche Voreinstellung. Das Profil Privat bringt eine lange Liste integrierter Zulassen-Regeln mit, die Datei- und Druckerfreigabe, Netzwerkerkennung, Remotedesktop und je nach Baseline noch mehr abdecken; eine Neuklassifizierung des VPN-Adapters aktiviert sie alle für jeden Client im Tunnel auf einmal. Eine begrenzte Regel erteilt einem Dienst für einen Bereich die Erlaubnis. Auf einem Laptop, der auch fremden Netzen beitritt, ist dieser Unterschied nicht kosmetisch.

Es gibt Fälle, in denen die Klassifizierung wirklich falsch ist: Ein dauerhaft aktiver oder Site-to-Site-Tunnel, der ein Büro-Subnetz transportiert, ist vertrauenswürdige Infrastruktur, und diesen Adapter als Privat zu kennzeichnen ist eine legitime Designentscheidung, die einmal per Richtlinie getroffen wird und nicht pro Ticket. Wenn Sie sie treffen, treffen Sie sie ausdrücklich:

Set-NetConnectionProfile -InterfaceAlias "OpenVPN TAP-Windows6" -NetworkCategory Private

Auf einem verwalteten Gerät prüfen Sie zuerst, ob eine Gruppenrichtlinie oder eine MDM-Baseline diese Einstellung besitzt. Ist das der Fall, wird die lokale Änderung beim nächsten Aktualisieren rückgängig gemacht, und gpresult /h nennt die Richtlinie, die sie besitzt; korrigieren Sie es dort und nicht auf dem Endpunkt.

Von beiden Enden prüfen und eine Spur hinterlassen

Prüfen Sie den vom Benutzer gemeldeten Ablauf nach der Änderung vom Client aus:

Test-NetConnection 10.8.0.1 -Port 445
Get-NetFirewallRule -DisplayName "VPN clients - SMB 445" | Get-NetFirewallAddressFilter | Select-Object RemoteAddress
Get-NetFirewallRule -DisplayName "VPN clients - SMB 445" | Get-NetFirewallPortFilter | Select-Object Protocol, LocalPort

Schließen Sie dann die Schleife bei den Dingen, die nächste Woche kaputtgehen. Starten Sie den Host neu und testen Sie erneut, denn eine Regel, die auf das falsche Profil begrenzt ist, funktioniert weiter, bis der Adapter in einer anderen Kategorie zurückkommt. Testen Sie von einem zweiten Client, denn ein Client mit einer veralteten Lease kann eine Pool-Abweichung verdecken. Zählen Sie die hinzugefügten Regeln gegen die entfernten auf, denn überlappende Ausnahmen sind der Weg, auf dem aus einem Zweizeiler eine Filterrichtlinie wird, die niemand mehr prüfen kann.

Bevor Sie es als erledigt betrachten:

• Das in der Regel genannte Profil ist das Profil der Schnittstelle, auf der der Datenverkehr ankommt.
• Die Remote-Begrenzung ist der VPN-Pool, und dieser Pool entspricht dem, was der Server tatsächlich vergibt.
• Keine von Ihnen hinzugefügte Regel verwendet -RemoteAddress Any im Profil Öffentlich.
• Nichts wurde deaktiviert, damit der Test besteht, und jede Kategorieänderung hält fest, wer sie genehmigt hat.