Internet töötab ainult VPN-rakendusega? Kontrolli nelja kihti

Proovid nädal aega tasuta VPN-klienti või brauserilaiendit, lülitad selle välja ja internet kaob. Wi-Fi ikoon näitab endiselt ühendust, teised seadmed samas ruuteris töötavad ning ainus, mis sirvimise tagasi toob, on rakenduse uuesti lubamine või selle desinstallimine. See muster ei ole krüpteerimisest tekkinud sõltuvus. See on seadistus, mille rakendus kirjutas kuhugi, mida tunnel ei halda.

Klient muudab seadistusi, mida tunnel ei halda

Privaatsusklient Windowsis või macOS-is puudutab tavaliselt kolme kohta korraga. Ta seab süsteemse HTTP-puhverserveri, mis on sama väli, mida Interneti-valikud näitavad. Ta paigaldab virtuaaladapteri, sageli TAP-draiveri, et pakette püüda. Ja ta kirjutab üle resolverite nimekirja, samal ajal kui ühenduse katkestamisel kaob ainult tunnel.

Brauserilaiend on kitsam asi. Tavaliselt muudab see oma profiili või puhverserverit, mida üks brauser järgib. Seetõttu võib üks brauser ebaõnnestuda, samal ajal kui käsurea tööriistad töötavad edasi, või vastupidi: laiendil ei olnudki voli teisi kihte puudutada. Millist kihti see muutis, määrab, millised tööriistad katkevad.

Mõlemal juhul tegi aegunud otsuse tarkvara, kellel polnud põhjust seda tagasi pöörata. Tunnel oli nähtav osa ja see oli ka ainus osa, millel oli korralik sulgemistee. Kõik muu on seade hoidlas, mis elab protsessist kauem, nii et rakenduse eemaldamine on ainus samm, mis pöörab kõik kolm korraga tagasi. Nende hoidlate lugemine enne uuesti paigaldamist muudab sümptomi diagnoosiks.

Kolm jääki, kolm erinevat riket

Esimene jääk on puhverserver, mis ei osuta kuhugi: LAN-i puhverserveri linnuke on endiselt sees või konfiguratsiooniskripti URL osutab localhosti pordile, kus enam ükski protsess ei kuula. Brauser suunab iga päringu sellesse surnud porti ja takerdub, kuni aegumine näeb välja nagu surnud võrk. Teine on adapter, millel on endiselt vaikemarsruut, sest TAP-Windowsi seade või tarnija marsruudidraiver jääb pärast desinstallimist tõeliseks liideseks. See hoiab talle antud marsruuti ja liiklus kaob tunnelisse, mida pole olemas. Kumbki jääk ei teata endast; mõlemad näevad välja täpselt nagu katkestus.

Kolmas on DNS ja see ebaõnnestub varem kui kaks teist. Kui resolverite nimekiri sisaldab ainult tunnelist kättesaadavaid servereid, aegub iga päring enne, kui ühtegi lehekülge küsitakse, nii et brauser teatab kättesaamatust saidist, mitte surnud puhverserverist. Ükskõik milline neist sul on, pole ükski neist võrgu tähenduses katkestus. Igaüks on jääk, mille keegi ei tühistanud, ja igaüks parandatakse erinevas kohas.

Liigu neli kihti alla

Alusta rakendusele kõige lähemalt ja liigu alla, sest kihid ebaõnnestuvad just selles nähtavuse järjekorras. Muuda iga testiga ühte kihti ja testi uuesti pärast igaüht. Kõige korraga lähtestamine taastab tavaliselt sirvimise ja jätab sind olukorda, kus ei oska öelda, milline jääk selle põhjustas, nii et järgmine paigaldus loob sama mõistatuse uuesti. Järjekord on puhverserver, adapterid, marsruudid, resolverid.

Windowsis on iga kontroll üks operatsioonisüsteemiga kaasas olev käsk, nii et midagi pole vaja paigaldada. Käivita need järjekorras ja hoia väljund koos, sest neli vastust on mõttekad ainult kõrvuti. Need raporteerivad puhverserveri, adapterid, IPv4-marsruudid ja resolverite nimekirja just selles järjekorras:

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

Linux ja macOS vajavad oma käske ja need ei ole omavahel vahetatavad. Linuxis tulevad marsruudid käsust ip route ja resolver käsust resolvectl status seal, kus systemd-resolved seda haldab, langedes tagasi käsule cat /etc/resolv.conf. macOS-is tulevad marsruudid käsust netstat -rn, resolverid käsust scutil --dns ja süsteemne puhverserver käsust scutil --proxy. macOS-i lugeja, kes käivitab ip route, saab vastuseks command not found, ja /etc/resolv.conf on seal genereeritud stub, mitte autoriteetne konfiguratsioon. Kontrolli platvormi enne kihi kontrollimist, muidu saab esimesest käsust leid.

Küsi iga kihi kohta ühte küsimust: kas see väärtus osutab endiselt millelegi, mis on olemas ka siis, kui rakendus on suletud? Puhverserver surnud pordil, adapter ilma tunnelita, vaikemarsruut läbi maas oleva liidese ja tunnelisisene resolver vastavad kõik eitavalt. Ükskõik milline eitav vastus on piisav sümptomi selgitamiseks, mistõttu on üks muudatus testi kohta oluline.

Puhverserver ei ole tunnel

Puhverserver võtab päringu vastu, toob selle mujalt ja annab vastuse tagasi, mis tähendab, et ta teab sihtkohta ja näeb kõike, mida sait ise ei krüpteerinud. Ta ei kanna muid protokolle. Ta ei kaitse teed, välja arvatud juhul, kui sihtkoht juba kasutab TLS-i. Ja seda võib muuta ükskõik mis selle paigaldas, ilma sinu osaluseta.

See erinevus muudab küsimust, mida tasub küsida. Kui puhverserver jääb maha, uuri, milline programm juhib endiselt sinu brauserit, mitte seda, kas tunnel on üleval. Tunnel võib olla täiesti terve ja rikke jaoks täiesti ebaoluline.

Kui tahad teada, mida selline klient tegelikult tegi, vaatle seda, mitte ära loe selle armatuurlauda. Process Monitor salvestab, milliseid registrivõtmeid ja faile see puudutab, samal ajal kui paketipüüdja näitab, kuhu selle liiklus läks. Mõlemad on tavalised tööriistad ja mõlemad vastavad jäägi küsimusele paremini kui ükski olekuriga. Kumbki ei nõua, et rakendus veel töötaks.

Eemalda komponent, mitte tõendid

Püsiv parandus on eemaldada see, mis seadistuse kirjutas. Desinstalli rakendus, kustuta selle lisatud virtuaaladapter, tühjenda puhverserver ja resolverite nimekiri, seejärel taaskäivita ja testi rakendusega endiselt desinstallituna. Kui sirvimine sel hetkel töötab, oled leidnud põhjuse, mitte möödaviigu. Pane kirja, milline kiht oli aegunud, sest sama tarnija kipub sama viga kaks korda tarnima.

Kui sümptom naaseb pärast järgmise kliendi paigaldamist, käi neli kihti uuesti läbi enne, kui otsustad, et teenus rikkus midagi. Tõendid on tavaliselt endiselt alles, ühes neist neljast kohast. Teine rakendus ei loo viiendat kihti; see muudab ühte neljast.

Uuesti paigaldamine lähtestab puhverserveri, aga mitte aegunud adapterit, ja see võib jätta nimekirja kaks resolverit. See asümmeetria on põhjus, miks desinstalli-ja-testi võidab lähtestamisnupu. See annab ka võrdlusaluse järgmiseks korraks, kui ühendus katkeb.