Ping fungerar bara åt ett håll: varför Windows släpper serverns eko

Din klient pingar servern, servern kan inte pinga klienten, och tunneln transporterar tydligt paket i båda de påståendena. Det som skiljer är inte vägen utan det första paketet i varje test: det ena är ett svar på ett flöde som Windows redan följer, det andra en ny inkommande begäran som ingen regel har släppt in. Den skillnaden förklarar de flesta rapporterna om enkelriktad ping och pekar rakt på regeln du måste skriva. Två test i motsatta riktningar skiljer fallen åt på ungefär en minut.

Två riktningar, två olika beslut

När klienten skickar ekobegäran ser Windows-brandväggen en utgående anslutning som den har beslutat att tillåta. Svaret kommer tillbaka inne i det etablerade flödet, så motorn som följer tillstånd släpper in det utan att fråga någon inkommande regel för ICMP. Det är vad tillståndsbaserad filtrering betyder i praktiken, och regeln som ingen skrev är inte inblandad. Klientens framgång säger därför ingenting om den inkommande policyn.

När servern skickar begäran först passar inget tillstånd den. Windows behandlar paketet som en ny inkommande anslutning och frågar den inkommande policyn, som som standard inte har någon bestämmelse för ekobegäranden från godtyckliga källor.

Klientens framgång bevisade alltså att utgående ICMP och returvägen fungerar. Den prövade aldrig det inkommande beslutet, och den naturliga slutsatsen, att brandväggen är i ordning, är rimlig och fel. Därför upprepas felet i ärenden som redan innehåller beviset.

Följ paketet tills det försvinner

Bekräfta adresserna innan du ändrar något: använd tunneladressen som klienten faktiskt har, och kontrollera att servern dirigerar dit och inte till en LAN-adress bakom klienten. De två felen ser identiska ut från serverns kommandotolk, eftersom båda slutar i en tidsgräns. Var paketet dör är det enda faktum som avgör vad som ska ändras.

Om begäran når tunnelgränssnittet och ingenting går ut är den lokala brandväggen den troliga orsaken. Om den aldrig når gränssnittet finns svaret högre upp: en rutt på servern, en utgående policy eller VPN:ens egen leverans mellan jämlikar.

Fånga på klientens tunnelgränssnitt medan servern pingar. Att se begäran anlända utan ett svar bredvid är beviset som berättigar att skriva en Windows-regel. Att inte se något skickar dig högre upp, och en regel som läggs till i det läget gör bara maskinen mer efterlåtande för ett paket som aldrig kom. I båda fallen kostar fångsten mindre än gissningarna den ersätter.

Begränsa en regel i stället för att öppna ICMP

Identifiera adaptern och dess nuvarande kategori innan du skriver något, eftersom båda förekommer i det omfång du ska ange. Det aliaset är Windows gränssnittsnamn, som inte nödvändigtvis är namnet på den VPN-profil du importerade. Kommandona nedan listar vad som finns och förhandsgranskar sedan en begränsad regel utan att tillämpa 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 typ 8 är ekobegäran, det enda meddelandet som servern behöver få svar på. Begränsa den till serverns tunneladress och till tunnelgränssnittet, och låt profilen vara som adaptern faktiskt är. Att byta namn på ett nätverk för att passa ett exempel är en separat ändring med egna konsekvenser.

Det regeln inte täcker

IPv6-eko är ett annat protokoll med en annan meddelandetyp, så en ICMPv4-regel säger ingenting om det, och en tunnel som bär båda familjerna behöver sin egen regel för den andra. Den här regeln öppnar inte heller något annat: RDP, fildelning och alla andra tjänster är fortfarande beroende av sin egen policy. Det är hela poängen med att begränsa en smal regel i stället för att aktivera ett brett ICMP-tillstånd. Det breda tillståndet är den enkla lösningen och den som överlever längst, eftersom ingen lägger märke till den efteråt.

På en hanterad enhet kan regeln ersättas vid nästa principuppdatering, så principägaren måste göra motsvarande ändring och inte en lokal administratör. Skriv avsikten i ärendet tillsammans med kommandot, eftersom en uppdatering raderar kommandot och lämnar kravet orört. De två är inte samma artefakt, och bara en av dem överlever.

Läs resultatet i rätt riktning

När regeln gäller, pinga från servern och bekräfta att ett svar når klienten, pinga sedan från en källa som fortfarande ska vara utesluten och bekräfta att det inte gör det. Upprepa nåbarhetstestet på den andra adressfamiljen om tunneln bär en sådan.

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

Att skriva ut regeln som trädde i kraft är mer användbart än att lita på kommandot som skapade den, eftersom en förhandsgranskning och en tillämpad regel är olika tillstånd. Om adressfiltret visar den avsedda källan och den uteslutna källan fortfarande får tidsgräns, gör regeln exakt det dess omfång säger. En lyckad ping från klienten hade aldrig visat det, och därför hör riktningen för varje test hemma i registret bredvid resultatet. Behåll båda riktningarna i ärendet, annars upprepar nästa läsare testet som inte kan misslyckas.