Gumagana Lang ang Internet Kapag Bukas ang Aplikasyon ng VPN? Suriin ang Apat na Antas

Susubukan mo ang isang libreng VPN client o isang browser extension nang isang linggo, patayin ito, at hihinto ang internet. Nagpapakita pa rin ng koneksyon ang Wi-Fi icon, maayos ang ibang device sa parehong router, at ang tanging nagbabalik ng pagba-browse ay ang muling pagbukas ng app o ang pag-uninstall nito. Ang ganitong pattern ay hindi encryption na gumagawa ng dependency. Configuration ito na isinulat ng app sa lugar na hindi pagmamay-ari ng tunnel.

Binabago ng client ang mga setting na hindi pagmamay-ari ng tunnel

Ang isang privacy client sa Windows o macOS ay karaniwang sabay na humahawak ng tatlong lugar. Itinatakda nito ang system HTTP proxy, na siya ring field na ipinapakita ng Internet Options. Nag-i-install ito ng virtual adapter, kadalasan TAP driver, para makakuha ng packets. At muling isinusulat nito ang resolver list, samantalang ang tunnel lang ang nawawala kapag pinindot mo ang disconnect.

Ang browser extension ay mas makitid na bagay. Karaniwang binabago nito ang sarili nitong profile o ang proxy na sinusundan ng isang browser. Kaya maaaring mabigo ang isang browser habang patuloy na gumagana ang mga command-line tool, o kabaliktaran: wala talagang awtoridad ang extension na hawakan ang ibang antas. Kung aling antas ang binago nito ang nagtatakda kung aling tool ang masisira.

Sa alinmang paraan, ang lumang desisyon ay ginawa ng software na walang dahilan para bawiin ito. Ang tunnel ang nakikitang bahagi, at ito rin ang tanging bahagi na may malinis na paraan ng pagsasara. Ang lahat ng iba ay setting sa isang imbakan na mas matagal kaysa sa proseso, kaya ang pag-alis ng app ang tanging hakbang na bumabaligtad sa tatlo nang sabay. Ang pagbasa sa mga imbakang iyon bago mag-install muli ang nagpapalit ng sintomas tungo sa diagnosis.

Tatlong labi, tatlong magkaibang pagkasira

Ang unang labi ay proxy na walang tinuturo: naka-tsek pa rin ang LAN proxy box, o may configuration script URL na nakaturo sa isang localhost port kung saan wala nang prosesong nakikinig. Ipinapasa ng browser ang bawat kahilingan sa patay na port na iyon at natutulala hanggang magmukhang patay na network ang timeout. Ang pangalawa ay adapter na may default route pa rin, dahil ang TAP-Windows device o vendor routing driver ay nananatiling tunay na interface pagkatapos ng uninstall. Pinapanatili nito ang rutang ibinigay dito, at nawawala ang traffic sa isang tunnel na wala naman. Wala sa mga labi ang nagpapakilala; pareho silang eksaktong mukhang outage.

Ang pangatlo ay DNS, at nabibigo ito nang mas maaga kaysa sa dalawa. Kung ang resolver list ay naglalaman lamang ng mga server na maabot sa pamamagitan ng tunnel, nag-time out ang bawat lookup bago pa humiling ng isang pahina, kaya unreachable site ang iniuulat ng browser sa halip na patay na proxy. Alinman sa mga ito ang mayroon ka, wala sa kanila ang outage sa kahulugan ng network. Bawat isa ay labi na walang nagbawi, at bawat isa ay inaayos sa magkaibang lugar.

Dumaan pababa sa apat na antas

Magsimula sa pinakamalapit sa application at dumaan pababa, dahil sa ganoong pagkakasunod-sunod ng visibility nabibigo ang mga antas. Baguhin ang isang antas bawat pagsubok, at muling subukan pagkatapos ng bawat isa. Ang pag-reset ng lahat nang sabay ay kadalasang nagbabalik ng pagba-browse, at iniiwan kang hindi masabi kung aling labi ang dahilan, kaya muling lilikhain ng susunod na install ang parehong palaisipan. Ang pagkakasunod-sunod ay proxy, adapter, ruta, resolver.

Sa Windows, ang bawat pagsusuri ay isang utos na kasama na ng operating system, kaya wala nang kailangang i-install. Patakbuhin ang mga ito nang sunod-sunod at pagsamahin ang output, dahil ang apat na sagot ay may saysay lamang kapag magkatabi. Iniulat nila ang proxy, ang mga adapter, ang IPv4 ruta at ang resolver list, sa ganoong pagkakasunod-sunod:

netsh winhttp show proxy
Get-NetAdapter
route print -4
Get-DnsClientServerAddress

Kailangan ng Linux at macOS ng sarili nilang mga utos, at hindi sila mapagpapalit. Sa Linux, ang mga ruta ay mula sa ip route at ang resolver mula sa resolvectl status kung saan pagmamay-ari ito ng systemd-resolved, na bumabalik sa cat /etc/resolv.conf. Sa macOS, ang mga ruta ay mula sa netstat -rn, ang mga resolver mula sa scutil --dns, at ang system proxy mula sa scutil --proxy. Ang isang mambabasang macOS na magpapatakbo ng ip route ay makakakuha ng command not found, at ang /etc/resolv.conf doon ay generated na stub sa halip na ang awtoritatibong configuration. Suriin ang platform bago suriin ang antas, kung hindi ang unang utos ang magiging mismong natuklasan.

Para sa bawat antas, magtanong ng isa: nakatutok pa ba ang value na ito sa isang bagay na umiiral habang nakasara ang app? Ang proxy sa patay na port, adapter na walang tunnel, default route sa pamamagitan ng nakababang interface at resolver sa loob ng tunnel ay lahat sumasagot ng hindi. Sapat ang isang hindi para ipaliwanag ang sintomas, kaya mahalaga ang isang pagbabago bawat pagsubok.

Ang proxy ay hindi tunnel

Tumatanggap ang proxy ng kahilingan, kinukuha ito sa ibang lugar at ibinabalik ang tugon, ibig sabihin alam nito ang destinasyon at nakikita ang anumang hindi ini-encrypt ng site mismo. Hindi ito nagdadala ng ibang protocol. Hindi nito pinoprotektahan ang landas maliban kung gumagamit na ng TLS ang destinasyon. At maaari itong baguhin ng kahit anong nag-install nito, nang wala kang kinalaman.

Binabago ng pagkakaibang iyon ang tanong na dapat itanong. Kapag may naiwang proxy, alamin kung aling programa ang patuloy na gumagabay sa browser mo kaysa sa kung bukas ang tunnel. Maaaring perpektong malusog ang tunnel at ganap na walang kaugnayan sa pagkasira.

Kung gusto mong malaman ang aktwal na ginawa ng gayong client, obserbahan ito kaysa basahin ang dashboard nito. Itinatala ng Process Monitor kung aling registry key at file ang hinahawakan nito, samantalang inilalantad ng packet capture kung saan napunta ang traffic nito. Pareho silang ordinaryong tool, at parehong sinasagot ang tanong ng labi nang mas mahusay kaysa sa anumang status light. Wala sa kanila ang nangangailangan na tumatakbo pa ang app.

Alisin ang component, hindi ang ebidensya

Ang matibay na lunas ay alisin ang bagay na nagsulat ng setting. I-uninstall ang app, tanggalin ang virtual adapter na idinagdag nito, i-clear ang proxy at ang resolver list, pagkatapos i-reboot at subukan habang naka-uninstall pa rin ang app. Kung gumagana ang pagba-browse sa puntong iyon, natagpuan mo ang sanhi sa halip na pansamantalang solusyon. Isulat kung aling antas ang luma, dahil ang parehong vendor ay madalas nagpapadala ng parehong pagkakamali nang dalawang beses.

Kung bumalik ang sintomas pagkatapos mong i-install ang susunod na client, dumaan muli sa apat na antas bago magpasyang may sinira ang serbisyo. Karaniwang naroon pa rin ang ebidensya, sa isa sa apat na lugar. Ang pangalawang app ay hindi gumagawa ng ikalimang antas; binabago nito ang isa sa apat.

Ang muling pag-install ay nagre-reset ng proxy pero hindi ng lumang adapter, at maaari itong mag-iwan ng dalawang resolver sa listahan. Ang kawalan ng simetryang iyon ang dahilan kung bakit mas mabuti ang uninstall-at-subukan kaysa sa reset-everything button. Nagbibigay din ito sa iyo ng baseline na paghahambingan sa susunod na pagbagsak ng koneksyon.