Ping funksionon vetëm në një drejtim: pse Windows hedh poshtë jehonën e serverit

Klienti juaj pingon serverin, serveri nuk mund të pingojë klientin, dhe tuneli padyshim transporton paketa në të dyja këto pohime. Ajo që ndryshon nuk është rruga, por paketa e parë e çdo prove: njëra është përgjigje për një rrjedhë që Windows e ndjek tashmë, tjetra është një kërkesë e re hyrëse që asnjë rregull nuk e ka lejuar. Ky ndryshim shpjegon shumicën e raporteve për ping njëdrejtimësh dhe tregon drejtpërdrejt rregullin që duhet të shkruani. Dy prova në drejtime të kundërta i ndajnë rastet për rreth një minute.

Dy drejtime, dy vendime të ndryshme

Kur klienti dërgon kërkesën e jehonës, firewalled e Windows sheh një lidhje dalëse që ka vendosur ta lejojë. Përgjigja kthehet brenda kësaj rrjedhe të vendosur, prandaj motori që ndjek gjendjen e lejon pa pyetur asnjë rregull hyrës për ICMP. Kjo është ajo që do të thotë filtrimi me gjendje në praktikë, dhe rregulli që nuk e shkroi askush nuk përfshihet. Pra suksesi i klientit nuk thotë asgjë për politikën hyrëse.

Kur serveri e dërgon kërkesën i pari, asnjë gjendje nuk i përshtatet. Windows e trajton paketën si një lidhje të re hyrëse dhe pyet politikën hyrëse, e cila si parazgjedhje nuk parashikon asgjë për kërkesat e jehonës që vijnë nga burime arbitrare.

Pra suksesi i klientit dëshmoi se ICMP dalës dhe rruga e kthimit funksionojnë. Ai nuk e provoi kurrë vendimin hyrës, dhe përfundimi i natyrshëm, se firewalled është në rregull, është i arsyeshëm dhe i gabuar. Prandaj gabimi përsëritet në tiketat që e përmbajnë tashmë provën.

Ndiqni paketën derisa të zhduket

Konfirmoni adresat përpara se të ndryshoni çdo gjë: përdorni adresën e tunelit që klienti e ka vërtet, dhe kontrolloni se serveri rrugëton drejt saj dhe jo drejt një adrese LAN pas klientit. Të dyja dështimet duken njësoj nga prompt-i i serverit, sepse të dyja përfundojnë me skadim kohe. Ku vdes paketa është fakti i vetëm që vendos çfarë duhet ndryshuar.

Nëse kërkesa arrin ndërfaqen e tunelit dhe asgjë nuk del, firewalled lokal është shkaku i mundshëm. Nëse nuk arrin kurrë ndërfaqen, përgjigja është më lart: një rrugë në server, një politikë dalëse ose dërgimi vetjak i VPN-së midis partnerëve.

Kapni në ndërfaqen e tunelit të klientit ndërsa serveri pingon. Të shohësh kërkesën duke ardhur pa një përgjigje pranë saj është prova që justifikon shkrimin e një rregulli të Windows. Të mos shohësh asgjë të dërgon më lart, dhe një rregull i shtuar në atë gjendje vetëm e bën makinën më tolerante për një paketë që nuk mbërriti kurrë. Në të dyja rastet kapja kushton më pak se hamendjet që zëvendëson.

Kufizoni një rregull në vend që të hapni ICMP

Identifikoni përshtatësin dhe kategorinë e tij aktuale përpara se të shkruani çdo gjë, sepse të dyja shfaqen në shtrirjen që po vendosni. Ai alias është emri i ndërfaqes së Windows, i cili nuk është domosdoshmërisht emri i profilit të VPN që keni importuar. Komandat më poshtë renditin çfarë ekziston, pastaj paraqesin një pamje paraprake të një rregulli të kufizuar pa e zbatuar atë.

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 tipi 8 është kërkesa e jehonës, mesazhi i vetëm për të cilin serverit i duhet përgjigje. Kufizojeni atë në adresën e tunelit të serverit dhe në ndërfaqen e tunelit, dhe lini profilin ashtu siç është përshtatësi në të vërtetë. Riemërtimi i një rrjeti për t'u përshtatur me një shembull është një ndryshim më vete me pasoja të vetat.

Çfarë nuk mbulon rregulli

Jehona e IPv6 është protokoll tjetër me tip tjetër mesazhi, prandaj një rregull ICMPv4 nuk thotë asgjë për të, dhe një tunel që transporton të dyja familjet ka nevojë për rregullin e vet për tjetrën. Ky rregull nuk hap asgjë tjetër: RDP, ndarja e skedarëve dhe çdo shërbim tjetër varen ende nga politika e tyre. Ky është i gjithë qëllimi i kufizimit të një rregulli të ngushtë në vend të aktivizimit të një lejeje të gjerë ICMP. Leja e gjerë është rregullimi i lehtë dhe ai që zgjat më shumë, sepse më pas askush nuk e vëren.

Në një pajisje të administruar rregulli mund të zëvendësohet në rifreskimin e ardhshëm të politikës, prandaj pronari i politikës duhet të bëjë ndryshimin ekuivalent dhe jo një administrator lokal. Shkruani qëllimin në tiketë bashkë me komandën, sepse një rifreskim do të fshijë komandën dhe do të lërë kërkesën të paprekur. Të dyja nuk janë i njëjti artefakt, dhe vetëm njëra mbijeton.

Lexoni rezultatin në drejtimin e saktë

Pasi rregulli të hyjë në fuqi, pingoni nga serveri dhe konfirmoni se një përgjigje arrin te klienti, pastaj pingoni nga një burim që duhet të mbetet i përjashtuar dhe konfirmoni se nuk arrin. Përsëritni provën e arritshmërisë në familjen tjetër të adresave nëse tuneli transporton një të tillë.

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

Të printosh rregullin që hyri në fuqi është më e dobishme sesa t'i besosh komandës që e krijoi, sepse një pamje paraprake dhe një rregull i zbatuar janë dy gjendje të ndryshme. Nëse filtri i adresave tregon burimin e synuar dhe burimi i përjashtuar skadon ende, rregulli bën saktësisht atë që thotë shtrirja e tij. Një ping i suksesshëm i nisur nga klienti nuk do ta kishte dëshmuar kurrë këtë, dhe prandaj drejtimi i çdo prove i takon regjistrit pranë rezultatit të tij. Mbani të dyja drejtimet në tiketë, përndryshe lexuesi tjetër do të përsëritë provën që nuk mund të dështojë.