Csak bekapcsolt VPN-alkalmazással van internet? Nézze meg a négy réteget

Kipróbál egy ingyenes VPN-klienst vagy bővítményt egy hétig, kikapcsolja, és az internet megáll. A Wi-Fi ikon továbbra is kapcsolatot mutat, a router többi eszköze működik, és a böngészést csak két dolog hozza vissza: az alkalmazás újraindítása vagy eltávolítása. Ez a minta nem a titkosítás által létrehozott függőség. Ez olyan konfiguráció, amelyet az alkalmazás olyan helyre írt, amely nem az alagúté.

A kliens olyan beállításokat ír, amelyek nem az alagútéi

Egy adatvédelmi kliens Windows vagy macOS alatt általában három helyet érint egyszerre. Beállítja a rendszer HTTP-proxyját, ugyanazt a mezőt, amelyet az Internet Options mutat. Telepít egy virtuális adaptert, gyakran TAP-illesztőt, hogy csomagokat foghasson. És átírja a feloldók listáját, miközben a kapcsolat bontásakor csak az alagút tűnik el.

A böngészőbővítmény szűkebb dolog. Általában a saját profilját vagy azt a proxyt módosítja, amelyet egy böngésző követ. Ezért állhat le egyetlen böngésző, miközben a parancssori eszközök működnek, vagy fordítva: a bővítménynek soha nem volt joga a többi réteget érinteni. Az dönti el, mely eszközök romlanak el, hogy melyik réteget írta.

Akárhogy is, azt az elavult döntést olyan szoftver hozta, amelynek nem volt oka visszavonni. Az alagút volt a látható rész, és egyben az egyetlen rész, amelynek tiszta leállítási útja volt. Minden más olyan tárolóban lévő beállítás, amely túléli a folyamatot, ezért az alkalmazás eltávolítása az egyetlen lépés, amely mindhármat egyszerre fordítja vissza. Az a tény, hogy újratelepítés előtt elolvassuk ezeket a tárolókat, teszi a tünetből diagnózist.

Három maradék, három különböző hiba

Az első maradék egy proxy, amely semmire nem mutat: a LAN-proxy jelölőnégyzet még bejelölve, vagy egy konfigurációs szkript URL-je olyan localhost-portra mutat, ahol már nincs figyelő folyamat. A böngésző minden kérést arra a halott portra továbbít, és addig akad, amíg az időtúllépés halott hálózatnak látszik. A második egy adapter, amely még mindig alapértelmezett útvonalat birtokol, mert egy TAP-Windows eszköz vagy egy gyártói útválasztó-illesztő eltávolítás után is valódi interfész marad. Megtartja a kapott útvonalat, és a forgalom olyan alagútba tűnik el, amely nincs ott. Egyik maradék sem jelenti be magát; mindkettő pontosan kiesésnek látszik.

A harmadik a DNS, és ez korábban hibázik, mint a másik kettő. Ha a feloldók listáján csak az alagúton át elérhető kiszolgálók szerepelnek, minden lekérdezés időtúllépéssel zárul, mielőtt egyetlen oldalt kérnének, ezért a böngésző elérhetetlen oldalt jelez, nem halott proxyt. Bármelyikük van is Önnél, egyik sem kiesés hálózati értelemben. Mindegyik olyan maradék, amelyet senki nem vont vissza, és mindegyiket más helyen kell megjavítani.

Haladjon végig a négy rétegen

Az alkalmazáshoz legközelebbivel kezdje, és haladjon lefelé, mert a rétegek ebben a láthatósági sorrendben hibáznak. Tesztenként egy réteget változtasson, és minden után teszteljen újra. Ha mindent egyszerre állít vissza, a böngészés általában helyreáll, de nem tudja megmondani, melyik maradék okozta, így a következő telepítés ugyanazt a rejtvényt teremti meg. A sorrend: proxy, adapterek, útvonalak, feloldók.

Windows alatt minden ellenőrzés egyetlen parancs, amely az operációs rendszerrel érkezik, tehát semmit nem kell telepíteni. Futtassa őket sorrendben, és tartsa együtt a kimenetet, mert a négy válasz csak egymás mellett értelmezhető. A proxyt, az adaptereket, az IPv4-útvonalakat és a feloldók listáját jelentik, ebben a sorrendben:

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

A Linuxnak és a macOS-nek saját parancsai vannak, és ezek nem cserélhetők fel. Linuxon az útvonalak az ip route-ból jönnek, a feloldó pedig a resolvectl status-ból, ahol a systemd-resolved kezeli, végső esetben a cat /etc/resolv.conf-ból. macOS-en az útvonalak a netstat -rn-ből, a feloldók a scutil --dns-ből, a rendszerproxy pedig a scutil --proxy-ból. Az a macOS-olvasó, aki ip route-ot futtat, command not found üzenetet kap, és az /etc/resolv.conf ott generált váz, nem mérvadó konfiguráció. A réteg előtt a platformot ellenőrizze, különben az első parancs lesz a lelet.

Minden rétegnél egy kérdést tegyen fel: mutat-e ez az érték még olyasmire, ami létezik, miközben az alkalmazás zárva van? A halott porton álló proxy, az alagút nélküli adapter, a leállt interfészen át vezető alapértelmezett útvonal és az alagúton belüli feloldó mind nemmel válaszol. Egyetlen nem is elég a tünet magyarázatához, ezért számít, hogy tesztenként egy dolgot változtat.

A proxy nem alagút

A proxy fogad egy kérést, máshol letölti, és visszaadja a választ, ami azt jelenti, hogy ismeri a célt, és lát mindent, amit az oldal maga nem titkosított. Nem szállít más protokollokat. Nem védi az útvonalat, hacsak a cél már nem használ TLS-t. És bármi módosíthatja, ami telepítette, az Ön közreműködése nélkül.

Ez a különbség megváltoztatja a felteendő kérdést. Amikor proxy marad hátra, azt derítse ki, melyik program tereli még a böngészőjét, és ne azt, hogy áll-e az alagút. Az alagút lehet teljesen egészséges és teljesen lényegtelen a hiba szempontjából.

Ha tudni akarja, mit tett valójában egy ilyen kliens, figyelje meg, ahelyett hogy az irányítópultját olvasná. A Process Monitor rögzíti, mely beállításjegyzék-kulcsokat és fájlokat érinti, a csomagrögzítés pedig megmutatja, hová ment a forgalma. Mindkettő hétköznapi eszköz, és mindkettő jobban megválaszolja a maradék kérdését, mint bármely állapotjelző fény. Egyik sem igényli, hogy az alkalmazás még fusson.

Az összetevőt távolítsa el, nem a bizonyítékot

A tartós javítás az, hogy eltávolítjuk azt, ami a beállítást írta. Távolítsa el az alkalmazást, törölje a hozzáadott virtuális adaptert, tisztítsa meg a proxyt és a feloldók listáját, majd indítsa újra a gépet, és teszteljen úgy, hogy az alkalmazás továbbra is el van távolítva. Ha akkor működik a böngészés, megtalálta az okot, nem egy kerülő megoldást. Jegyezze fel, melyik réteg volt elavult, mert ugyanaz a gyártó hajlamos ugyanazt a hibát kétszer is kiszállítani.

Ha a tünet visszatér a következő kliens telepítése után, ismét járja végig a négy réteget, mielőtt eldönti, hogy a szolgáltatás tört el valamit. A bizonyíték általában még ott van, a négy hely valamelyikén. Egy második alkalmazás nem hoz létre ötödik réteget; a négy közül szerkeszt egyet.

Az újratelepítés visszaállítja a proxyt, de egy elavult adaptert nem, és két feloldót hagyhat a listán. Ez az aszimmetria az oka, hogy az eltávolítás-utáni teszt jobb, mint a mindent-visszaállít gomb. Alapot is ad az összehasonlításhoz, amikor legközelebb megszakad a kapcsolat.