Ping deluje samo v eno smer: zakaj Windows zavrže odmev strežnika

Vaš odjemalec pinga strežnik, strežnik ne more pingati odjemalca, in tunel v obeh trditvah očitno prenaša pakete. Ne razlikuje se pot, ampak prvi paket vsakega preizkusa: eden je odgovor na tok, ki ga Windows že sledi, drugi je nova dohodna zahteva, ki je ni spustilo nobeno pravilo. Ta razlika pojasnjuje večino poročil o enosmernem pingu in kaže naravnost na pravilo, ki ga morate napisati. Dva preizkusa v nasprotnih smereh ločita primere v približno eni minuti.

Dve smeri, dve različni odločitvi

Ko odjemalec pošlje zahtevo za odmev, požarni zid Windows vidi odhodno povezavo, ki se je odločil, da jo bo dovolil. Odgovor se vrne znotraj tega vzpostavljenega toka, zato ga mehanizem, ki sledi stanju, spusti, ne da bi vprašal katero koli dohodno pravilo za ICMP. To v praksi pomeni filtriranje na podlagi stanja, in pravilo, ki ga ni napisal nihče, pri tem ne sodeluje. Uspeh odjemalca torej ne pove ničesar o dohodni politiki.

Ko zahtevo prvi pošlje strežnik, se z njo ne ujema nobeno stanje. Windows paket obravnava kot novo dohodno povezavo in vpraša dohodno politiko, ki privzeto ne predvideva ničesar za zahteve za odmev iz poljubnih virov.

Uspeh odjemalca je torej dokazal, da odhodni ICMP in povratna pot delujeta. Nikoli ni preizkusil dohodne odločitve, in naravni sklep, da je požarni zid v redu, je razumen in napačen. Zato se napaka ponavlja v zahtevkih, ki že vsebujejo dokaz.

Sledite paketu, dokler ne izgine

Preden karkoli spremenite, potrdite naslove: uporabite naslov tunela, ki ga odjemalec resnično ima, in preverite, da strežnik usmerja nanj in ne na naslov LAN za odjemalcem. Obe napaki sta s strežnikove ukazne vrstice videti enako, ker se obe končata s potekom časa. Kje paket umre, je edino dejstvo, ki odloči, kaj spremeniti.

Če zahteva doseže vmesnik tunela in nič ne pride ven, je verjetni vzrok krajevni požarni zid. Če vmesnika nikoli ne doseže, je odgovor višje: pot na strežniku, odhodna politika ali lastna dostava med enakovrednimi vozlišči VPN.

Zajemajte na vmesniku tunela odjemalca, medtem ko strežnik pinga. Videti zahtevo, ki prispe brez odgovora ob njej, je dokaz, ki upravičuje pisanje pravila Windows. Če ne vidite ničesar, vas to pošlje višje, pravilo, dodano v tem stanju, pa naredi stroj le bolj popustljiv za paket, ki ni nikoli prispel. V obeh primerih zajem stane manj kot ugibanja, ki jih nadomesti.

Omejite eno pravilo namesto odpiranja ICMP

Preden karkoli napišete, določite vmesnik in njegovo trenutno kategorijo, ker se oboje pojavi v obsegu, ki ga boste nastavili. Ta vzdevek je ime vmesnika Windows, ki ni nujno ime profila VPN, ki ste ga uvozili. Ukazi spodaj naštejejo, kaj obstaja, nato pa prikažejo predogled omejenega pravila, ne da bi ga uporabili.

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 zahteva za odmev, edino sporočilo, na katero mora strežnik dobiti odgovor. Omejite jo na naslov tunela strežnika in na vmesnik tunela, in pustite profil takšen, kakršen vmesnik v resnici je. Preimenovanje omrežja, da bi ustrezalo zgledu, je ločena sprememba z lastnimi posledicami.

Česa pravilo ne pokriva

Odmev IPv6 je drugo omrežno geslo z drugo vrsto sporočila, zato pravilo ICMPv4 o njem ne pove ničesar, in tunel, ki prenaša obe družini, potrebuje svoje pravilo za drugo. To pravilo tudi ne odpira ničesar drugega: RDP, souporaba datotek in vsaka druga storitev so še vedno odvisne od svoje politike. V tem je ves smisel omejitve enega ozkega pravila namesto omogočanja širokega dovoljenja ICMP. Široko dovoljenje je preprost popravek in tisto, ki preživi najdlje, ker ga potem nihče ne opazi.

Na upravljani napravi se lahko pravilo zamenja ob naslednji osvežitvi politike, zato mora enakovredno spremembo izvesti lastnik politike, ne krajevni skrbnik. Zapišite namen v zahtevek skupaj z ukazom, ker bo osvežitev izbrisala ukaz in pustila pogoj nedotaknjen. To nista ista predmeta, in preživi le eden od njiju.

Rezultat berite v pravi smeri

Ko pravilo začne veljati, pingajte s strežnika in potrdite, da odgovor doseže odjemalca, nato pingajte iz vira, ki mora ostati izključen, in potrdite, da ne doseže. Ponovite preizkus dosegljivosti na drugi družini naslovov, če jo tunel prenaša.

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

Natisniti pravilo, ki je stopilo v veljavo, je koristneje kot zaupati ukazu, ki ga je ustvaril, ker sta predogled in uporabljeno pravilo različni stanji. Če filter naslovov kaže predvideni vir, izključeni vir pa še vedno poteče, pravilo dela natanko to, kar pravi njegov obseg. Uspešen ping z odjemalca tega ne bi nikoli pokazal, zato smer vsakega preizkusa sodi v zapis ob njegovem rezultatu. V zahtevku ohranite obe smeri, sicer bo naslednji bralec ponovil preizkus, ki ne more spodleteti.