Ping virker kun den ene vej: hvorfor Windows dropper serverens ekko

Din klient pinger serveren, serveren kan ikke pinge klienten, og tunnelen bærer tydeligvis pakker i begge de udsagn. Det, der er forskelligt, er ikke vejen men den første pakke i hver test: den ene er et svar på en strøm, som Windows allerede følger, den anden er en ny indgående forespørgsel, som ingen regel har lukket ind. Forskellen forklarer de fleste rapporter om envejs-ping og peger direkte på den regel, du skal skrive. To tests i modsatte retninger skiller tilfældene på cirka et minut.

To retninger, to forskellige beslutninger

Når klienten sender ekko-forespørgslen, ser Windows-firewallen en udgående forbindelse, som den har besluttet at tillade. Svaret kommer tilbage inde i denne etablerede strøm, så den tilstandsbaserede motor lukker det ind uden at spørge nogen indgående regel for ICMP. Det er, hvad tilstandsbaseret filtrering betyder i praksis, og den regel, som ingen skrev, er ikke involveret. Klientens succes siger derfor intet om den indgående politik.

Når serveren sender forespørgslen først, matcher ingen tilstand den. Windows behandler pakken som en ny indgående forbindelse og spørger den indgående politik, som som standard ikke har nogen bestemmelse for ekko-forespørgsler fra vilkårlige kilder.

Klientens succes beviste altså, at udgående ICMP og returvejen virker. Den prøvede aldrig den indgående beslutning, og den naturlige konklusion, at firewallen er i orden, er rimelig og forkert. Derfor gentager fejlen sig i sager, der allerede indeholder beviset.

Følg pakken, til den forsvinder

Bekræft adresserne, før du ændrer noget: brug den tunneladresse, klienten faktisk har, og kontrollér, at serveren ruter til den og ikke til en LAN-adresse bag klienten. De to fejl ser identiske ud fra serverens kommandoprompt, fordi begge ender i en timeout. Hvor pakken dør, er det eneste faktum, der afgør, hvad der skal ændres.

Hvis forespørgslen når tunnelinterfacet og intet forlader det, er den lokale firewall den sandsynlige grund. Hvis den aldrig når interfacet, er svaret opstrøms: en rute på serveren, en udgående politik eller VPN'ens egen levering mellem peers.

Optag på klientens tunnelinterface, mens serveren pinger. At se forespørgslen ankomme uden et svar ved siden af er det bevis, der berettiger at skrive en Windows-regel. At se ingenting sender dig opstrøms, og en regel tilføjet i den tilstand gør kun maskinen mere eftergivende for en pakke, der aldrig kom. I begge tilfælde koster optagelsen mindre end det gætværk, den erstatter.

Begræns én regel i stedet for at åbne ICMP

Identificér adapteren og dens nuværende kategori, før du skriver noget, fordi begge optræder i det omfang, du er ved at sætte. Det alias er Windows-interfacenavnet, som ikke nødvendigvis er navnet på den VPN-profil, du importerede. Kommandoerne nedenfor viser, hvad der findes, og forhåndsviser derefter en begrænset regel uden at anvende 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ørgslen, den eneste meddelelse, serveren skal have besvaret. Begræns den til serverens tunneladresse og til tunnelinterfacet, og lad profilen være, som adapteren faktisk er. At omdøbe et netværk for at passe til et eksempel er en særskilt ændring med egne konsekvenser.

Det dækker reglen ikke

IPv6-ekko er en anden protokol med en anden meddelelsestype, så en ICMPv4-regel siger intet om den, og en tunnel, der bærer begge familier, har brug for sin egen regel til den anden. Denne regel åbner heller ikke noget andet: RDP, fildeling og alle andre tjenester afhænger stadig af deres egen politik. Det er hele pointen i at begrænse én smal regel i stedet for at aktivere en bred ICMP-tilladelse. Den brede tilladelse er den nemme løsning og den, der holder længst, fordi ingen bemærker den bagefter.

På en administreret enhed kan reglen blive erstattet ved næste politikopdatering, så politikkens ejer skal foretage den tilsvarende ændring i stedet for en lokal administrator. Skriv hensigten i sagen sammen med kommandoen, fordi en opdatering vil slette kommandoen og lade kravet være intakt. De to er ikke samme artefakt, og kun én af dem overlever.

Læs resultatet i den rigtige retning

Når reglen er anvendt, ping fra serveren, og bekræft at et svar når klienten, og ping derefter fra en kilde, der stadig skal være udelukket, og bekræft at det ikke gør. Gentag tilgængelighedstesten på den anden adressefamilie, hvis tunnelen bærer en.

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

At printe den regel, der trådte i kraft, er mere nyttigt end at stole på kommandoen, der oprettede den, fordi en forhåndsvisning og en anvendt regel er forskellige tilstande. Hvis adressefilteret viser den kilde, du tilsigtede, og den udelukkede kilde stadig timer ud, gør reglen præcis det, dens omfang siger. Et vellykket ping fra klienten ville aldrig have demonstreret det, og derfor hører retningen af hver test i registret ved siden af resultatet. Behold begge retninger i sagen, ellers gentager den næste læser den test, der ikke kan fejle.