Ynternet wurket allinnich mei de VPN-app oan? Kontrolearje fjouwer lagen

Jo probearje in wike lang in fergees VPN-klant of in browserútwreiding, jo sette it út, en it ynternet stops. It Wi-Fi-ikoan lit noch in ferbining sjen, oare apparaten op deselde router wurkje wol, en it iennige dat sneupen werom bringt, is de app opnij ynskeakelje of fuortsmite. Dat patroan is gjin fersifering dy’t in ôfhinklikens makket. It binne ynstellings dy’t de app earne skreau dêr’t de tunnel gjin eigener fan is.

De klant bewurket ynstellings dy’t de tunnel net besit

In privacy-klant op Windows of macOS rekket meastentiids tagelyk trije plakken oan. It set de HTTP-proxy fan it systeem, itselde fjild dat Internet Options sjen lit. It ynstallearret in firtuele adapter, faak in TAP-stjoerder, sadat it pakketten fange kin. En it skriuwt de resolverlist opnij, wylst by it yndrukken fan ferbine ferbrekke allinnich de tunnel ferdwynt.

In browserútwreiding is in smeller ding. It feroaret meastentiids syn eigen profyl of de proxy dy’t ien browser folget. Dêrom kin ien browser mislearje wylst kommandorigel-ark trochwurkje, of oarsom: de útwreiding hie nea it foech om de oare lagen oan te reitsjen. Hokker laach it bewurke, beslút hokker ark stikken geane.

Hoe dan ek, de ferâldere beslissing waard nomd troch software dy’t gjin reden hie om it werom te draaien. De tunnel wie it sichtbere part, en it wie ek it iennige part mei in skjinne ôfslútpaad. Al it oare is in ynstelling yn in opslach dat it proses oerlibbet, dus it fuortsmite fan de app is de iene stap dy’t alle trije tagelyk weromdraait. It lêzen fan dy opslaggen foar’t jo wat opnij ynstallearje, is wat it symptoom yn in diagnoaze feroaret.

Trije oerbliuwsels, trije ferskillende flatsen

It earste oerbliuwsel is in proxy dy’t nei neat wiist: it LAN-proxyfak is noch oanfinke, of de URL fan in konfiguraasjeskript rjochtet him op in localhost-poarte dêr’t gjin proses mear harket. De browser stjoert elke oanfraach nei dy deade poarte en hinget oant de tiidferrin liket as in dea netwurk. It twadde is in adapter dy’t noch in standertrûte besit, om’t in TAP-Windows-apparaat of in routeringsstjoerder fan de leveransier nei in de-ynstallaasje in echte ynterface bliuwt. It hâldt de rûte dy’t it krigen hat, en ferkear ferdwynt yn in tunnel dy’t der net is. Gjin fan beide oerbliuwsels kundiget himsels oan; beide lykje krekt as in steuring.

It tredde is DNS, en it mislearret earder as de oare twa. As de resolverlist allinnich servers befettet dy’t fia de tunnel berikber binne, ferfalt elke opfraach foar’t ien side oanfrege wurdt, dus de browser meldt in ûnberikbere side ynstee fan in deade proxy. Hokker fan de trije jo ek hawwe, net ien is in steuring yn ’e sin fan it netwurk. Elk is in oerbliuwsel dat nimmen werom naam hat, en elk wurdt op in oar plak reparearre.

Wurkje de fjouwer lagen del

Begjin it tichtst by de applikaasje en wurkje del, om’t de lagen yn dy folchoarder fan sichtberens mislearje. Feroarje ien laach per test, en test opnij nei elk. Alles tagelyk weromsette bringt it sneupen meastentiids werom, en it lit jo sûnder antwurd oer hokker oerbliuwsel de oarsaak wie, dus de folgjende ynstallaasje makket itselde riedsel opnij. De folchoarder is proxy, adapters, rûtes, resolvers.

Op Windows is elke kontrôle ien opdracht dy’t mei it bestjoeringssysteem komt, dus der hoecht neat ynstallearre te wurden. Rin se yn folchoarder en hâld de útfier byinoar, om’t de fjouwer antwurden allinnich njonken elkoar sin hawwe. Se melde de proxy, de adapters, de IPv4-rûtes en de resolverlist, yn dy folchoarder:

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

Linux en macOS hawwe har eigen opdrachten nedich, en dy binne net útwikselber. Op Linux komme de rûtes fan ip route en de resolvers fan resolvectl status dêr’t systemd-resolved eigner is, mei in weromfal op cat /etc/resolv.conf. Op macOS komme de rûtes fan netstat -rn, de resolvers fan scutil --dns, en de systeemproxy fan scutil --proxy. In macOS-lêzer dy’t ip route rint, krijt command not found, en /etc/resolv.conf is dêr in generearre stomp ynstee fan de autoritative konfiguraasje. Kontrolearje it platfoarm foar’t jo de laach kontrolearje, oars wurdt de earste opdracht sels de befinning.

Freegje by elke laach ien fraach: wiist dizze wearde noch nei eat dat bestiet wylst de app ticht is? In proxy op in deade poarte, in adapter sûnder tunnel, in standertrûte fia in del lizzende ynterface en in resolver binnen de tunnel antwurdzje allegear nee. Elk inkeld nee is genôch om it symptoom te ferklearjen, en dêrom is ien feroaring per test fan belang.

In proxy is gjin tunnel

In proxy akseptearret in oanfraach, hellet him earne oars en jout it antwurd werom, wat betsjut dat hy de bestimming ken en alles sjocht dat de side sels net fersifere hat. Hy ferfiert gjin oare protokollen. Hy beskermet it paad net, útsein as de bestimming al TLS brûkt. En hy kin feroare wurde troch wat him ynstallearre hat, sûnder jo belutsenens.

Dat ûnderskie feroaret de fraach dy’t it freegjen wurdich is. As der in proxy oerbliuwt, sykje dan út hokker programma jo browser noch stjoert ynstee fan oft de tunnel omheech is. De tunnel kin perfoarst sûn wêze en folslein net relevant foar de flater.

As jo witte wolle wat sa’n klant eins die, observearje him dan ynstee fan syn dashboard te lêzen. Process Monitor registrearret hokker registerkaaien en bestannen hy oanrekket, wylst in pakketopname sjen lit wêr’t syn ferkear hinne gie. Beide binne gewoane ark, en beide beantwurdzje de oerbliuwselfraach better as hokker statusljocht ek. Gjin fan beide freget dat de app noch rint.

Helje it komponint fuort, net it bewiis

De duorsume oplossing is it fuortheljen fan wat de ynstelling skreau. De-ynstallearje de app, smyt de firtuele adapter fuort dy’t er tafoege hat, wiskje de proxy en de resolverlist, start dan opnij op en test wylst de app noch hieltyd de-ynstallearre is. As it sneupen dan wurket, hawwe jo de oarsaak fûn ynstee fan in omwei. Skriuw op hokker laach ferâldere wie, om’t deselde leveransier deselde flater twa kear leveret.

As it symptoom weromkomt nei’t jo de folgjende klant ynstalleare hawwe, rin dan de fjouwer lagen wer del foar’t jo beslute dat de tsjinst eat stikken makke hat. It bewiis is meastentiids noch der, op ien fan de fjouwer plakken. In twadde app makket gjin fyfde laach; hy bewurket ien fan de fjouwer.

Opnij ynstallearje set de proxy werom, mar net in ferâldere adapter, en it kin twa resolvers yn ’e list litte. Dy asymmetry is wêrom de-ynstallearje-en-test it winne fan in knop dy’t alles weromset. It jout jo ek in basisline om de folgjende kear dat de ferbining falt mei te fergelykjen.