Ping werkt maar één kant op: waarom Windows de echo van de server laat vallen

Je client pingt de server, de server kan de client niet pingen, en de tunnel vervoert in beide uitspraken duidelijk pakketten. Wat verschilt is niet het pad maar het eerste pakket van elke test: het ene is een antwoord op een stroom die Windows al volgt, het andere een nieuw inkomend verzoek dat geen enkele regel heeft toegelaten. Dat verschil verklaart de meeste meldingen van eenrichtings-ping en wijst rechtstreeks naar de regel die je moet schrijven. Twee tests in tegengestelde richtingen scheiden de gevallen in ongeveer een minuut.

Twee richtingen, twee verschillende beslissingen

Wanneer de client het echo-verzoek stuurt, ziet de Windows-firewall een uitgaande verbinding die hij heeft besloten toe te staan. Het antwoord komt terug binnen die gevestigde stroom, dus de stateful engine laat het door zonder een inkomende regel voor ICMP te raadplegen. Dat is wat stateful filtering in de praktijk betekent, en de regel die niemand schreef is er niet bij betrokken. Het succes van de client zegt dus niets over het inkomende beleid.

Wanneer de server het verzoek als eerste stuurt, past er geen enkele status bij. Windows behandelt het pakket als een nieuwe inkomende verbinding en vraagt het inkomende beleid, dat standaard niets regelt voor echo-verzoeken van willekeurige bronnen.

Het succes van de client bewees dus dat uitgaand ICMP en de terugweg werken. Het heeft de inkomende beslissing nooit beproefd, en de natuurlijke conclusie, dat de firewall in orde is, is redelijk en onjuist. Daarom herhaalt de fout zich in tickets die het bewijs al bevatten.

Volg het pakket tot het verdwijnt

Bevestig de adressen voordat je iets verandert: gebruik het tunneladres dat de client echt heeft, en controleer dat de server daarheen routeert en niet naar een LAN-adres achter de client. De twee storingen zien er identiek uit vanaf de opdrachtprompt van de server, omdat beide in een time-out eindigen. Waar het pakket sterft is het enige feit dat bepaalt wat er moet veranderen.

Als het verzoek de tunnelinterface bereikt en er gaat niets naar buiten, is de lokale firewall de waarschijnlijke oorzaak. Als het de interface nooit bereikt, ligt het antwoord stroomopwaarts: een route op de server, een uitgaand beleid of de eigen peerbezorging van de VPN.

Leg vast op de tunnelinterface van de client terwijl de server pingt. Zien dat het verzoek aankomt zonder antwoord ernaast is het bewijs dat het schrijven van een Windows-regel rechtvaardigt. Niets zien stuurt je stroomopwaarts, en een regel die in die toestand wordt toegevoegd maakt de machine alleen maar toeschietelijker voor een pakket dat nooit aankwam. Hoe dan ook kost het vastleggen minder dan het giswerk dat het vervangt.

Beperk één regel in plaats van ICMP te openen

Identificeer de adapter en zijn huidige categorie voordat je iets schrijft, want beide komen voor in het bereik dat je gaat instellen. Die alias is de interfacenaam van Windows, die niet per se de naam is van het VPN-profiel dat je hebt geïmporteerd. De opdrachten hieronder laten zien wat er bestaat en tonen daarna een beperkte regel als voorbeeld zonder die toe te passen.

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 type 8 is het echo-verzoek, het enige bericht waarop de server een antwoord nodig heeft. Beperk het tot het tunneladres van de server en tot de tunnelinterface, en laat het profiel zoals de adapter werkelijk is. Een netwerk hernoemen om het bij een voorbeeld te laten passen is een aparte wijziging met eigen gevolgen.

Wat de regel niet dekt

IPv6-echo is een ander protocol met een ander berichttype, dus een ICMPv4-regel zegt er niets over, en een tunnel die beide families draagt heeft zijn eigen regel nodig voor de andere. Deze regel opent ook niets anders: RDP, bestand delen en elke andere dienst hangen nog steeds van hun eigen beleid af. Dat is het hele punt van één smalle regel beperken in plaats van een brede ICMP-toestemming aan te zetten. De brede toestemming is de makkelijke oplossing en degene die het langst overleeft, omdat niemand hem daarna opmerkt.

Op een beheerd apparaat kan de regel bij de volgende beleidsvernieuwing worden vervangen, dus moet de eigenaar van het beleid de gelijkwaardige wijziging doorvoeren en niet een lokale beheerder. Schrijf de bedoeling in het ticket naast de opdracht, want een vernieuwing wist de opdracht en laat de eis intact. De twee zijn niet hetzelfde artefact, en slechts één ervan overleeft.

Lees het resultaat in de juiste richting

Nadat de regel geldt, ping vanaf de server en bevestig dat een antwoord de client bereikt, ping daarna vanaf een bron die nog steeds uitgesloten moet blijven en bevestig dat dit niet gebeurt. Herhaal de bereikbaarheidstest op de andere adresfamilie als de tunnel er een draagt.

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

De regel afdrukken die van kracht werd is nuttiger dan de opdracht vertrouwen die hem maakte, want een voorbeeld en een toegepaste regel zijn verschillende toestanden. Als het adresfilter de bedoelde bron toont en de uitgesloten bron nog steeds een time-out geeft, doet de regel precies wat zijn bereik zegt. Een geslaagde ping vanaf de client zou dat nooit hebben aangetoond, en daarom hoort de richting van elke test in het verslag naast het resultaat. Houd beide richtingen in het ticket, anders herhaalt de volgende lezer de test die niet kan mislukken.