Werk die internet net met die VPN-program aan? Ondersoek vier lae

Jy probeer 'n gratis VPN-kliënt of 'n blaaieruitbreiding vir 'n week, skakel dit af, en die internet stop. Die Wi-Fi-ikoon wys steeds 'n verbinding, ander toestelle op dieselfde router werk fyn, en die enigste dinge wat die web terugbring is om die program weer aan te skakel of dit te verwyder. Daardie patroon is nie enkripsie wat 'n afhanklikheid skep nie. Dit is konfigurasie wat die program iewers geskryf het waar die tonnel nie eienaar is nie.

Die kliënt verander instellings wat nie aan die tonnel behoort nie

'n Privaatheidskliënt op Windows of macOS raak gewoonlik drie plekke gelyk aan. Dit stel die stelsel se HTTP-proxy op, dieselfde veld wat Internet Options wys. Dit installeer 'n virtuele adapter, dikwels 'n TAP-drywer, sodat dit pakkette kan vang. En dit herskryf die oplosserlys, terwyl net die tonnel verdwyn wanneer jy op disconnect druk.

'n Blaaieruitbreiding is 'n smaller ding. Dit verander gewoonlik net sy eie profiel of die proxy wat een blaaier volg. Daarom kan een blaaier faal terwyl opdragreël-gereedskap werk, of omgekeerd: die uitbreiding het nooit die mag gehad om die ander lae te raak nie. Watter laag dit verander het, bepaal watter gereedskap breek.

In elk geval is die verouderde besluit geneem deur sagteware wat geen rede gehad het om dit terug te draai nie. Die tonnel was die sigbare deel, en dit was ook die enigste deel met 'n skoon afsluitpad. Al die res is 'n instelling in 'n stoor wat die proses oorleef, so die program te verwyder is die een stap wat al drie gelyk terugdraai. Om daardie store te lees voordat jy iets herinstalleer, is wat die simptoom in 'n diagnose verander.

Drie oorblyfsels, drie verskillende foute

Die eerste oorblyfsel is 'n proxy wat na niks wys: die LAN-proxy-boks is steeds aangevink, of 'n konfigurasie-skrip-URL wys na 'n localhost-poort waar geen proses meer luister nie. Die blaaier stuur elke versoek na daardie dooie poort en hang tot die tydsverloop soos 'n dooie netwerk lyk. Die tweede is 'n adapter wat steeds 'n verstekroete besit, omdat 'n TAP-Windows-toestel of 'n vervaardiger se roeteerder-drywer ná 'n deïnstallasie 'n regte koppelvlak bly. Dit hou die roete wat dit gekry het, en verkeer verdwyn in 'n tonnel wat nie daar is nie. Nie een van die twee oorblyfsels kondig homself aan nie; albei lyk presies soos 'n onderbreking.

Die derde is DNS, en dit faal vroeër as die ander twee. As die oplosserlys net bedieners bevat wat deur die tonnel bereikbaar is, verstryk elke opsoek voordat 'n enkele bladsy aangevra word, so die blaaier rapporteer 'n onbereikbare werf eerder as 'n dooie proxy. Watter een jy ook het, nie een is 'n onderbreking in die netwerksin nie. Elkeen is 'n oorblyfsel wat niemand herroep het nie, en elkeen word op 'n ander plek herstel.

Werk die vier lae van bo na onder deur

Begin naaste aan die toepassing en werk af, want die lae faal in daardie volgorde van sigbaarheid. Verander een laag per toets, en toets weer ná elkeen. Om alles gelyk te herstel bring gewoonlik die web terug, en dit laat jou nie in staat om te sê watter oorblyfsel dit veroorsaak het nie, so die volgende installasie skep dieselfde raaisel. Die volgorde is proxy, adapters, roetes, oplossers.

Op Windows is elke kontrole 'n enkele opdrag wat saam met die bedryfstelsel kom, so niks hoef geïnstalleer te word nie. Voer hulle in volgorde uit en hou die uitvoer bymekaar, want die vier antwoorde maak net sin langs mekaar. Hulle rapporteer die proxy, die adapters, die IPv4-roetes en die oplosserlys, in daardie volgorde:

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

Linux en macOS het hul eie opdragte nodig, en hulle is nie uitruilbaar nie. Op Linux kom die roetes van ip route en die oplosser van resolvectl status waar systemd-resolved dit besit, met 'n terugval na cat /etc/resolv.conf. Op macOS kom die roetes van netstat -rn, die oplossers van scutil --dns, en die stelsel-proxy van scutil --proxy. 'n macOS-leser wat ip route hardloop, kry command not found, en /etc/resolv.conf daar is 'n gegenereerde stomp eerder as die gesaghebbende konfigurasie. Kontroleer die platform voordat jy die laag kontroleer, anders word die eerste opdrag die bevinding.

Vra vir elke laag een vraag: wys hierdie waarde steeds na iets wat bestaan terwyl die program toegemaak is? 'n Proxy by 'n dooie poort, 'n adapter sonder 'n tonnel, 'n verstekroete deur 'n af koppelvlak en 'n oplosser binne die tonnel antwoord almal nee. Enige enkele nee is genoeg om die simptoom te verduidelik, daarom maak een verandering per toets saak.

'n Proxy is nie 'n tonnel nie

'n Proxy aanvaar 'n versoek, haal dit elders en gee die antwoord terug, wat beteken dit ken die bestemming en sien alles wat die werf nie self geënkripteer het nie. Dit dra nie ander protokolle nie. Dit beskerm nie die pad nie tensy die bestemming reeds TLS gebruik. En dit kan verander word deur wat dit ook al geïnstalleer het, sonder jou betrokkenheid.

Daardie onderskeid verander die vraag wat die moeite werd is om te vra. Wanneer 'n proxy agterbly, vind uit watter program jou blaaier steeds stuur eerder as of die tonnel op is. Die tonnel kan heeltemal gesond en heeltemal irrelevant vir die fout wees.

As jy wil weet wat so 'n kliënt werklik gedoen het, waarneem dit eerder as om sy paneel te lees. Process Monitor teken aan watter registersleutels en lêers dit raak, terwyl 'n pakketopname onthul waarheen sy verkeer gegaan het. Albei is gewone gereedskap, en albei antwoord die oorblyfsel-vraag beter as enige statuslig. Nie een vereis dat die program nog loop nie.

Verwyder die komponent, nie die bewyse nie

Die blywende oplossing is om die ding te verwyder wat die instelling geskryf het. Deïnstalleer die program, verwyder die virtuele adapter wat dit bygevoeg het, maak die proxy en die oplosserlys skoon, herbegin dan en toets met die program steeds gedeïnstalleer. As die web op daardie punt werk, het jy die oorsaak gevind eerder as 'n workaround. Hou 'n nota van watter laag verouderd was, want dieselfde vervaardiger is geneig om dieselfde fout twee keer te maak.

As die simptoom terugkom nadat jy die volgende kliënt installeer, stap die vier lae weer deur voordat jy besluit dat die diens iets gebreek het. Die bewyse is gewoonlik steeds daar, in een van die vier plekke. 'n Tweede program skep nie 'n vyfde laag nie; dit verander een van die vier.

Herinstallasie stel die proxy terug, maar nie 'n verouderde adapter nie, en dit kan twee oplossers in die lys laat. Daardie asimmetrie is waarom deïnstalleer-dan-toets beter is as 'n herstel-alles-knoppie. Dit gee jou ook 'n basislyn om teen te vergelyk die volgende keer wanneer die verbinding val.