Ping virker bare én vei: hvorfor Windows slipper serverens ekko

Klienten din pinger serveren, serveren kan ikke pinge klienten, og tunnelen frakter tydelig pakker i begge de utsagnene. Det som er forskjellig er ikke veien, men den første pakken i hver test: den ene er et svar på en strøm Windows allerede følger, den andre er en ny innkommende forespørsel som ingen regel har sluppet inn. Forskjellen forklarer de fleste rapportene om enveis ping og peker rett på regelen du må skrive. To tester i motsatte retninger skiller tilfellene på rundt et minutt.

To retninger, to forskjellige beslutninger

Når klienten sender ekko-forespørselen, ser Windows-brannmuren en utgående forbindelse den har bestemt seg for å tillate. Svaret kommer tilbake inne i denne etablerte strømmen, så motoren som følger tilstand slipper det inn uten å spørre noen innkommende regel for ICMP. Det er hva tilstandsbasert filtrering betyr i praksis, og regelen ingen skrev er ikke involvert. Klientens suksess sier derfor ingenting om den innkommende policyen.

Når serveren sender forespørselen først, passer ingen tilstand til den. Windows behandler pakken som en ny innkommende forbindelse og spør den innkommende policyen, som som standard ikke har noen bestemmelse for ekko-forespørsler fra vilkårlige kilder.

Klientens suksess beviste altså at utgående ICMP og returveien virker. Den prøvde aldri den innkommende beslutningen, og den naturlige konklusjonen, at brannmuren er i orden, er rimelig og feil. Derfor gjentar feilen seg i saker som allerede inneholder beviset.

Følg pakken til den forsvinner

Bekreft adressene før du endrer noe: bruk tunneladressen klienten faktisk har, og kontroller at serveren ruter dit og ikke til en LAN-adresse bak klienten. De to feilene ser identiske ut fra serverens ledetekst, fordi begge ender i en tidsavbrudd. Hvor pakken dør er det eneste faktum som avgjør hva som må endres.

Hvis forespørselen når tunnelgrensesnittet og ingenting går ut, er den lokale brannmuren den sannsynlige årsaken. Hvis den aldri når grensesnittet, er svaret lenger oppe: en rute på serveren, en utgående policy eller VPN-ens egen levering mellom likemenn.

Ta opp på klientens tunnelgrensesnitt mens serveren pinger. Å se forespørselen komme uten et svar ved siden av er beviset som rettferdiggjør å skrive en Windows-regel. Å se ingenting sender deg lenger oppe, og en regel lagt til i den tilstanden gjør bare maskinen mer ettergivende for en pakke som aldri kom. I begge tilfeller koster opptaket mindre enn gjettingen det erstatter.

Begrens én regel i stedet for å åpne ICMP

Identifiser adapteren og dens nåværende kategori før du skriver noe, fordi begge vises i omfanget du er i ferd med å sette. Det aliaset er Windows-grensesnittnavnet, som ikke nødvendigvis er navnet på VPN-profilen du importerte. Kommandoene nedenfor viser hva som finnes, og forhåndsviser deretter en begrenset regel uten å bruke den.

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 er ekko-forespørselen, den eneste meldingen serveren trenger å få besvart. Begrens den til serverens tunneladresse og til tunnelgrensesnittet, og la profilen være slik adapteren faktisk er. Å gi et nettverk nytt navn for å passe et eksempel er en egen endring med egne konsekvenser.

Det regelen ikke dekker

IPv6-ekko er en annen protokoll med en annen meldingstype, så en ICMPv4-regel sier ingenting om den, og en tunnel som bærer begge familiene trenger sin egen regel for den andre. Denne regelen åpner heller ikke noe annet: RDP, fildeling og alle andre tjenester avhenger fortsatt av sin egen policy. Det er hele poenget med å begrense én smal regel i stedet for å aktivere en bred ICMP-tillatelse. Den brede tillatelsen er den enkle løsningen og den som varer lengst, fordi ingen legger merke til den etterpå.

På en administrert enhet kan regelen bli erstattet ved neste policyoppdatering, så policyeieren må gjøre den tilsvarende endringen og ikke en lokal administrator. Skriv hensikten i saken sammen med kommandoen, fordi en oppdatering vil slette kommandoen og la kravet stå urørt. De to er ikke samme artefakt, og bare én av dem overlever.

Les resultatet i riktig retning

Når regelen gjelder, ping fra serveren og bekreft at et svar når klienten, ping deretter fra en kilde som fortsatt skal være utelukket og bekreft at det ikke gjør det. Gjenta tilgjengelighetstesten på den andre adressefamilien hvis tunnelen bærer en.

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

Å skrive ut regelen som trådte i kraft er nyttigere enn å stole på kommandoen som lagde den, fordi en forhåndsvisning og en anvendt regel er forskjellige tilstander. Hvis adressefilteret viser kilden du mente, og den utelukkede kilden fortsatt får tidsavbrudd, gjør regelen nøyaktig det omfanget sier. En vellykket ping fra klienten ville aldri ha vist det, og derfor hører retningen til hver test hjemme i registret ved siden av resultatet. Behold begge retningene i saken, ellers vil neste leser gjenta testen som ikke kan feile.