Ping działa tylko w jedną stronę: dlaczego Windows odrzuca echo serwera

Twój klient pinguje serwer, serwer nie może pingować klienta, a tunel w obu tych zdaniach najwyraźniej przenosi pakiety. Różni się nie ścieżka, lecz pierwszy pakiet każdego testu: jeden jest odpowiedzią na przepływ, który Windows już śledzi, drugi to nowe żądanie przychodzące, którego nie wpuściła żadna reguła. Ta różnica wyjaśnia większość zgłoszeń o jednokierunkowym pingu i wskazuje wprost regułę, którą trzeba napisać. Dwa testy w przeciwnych kierunkach rozdzielają przypadki w około minutę.

Dwa kierunki, dwie różne decyzje

Gdy klient wysyła żądanie echa, zapora Windows widzi połączenie wychodzące, które postanowiła dopuścić. Odpowiedź wraca wewnątrz tego ustalonego przepływu, więc mechanizm śledzący stan wpuszcza ją bez pytania o jakąkolwiek regułę przychodzącą dla ICMP. To właśnie oznacza filtrowanie stanowe w praktyce, a reguła, której nikt nie napisał, nie bierze w tym udziału. Sukces klienta nie mówi więc nic o polityce przychodzącej.

Gdy serwer wysyła żądanie pierwszy, nie pasuje do niego żaden stan. Windows traktuje pakiet jako nowe połączenie przychodzące i pyta politykę przychodzącą, która domyślnie niczego nie przewiduje dla żądań echa z dowolnych źródeł.

Sukces klienta dowiódł więc, że wychodzący ICMP i droga powrotna działają. Nigdy nie sprawdził decyzji przychodzącej, a naturalny wniosek, że zapora jest w porządku, jest rozsądny i błędny. Dlatego błąd powtarza się w zgłoszeniach, które już zawierają dowód.

Śledź pakiet, aż zniknie

Potwierdź adresy, zanim cokolwiek zmienisz: użyj adresu tunelu, który klient naprawdę ma, i sprawdź, czy serwer kieruje do niego, a nie do adresu LAN za klientem. Oba objawy wyglądają identycznie z wiersza poleceń serwera, bo oba kończą się przekroczeniem czasu. To, gdzie ginie pakiet, jest jedynym faktem, który decyduje, co zmienić.

Jeśli żądanie dociera do interfejsu tunelu i nic nie wychodzi, prawdopodobną przyczyną jest miejscowa zapora. Jeśli nigdy nie dociera do interfejsu, odpowiedź jest wyżej: trasa na serwerze, polityka wychodząca albo własne dostarczanie między równorzędnymi węzłami VPN.

Przechwytuj na interfejsie tunelu klienta, gdy serwer pinguje. Widok żądania przychodzącego bez odpowiedzi obok jest dowodem uzasadniającym napisanie reguły Windows. Brak jakiegokolwiek widoku kieruje wyżej, a reguła dodana w tym stanie tylko czyni maszynę bardziej pobłażliwą dla pakietu, który nigdy nie dotarł. W obu przypadkach przechwytywanie kosztuje mniej niż domysły, które zastępuje.

Ogranicz jedną regułę zamiast otwierać ICMP

Zidentyfikuj kartę i jej bieżącą kategorię, zanim cokolwiek napiszesz, bo obie pojawiają się w zakresie, który zaraz ustawisz. Ten alias to nazwa interfejsu Windows, która nie musi być nazwą zaimportowanego profilu VPN. Polecenia poniżej wyliczają, co istnieje, a potem pokazują podgląd ograniczonej reguły bez jej stosowania.

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 to żądanie echa, jedyna wiadomość, na którą serwer musi otrzymać odpowiedź. Ogranicz je do adresu tunelu serwera i do interfejsu tunelu, i zostaw profil taki, jaki karta naprawdę jest. Zmiana nazwy sieci, aby pasowała do przykładu, to osobna zmiana z własnymi konsekwencjami.

Czego reguła nie obejmuje

Echo IPv6 to inny protokół z innym typem wiadomości, więc reguła ICMPv4 nic o nim nie mówi, a tunel przenoszący obie rodziny potrzebuje własnej reguły dla drugiej. Ta reguła niczego innego nie otwiera: RDP, udostępnianie plików i każda inna usługa nadal zależą od własnej polityki. W tym cały sens ograniczania jednej wąskiej reguły zamiast włączania szerokiego zezwolenia ICMP. Szerokie zezwolenie jest łatwą poprawką i tą, która przetrwa najdłużej, bo potem nikt go nie zauważa.

Na urządzeniu zarządzanym reguła może zostać zastąpiona przy następnym odświeżeniu polityki, więc równoważnej zmiany musi dokonać właściciel polityki, a nie lokalny administrator. Zapisz intencję w zgłoszeniu obok polecenia, bo odświeżenie usunie polecenie i pozostawi wymóg nietknięty. To nie ten sam artefakt i przeżywa tylko jeden z nich.

Czytaj wynik we właściwym kierunku

Po zastosowaniu reguły pinguj z serwera i potwierdź, że odpowiedź dociera do klienta, następnie pinguj ze źródła, które nadal ma być wyłączone, i potwierdź, że nie dociera. Powtórz test osiągalności na drugiej rodzinie adresów, jeśli tunel ją przenosi.

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

Wydruk reguły, która weszła w życie, jest użyteczniejszy niż zaufanie poleceniu, które ją utworzyło, bo podgląd i zastosowana reguła to różne stany. Jeśli filtr adresów pokazuje zamierzone źródło, a wyłączone źródło nadal kończy się przekroczeniem czasu, reguła robi dokładnie to, co mówi jej zakres. Udany ping rozpoczęty z klienta nigdy by tego nie pokazał, dlatego kierunek każdego testu należy do zapisu obok jego wyniku. Zachowaj oba kierunki w zgłoszeniu, inaczej następny czytelnik powtórzy test, który nie może się nie udać.