Virker internettet kun med VPN-appen slået til? Tjek fire lag

Du prøver en gratis VPN-klient eller en browserudvidelse i en uge, slår den fra, og internettet stopper. Wi-Fi-ikonet viser stadig forbindelse, andre enheder på samme router fungerer, og det eneste, der bringer browsing tilbage, er at aktivere appen igen eller afinstallere den. Det mønster er ikke kryptering, der skaber en afhængighed. Det er konfiguration, som appen skrev et sted, som tunnelen ikke ejer.

Klienten ændrer indstillinger, som tunnelen ikke ejer

En privatlivsklient på Windows eller macOS rører normalt tre steder på én gang. Den sætter systemets HTTP-proxy, det samme felt som Internet Options viser. Den installerer en virtuel adapter, ofte en TAP-driver, så den kan opfange pakker. Og den overskriver resolverlisten, mens kun tunnelen forsvinder, når du trykker afbryd.

En browserudvidelse er en smallere ting. Den ændrer normalt sin egen profil eller den proxy, som én browser følger. Derfor kan én browser fejle, mens kommandolinjeværktøjer bliver ved med at virke, eller omvendt: udvidelsen havde aldrig myndighed til at røre de andre lag. Hvilket lag den redigerede, afgør hvilke værktøjer der knækker.

Under alle omstændigheder blev den forældede beslutning taget af software, som ikke havde nogen grund til at fortryde den. Tunnelen var den synlige del, og den var også den eneste del med en ren nedlukningsvej. Alt andet er en indstilling i et lager, der overlever processen, så at fjerne appen er det ene skridt, der ruller alle tre tilbage på én gang. At læse de lagre, før du geninstallerer noget, er det, der gør symptomet til en diagnose.

Tre rester, tre forskellige fejl

Den første rest er en proxy, der peger på ingenting: LAN-proxyfeltet er stadig markeret, eller en URL til et konfigurationsscript peger på en localhost-port, hvor ingen proces lytter længere. Browseren sender hver anmodning til den døde port og går i stå, indtil timeoutet ligner et dødt netværk. Den anden er en adapter, der stadig ejer en standardrute, fordi en TAP-Windows-enhed eller en leverandørs routingdriver forbliver en rigtig grænseflade efter en afinstallation. Den beholder den rute, den fik, og trafikken forsvinder ind i en tunnel, der ikke er der. Ingen af resterne melder sig selv; begge ser præcis ud som et udfald.

Den tredje er DNS, og den fejler tidligere end de to andre. Hvis resolverlisten kun indeholder servere, der kan nås gennem tunnelen, udløber hvert opslag, før en enkelt side bliver bedt om, så browseren rapporterer et utilgængeligt websted i stedet for en død proxy. Uanset hvilken du har, er ingen af dem et udfald i netværksforstand. Hver er en rest, som ingen tilbagekaldte, og hver repareres et andet sted.

Gå de fire lag igennem

Start tættest på applikationen og arbejd nedad, fordi lagene fejler i netop den rækkefølge af synlighed. Skift ét lag pr. test, og test igen efter hvert. At nulstille alt på én gang gendanner normalt browsing, og det efterlader dig ude af stand til at sige, hvilken rest der gjorde det, så den næste installation genskaber det samme puslespil. Rækkefølgen er proxy, adaptere, ruter, resolvere.

På Windows er hver kontrol en enkelt kommando, der følger med styresystemet, så intet skal installeres. Kør dem i rækkefølge, og hold outputtet sammen, fordi de fire svar kun giver mening side om side. De rapporterer proxyen, adapterne, IPv4-ruterne og resolverlisten i den rækkefølge:

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

Linux og macOS har brug for deres egne kommandoer, og de kan ikke byttes. På Linux kommer ruterne fra ip route og resolveren fra resolvectl status, hvor systemd-resolved ejer den, med tilbagefald til cat /etc/resolv.conf. På macOS kommer ruterne fra netstat -rn, resolverne fra scutil --dns og systemproxyen fra scutil --proxy. En macOS-læser, der kører ip route, får command not found, og /etc/resolv.conf der er en genereret stub, ikke den autoritative konfiguration. Tjek platformen, før du tjekker laget, ellers bliver den første kommando fundet.

Stil ét spørgsmål for hvert lag: peger denne værdi stadig på noget, der findes, mens appen er lukket? En proxy på en død port, en adapter uden tunnel, en standardrute gennem en nede grænseflade og en resolver inde i tunnelen svarer alle nej. Et enkelt nej er nok til at forklare symptomet, og derfor betyder én ændring pr. test noget.

En proxy er ikke en tunnel

En proxy accepterer en anmodning, henter den andre steder og giver svaret tilbage, hvilket betyder, at den kender destinationen og ser alt, som webstedet ikke selv krypterede. Den bærer ikke andre protokoller. Den beskytter ikke vejen, medmindre destinationen allerede bruger TLS. Og den kan ændres af hvad der end installerede den, uden din medvirken.

Den forskel ændrer det spørgsmål, der er værd at stille. Når en proxy bliver tilbage, find ud af, hvilket program der stadig styrer din browser, i stedet for om tunnelen er oppe. Tunnelen kan være helt sund og fuldstændig irrelevant for fejlen.

Hvis du vil vide, hvad sådan en klient faktisk gjorde, så observer den i stedet for at læse dens dashboard. Process Monitor registrerer, hvilke registreringsdatabasenøgler og filer den rører, mens en pakkeoptagelse afslører, hvor dens trafik gik hen. Begge er almindelige værktøjer, og begge besvarer rest-spørgsmålet bedre end nogen statuslampe. Ingen af dem kræver, at appen stadig kører.

Fjern komponenten, ikke beviserne

Den holdbare løsning er at fjerne det, der skrev indstillingen. Afinstaller appen, slet den virtuelle adapter, den tilføjede, ryd proxyen og resolverlisten, genstart derefter og test med appen stadig afinstalleret. Hvis browsing virker på det tidspunkt, har du fundet årsagen og ikke en omvej. Noter, hvilket lag der var forældet, fordi den samme leverandør har en tendens til at lave den samme fejl to gange.

Hvis symptomet vender tilbage, efter du installerer den næste klient, gå de fire lag igennem igen, før du beslutter, at tjenesten har ødelagt noget. Beviserne er normalt stadig der, på et af de fire steder. En anden app skaber ikke et femte lag; den redigerer et af de fire.

Geninstallation nulstiller proxyen, men ikke en forældet adapter, og den kan efterlade to resolvere på listen. Den asymmetri er grunden til, at afinstaller-og-test slår en nulstil-alt-knap. Den giver dig også en baseline at sammenligne med, næste gang forbindelsen falder ud.