Ping funguje jen jedním směrem: proč Windows zahazuje ozvěnu serveru

Váš klient pinguje server, server nemůže pingovat klienta, a tunel přitom v obou těch tvrzeních zjevně přenáší pakety. Nelíší se cesta, ale první paket každého testu: jeden je odpověď na tok, který Windows už sleduje, druhý je nový příchozí požadavek, který nepustilo žádné pravidlo. Ten rozdíl vysvětluje většinu hlášení o jednosměrném pingu a ukazuje přímo na pravidlo, které musíte napsat. Dva testy v opačných směrech oddělí případy zhruba za minutu.

Dva směry, dvě různá rozhodnutí

Když klient odešle požadavek na ozvěnu, brána Windows vidí odchozí spojení, které se rozhodla povolit. Odpověď se vrací uvnitř tohoto navázaného toku, takže stavový engine ji pustí, aniž by se ptal nějakého příchozího pravidla pro ICMP. To je v praxi význam stavového filtrování a pravidlo, které nikdo nenapsal, do toho nevstupuje. Úspěch klienta tedy o příchozí politice neříká nic.

Když požadavek odešle jako první server, neodpovídá mu žádný stav. Windows považuje paket za nové příchozí spojení a ptá se příchozí politiky, která ve výchozím stavu s požadavky na ozvěnu z libovolných zdrojů vůbec nepočítá.

Úspěch klienta tedy dokázal, že odchozí ICMP a zpáteční cesta fungují. Příchozí rozhodnutí ale nikdy neprověřil, a přirozený závěr, že brána je v pořádku, je rozumný a chybný. Proto se ta chyba opakuje v tikketech, které už důkaz obsahují.

Sledujte paket, dokud nezmizí

Než cokoli změníte, potvrďte adresy: použijte adresu tunelu, kterou klient skutečně má, a ověřte, že server směruje na ni, a ne na adresu LAN za klientem. Obě selhání vypadají z příkazového řádku serveru stejně, protože obě končí vypršením časového limitu. Kde paket umírá, je jediný fakt, který rozhoduje o tom, co změnit.

Pokud požadavek dorazí na rozhraní tunelu a nic nevychází, pravděpodobnou příčinou je místní brána. Pokud na rozhraní nikdy nedorazí, odpověď je výš: trasa na serveru, odchozí politika nebo vlastní doručení mezi peery VPN.

Zachytávejte na rozhraní tunelu klienta, zatímco server pinguje. Vidět požadavek přicházet bez odpovědi vedle je důkaz, který ospravedlňuje napsání pravidla Windows. Když nevidíte nic, posílá vás to výš, a pravidlo přidané v takovém stavu jen udělá stroj vstřícnějším pro paket, který nikdy nedorazil. V obou případech zachytávání stojí méně než dohady, které nahrazuje.

Omezte jedno pravidlo místo otevření ICMP

Než cokoli napíšete, určete adaptér a jeho aktuální kategorii, protože obojí se objeví v rozsahu, který se chystáte nastavit. Ten alias je název rozhraní Windows, který nemusí být názvem profilu VPN, který jste importovali. Příkazy níže vypíšou, co existuje, a pak zobrazí náhled omezeného pravidla, aniž by ho použily.

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 je požadavek na ozvěnu, jediná zpráva, na kterou server potřebuje odpovědět. Omezte ho na adresu tunelu serveru a na rozhraní tunelu a nechte profil takový, jaký adaptér skutečně je. Přejmenovat síť, aby odpovídala příkladu, je samostatná změna s vlastními důsledky.

Co pravidlo nepokrývá

Ozvěna IPv6 je jiný protokol s jiným typem zprávy, takže pravidlo ICMPv4 o ní neříká nic, a tunel přenášející obě rodiny potřebuje vlastní pravidlo pro tu druhou. Toto pravidlo také nic jiného neotevírá: RDP, sdílení souborů a každá další služba nadále závisí na své vlastní politice. V tom je celý smysl omezení jednoho úzkého pravidla místo povolení širokého přístupu k ICMP. Široké povolení je snadná oprava a ta, která vydrží nejdéle, protože si ho pak nikdo nevšimne.

Na spravovaném zařízení může být pravidlo nahrazeno při příští obnově politiky, takže ekvivalentní změnu musí provést vlastník politiky, ne místní správce. Zapište záměr do tiketu spolu s příkazem, protože obnova příkaz smaže a požadavek zůstane nedotčen. To nejsou stejný artefakt a přežije jen jeden z nich.

Čtěte výsledek správným směrem

Po použití pravidla pingujte ze serveru a potvrďte, že odpověď dorazí ke klientovi, pak pingujte ze zdroje, který má zůstat vyloučen, a potvrďte, že nedorazí. Opakujte test dostupnosti na druhé rodině adres, pokud ji tunel přenáší.

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

Vypsat pravidlo, které vstoupilo v platnost, je užitečnější než věřit příkazu, který ho vytvořil, protože náhled a použité pravidlo jsou různé stavy. Pokud filtr adres ukazuje zamýšlený zdroj a vyloučený zdroj stále vyprší, pravidlo dělá přesně to, co říká jeho rozsah. Úspěšný ping z klienta by to nikdy neprokázal, a proto směr každého testu patří do záznamu vedle jeho výsledku. Uchovejte v tiketu oba směry, jinak další čtenář zopakuje test, který nemůže selhat.