Nakakonekta ang VPN pero walang internet? Suriin ang apat na patong

Sinasabi ng kliyente na konektado, umiikot ang browser, at bawat site ay nagtatapos sa timeout. Karaniwan ang kombinasyong iyon at hindi kontradiksyon: konektado ay nangangahulugang nagnegosyo ang tunel, at wala nang iba. Ang resolusyon ng pangalan, routing at sariling labasan ng server ay nabigo bawat isa sa sariling paraan, at bawat isa ay may ibang may-ari. Suriin ang mga patong sa pagkakasunod-sunod at huminto sa unang nabigo.

Magsimula sa network na pinanggalingan mo

Ibaba ang tunel gamit ang sariling kontrol ng kliyente sa pagdiskonekta, pagkatapos subukan ang dalawang walang kaugnayang site ng HTTPS kung pinapayagan ng patakaran. Iwanang sarado ang sensitibong trabaho sa buong pagsubok na iyon. Kung nabigo rin ang ordinaryong access, ang VPN ay hindi ang unang pinaghihinalaan.

Tingnan ang koneksyon ng Wi-Fi, ang router at anumang portal na pahina na humihingi ng pag-login bago hawakan ang tunel. Maaaring harangan ng kill switch ang trapiko habang nadiskonekta ayon sa disenyo, kaya sundan ang dokumentadong pamamaraan ng pagsubok nito sa halip na magpasyang patay na ang network. Ang isa pang pinagkakatiwalaang network ay kapaki-pakinabang na paghahambing, at ang bagong labasan ng VPN ay hindi tatapusin ang nag-expire na pag-login sa hotel. Kung gumagana ang bukas na network at hindi ang tunel, walang kasalanan ang network at sa iyo ang susunod na patong.

Magpasya kung resolusyon ng pangalan ang problema

Isulat ang teksto ng error, dahil ang pagkabigo ng resolusyon, timeout at babala sa sertipiko ay tumuturo bawat isa sa ibang lugar. Ang pattern na dapat mahuli nang maaga ay isang hostname na hindi mo pa nabisita na nabigo habang ang aplikasyong may bukas na sesyon ay nagpapatuloy. Ang pattern na iyon ay tungkol sa mga bagong paghahanap, hindi sa kung nagdadala ng packet ang tunel. Ang isang paghahanap ay nagpapakita kung ano ang ibinabalik ng resolver, at tumatagal ito ng isang segundo. Subukan din ang pangalawang pangalan, upang ang isang naka-cache na sagot o isang sirang record ay hindi magpasya sa diagnosis.

nslookup example.com

Ang di-makatwirang IP sa bar ng address ng HTTPS ay hindi pagsubok ng DNS, dahil ang sertipiko at virtual host ay karaniwang nakadepende sa pangalan. Maaaring kailanganin ng mga panloob na pangalan ang resolver ng organisasyon sa halip na pampublikong kapalit, at ang browser na may sariling secure na resolver ay maaaring sumagot nang iba kaysa sa paghahanap ng operating system. Kung saan nagkakaiba ang dalawa, ang resolver ng browser ang nararanasan ng user, at ang pagkakaibang iyon ay kabilang sa ticket.

Buong tunel o mga subnet ng kumpanya lamang

Ang ilang profile ay umiiral lamang upang maabot ang ilang subnet ng kumpanya; ang iba ay itinayo upang magdala ng lahat at kailangan ng gumaganang labasan sa likod. Basahin ang dokumentadong layunin bago ipagpalagay na sakop ng tagapagpahiwatig ang bawat aplikasyon at bawat pamilya ng address. Ang profile ng pribadong network ay maaaring gumana nang eksakto ayon sa disenyo habang ang browser, na hindi dapat gumamit nito, ay nabigo pa rin. Basahin ang talahanayan ng ruta nang hindi ito binabago, at isama ang IPv6, dahil ang gumaganang landas ng IPv4 ay walang sinasabi tungkol sa kabilang pamilya.

Ang mas partikular na ruta ay maaaring manalo habang umiiral pa ang default na ruta, kaya dapat basahin ang talahanayan at hindi ipagpalagay. Ang mga nakikipagkumpitensyang virtual adapter ay maaaring magmay-ari din ng trapikong inaasahan mo sa ibang lugar, lalo na pagkatapos mai-install at makalimutan ang pangalawang kliyente ng VPN. Huwag tanggalin ang default na ruta bilang eksperimento; ginagawa nitong pangalawang pagkawala ang diagnosis.

Ang isang site na nabigo sa mga gumagana ay problema ng site na iyon, at pinatutunayan din nito na nagdadala ng trapiko ang tunel. Ang mga paghinto na lumilitaw lamang sa malalaking paglilipat ay tumuturo sa laki ng packet at hindi sa maabot.

Kapag hindi kailanman nagpapasa ang server ng anuman

Kung bawat destinasyon ay nabigo sa dalawang device at dalawang access network, bumangon ang tunel at hindi nagpapasa ang labasan. Ang pares na iyon ang naghihiwalay ng pagkabigo sa panig ng server mula sa isang device na mali ang pagkaka-configure sa isang lugar. Ipadala sa operator ang mga tanong sa pagpapasa, NAT at daan pabalik, hindi screenshot ng tagapagpahiwatig.

Ang tatlong iyon ay sumasakop sa karamihan ng dahilan sa panig ng server, at ang pagsagot ay trabaho ng operator. Ang pahina ng pag-troubleshoot ng koneksyon ng OpenVPN ay dumadaan sa parehong mga tanong mula sa panig ng server, kaya ipasa ito kasama ng ticket. Ang screenshot ng berdeng tagapagpahiwatig ay hindi sumasagot sa alinman.

Suriin ang log ng kliyente pagkatapos ng login para sa mga pagkabigo sa paglalapat ng ruta, setting ng DNS o virtual adapter. Ang mga error sa yugtong iyon ay tumuturo sa device at hindi sa server. Ang error na hindi kailanman lumilitaw sa log ay kasing-informasyon, dahil inililipat nito ang hinala sa kabilang panig.

Suriin ang isang patong sa isang pagkakataon

Kapag may binago ka, kumonekta muli at ulitin ang eksaktong aplikasyong nabigo. Ang isang pahinang nag-load ay nagpapatunay ng mas mababa kaysa sa nauulit na landas patungo sa mga resource na ginawa para sa profile. Dalawang utos ang naghihiwalay ng resolusyon mula sa maabot, at ang pangalawa ay nakadepende sa host. Patakbuhin ang linyang curl kahit saan, pagkatapos ang utos ng ruta na tumutugma sa host sa harap mo.

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

Kung gumagana ang numerong kahilingan at hindi ang pangalan, manatili sa DNS. Kung wala sa dalawa ang gumagana, ihambing ang talahanayan ng ruta sa inaasahang default ng tunel, at suriin ang pamilyang talagang sinusubukan mo. Kung tama ang ruta at namamatay pa rin ang kahilingan sa labasan, ang natitirang tanong ay sa operator, at ang ebidensyang iningatan mo ay ang ticket.