VPN i lidhur por pa internet? Kaloni nëpër katër shtresat

Klienti thotë i lidhur, shfletuesi rrotullohet dhe çdo faqe përfundon me skadim kohe. Ky kombinim është i zakonshëm dhe nuk është kundërshti: i lidhur do të thotë që tuneli negocioi, dhe asgjë më shumë. Zgjidhja e emrave, rrugëtimi dhe vetë dalja e serverit dështojnë secili në mënyrën e vet, dhe secili ka pronar tjetër. Kaloni shtresat me radhë dhe ndaloni në të parën që dështon.

Filloni nga rrjeti prej nga erdhët

Ulni tunelin me kontrollin e vetë klientit për shkëputje, më pas provoni dy faqe HTTPS të palidhura nëse politika lejon. Lëreni punën e ndjeshme të mbyllur për kohëzgjatjen e atij testi. Nëse edhe aksesi i zakonshëm dështon, VPN nuk është i dyshuari i parë.

Shikoni lidhjen Wi-Fi, ruterin dhe çdo faqe portali që kërkon hyrje përpara se të prekni tunelin. Një kill switch mund të bllokojë trafikun gjatë shkëputjes sipas projektimit, prandaj ndiqni procedurën e tij të dokumentuar të testit në vend që të përfundoni se rrjeti ka vdekur. Një rrjet tjetër i besuar është një krahasim i dobishëm, dhe një dalje e re VPN nuk do të përfundojë një hyrje hoteli të skaduar. Nëse rrjeti i hapur funksionon dhe tuneli jo, rrjeti lirohet dhe shtresa tjetër është e juaja.

Vendosni nëse dështimi është zgjidhje emrash

Shkruani tekstin e gabimit, sepse dështimi i zgjidhjes, skadimi i kohës dhe paralajmërimi i certifikatës tregojnë secili diku tjetër. Modeli që duhet kapur herët është një emër hosti që nuk e keni vizituar kurrë duke dështuar ndërsa një aplikacion me sesion të hapur vazhdon. Ky model ka të bëjë me kërkime të reja, jo me atë nëse tuneli mban paketa. Një kërkim i vetëm tregon çfarë kthen zgjidhësi, dhe zgjat një sekondë. Provoni edhe një emër të dytë, që një përgjigje e ruajtur në cache ose një regjistrim i prishur të mos vendosë diagnozën.

nslookup example.com

Një IP arbitrare në shiritin e adresave HTTPS nuk është test DNS, sepse certifikata dhe hosti virtual zakonisht varen nga emri. Emrat e brendshëm mund të kërkojnë zgjidhësin e organizatës në vend të një zëvendësimi publik, dhe një shfletues me zgjidhësin e vet të sigurt mund të përgjigjet ndryshe nga kërkimi i sistemit operativ. Kur të dy ndryshojnë, zgjidhësi i shfletuesit është ai që përjeton përdoruesi, dhe ky dallim i përket biletës.

Tunel i plotë apo vetëm nënrrjetet e kompanisë

Disa profile ekzistojnë vetëm për të arritur një grusht nënrrjetesh të kompanisë; të tjerët janë ndërtuar për të mbajtur gjithçka dhe kërkojnë një dalje funksionale pas tyre. Lexoni qëllimin e dokumentuar përpara se të supozoni se treguesi mbulon çdo aplikacion dhe çdo familje adresash. Një profil i rrjetit privat mund të funksionojë saktësisht siç është projektuar, ndërsa shfletuesi, që nuk duhej ta përdorte kurrë, ende dështon. Lexoni tabelën e rrugëtimit pa e ndryshuar, dhe përfshini IPv6, sepse një rrugë IPv4 që funksionon nuk thotë asgjë për familjen tjetër.

Një rrugë më specifike mund të fitojë ndërsa rruga e paracaktuar ekziston ende, prandaj tabela duhet lexuar dhe jo supozuar. Përshtatësit virtualë konkurrues mund të zotërojnë gjithashtu trafik që e prisnit diku tjetër, sidomos pasi një klient i dytë VPN është instaluar dhe harruar. Mos e fshini rrugën e paracaktuar si eksperiment; kjo e kthen diagnozën në një ndërprerje të dytë.

Një faqe e vetme që dështon mes atyre që funksionojnë është problem i asaj faqeje, dhe gjithashtu dëshmon se tuneli mban trafik. Ndalimet që shfaqen vetëm në transferime të mëdha tregojnë madhësinë e paketës dhe jo arritshmërinë.

Kur serveri nuk përcjell kurrë asgjë

Nëse çdo destinacion dështon në dy pajisje dhe dy rrjete aksesi, tuneli është lart dhe dalja nuk përcjell. Pikërisht ky çift ndan një dështim nga ana e serverit nga një pajisje e konfiguruar gabimisht në një vend. Dërgoni operatorit pyetjet për përcjelljen, NAT dhe rrugën e kthimit, jo një pamje ekrani të treguesit.

Këto të treja mbulojnë shumicën e shkaqeve nga ana e serverit, dhe përgjigjja është e operatorit. Faqja e zgjidhjes së problemeve të lidhjes së OpenVPN kalon të njëjtat pyetje nga ana e serverit, prandaj përcilleni me biletën. Një pamje ekrani e një treguesi të gjelbër nuk përgjigjet asnjërës prej tyre.

Shqyrtoni regjistrin e klientit pas hyrjes për dështime në zbatimin e rrugëve, cilësimeve të DNS ose përshtatësit virtual. Gabimet në atë fazë tregojnë pajisjen dhe jo serverin. Një gabim që nuk shfaqet kurrë në regjistër është po aq informativ, sepse e zhvendos dyshimin në anën tjetër.

Kontrolloni një shtresë në një herë

Pasi ndryshoni diçka, rilidhuni dhe përsëritni saktësisht aplikacionin që dështoi. Një faqe e vetme që ngarkohet dëshmon më pak se një rrugë e përsëritshme drejt burimeve për të cilat u ndërtua profili. Dy komanda ndajnë zgjidhjen nga arritshmëria, dhe e dyta varet nga hosti. Ekzekutoni rreshtin curl kudo, pastaj komandën e rrugëve që përputhet me hostin përpara jush.

curl -sS -o /dev/null -w "%{http_code}" --max-time 5 https://example.com
route print -4          # Windows
ip -4 route show        # Linux
netstat -rn | head      # macOS

Nëse kërkesa numerike funksionon dhe emri jo, qëndroni në DNS. Nëse asnjëra nuk funksionon, krahasoni tabelën e rrugëtimit me parazgjedhjen e pritur të tunelit, dhe kontrolloni familjen që po testoni vërtet. Nëse rruga është e saktë dhe kërkesa vdes ende në dalje, pyetja e mbetur i përket operatorit, dhe provat që ruajtët janë bileta.