Ping radi samo u jednom smjeru: zašto Windows odbacuje eho servera

Tvoj klijent pinga server, server ne može pingati klijent, a tunel očito prenosi pakete u obje te tvrdnje. Razlika nije u putu nego u prvom paketu svakog testa: jedan je odgovor na tok koji Windows već prati, drugi je novi dolazni zahtjev koji nijedno pravilo nije propustilo. Ta razlika objašnjava većinu izvještaja o jednostranom pingu i pokazuje pravo na pravilo koje moraš napisati. Dva testa u suprotnim smjerovima razdvajaju slučajeve za otprilike minutu.

Dva smjera, dvije različite odluke

Kad klijent pošalje zahtjev za eho, Windows zaštitni zid vidi odlaznu vezu koju je odlučio dopustiti. Odgovor se vraća unutar tog uspostavljenog toka, pa ga mehanizam koji prati stanje propušta bez provjere ikakvog dolaznog pravila za ICMP. To znači filtriranje sa stanjem u praksi, a pravilo koje niko nije napisao nije uključeno. Zato uspjeh klijenta ne govori ništa o dolaznoj politici.

Kad server pošalje zahtjev prvi, nijedno stanje mu ne odgovara. Windows tretira paket kao novu dolaznu vezu i pita dolaznu politiku, koja po zadanom ne predviđa ništa za zahtjeve za eho iz proizvoljnih izvora.

Dakle, uspjeh klijenta dokazao je da odlazni ICMP i povratni put rade. On nikad nije provjerio dolaznu odluku, a prirodan zaključak da je zaštitni zid ispravan razuman je i pogrešan. Zato se greška ponavlja u tiketima koji već sadrže dokaz.

Prati paket dok ne nestane

Potvrdi adrese prije nego što bilo šta promijeniš: koristi adresu tunela koju klijent stvarno ima i provjeri da server usmjerava na nju, a ne na LAN adresu iza klijenta. Dva kvara izgledaju isto s upita servera, jer oba završavaju istekom vremena. Gdje paket umre jedina je činjenica koja odlučuje šta promijeniti.

Ako zahtjev stigne do interfejsa tunela i ništa ne izađe, vjerovatan razlog je lokalni zaštitni zid. Ako nikad ne stigne do interfejsa, odgovor je uzvodno: ruta na serveru, odlazna politika ili vlastita isporuka između peerova VPN-a.

Snimaj na interfejsu tunela klijenta dok server pinga. Vidjeti zahtjev kako stiže bez odgovora pored sebe dokaz je koji opravdava pisanje Windows pravila. Ako ne vidiš ništa, to te šalje uzvodno, a pravilo dodano u tom stanju samo čini mašinu propusnijom za paket koji nikad nije stigao. U oba slučaja snimanje košta manje od nagađanja koje zamjenjuje.

Ograniči jedno pravilo umjesto otvaranja ICMP-a

Identifikuj adapter i njegovu trenutnu kategoriju prije nego što bilo šta napišeš, jer se oboje pojavljuje u opsegu koji ćeš postaviti. Taj alias je ime Windows interfejsa, koje nije nužno ime VPN profila koji si uvezao. Komande ispod popisuju šta postoji, a zatim prikazuju ograničeno pravilo bez primjene.

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 tip 8 je zahtjev za eho, jedina poruka na koju server treba odgovoriti. Ograniči ga na adresu tunela servera i na interfejs tunela, i ostavi profil onakvim kakav adapter zaista jeste. Preimenovanje mreže da bi se uklopila u primjer zasebna je promjena sa vlastitim posljedicama.

Šta pravilo ne pokriva

IPv6 eho je drugi protokol s drugim tipom poruke, pa ICMPv4 pravilo o njemu ne govori ništa, a tunel koji nosi obje familije treba vlastito pravilo za drugu. Ovo pravilo ne otvara ništa drugo: RDP, dijeljenje datoteka i svaka druga usluga i dalje zavise od vlastite politike. U tome je cijela poanta ograničavanja jednog uskog pravila umjesto uključivanja širokog ICMP dopuštenja. Široko dopuštenje je lako rješenje i ono koje najduže preživi, jer ga poslije niko ne primijeti.

Na upravljanom uređaju pravilo može biti zamijenjeno pri sljedećem osvježavanju politike, pa vlasnik politike mora napraviti ekvivalentnu promjenu, a ne lokalni administrator. Upiši namjeru u tiket kao i komandu, jer će osvježavanje izbrisati komandu i ostaviti zahtjev netaknutim. To nisu isti artefakt i samo jedan od njih preživi.

Čitaj rezultat u pravom smjeru

Nakon što pravilo stupi na snagu, pingaj sa servera i potvrdi da odgovor stiže do klijenta, zatim pingaj s izvora koji i dalje treba biti isključen i potvrdi da ne stiže. Ponovi test dostupnosti na drugoj familiji adresa ako je tunel nosi.

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

Ispis pravila koje je stupilo na snagu korisniji je od povjerenja u komandu koja ga je stvorila, jer su pregled i primijenjeno pravilo različita stanja. Ako filter adresa pokazuje izvor koji si namjeravao, a isključeni izvor i dalje isteče, pravilo radi tačno ono što njegov opseg kaže. Uspješan ping pokrenut s klijenta to nikad ne bi pokazao, zato smjer svakog testa pripada u zapis pored njegovog rezultata. Zadrži oba smjera u tiketu, inače će sljedeći čitatelj ponoviti test koji ne može propasti.