Fungerar internet bara med VPN-appen påslagen? Kontrollera fyra lager

Du prövar en gratis VPN-klient eller ett webbläsartillägg i en vecka, stänger av det, och internet slutar fungera. Wi-Fi-ikonen visar fortfarande en anslutning, andra enheter på samma router fungerar, och det enda som får surfandet tillbaka är att aktivera appen igen eller avinstallera den. Det mönstret är inte kryptering som skapar ett beroende. Det är konfiguration som appen skrev någonstans där tunneln inte äger den.

Klienten ändrar inställningar som tunneln inte äger

En integritetsklient på Windows eller macOS rör oftast tre ställen samtidigt. Den ställer in systemets HTTP-proxy, samma fält som Internet Options visar. Den installerar en virtuell adapter, ofta en TAP-drivrutin, så att den kan fånga paket. Och den skriver om resolverlistan, medan det bara är tunneln som försvinner när du klickar på koppla från.

Ett webbläsartillägg är en snävare sak. Det ändrar normalt sin egen profil eller den proxy som en webbläsare följer. Därför kan en enda webbläsare sluta fungera medan kommandoradsverktyg fortsätter att fungera, eller tvärtom: tillägget hade aldrig befogenhet att röra de andra lagren. Vilket lager det ändrade avgör vilka verktyg som går sönder.

Hur som helst fattades det kvarvarande beslutet av programvara som inte hade någon anledning att ångra det. Tunneln var den synliga delen, och den var också den enda delen med en ren avstängningsväg. Allt annat är en inställning i ett lager som lever längre än processen, så att ta bort appen är det enda steget som vänder alla tre på en gång. Att läsa de lagren innan du installerar om något är det som gör symtomet till en diagnos.

Tre rester, tre olika fel

Den första resten är en proxy som pekar på ingenting: LAN-proxyrutan fortfarande ikryssad, eller en URL till ett konfigurationsskript som pekar på en localhost-port där ingen process lyssnar längre. Webbläsaren skickar varje begäran till den döda porten och hänger sig tills tidsgränsen ser ut som ett dött nätverk. Den andra är en adapter som fortfarande äger en standardrutt, eftersom en TAP-Windows-enhet eller en leverantörs routningsdrivrutin förblir ett riktigt gränssnitt efter en avinstallation. Den behåller rutten den fick, och trafiken försvinner in i en tunnel som inte finns. Ingen av resterna annonserar sig; båda ser exakt ut som ett avbrott.

Den tredje är DNS, och den fallerar tidigare än de andra två. Om resolverlistan bara innehåller servrar som nås via tunneln, tar varje uppslag en timeout innan en enda sida begärs, så webbläsaren rapporterar en onåbar webbplats i stället för en död proxy. Vilken du än har, ingen av dem är ett avbrott i nätverkets mening. Var och en är en rest som ingen återkallade, och var och en repareras på ett annat ställe.

Arbeta dig ned genom de fyra lagren

Börja närmast applikationen och arbeta nedåt, eftersom lagren fallerar i den synlighetsordningen. Ändra ett lager per test och testa om efter varje. Att återställa allt på en gång återställer oftast surfandet, och det lämnar dig oförmögen att säga vilken rest som orsakade det, så nästa installation skapar samma pussel. Ordningen är proxy, adaptrar, rutter, resolvers.

På Windows är varje kontroll ett enda kommando som följer med operativsystemet, så inget behöver installeras. Kör dem i ordning och håll utdata tillsammans, eftersom de fyra svaren bara ger mening sida vid sida. De rapporterar proxyn, adaptrarna, IPv4-rutterna och resolverlistan, i den ordningen:

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

Linux och macOS behöver sina egna kommandon, och de är inte utbytbara. På Linux kommer rutterna från ip route och resolvern från resolvectl status där systemd-resolved äger den, med fallback till cat /etc/resolv.conf. På macOS kommer rutterna från netstat -rn, resolverna från scutil --dns och systemproxyn från scutil --proxy. En macOS-läsare som kör ip route får command not found, och /etc/resolv.conf där är en genererad stubbe snarare än den auktoritativa konfigurationen. Kontrollera plattformen innan du kontrollerar lagret, annars blir det första kommandot själva fyndet.

För varje lager, ställ en fråga: pekar det här värdet fortfarande på något som finns medan appen är stängd? En proxy på en död port, en adapter utan tunnel, en standardrutt genom ett nedkopplat gränssnitt och en resolver inuti tunneln svarar alla nej. Ett enda nej räcker för att förklara symtomet, vilket är varför en ändring per test spelar roll.

En proxy är inte en tunnel

En proxy tar emot en begäran, hämtar den någon annanstans och lämnar tillbaka svaret, vilket betyder att den känner till målet och ser allt som webbplatsen inte själv krypterade. Den bär inte andra protokoll. Den skyddar inte vägen om målet inte redan använder TLS. Och den kan ändras av vad som helst som installerade den, utan din inblandning.

Den distinktionen ändrar frågan som är värd att ställa. När en proxy ligger kvar, ta reda på vilket program som fortfarande styr din webbläsare i stället för om tunneln är uppe. Tunneln kan vara helt frisk och helt irrelevant för felet.

Om du vill veta vad en sådan klient faktiskt gjorde, observera den i stället för att läsa dess instrumentpanel. Process Monitor registrerar vilka registerposter och filer den rör, medan en paketinsamling avslöjar vart dess trafik tog vägen. Båda är vanliga verktyg, och båda svarar på restfrågan bättre än någon statuslampa. Ingen av dem kräver att appen fortfarande körs.

Ta bort komponenten, inte beviset

Den hållbara lösningen är att ta bort det som skrev inställningen. Avinstallera appen, radera den virtuella adaptern den lade till, rensa proxyn och resolverlistan, starta sedan om och testa med appen fortfarande avinstallerad. Om surfandet fungerar då har du hittat orsaken i stället för en tillfällig lösning. Anteckna vilket lager som var inaktuellt, eftersom samma leverantör tenderar att leverera samma misstag två gånger.

Om symtomet kommer tillbaka efter att du installerat nästa klient, gå igenom de fyra lagren igen innan du bestämmer att tjänsten förstörde något. Beviset finns oftast kvar, på en av de fyra platserna. En andra app skapar inte ett femte lager; den ändrar ett av de fyra.

Att installera om återställer proxyn men inte en inaktuell adapter, och det kan lämna två resolvers i listan. Den asymmetrin är varför avinstallera-sedan-testa slår en återställ-allt-knapp. Det ger dig också en baslinje att jämföra med nästa gång anslutningen faller.