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

Du prøver ein gratis VPN-klient eller ei nettlesarutviding i ei veke, slår han av, og internettet stoppar. Wi-Fi-ikonet viser framleis ei tilkopling, andre einingar på same rutaren fungerer fint, og det einaste som får nettlesinga tilbake er å slå på appen igjen eller avinstallere han. Det mønsteret er ikkje kryptering som skaper ein avhengigheit. Det er konfigurasjon som appen skreiv ned ein stad der tunnelen ikkje eig noko.

Klienten endrar innstillingar som tunnelen ikkje eig

Ein personvernklient på Windows eller macOS rører vanlegvis tre stader på ein gong. Han set system-HTTP-proxyen, det same feltet som Internettval viser. Han installerer ein virtuell adapter, ofte ein TAP-drivar, slik at han kan fange pakkar. Og han skriv om oppløysarlista, medan berre tunnelen forsvinn når du trykkjer på kople frå.

Ei nettlesarutviding er noko trongare. Ho endrar vanlegvis sin eigen profil eller proxyen som éin nettlesar følgjer. Derfor kan éin nettlesar feile medan kommandolinjeverktøy held fram med å virke, eller omvendt: utvidinga hadde aldri myndigheit til å røre dei andre laga. Kva lag ho endra, avgjer kva verktøy som bryt saman.

Uansett kven, den gamle avgjerda vart teken av programvare som ikkje hadde noka grunn til å angre han. Tunnelen var den synlege delen, og han var også den einaste delen med ein rein avslutningsveg. Alt anna er ei innstilling i eit lager som overlever prosessen, så å fjerne appen er det eine steget som reverserer alle tre på ein gong. Å lese dei lagra før du installerer noko på nytt er det som gjer symptomet om til ei diagnose.

Tre restar, tre ulike feil

Den første resten er ein proxy som peikar på ingenting: LAN-proxyboksen er framleis avkryssa, eller ein konfigurasjonsskript-URL peikar på ein localhost-port der ingen prosess lyttar lenger. Nettlesaren sender kvar førespurnad til den døde porten og heng til tidsavbrotet ser ut som eit dødt nettverk. Den andre er ein adapter som framleis eig ei standardrute, fordi ei TAP-Windows-eining eller ein leverandørruter-drivar blir verande eit verkeleg grensesnitt etter ein avinstallasjon. Han held på ruta han fekk, og trafikken forsvinn inn i ein tunnel som ikkje er der. Ingen av restane kunngjer seg sjølv; begge ser nøyaktig ut som eit avbrot.

Den tredje er DNS, og han feilar tidlegare enn dei to andre. Viss oppløysarlista berre inneheld tenarar som er nåbare gjennom tunnelen, går kvar oppslag ut på tid før ei einaste side blir beden om, så nettlesaren rapporterer ein utilgjengeleg stad i staden for ein død proxy. Kva enn du har, ingen av dei er eit avbrot i nettverksforstand. Kvar av dei er ein rest som ingen har trekt tilbake, og kvar av dei blir reparert på ein annan stad.

Arbeid deg nedover dei fire laga

Start nærast programmet og arbeid nedover, fordi laga feilar i den synlegheitsrekkjefølgja. Endre eitt lag per test, og test på nytt etter kvart einaste. Å nullstille alt på ein gong får vanlegvis nettlesinga tilbake, og det lèt deg ikkje seie kva rest som var årsaka, så neste installasjon skaper same gåta på nytt. Rekkjefølgja er proxy, adapter, ruter, oppløysarar.

På Windows er kvar sjekk ein einaste kommando som følgjer med operativsystemet, så ingenting må installerast. Køyr dei i rekkjefølgje og hald utdata saman, fordi dei fire svara berre gir meining side om side. Dei rapporterer proxyen, adapterane, IPv4-rutene og oppløysarlista, i den rekkjefølgja:

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

Linux og macOS treng sine eigne kommandoar, og dei kan ikkje bytast om. På Linux kjem rutene frå ip route og oppløysaren frå resolvectl status der systemd-resolved eig han, med tilbakefall til cat /etc/resolv.conf. På macOS kjem rutene frå netstat -rn, oppløysarane frå scutil --dns og systemproxyen frå scutil --proxy. Ein macOS-lesar som køyrer ip route får command not found, og /etc/resolv.conf der er ein generert stub i staden for den autoritative konfigurasjonen. Sjekk plattforma før du sjekkar laget, elles blir den første kommandoen sjølve funnet.

Spør om eitt og same for kvart lag: peikar denne verdien framleis på noko som finst medan appen er lukka? Ein proxy på ein død port, ein adapter utan tunnel, ei standardrute gjennom eit grensesnitt som er nede og ein oppløysar inne i tunnelen svarar alle nei. Eit einaste nei er nok til å forklare symptomet, og derfor er éi endring per test viktig.

Ein proxy er ikkje ein tunnel

Ein proxy tek imot ein førespurnad, hentar han ein annan stad og gir svaret tilbake, som betyr at han kjenner målet og ser alt nettstaden ikkje krypterte sjølv. Han ber ikkje andre protokollar. Han verner ikkje vegen med mindre målet alt brukar TLS. Og han kan endrast av det som helst installerte han, utan at du er involvert.

Den skilnaden endrar spørsmålet som er verdt å stille. Når ein proxy blir liggjande att, finn ut kva program som framleis styrer nettlesaren din i staden for om tunnelen er oppe. Tunnelen kan vere heilt frisk og heilt irrelevant for feilen.

Vil du vite kva ein slik klient faktisk gjorde, observer han i staden for å lese dashbordet hans. Process Monitor registrerer kva registernøklar og filer han rører, medan ei pakkefangst avdekkjer kvar trafikken hans gjekk. Begge er vanlege verktøy, og begge svarar på rest-spørsmålet betre enn noko statuslys. Ingen av dei krev at appen framleis køyrer.

Fjern komponenten, ikkje provet

Den varige løysinga er å fjerne det som skreiv innstillinga. Avinstaller appen, slett den virtuelle adapteren han la til, tøm proxyen og oppløysarlista, start på nytt og test med appen framleis avinstallert. Viss nettlesinga fungerer då, har du funne årsaka i staden for ein omveg. Noter kva lag som var gammalt, fordi same leverandør ofte leverer same feilen to gonger.

Kjem symptomet tilbake etter at du installerer neste klient, gå dei fire laga gjennom på nytt før du avgjer at tenesta øydela noko. Provet ligg vanlegvis framleis der, på ein av dei fire stadene. Ein andre app skaper ikkje eit femte lag; han endrar eitt av dei fire.

Å installere på nytt nullstiller proxyen men ikkje ein gammal adapter, og det kan lære to oppløysarar att i lista. Den asymmetrien er grunnen til at avinstaller-så-test slår ein nullstill-alt-knapp. Det gir deg også ein grunnlinje å samanlikne med neste gong tilkoplinga dett ut.