Ping veikia tik viena kryptimi: kodėl Windows atmeta serverio atgarsį

Jūsų klientas pingina serverį, serveris negali pinginti kliento, o tunelis abiejuose tuose teiginiuose akivaizdžiai perduoda paketus. Skiriasi ne kelias, o pirmasis kiekvieno bandymo paketas: vienas yra atsakymas į srautą, kurį Windows jau seka, kitas yra nauja įeinanti užklausa, kurios nepraleido nė viena taisyklė. Šis skirtumas paaiškina daugumą vienos krypties ping ataskaitų ir tiesiai nurodo taisyklę, kurią turite parašyti. Du bandymai priešingomis kryptimis atskiria atvejus per maždaug minutę.

Dvi kryptys, du skirtingi sprendimai

Kai klientas siunčia atgarsio užklausą, Windows užkarda mato išeinantį ryšį, kurį nusprendė leisti. Atsakymas grįžta šio jau nustatyto srauto viduje, todėl būseną sekantis mechanizmas jį praleidžia nesikreipdamas į jokią įeinančią ICMP taisyklę. Tai ir reiškia būsena pagrįstą filtravimą praktiškai, o taisyklė, kurios niekas neparašė, čia nedalyvauja. Todėl kliento sėkmė nieko nesako apie įeinančią politiką.

Kai serveris užklausą siunčia pirmas, jokia būsena jos neatitinka. Windows traktuoja paketą kaip naują įeinantį ryšį ir klausia įeinančios politikos, kuri pagal numatytuosius nustatymus nieko nenumato atgarsio užklausoms iš savavališkų šaltinių.

Taigi kliento sėkmė įrodė, kad išeinantis ICMP ir grįžimo kelias veikia. Jis niekada neišbandė įeinančio sprendimo, o natūrali išvada, kad užkarda tvarkinga, yra pagrįsta ir klaidinga. Štai kodėl klaida kartojasi bilietuose, kuriuose jau yra įrodymas.

Sekite paketą, kol jis išnyks

Prieš ką nors keisdami patvirtinkite adresus: naudokite tunelio adresą, kurį klientas iš tikrųjų turi, ir patikrinkite, ar serveris maršrutizuoja būtent į jį, o ne į LAN adresą už kliento. Abi nesėkmės iš serverio komandinės eilutės atrodo vienodai, nes abi baigiasi laukimo pabaiga. Kur paketas miršta, yra vienintelis faktas, lemiantis, ką keisti.

Jei užklausa pasiekia tunelio sąsają ir niekas neišeina, tikėtina priežastis yra vietinė užkarda. Jei ji sąsajos niekada nepasiekia, atsakymas yra aukščiau: maršrutas serveryje, išeinanti politika arba paties VPN tarpusavio mazgų pristatymas.

Fiksuokite kliento tunelio sąsajoje, kol serveris pingina. Matyti užklausą ateinant be šalia esančio atsakymo yra įrodymas, pateisinantis Windows taisyklės rašymą. Nematyti nieko nukreipia aukščiau, o toje būsenoje pridėta taisyklė tik daro mašiną paketesnę paketui, kuris niekada neatėjo. Abiem atvejais fiksavimas kainuoja mažiau nei spėlionės, kurias jis pakeičia.

Apribokite vieną taisyklę, o ne atverkite ICMP

Prieš ką nors rašydami nustatykite adapterį ir jo dabartinę kategoriją, nes abu pasirodo apimtyje, kurią ruošiatės nustatyti. Ta slapyvardė yra Windows sąsajos pavadinimas, kuris nebūtinai yra importuoto VPN profilio pavadinimas. Toliau pateikti komandai išvardija, kas egzistuoja, o tada rodo apribotos taisyklės peržiūrą jos nepritaikydami.

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 8 tipas yra atgarsio užklausa, vienintelis pranešimas, į kurį serveriui reikia atsakymo. Apribokite ją serverio tunelio adresu ir tunelio sąsaja, ir palikite profilį tokį, koks adapteris iš tikrųjų yra. Tinklo pervadinimas, kad jis atitiktų pavyzdį, yra atskiras pakeitimas su savo pasekmėmis.

Ko taisyklė neapima

IPv6 atgarsis yra kitas protokolas su kitu pranešimo tipu, todėl ICMPv4 taisyklė apie jį nieko nesako, o tuneliui, perduodančiam abi šeimas, reikia savo taisyklės kitai. Ši taisyklė taip pat nieko daugiau neatveria: RDP, failų bendrinimas ir visos kitos paslaugos vis dar priklauso nuo savo politikos. Tai ir yra visa prasmė apriboti vieną siaurą taisyklę, o ne įjungti platų ICMP leidimą. Platus leidimas yra lengvas sprendimas ir tas, kuris išlieka ilgiausiai, nes vėliau niekas jo nepastebi.

Valdomame įrenginyje taisyklė gali būti pakeista kito politikos atnaujinimo metu, todėl lygiavertį pakeitimą turi atlikti politikos savininkas, o ne vietinis administratorius. Įrašykite ketinimą į bilietą kartu su komanda, nes atnaujinimas ištrins komandą ir paliks reikalavimą nepakeistą. Tai ne tas pats artefaktas, ir išgyvena tik vienas iš jų.

Skaitykite rezultatą teisinga kryptimi

Kai taisyklė įsigalioja, pinginkite iš serverio ir patvirtinkite, kad atsakymas pasiekia klientą, tada pinginkite iš šaltinio, kuris dar turi būti neįtrauktas, ir patvirtinkite, kad jis nepasiekia. Pakartokite pasiekiamumo bandymą kitoje adresų šeimoje, jei tunelis ją perduoda.

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

Atspausdinti įsigaliojusią taisyklę naudingiau nei pasitikėti ją sukūrusia komanda, nes peržiūra ir pritaikyta taisyklė yra skirtingos būsenos. Jei adresų filtras rodo numatytą šaltinį, o neįtrauktas šaltinis vis dar baigiasi laukimo pabaiga, taisyklė daro būtent tai, ką sako jos apimtis. Sėkmingas ping iš kliento to niekada nebūtų parodęs, todėl kiekvieno bandymo kryptis priklauso įrašui šalia jo rezultato. Laikykite abi kryptis biliete, kitaip kitas skaitytojas pakartos bandymą, kuris negali nepavykti.