Internett virker 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 fungerer, og det eneste som får nettlesingen tilbake, er å slå appen på igjen eller avinstallere den. Det mønsteret er ikke kryptering som har skapt en avhengighet. Det er konfigurasjon appen skrev et sted tunnelen ikke eier.

Klienten endrer innstillinger tunnelen ikke eier

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

En nettleserutvidelse er en smalere sak. 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 redigerte avgjør hvilke verktøy som brytes.

Uansett hvordan, ble den foreldede avgjørelsen tatt av programvare som ikke hadde 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 samtidig. Å lese de lagrene før du installerer noe på nytt er det som gjør symptomet til en diagnose.

Tre rester, tre forskjellige feil

Den første resten er en proxy som peker på ingenting: LAN-proxyboksen fortsatt avkrysset, eller en URL til et konfigurasjonsskript rettet mot en localhost-port der ingen prosess lenger lytter. Nettleseren videresender hver forespørsel til den døde porten og stopper 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ørs rutingsdriver forblir et reelt grensesnitt etter en avinstallering. Den beholder ruten den fikk, og trafikken forsvinner inn i en tunnel som ikke finnes. Ingen av restene kunngjør seg selv; begge ser nøyaktig ut som et avbrudd.

Den tredje er DNS, og den feiler tidligere enn de to andre. Hvis resolverlisten bare inneholder servere som er tilgjengelige gjennom tunnelen, går hvert oppslag ut på tid før en eneste side er forespurt, så nettleseren rapporterer et utilgjengelig nettsted i stedet for en død proxy. Uansett hvilken du har, er ingen av dem et avbrudd i nettverksforstand. Hver er en rest ingen tilbakekalte, og hver repareres på et forskjellig sted.

Gå nedover de fire lagene

Start nærmest applikasjonen og arbeid deg nedover, fordi lagene feiler i nettopp den synlighetsrekkefølgen. Endre ett lag per test, og test på nytt etter hvert eneste. Å tilbakestille alt samtidig gjenoppretter vanligvis nettlesingen, men det gjør deg ute av stand til å si hvilken rest som forårsaket det, så neste installasjon gjenoppretter det samme puslespillet. Rekkefølgen er proxy, adaptere, ruter, resolvere.

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 samlet, fordi de fire svarene bare gir mening side om side. De rapporterer proxyen, adapterne, IPv4-rutene og resolverlisten, 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 resolveren fra resolvectl status der systemd-resolved eier den, med tilbakefall til cat /etc/resolv.conf. På macOS kommer rutene fra netstat -rn, resolverne 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 stubbe og ikke den autoritative konfigurasjonen. Sjekk plattformen før du sjekker laget, ellers blir den første kommandoen funnet.

For hvert lag, still ett spørsmål: 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 resolver inne i tunnelen svarer alle nei. Et enkelt 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 leverer svaret tilbake, som betyr at den kjenner destinasjonen og ser alt nettstedet ikke krypterte selv. Den bærer ikke andre protokoller. Den beskytter ikke veien med mindre destinasjonen 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.

Hvis du vil vite hva en slik klient faktisk gjorde, observer den i stedet for å lese dashbordet. Process Monitor registrerer hvilke registernøkler og filer den berører, mens en pakkefangst avslører hvor trafikken tok veien. Begge er vanlige verktøy, og begge svarer på restspø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 resolverlisten, og start deretter på nytt og test med appen fortsatt avinstallert. Hvis nettlesingen virker på det punktet, har du funnet årsaken og ikke en omvei. Noter hvilket lag som var foreldet, fordi samme leverandør har en tendens til å sende den samme feilen to ganger.

Hvis symptomet kommer tilbake etter at du installerer neste klient, gå gjennom de fire lagene igjen før du bestemmer at tjenesten ødela noe. Beviset er vanligvis fortsatt der, på ett av de fire stedene. En andre app lager ikke et femte lag; den redigerer ett av de fire.

Reinstallering tilbakestiller proxyen, men ikke en foreldet adapter, og den kan etterlate to resolvere i listen. Den asymmetrien er grunnen til at avinstaller-så-test slår en tilbakestill-alt-knapp. Den gir deg også en baseline å sammenligne med neste gang tilkoblingen faller.