VPN lidhet në shtëpi por skadon në Wi-Fi-n e hotelit

Laptopi lidhet me Wi-Fi-n e shtëpisë, klienti lidhet në tre sekonda, dhe i njëjti profil dështon në hotel një orë më vonë. Në mes nuk u përditësua asgjë. Kalimi nëpër këtë me një klient përpara teje ka të bëjë kryesisht me ditur se cili gabim i përket cilës fazë, sepse informacioni i dobishëm është në kodin që printon klienti, jo në faktin që dështoi. Ndjek katër hapat më poshtë me radhë dhe do të dish nëse të refuzoi një emër, një paketë, një portë apo një politikë.

Lexoje kodin e gabimit si fazë, jo si vendim

Klienti arrin tre piketa të veçanta para se të ekzistojë një tunel. Zgjidh emrin e serverit, merr një përgjigje nga diçka në rrjet dhe negocion një shoqatë sigurie. Çdo piketë ka mesazhin e vet të dështimit, dhe veçanërisht Windows është bujar me kode të ndryshme sapo të dish se cilës fazë i përkasin.

Dy prej atyre kodeve nënkuptojnë se rrjeti është i pafajshëm. 789 do të thotë se paketat rrjedhshin dhe të dy skajet nuk binin dakord për kripton, që është një problem konfigurimi që mund ta rregullosh në shtëpi. 868 do të thotë se asnjë paketë nuk kishte nevojë të dilte, prandaj dizajni i tunelit është i parëndësishëm derisa emri të zgjidhet. Klasifikimi i kodit në fazën e duhur kursen më shumë kohë se çdo kapje, sepse të tregon cilin nga tre hapat e ardhshëm të anashkalosh.

Bëhu i kujdesshëm në masën e duhur nëse klienti nuk është Windows. Klientët e palëve të treta e reduktojnë pjesën më të madhe të kësaj në "lidhja dështoi", prandaj dy hapat e ardhshëm nuk mbështeten fare te mesazhi.

Kontrollo emrin para se të fajësosh tunelin

Rrjetet e hoteleve dhe aeroporteve ndërpresin vazhdimisht DNS-në, dhe një zgjidhës që përgjigjet me një adresë portali prodhon një dështim që duket saktësisht si një server i vdekur. Krahaso çfarë thotë zgjidhësi lokal me atë që thotë një zgjidhës publik:

Resolve-DnsName vpn.example.net -Type A
nslookup vpn.example.net 1.1.1.1
ipconfig /all | findstr /i "DNS Servers"

Nëse dy përgjigjet ndryshojnë, po të drejtojnë dhe pjesa tjetër e diagnostikimit është e humbur derisa kjo të zgjidhet. Veçanërisht një adresë portali do ta pranojë me kënaqësi lidhjen TCP dhe pastaj do të ngecë, prandaj mund të duket si bllokim i murit të zjarrit kur teston me një shfletues.

Tani konfirmo që adresa që do të arrish është ajo që përdoret. Disa klientë e ruajnë në cache zgjidhjen e mëparshme për gjithë jetën e profilit, prandaj një rilidhje pas ndryshimit të DNS-së shkon ende te adresa e vjetër. Mbyll klientin plotësisht para se të retestosh, në vend që të shtypësh shkëput dhe lidh në të njëjtën dritare.

Zbulo cila paketë e jashtme zhduket

Tuneli ka një rrjedhë të jashtme që i përket plotësisht rrugës midis teje dhe serverit, dhe është pikërisht ajo rrjedhë që kutitë e ndërmjetme e klasifikojnë dhe e hedhin. Kap-e në klient, pastaj krahaso një rrjet që funksionon me atë që dështon. Në Windows kapja e integruar mjafton për një vështrim të parë:

pktmon filter remove
pktmon filter add -p 500 -t UDP
pktmon start --capture --pkt-size 128
pktmon stop
pktmon etl2txt PktMon.etl

Ajo që do të shohësh është nëse paketat e tua dalin fare dhe nëse kthehet diçka. Paketa jashtë pa asgjë mbrapsht do të thotë se rruga ose skaji i largët i hedh; nëse nuk del asgjë fare, klienti nuk arriti kurrë të dërgojë, gjë që të kthen te zgjidhja e emrave ose te një politikë lokale e murit të zjarrit.

Përsërit të njëjtin test në një hotspot telefoni. Ky është krahasimi më informativ që ke në dispozicion, sepse heq nga rruga çdo kuti në hotel duke mbajtur të njëjtë laptopin, klientin dhe kredencialet. Nëse tuneli ngrihet në hotspot, ndalo së shikuari serverin. Nëse dështon edhe atje, ke një problem klienti ose llogarie që rrjeti nuk e shkaktoi kurrë.

Ndrysho një transport dhe testo përsëri

Pasi e di që rrjedha e jashtme hidhet, pyetja praktike është cilën rrjedhë lejon rrjeti. Shumica e rrjeteve të kufizuara lejojnë TCP 443 në dalje sepse ndryshe nuk mund të funksionojnë, prandaj zhvendosja e dëgjuesit atje është përgjigja e zakonshme. Në OpenVPN ky është një çelës nga ana e klientit derisa të ndryshohet serveri:

openvpn --config corp.ovpn --proto tcp-client --remote vpn.example.net 443 --verb 4

Klientët IPsec kanë një çelës ekuivalent në panelet e tyre të cilësimeve, zakonisht i përshkruar si IPsec mbi TCP ose kalim NAT. Ndryshimi i tij është gjithashtu një diagnostikim: nëse tuneli ngrihet mbi TCP dhe vdes mbi UDP, ke provuar që rrjeti filtron UDP-në, dhe ke gjetur edhe cilësimin që do të të duhet sa herë të vizitosh atë vend.

Përballu me tundimin për të çaktivizuar funksionet e ruterit në provën e parë. Çaktivizimi i inspektimit me gjendje ose i mbrojtjes nga përmbytja në një rrjet hoteli nuk është i disponueshëm për ty gjithsesi, dhe në pajisjen tënde ndërron një mbrojtje reale me një laptop të vetëm. Shëno cili cilësim ndryshoi rezultatin, pastaj ktheje atë dhe kërko një transport që rrjeti tashmë e lejon.

Verifiko të njëjtin profil në rrjetin e dytë

Para se të mbyllësh tiketën, provo që ndryshimi mbijetoi daljen nga ndërtesa. Rilidhu në rrjetin origjinal me cilësimet origjinale, kap tridhjetë sekondat e para dhe konfirmo që klienti arrin të njëjtën gjendje që arriti në hotspot:

pktmon filter add -p 443 -t TCP
pktmon start --capture
Get-VpnConnection -Name "Corp" | Select-Object ConnectionStatus, TunnelType, ServerAddress

Dallimi që zbulon komanda e fundit ia vlen të mbahet: profili mund të raportojë një tunel të lidhur ndërkohë që rrugëtimi brenda tij është i gabuar, dhe kjo prodhon "VPN-ja është ndezur por asgjë nuk funksionon", që është një artikull tjetër. Nëse lloji i tunelit ndryshoi pas redaktimit tënd, profili nuk është ai që testove.

Pastaj shkruaj gjetjen atje ku do të shohë personi tjetër. "Profili i kompanisë kërkon TCP 443 në këtë vend; UDP 500 filtrohet nga hoteli" është një fjali mbi të cilën një koleg mund të veprojë. "VPN-ja është e paqëndrueshme në hotele" nuk është, dhe garanton që i njëjti orë do të shpenzohet përsëri muajin tjetër.