VPN-Verkehrsfilter oder IPsec-Regel: Wo Windows einen Port durchsetzt

Eine Route sieht ein Ziel, keinen Dienst. Entscheiden Sie, ob Sie einen Zugriffsfilter im VPN-Profil brauchen oder eine IPsec-Regel, die Schutz für den Datenfluss verlangt.

Ein Windows-VPN-Benutzer soll HTTPS auf einem Server erreichen und nicht SMB auf demselben Server, und eine Route kann das nicht ausdrücken. Beide Anforderungen tragen dieselbe Zieladresse, also trägt das Präfix, das Verkehr in den Tunnel schickt, auch den Datenfluss, den Sie ausschließen wollten. Sie zu trennen erfordert eine Regel, die etwas Feineres als das Ziel prüft.

Zwei verschiedene Absichten werden mit zwei verschiedenen Windows-Mechanismen gebaut. Sie zu vermischen erzeugt eine Richtlinie, die vollständig aussieht und doch nur die Hälfte dessen durchsetzt, was Sie gemeint haben.

Eine Route kann zwei Dienste an einer Adresse nicht trennen

Native VPN-Routenplanung ist präfixbasiert: Sie entscheidet, welche Ziele durch den Tunnel fahren und welche draußen bleiben. Das ist das richtige Werkzeug, um ein Subnetz drinnen und ein anderes draußen zu halten, und sie ist konstruktionsbedingt blind für Ports. Ein Verkehrsfilter im VPN-Profil fügt eine zweite Dimension hinzu: Er gleicht Protokoll, entfernte Adresse und entfernten Port dafür ab, was diese Schnittstelle überqueren darf. Eine IPsec-Regel arbeitet an dritter Stelle und drückt aus, welche Datenflüsse Schutz verlangen und mit wem sie sich authentifizieren. Die drei beantworten verschiedene Fragen, und keine ersetzt die anderen.

Beginnen Sie damit, den gewünschten Satz zu schreiben. Nur HTTPS erlauben ist ein Zugriffssatz, während IPsec für HTTPS verlangen ein Schutzsatz ist, und beide führen zu unterschiedlicher Konfiguration.

Zugriffsbeschränkung und Schutzanforderung laufen auseinander

Eine Zugriffsbeschränkung sagt, was die Schnittstelle nutzen darf, und wird durchgesetzt, indem eine Menge erlaubt und alles andere abgelehnt wird. Eine Schutzanforderung sagt, welche Datenflüsse verschlüsselt und authentifiziert sein müssen, und wird durchgesetzt, indem passende Sicherheitsassoziationen ausgehandelt werden. Die erste erzeugt eine blockierte Anforderung, wenn etwas nicht auf der Liste steht, während die zweite eine Verbindung erzeugt, die entweder den geforderten Schutz trägt oder nicht zustande kommt. Das eine wie das andere zu behandeln ist der Weg, auf dem eine Richtlinie am Ende nichts blockiert oder nichts schützt.

Die praktische Folge ist, dass eine Filterliste eine geschlossene Menge ist. Sobald eine Liste im Profil existiert, wird Verkehr über diese Schnittstelle, der keinem Eintrag entspricht, abgelehnt, also brauchen DNS, Authentifizierungsaustausch und jede Abhängigkeit, die die Anwendung benötigt, eigene Einträge. Eine breite Regel hinzuzufügen, um die Ablehnungen zu beenden, öffnet die ganze Schnittstelle wieder und hebt die Beschränkung still auf. Die Liste sollte so kurz sein, wie es die Anforderung erlaubt, und so vollständig, wie es die Anwendung verlangt.

Bauen Sie die Filterliste als vollständige Menge

VPNv2-Profile tragen die Filterliste getrennt von der Routenliste, und ihre Einträge sind Profileigenschaften statt Befehle. Für das HTTPS-Beispiel braucht der Eintrag Protokoll 6, die entfernte Adresse und den entfernten Port, bereitgestellt über den Verwaltungskanal oder ProfileXML für den verwendeten Profiltyp. Microsofts Definition des VPNv2-Verkehrsfilters stellt fest, dass Bedingungen innerhalb einer Regel kombiniert werden, während getrennte Regelkennungen als Alternativen wirken.

TrafficFilterList/0/Protocol            = 6
TrafficFilterList/0/RemoteAddressRanges = 10.60.4.20/32
TrafficFilterList/0/RemotePortRanges    = 443
RouteList/0/Address                     = 10.60.4.0/24

Portwerte in dieser Liste beschreiben den Dienstport am fernen Ende, und der lokale Port sollte uneingeschränkt bleiben, damit der kurzlebige Quellport des Clients nicht herausgefiltert wird. Das umgekehrt zu machen erzeugt eine Regel, die auf nichts passt, und ein Rätsel, das einen Nachmittag kostet.

Schreiben Sie die Route und den Filter als zwei getrennte Entscheidungen. Die Route entscheidet, dass dieser Server durch den Tunnel erreicht wird, und der Filter entscheidet, welche Dienste diesen Weg nutzen dürfen.

Beweisen Sie beide Ergebnisse mit zwei Anforderungen

Testen Sie den erlaubten Datenfluss und den abgelehnten Datenfluss getrennt und lesen Sie den Fehler statt der fehlenden Seite. Eine Ablehnung, die schnell kommt, ist eine Richtlinienentscheidung, während eine Zeitüberschreitung eher eine fehlende Route oder ein Dienst ist, der nicht lauscht. Die Befehle unten führen beide Anforderungen aus und zeigen die geltenden Regeln.

Test-NetConnection 10.60.4.20 -Port 443
Test-NetConnection 10.60.4.20 -Port 445
Get-NetIPsecRule -DisplayName *Vpn*
Get-VpnConnection -Name Corp

Eine schnelle Ablehnung im SMB-Test bei erfolgreichem HTTPS-Test ist das Ergebnis, das der Filter erzeugen sollte. Eine Ablehnung auf beiden Ports bedeutet, dass der Liste etwas fehlt, was die Sitzung braucht, und eine Zeitüberschreitung auf beiden deutet auf Routing statt auf Filterung hin. Wenn die geschützten Datenflüsse keine Sicherheitsassoziation in der IPsec-Ausgabe zeigen, ist die Schutzanforderung nicht erfüllt, selbst wenn die Verbindung gelingt. Lesen Sie alle vier Ausgaben zusammen, denn jede einzelne stützt eine andere Geschichte.

Halten Sie das wirksame Profil, das Regelset und die Richtlinie der Gegenseite zusammen mit den Ergebnissen fest. Historische Kompatibilitätshinweise zu älteren Windows-Clients beschreiben nicht, was die heutigen verwalteten Profilfunktionen an einem bestimmten Gateway unterstützen. Versionsspezifisches Verhalten gehört in den Datensatz und nicht in die Annahme.

Ähnliche Artikel