Ping funktioniert nur in eine Richtung: warum Windows das Echo des Servers verwirft

Ihr Client pingt den Server, der Server kann den Client nicht pingen, und der Tunnel befördert in beiden Aussagen offensichtlich Pakete. Unterschiedlich ist nicht der Pfad, sondern das erste Paket jedes Tests: Das eine ist eine Antwort auf einen Fluss, den Windows bereits verfolgt, das andere eine neue eingehende Anfrage, die keine Regel zugelassen hat. Dieser Unterschied erklärt die meisten Berichte über einseitiges Ping und weist direkt auf die Regel, die Sie schreiben müssen. Zwei Tests in entgegengesetzte Richtungen trennen die Fälle in etwa einer Minute.

Zwei Richtungen, zwei verschiedene Entscheidungen

Wenn der Client die Echo-Anfrage sendet, sieht die Windows-Firewall eine ausgehende Verbindung, die sie zugelassen hat. Die Antwort kommt innerhalb dieses etablierten Flusses zurück, sodass die zustandsbehaftete Engine sie durchlässt, ohne eine eingehende Regel für ICMP zu befragen. Das bedeutet zustandsbehaftetes Filtern in der Praxis, und die Regel, die niemand geschrieben hat, ist daran nicht beteiligt. Der Erfolg des Clients sagt daher nichts über die eingehende Richtlinie aus.

Sendet der Server die Anfrage zuerst, passt kein Zustand darauf. Windows behandelt das Paket als neue eingehende Verbindung und fragt die eingehende Richtlinie, die standardmäßig nichts für Echo-Anfragen aus beliebigen Quellen vorsieht.

Der Erfolg des Clients bewies also, dass ausgehendes ICMP und der Rückweg funktionieren. Er hat die eingehende Entscheidung nie geprüft, und die naheliegende Schlussfolgerung, die Firewall sei in Ordnung, ist vernünftig und falsch. Deshalb wiederholt sich der Fehler in Tickets, die den Beweis bereits enthalten.

Folgen Sie dem Paket, bis es verschwindet

Bestätigen Sie die Adressen, bevor Sie etwas ändern: Nehmen Sie die Tunneladresse, die der Client tatsächlich hält, und prüfen Sie, ob der Server dorthin routet und nicht zu einer LAN-Adresse hinter dem Client. Die beiden Fehlerbilder sehen von der Eingabeaufforderung des Servers identisch aus, weil beide in einem Timeout enden. Wo das Paket stirbt, ist die einzige Tatsache, die entscheidet, was zu ändern ist.

Wenn die Anfrage die Tunnelschnittstelle erreicht und nichts sie verlässt, ist die lokale Firewall der wahrscheinliche Grund. Wenn sie die Schnittstelle nie erreicht, liegt die Antwort weiter oben: eine Route auf dem Server, eine ausgehende Richtlinie oder die eigene Peer-Zustellung des VPN.

Zeichnen Sie an der Tunnelschnittstelle des Clients auf, während der Server pingt. Zu sehen, wie die Anfrage ohne Antwort daneben ankommt, ist der Beweis, der eine Windows-Regel rechtfertigt. Nichts zu sehen schickt Sie weiter nach oben, und eine in diesem Zustand hinzugefügte Regel macht die Maschine nur durchlässiger für ein Paket, das nie ankam. So oder so kostet die Aufzeichnung weniger als die Vermutungen, die sie ersetzt.

Eine Regel begrenzen statt ICMP zu öffnen

Identifizieren Sie den Adapter und seine aktuelle Kategorie, bevor Sie etwas schreiben, denn beides erscheint in dem Bereich, den Sie gleich festlegen. Dieser Alias ist der Windows-Schnittstellenname, der nicht unbedingt der Name des importierten VPN-Profils ist. Die folgenden Befehle listen auf, was existiert, und zeigen dann eine begrenzte Regel als Vorschau, ohne sie anzuwenden.

Get-NetConnectionProfile
Get-NetAdapter | Where-Object Status -eq 'Up'
New-NetFirewallRule -DisplayName "VPN server echo" -Direction Inbound -Protocol ICMPv4 -IcmpType 8 -RemoteAddress 10.63.0.1 -InterfaceAlias "Office VPN" -Profile Private -Action Allow -WhatIf

ICMPv4 Typ 8 ist die Echo-Anfrage, die einzige Nachricht, die der Server beantwortet haben muss. Begrenzen Sie sie auf die Tunneladresse des Servers und auf die Tunnelschnittstelle, und lassen Sie das Profil so, wie der Adapter wirklich ist. Ein Netz umzubenennen, damit es zu einem Beispiel passt, ist eine separate Änderung mit eigenen Folgen.

Was die Regel nicht abdeckt

IPv6-Echo ist ein anderes Protokoll mit einem anderen Nachrichtentyp, also sagt eine ICMPv4-Regel nichts darüber aus, und ein Tunnel, der beide Familien trägt, braucht seine eigene Regel für die andere. Diese Regel öffnet auch sonst nichts: RDP, Dateifreigabe und jeder andere Dienst hängen weiterhin von ihrer eigenen Richtlinie ab. Das ist der ganze Sinn, eine enge Regel zu begrenzen, statt eine breite ICMP-Freigabe zu aktivieren. Die breite Freigabe ist die einfache Lösung und die, die am längsten überlebt, weil sie danach niemandem auffällt.

Auf einem verwalteten Gerät kann die Regel beim nächsten Richtlinien-Refresh ersetzt werden, also muss der Richtlinieninhaber die entsprechende Änderung vornehmen und nicht ein lokaler Administrator. Schreiben Sie die Absicht ins Ticket ebenso wie den Befehl, denn ein Refresh löscht den Befehl und lässt die Anforderung unberührt. Beides ist nicht dasselbe Artefakt, und nur eines davon überlebt.

Lesen Sie das Ergebnis in der richtigen Richtung

Nachdem die Regel greift, pingen Sie vom Server und bestätigen Sie, dass eine Antwort den Client erreicht, dann pingen Sie von einer Quelle, die weiterhin ausgeschlossen sein soll, und bestätigen Sie, dass sie es nicht tut. Wiederholen Sie den Erreichbarkeitstest auf der anderen Adressfamilie, wenn der Tunnel eine trägt.

Get-NetFirewallRule -DisplayName "VPN server echo" | Get-NetFirewallAddressFilter
ping 10.63.4.17
ping -6 fd00:63::17

Die Regel auszugeben, die wirksam geworden ist, ist nützlicher, als dem Befehl zu vertrauen, der sie erzeugt hat, denn eine Vorschau und eine angewandte Regel sind verschiedene Zustände. Wenn der Adressfilter die beabsichtigte Quelle zeigt und die ausgeschlossene Quelle weiterhin in einen Timeout läuft, tut die Regel genau das, was ihr Bereich sagt. Ein erfolgreicher Ping vom Client hätte das nie gezeigt, und deshalb gehört die Richtung jedes Tests neben sein Ergebnis in den Eintrag. Behalten Sie beide Richtungen im Ticket, sonst wiederholt der nächste Leser den Test, der nicht fehlschlagen kann.