A ping csak egy irányban működik: miért dobja el a Windows a kiszolgáló visszhangját

Az ügyfél pingel a kiszolgálónak, a kiszolgáló nem tud pingelni az ügyfélnek, és az alagút mindkét állításban szemlátomást csomagokat továbbít. Nem az útvonal más, hanem az egyes tesztek első csomagja: az egyik válasz egy olyan folyamra, amelyet a Windows már követ, a másik új bejövő kérés, amelyet egyetlen szabály sem engedett be. Ez a különbség magyarázza az egyirányú pingről szóló jelentések többségét, és egyenesen arra a szabályra mutat, amelyet meg kell írnia. Két ellentétes irányú teszt körülbelül egy perc alatt elválasztja az eseteket.

Két irány, két különböző döntés

Amikor az ügyfél elküldi a visszhangkérést, a Windows tűzfala egy kimenő kapcsolatot lát, amelyet engedélyezni döntött. A válasz ezen a már létrejött folyamon belül érkezik vissza, ezért az állapotkövető motor anélkül engedi be, hogy bármilyen bejövő ICMP-szabályt megkérdezne. Ez az állapotalapú szűrés jelentése a gyakorlatban, és a szabály, amelyet senki nem írt meg, nem játszik benne szerepet. Az ügyfél sikere tehát semmit nem mond a bejövő házirendről.

Amikor a kiszolgáló küldi el először a kérést, egyetlen állapot sem illeszkedik rá. A Windows új bejövő kapcsolatként kezeli a csomagot, és megkérdezi a bejövő házirendet, amely alapértelmezés szerint semmit nem ír elő a tetszőleges forrásból érkező visszhangkérésekre.

Az ügyfél sikere tehát bebizonyította, hogy a kimenő ICMP és a visszaút működik. A bejövő döntést viszont soha nem próbálta ki, és a kézenfekvő következtetés, hogy a tűzfal rendben van, ésszerű és téves. Ezért ismétlődik a hiba azokban a jegyekben, amelyek már tartalmazzák a bizonyítékot.

Kövesse a csomagot, amíg el nem tűnik

Erősítse meg a címeket, mielőtt bármit módosítana: használja azt az alagútcímet, amellyel az ügyfél valóban rendelkezik, és ellenőrizze, hogy a kiszolgáló oda irányít, és nem az ügyfél mögötti LAN-címre. A két hiba azonosnak látszik a kiszolgáló parancssorából, mert mindkettő időtúllépéssel végződik. Az, hogy hol hal meg a csomag, az egyetlen tény, amely eldönti, mit kell módosítani.

Ha a kérés eléri az alagút interfészét, és semmi nem lép ki, a helyi tűzfal a valószínű ok. Ha soha nem éri el az interfészt, a válasz feljebb van: egy útvonal a kiszolgálón, egy kimenő házirend vagy a VPN saját társak közötti kézbesítése.

Rögzítsen az ügyfél alagút-interfészén, miközben a kiszolgáló pingel. A kérés megérkezését válasz nélkül látni az a bizonyíték, amely igazolja egy Windows-szabály megírását. Ha semmit nem lát, az feljebb küldi, és az ebben az állapotban hozzáadott szabály csak engedékenyebbé teszi a gépet egy olyan csomag iránt, amely soha nem érkezett meg. Mindkét esetben a rögzítés kevesebbe kerül, mint a helyébe lépő találgatás.

Szűkítsen egy szabályt ahelyett, hogy megnyitná az ICMP-t

Azonosítsa az adaptert és annak jelenlegi kategóriáját, mielőtt bármit írna, mert mindkettő megjelenik abban a hatókörben, amelyet hamarosan beállít. Ez az alias a Windows interfészének neve, amely nem feltétlenül az importált VPN-profil neve. Az alábbi parancsok felsorolják, mi létezik, majd előnézetben megmutatnak egy szűkített szabályt anélkül, hogy alkalmaznák.

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

Az ICMPv4 8-as típusa a visszhangkérés, az egyetlen üzenet, amelyre a kiszolgálónak válaszolnia kell. Szűkítse a kiszolgáló alagútcímére és az alagút interfészére, és hagyja a profilt olyannak, amilyen az adapter valójában. Egy hálózat átnevezése, hogy illeszkedjen egy példához, külön változtatás a maga következményeivel.

Amit a szabály nem fed le

Az IPv6 visszhang más protokoll, más üzenettípussal, ezért az ICMPv4 szabály semmit nem mond róla, és a mindkét családot szállító alagútnak saját szabálya kell a másikhoz. Ez a szabály sem nyit meg semmi mást: az RDP, a fájlmegosztás és minden más szolgáltatás továbbra is a saját házirendjétől függ. Ez a lényege annak, hogy egyetlen szűk szabályt szűkítsünk ahelyett, hogy széles ICMP-engedélyt kapcsolnánk be. A széles engedély a könnyű megoldás, és az, amelyik a legtovább marad meg, mert utána senki nem veszi észre.

Kezelt eszközön a szabály a következő házirend-frissítéskor lecserélődhet, ezért az egyenértékű változtatást a házirend tulajdonosának kell megtennie, nem egy helyi rendszergazdának. Írja be a szándékot is a jegybe a parancs mellé, mert a frissítés törli a parancsot, a követelményt pedig érintetlenül hagyja. A kettő nem ugyanaz az artefaktum, és csak az egyikük marad fenn.

A megfelelő irányból olvassa le az eredményt

Miután a szabály érvénybe lép, pingeljen a kiszolgálóról, és erősítse meg, hogy a válasz eléri az ügyfelet, majd pingeljen egy olyan forrásból, amelyet még ki kell zárni, és erősítse meg, hogy nem éri el. Ismételje meg az elérhetőségi tesztet a másik címcsaládon, ha az alagút szállít ilyet.

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

Az érvénybe lépett szabály kinyomtatása hasznosabb, mint megbízni az őt létrehozó parancsban, mert az előnézet és az alkalmazott szabály különböző állapotok. Ha a címek szűrője a szándékolt forrást mutatja, a kizárt forrás pedig továbbra is időtúllépéssel végződik, a szabály pontosan azt teszi, amit a hatóköre mond. Az ügyfélből indított sikeres ping ezt soha nem bizonyította volna, ezért tartozik minden teszt iránya a nyilvántartásba az eredménye mellé. Tartsa meg mindkét irányt a jegyben, különben a következő olvasó megismétli azt a tesztet, amely nem tud meghiúsulni.