Ping funguje len jedným smerom: prečo Windows zahadzuje ozvu servera

Váš klient pinguje server, server nemôže pingovať klienta, a tunel pritom v oboch tých tvrdeniach zjavne prenáša pakety. Nelíši sa cesta, ale prvý paket každého testu: jeden je odpoveď na tok, ktorý Windows už sleduje, druhý je nová prichádzajúca požiadavka, ktorú nepustilo žiadne pravidlo. Ten rozdiel vysvetľuje väčšinu hlásení o jednosmernom pingu a ukazuje priamo na pravidlo, ktoré musíte napísať. Dva testy v opačných smeroch oddelia prípady zhruba za minútu.

Dva smery, dve rôzne rozhodnutia

Keď klient odošle požiadavku na ozvu, brána Windows vidí odchádzajúce spojenie, ktoré sa rozhodla povoliť. Odpoveď sa vracia vnútri tohto nadviazaného toku, takže stavový engine ju pustí bez toho, aby sa pýtal nejakého prichádzajúceho pravidla pre ICMP. To je v praxi význam stavového filtrovania a pravidlo, ktoré nikto nenapísal, do toho nevstupuje. Úspech klienta teda o prichádzajúcej politike nehovorí nič.

Keď požiadavku odošle ako prvý server, nezodpovedá jej žiadny stav. Windows považuje paket za nové prichádzajúce spojenie a pýta sa prichádzajúcej politiky, ktorá v predvolenom stave s požiadavkami na ozvu z ľubovoľných zdrojov vôbec nepočíta.

Úspech klienta teda dokázal, že odchádzajúci ICMP a spiatočná cesta fungujú. Prichádzajúce rozhodnutie však nikdy nepreveril, a prirodzený záver, že brána je v poriadku, je rozumný a chybný. Preto sa tá chyba opakuje v tiketoch, ktoré už dôkaz obsahujú.

Sledujte paket, kým nezmizne

Než čokoľvek zmeníte, potvrďte adresy: použite adresu tunela, ktorú klient skutočne má, a overte, že server smeruje na ňu a nie na adresu LAN za klientom. Obe zlyhania vyzerajú z príkazového riadka servera rovnako, pretože obe končia vypršaním časového limitu. Kde paket umiera, je jediný fakt, ktorý rozhoduje o tom, čo zmeniť.

Ak požiadavka dorazí na rozhranie tunela a nič nevychádza, pravdepodobnou príčinou je miestna brána. Ak na rozhranie nikdy nedorazí, odpoveď je vyššie: trasa na serveri, odchádzajúca politika alebo vlastné doručovanie medzi peerami VPN.

Zachytávajte na rozhraní tunela klienta, kým server pinguje. Vidieť požiadavku prichádzať bez odpovede vedľa je dôkaz, ktorý ospravedlňuje napísanie pravidla Windows. Keď nevidíte nič, posiela vás to vyššie, a pravidlo pridané v takom stave len urobí stroj ústretovejším pre paket, ktorý nikdy nedorazil. V oboch prípadoch zachytávanie stojí menej ako dohady, ktoré nahrádza.

Obmedzte jedno pravidlo namiesto otvorenia ICMP

Než čokoľvek napíšete, určte adaptér a jeho aktuálnu kategóriu, pretože oboje sa objaví v rozsahu, ktorý sa chystáte nastaviť. Ten alias je názov rozhrania Windows, ktorý nemusí byť názvom profilu VPN, ktorý ste importovali. Príkazy nižšie vypíšu, čo existuje, a potom zobrazia náhľad obmedzeného pravidla bez toho, aby ho použili.

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žiadavka na ozvu, jediná správa, na ktorú server potrebuje odpoveď. Obmedzte ho na adresu tunela servera a na rozhranie tunela a nechajte profil taký, aký adaptér skutočne je. Premenovať sieť, aby zodpovedala príkladu, je samostatná zmena s vlastnými dôsledkami.

Čo pravidlo nepokrýva

Ozva IPv6 je iný protokol s iným typom správy, takže pravidlo ICMPv4 o nej nehovorí nič, a tunel prenášajúci obe rodiny potrebuje vlastné pravidlo pre tú druhú. Toto pravidlo tiež nič iné neotvára: RDP, zdieľanie súborov a každá ďalšia služba naďalej závisia od svojej vlastnej politiky. V tom je celý zmysel obmedzenia jedného úzkeho pravidla namiesto povolenia širokého prístupu k ICMP. Široké povolenie je jednoduchá oprava a tá, ktorá vydrží najdlhšie, pretože si ho potom nikto nevšimne.

Na spravovanom zariadení môže byť pravidlo nahradené pri najbližšej obnove politiky, takže ekvivalentnú zmenu musí vykonať vlastník politiky, nie miestny správca. Zapíšte zámer do tiketu spolu s príkazom, pretože obnova príkaz zmaže a požiadavku nechá nedotknutú. To nie sú rovnaké artefakty a prežije len jeden z nich.

Čítajte výsledok správnym smerom

Po použití pravidla pingujte zo servera a potvrďte, že odpoveď dorazí ku klientovi, potom pingujte zo zdroja, ktorý má zostať vylúčený, a potvrďte, že nedorazí. Zopakujte test dostupnosti na druhej rodine adries, ak ju tunel prenáša.

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

Vypísať pravidlo, ktoré vstúpilo do platnosti, je užitočnejšie než veriť príkazu, ktorý ho vytvoril, pretože náhľad a použité pravidlo sú rôzne stavy. Ak filter adries ukazuje zamýšľaný zdroj a vylúčený zdroj stále vyprší, pravidlo robí presne to, čo hovorí jeho rozsah. Úspešný ping z klienta by to nikdy nepreukázal, a preto smer každého testu patrí do záznamu vedľa jeho výsledku. Uchovajte v tikete oba smery, inak ďalší čitateľ zopakuje test, ktorý nemôže zlyhať.