Ping töötab ainult ühes suunas: miks Windows viskab serveri kaja ära

Sinu klient pingib serverit, server ei saa klienti pingida, ja tunnel kannab mõlemas väites selgelt pakette. Erineb mitte tee, vaid iga testi esimene pakett: üks on vastus voolule, mida Windows juba jälgib, teine on uus sissetulev päring, mida ükski reegel pole lubanud. See erinevus selgitab enamikku ühesuunalise pingi aruandeid ja osutab otse reeglile, mille pead kirjutama. Kaks vastassuunalist testi eraldavad juhtumid umbes minuti jooksul.

Kaks suunda, kaks erinevat otsust

Kui klient saadab kaja päringu, näeb Windowsi tulemüür väljuvat ühendust, mille see on otsustanud lubada. Vastus tuleb tagasi selle juba loodud voolu sees, seega olekut jälgiv mootor lubab selle ilma ICMP jaoks mõeldud sissetulevat reeglit küsima. Seda tähendab olekupõhine filtreerimine praktikas ja reegel, mida keegi ei kirjutanud, ei ole sellesse kaasatud. Seega ei ütle kliendi edu sissetuleva poliitika kohta midagi.

Kui server saadab päringu esimesena, ei vasta sellele ükski olek. Windows käsitleb paketti uue sissetuleva ühendusena ja küsib sissetulevat poliitikat, mis vaikimisi ei näe ette midagi suvalistest allikatest saabuvate kaja päringute jaoks.

Nii tõestas kliendi edu, et väljuv ICMP ja tagasitee töötavad. Sissetulevat otsust ei proovinud see kordagi ja loomulik järeldus, et tulemüür on korras, on mõistlik ja vale. Seepärast kordub viga piletites, mis juba sisaldavad tõendit.

Jälgi paketti, kuni see kaob

Kinnita aadressid enne millegi muutmist: kasuta tunneliaadressi, mis kliendil tegelikult on, ja kontrolli, et server marsruudib sinna, mitte kliendi taga olevale LAN-aadressile. Kaks tõrget näevad serveri käsurealt identsed välja, sest mõlemad lõpevad ajalõpuga. Kus pakett sureb, on ainus fakt, mis otsustab, mida muuta.

Kui päring jõuab tunneliliideseni ja sealt ei välju midagi, on tõenäoline põhjus kohalik tulemüür. Kui see ei jõua liideseni kunagi, on vastus ülesvoolu: serveri marsruut, väljuv poliitika või VPN-i enda tarnimine võrdsete vahel.

Jäädvusta kliendi tunneliliidesel, kui server pingib. Päringu saabumine ilma kõrval oleva vastuseta on tõend, mis õigustab Windowsi reegli kirjutamist. Mitte millegi nägemine saadab sind ülesvoolu ja selles olekus lisatud reegel teeb masina vaid lubavamaks paketi suhtes, mis kunagi ei saabunud. Mõlemal juhul maksab jäädvustus vähem kui oletused, mida see asendab.

Piira üks reegel, mitte ava ICMP-d

Tuvasta adapter ja selle praegune kategooria enne millegi kirjutamist, sest mõlemad esinevad ulatuses, mille kohe seadistad. See alias on Windowsi liidese nimi, mis ei pruugi olla imporditud VPN-profiili nimi. Allolevad käsud loetlevad, mis olemas on, ja näitavad seejärel piiratud reeglit eelvaates, ilma seda rakendamata.

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 tüüp 8 on kaja päring, ainus sõnum, millele server peab vastuse saama. Piira see serveri tunneliaadressi ja tunneliliidesega ning jäta profiil selliseks, nagu adapter tegelikult on. Võrgu ümbernimetamine, et see näitega sobiks, on eraldi muudatus oma tagajärgedega.

Mida reegel ei kata

IPv6 kaja on teine protokoll teise sõnumitüübiga, seega ei ütle ICMPv4 reegel selle kohta midagi ja mõlemat perekonda kandev tunnel vajab teise jaoks oma reeglit. See reegel ei ava ka midagi muud: RDP, failide jagamine ja iga teine teenus sõltub endiselt oma poliitikast. See ongi kogu mõte piirata ühte kitsast reeglit, selle asemel et lubada lai ICMP-luba. Lai luba on lihtne parandus ja see, mis kestab kõige kauem, sest hiljem ei märka seda keegi.

Hallataval seadmel võidakse reegel järgmisel poliitika värskendusel välja vahetada, seega peab samaväärse muudatuse tegema poliitika omanik, mitte kohalik administraator. Kirjuta kavatsus piletisse koos käsuga, sest värskendus kustutab käsu ja jätab nõude puutumata. Need ei ole sama artefakt ja ellu jääb neist ainult üks.

Loe tulemust õiges suunas

Kui reegel rakendub, pingi serverist ja kinnita, et vastus jõuab kliendini, seejärel pingi allikast, mis peaks endiselt välja jääma, ja kinnita, et ei jõua. Korda kättesaadavuse testi teisel aadressiperekonnal, kui tunnel seda kannab.

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

Jõustunud reegli printimine on kasulikum kui selle loonud käsu usaldamine, sest eelvaade ja rakendatud reegel on erinevad olekud. Kui aadressifilter näitab kavatsetud allikat ja välistatud allikas lõpeb endiselt ajalõpuga, teeb reegel täpselt seda, mida selle ulatus ütleb. Kliendist algatatud edukas ping ei oleks seda kunagi näidanud, seepärast kuulub iga testi suund kirjesse selle tulemuse kõrvale. Hoia piletis mõlemad suunad, muidu kordab järgmine lugeja testi, mis ei saa ebaõnnestuda.