A po e bllokon firewall-i VPN-në? Kontroll hap pas hapi

Një afat i vetëm i skaduar i VPN-së provon që nuk mbërriti asnjë përgjigje e përdorshme, dhe nuk provon asgjë për arsyen. Profili mund të tregojë portën e gabuar, serveri mund të jetë i fikur, ose kërkesa mund të mbërrijë pa një rrugë kthimi funksionale. Secili prej tyre lë një gjurmë të ndryshme, dhe gjurma është ajo që të tregon cilën rregull të prekësh. Kalo nëpër katër fazat më poshtë me radhë. Ndal sapo njëra prej tyre e shpjegon simptomën.

Hapi 1: konfirmo serverin dhe transportin

Lexo emrin e serverit, transportin dhe portën nga profili aktual i operatorit dhe jo nga një ndryshim lokal. Një portë e ndryshuar në laptopin tënd nuk mund të krijojë një dëgjues në një server publik, dhe kjo mospërputhje prodhon një afat të skaduar identik me një bllokim. Nëse profili ofron një transport alternativ të mbështetur, shënoje si rezervë dhe jo si rregullim. Zgjidh emrin dhe krahaso përgjigjen me adresën që operatori ka publikuar.

Një regjistrim DNS i vjetëruar e dërgon klientin te një host që nuk u përgjigj kurrë. Ky është një tjetër defekt që imiton një filtër, dhe përjashtimi i tij kushton një pyetës të vetëm.

Shkruaj të dyja vlerat në tiketë. Çdo krahasim i mëvonshëm i përdor ato, dhe një tiketë pa to e nis hetimin nga e para.

Hapi 2: provo rrugën me një krahasim të kontrolluar

Lëri pajisjen dhe profilin të pandryshuara dhe provo një rrjet tjetër aksesi të besuar. Nëse tuneli ngrihet atje, ndryshimi është rruga origjinale ose politika e saj. Nëse një pajisje e dytë e miratuar punon në rrjetin origjinal, ndryshimi është pajisja e parë. Njëri nga këto dy krahasime është pothuajse gjithmonë vendimtar.

Përfundo më parë çdo hyrje legjitime në rrjet, sepse një portal i zënë duket si bllokim derisa të përfundojë.

Testo portën që përdor në të vërtetë, dhe trajto një rezultat TCP si informacion vetëm për TCP.

Resolve-DnsName vpn.corp.example
tracert -h 8 -w 500 vpn.corp.example
Test-NetConnection vpn.corp.example -Port 443 -InformationLevel Detailed

Një shtrëngim duarsh TCP i suksesshëm në portën 443 do të thotë që atje u përgjigj një dëgjues. Nuk thotë asgjë për një dëgjues UDP në 51820, as nëse negociatat përfunduan.

Hapi 3: lexo ngjarjet e sigurisë për momentin e dështimit

Ngjarjet e firewall-it janë prova më e fortë e disponueshme, dhe mbajnë një kusht që ia vlen të thuhet së pari. Regjistrimi është i çaktivizuar në shumë profile të parazgjedhur, prandaj kontrollo nëse profili përkatës regjistron hedhjet përpara se të lexosh një regjistër bosh si provë pafajësie. Kur regjistrimi është i ndezur, ngjarja emërton rregullin, drejtimin dhe adresat, që është pikërisht ajo që i duhet një ndryshimi rregulli. Rregullat e aplikacioneve dhe rregullat e portave janë objekte të veçanta, dhe politika e menaxhuar mund të anashkalojë një cilësim lokal. Konfirmo cilin klient dhe cilën shërbim mbulon vërtet një rregull.

Mblidh gjendjen e profilit dhe ngjarjet e fundit nga makina që dështoi, dhe jo nga një host fqinj.

Krahaso kohën e ngjarjes me kohën e përpjekjes sate të testit, sepse një emër rregulli që përputhet me një vulë kohe tjetër është rastësi.

Get-NetFirewallProfile | Select-Object Name, Enabled, DefaultInboundAction, LogBlocked
Get-NetFirewallRule -Enabled True -Direction Outbound | Where-Object DisplayName -match 'VPN'
Get-WinEvent -LogName 'Microsoft-Windows-Windows Firewall With Advanced Security/Firewall' -MaxEvents 20

Në një server që administron, pyet nëse kërkesa arriti fare te dëgjuesi. Një paketë që mbërrin pa përgjigje është problem përcjelljeje ose rruge kthimi. Një kërkesë që nuk shfaqet kurrë është problem filtrimi ose adresimi.

Hapi 4: testo përcjelljen pasi tuneli të jetë ngritur

Firewall-i mund ta lejojë sesionin dhe gjithsesi të refuzojë gjithçka që sesioni kërkon të arrijë. Sysctl-t e përcjelljes, rregullat NAT dhe rrugët e kthimit qëndrojnë të gjitha pas vërtetimit, dhe një përjashtim i gjerë për portën e VPN nuk rregullon asnjërën prej tyre. Testo veçmas një destinacion të brendshëm dhe një destinacion interneti, sepse zakonisht dështojnë për arsye të ndryshme. Nëse emrat e brendshëm dështojnë por adresat punojnë, shiko DNS-në e shtyrë përpara çdo rregulli.

Ekzekuto tre kontrollet më poshtë në server ndërsa një klient është i lidhur dhe po provon kërkesën që dështon.

Numëruesit në ndërfaqen e tunelit janë pika, sepse tregojnë nëse paketat hynë dhe nëse diçka doli.

sysctl net.ipv4.ip_forward
nft list ruleset | grep -n -E 'forward|masquerade'
tcpdump -ni tun0 -c 10

Kur paketat mbërrijnë në tunel dhe asgjë nuk del drejt destinacionit, i dyshuari është përcjellja ose NAT-i. Kur nuk mbërrin asgjë, sesioni është ngritur por klienti nuk dërgon, dhe vendi për të shikuar është tabela e rrugëve e klientit.

Verifiko rregullimin dhe hiq atë që nuk ndihmoi

Pas një korrigjimi të miratuar, përsërit saktësisht testin që dështoi dhe regjistro rezultatin ndaj të njëjtit profil dhe pajisje. Më pas hiq çdo përjashtim të përkohshëm që nuk e ndryshoi rezultatin, sepse përjashtimet e papërdorura grumbullohen dhe secili është një vendim që askush nuk e mban mend. Mbaje të ngushtë atë që mbetet: një destinacion, një portë, një drejtim, një përgjegjës.

Ekzekuto përsëri të njëjtat tre komanda dhe krahasoji me daljet që ruajte përpara ndryshimit.

Test-NetConnection vpn.corp.example -Port 443 -InformationLevel Detailed
tracert -h 8 -w 500 vpn.corp.example
Get-NetFirewallRule -Enabled True | Where-Object DisplayName -match 'VPN' | Select-Object DisplayName, Action

Kur rrjeti i krahasimit punon, rrjeti origjinal ende dështon dhe ngjarjet mbeten bosh, i dyshuari i mbetur është rruga dhe jo host-i. Kaloja atë pronarit të rrjetit si një pohim konkret, me të dyja rezultatet e krahasimit bashkangjitur. Ai është një vend më i mirë për të ndaluar sesa një profil firewall i çaktivizuar.