Internett fungerer bare med VPN-appen på? Sjekk fire lag

Du prøver en gratis VPN-klient eller en nettleserutvidelse i en uke, slår den av, og internett stopper. Wi-Fi-ikonet viser fortsatt en tilkobling, andre enheter på samme ruter er fine, og det eneste som får nettlesingen tilbake er å slå på appen igjen eller avinstallere den. Det mønsteret er ikke kryptering som skaper en avhengighet. Det er konfigurasjon appen skrev et sted tunnelen ikke eier.

Klienten endrer innstillinger tunnelen ikke eier

En personvernklient på Windows eller macOS rører vanligvis tre steder samtidig. Den setter system-HTTP-proxyen, det samme feltet som Internettalternativer viser. Den installerer en virtuell adapter, ofte en TAP-driver, slik at den kan fange pakker. Og den skriver om oppløserlisten, mens bare tunnelen forsvinner når du trykker på koble fra.

En nettleserutvidelse er noe smalere. Den endrer vanligvis sin egen profil eller proxyen én nettleser følger. Derfor kan én nettleser feile mens kommandolinjeverktøy fortsetter å virke, eller omvendt: utvidelsen hadde aldri myndighet til å røre de andre lagene. Hvilket lag den endret, avgjør hvilke verktøy som bryter sammen.

Uansett hvem, den gamle avgjørelsen ble tatt av programvare som ikke hadde noen grunn til å angre den. Tunnelen var den synlige delen, og den var også den eneste delen med en ren avslutningsvei. Alt annet er en innstilling i et lager som overlever prosessen, så å fjerne appen er det ene trinnet som reverserer alle tre på en gang. Å lese de lagrene før du installerer noe på nytt er det som gjør symptomet om til en diagnose.

Tre rester, tre forskjellige feil

Den første resten er en proxy som peker på ingenting: LAN-proxyboksen er fortsatt avkrysset, eller en konfigurasjonsskript-URL peker på en localhost-port der ingen prosess lytter lenger. Nettleseren sender hver forespørsel til den døde porten og henger til tidsavbruddet ser ut som et dødt nettverk. Den andre er en adapter som fortsatt eier en standardrute, fordi en TAP-Windows-enhet eller en leverandørruterdriver blir værende et ekte grensesnitt etter en avinstallering. Den beholder ruten den fikk, og trafikken forsvinner inn i en tunnel som ikke er der. Ingen av restene kunngjør seg selv; begge ser nøyaktig ut som en driftsstans.

Den tredje er DNS, og den feiler tidligere enn de to andre. Hvis oppløserlisten bare inneholder servere som er nåbare gjennom tunnelen, går hvert oppslag ut på tid før en eneste side blir bedt om, så nettleseren rapporterer et utilgjengelig nettsted i stedet for en død proxy. Uansett hvilken du har, ingen av dem er en driftsstans i nettverksforstand. Hver av dem er en rest ingen har trukket tilbake, og hver av dem repareres på et annet sted.

Arbeid deg nedover de fire lagene

Start nærmest programmet og arbeid nedover, fordi lagene feiler i den synlighetsrekkefølgen. Endre ett lag per test, og test på nytt etter hvert eneste. Å nullstille alt på en gang gjenoppretter vanligvis nettlesingen, og det lar deg ikke si hvilken rest som var årsaken, så neste installasjon skaper samme gåte på nytt. Rekkefølgen er proxy, adaptere, ruter, oppløsere.

På Windows er hver sjekk én enkelt kommando som følger med operativsystemet, så ingenting må installeres. Kjør dem i rekkefølge og hold utdataene sammen, fordi de fire svarene bare gir mening side ved side. De rapporterer proxyen, adapterne, IPv4-rutene og oppløserlisten, i den rekkefølgen:

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

Linux og macOS trenger sine egne kommandoer, og de kan ikke byttes om. På Linux kommer rutene fra ip route og oppløseren fra resolvectl status der systemd-resolved eier den, med tilbakefall til cat /etc/resolv.conf. På macOS kommer rutene fra netstat -rn, oppløserne fra scutil --dns og systemproxyen fra scutil --proxy. En macOS-leser som kjører ip route får command not found, og /etc/resolv.conf der er en generert stub i stedet for den autoritative konfigurasjonen. Sjekk plattformen før du sjekker laget, ellers blir den første kommandoen selve funnet.

Still ett spørsmål for hvert lag: peker denne verdien fortsatt på noe som finnes mens appen er lukket? En proxy på en død port, en adapter uten tunnel, en standardrute gjennom et grensesnitt som er nede og en oppløser inne i tunnelen svarer alle nei. Et eneste nei er nok til å forklare symptomet, og derfor er én endring per test viktig.

En proxy er ikke en tunnel

En proxy tar imot en forespørsel, henter den et annet sted og gir svaret tilbake, som betyr at den kjenner målet og ser alt nettstedet ikke krypterte selv. Den bærer ikke andre protokoller. Den beskytter ikke veien med mindre målet allerede bruker TLS. Og den kan endres av det som helst installerte den, uten at du er involvert.

Den forskjellen endrer spørsmålet som er verdt å stille. Når en proxy blir liggende igjen, finn ut hvilket program som fortsatt styrer nettleseren din i stedet for om tunnelen er oppe. Tunnelen kan være helt frisk og helt irrelevant for feilen.

Vil du vite hva en slik klient faktisk gjorde, observer den i stedet for å lese dashbordet. Process Monitor registrerer hvilke registernøkler og filer den rører, mens en pakkefangst avslører hvor trafikken gikk. Begge er vanlige verktøy, og begge svarer på rest-spørsmålet bedre enn noe statuslys. Ingen av dem krever at appen fortsatt kjører.

Fjern komponenten, ikke beviset

Den varige løsningen er å fjerne det som skrev innstillingen. Avinstaller appen, slett den virtuelle adapteren den la til, tøm proxyen og oppløserlisten, start på nytt og test med appen fortsatt avinstallert. Hvis nettlesingen virker da, har du funnet årsaken i stedet for en omvei. Noter hvilket lag som var gammelt, fordi samme leverandør ofte leverer samme feil to ganger.

Kommer symptomet tilbake etter at du installerer neste klient, gå de fire lagene gjennom på nytt før du avgjør at tjenesten ødela noe. Beviset ligger vanligvis fortsatt der, på ett av de fire stedene. En andre app skaper ikke et femte lag; den endrer ett av de fire.

Å installere på nytt nullstiller proxyen men ikke en gammel adapter, og det kan etterlate to oppløsere i listen. Den asymmetrien er grunnen til at avinstaller-så-test slår en nullstill-alt-knapp. Det gir deg også en grunnlinje å sammenligne med neste gang tilkoblingen faller ut.