Netið virkar aðeins með VPN-forritinu í gangi? Athugaðu fjögur lög

Þú prófar ókeypis VPN-biðlara eða viðbót í vafra í viku, slokknir á henni og netið stöðvast. Wi-Fi-táknið sýnir enn tengingu, önnur tæki á sama beini virka, og það eina sem færir vafrið aftur eru að kveikja á forritinu eða fjarlægja það. Þetta mynstur er ekki dulkóðun sem skapar háð. Það er stilling sem forritið skrifaði þar sem göngin eiga hana ekki.

Biðlarinn breytir stillingum sem göngin eiga ekki

Biðlari fyrir friðhelgi á Windows eða macOS snertir venjulega þrjá staði í einu. Hann stillir HTTP-proxy kerfisins, sama reit og Internet Options sýnir. Hann setur upp sýndaradapter, oft TAP-rekil, svo hann geti gripið pakka. Og hann endurskrifar lista yfir leysa, en aðeins göngin hverfa þegar ýtt er á að aftengja.

Viðbót í vafra er þrengra fyrirbæri. Hún breytir venjulega eigin prófíl eða þeim proxy sem einn vafri fylgir. Þess vegna getur einn vafri bilað á meðan skipanalínutól virka áfram, eða öfugt: viðbótin hafði aldrei heimild til að snerta hin lögin. Hvaða lag hún breytti ræður því hvaða tól bila.

Hvort sem er, þá tók þá úreltu ákvörðun hugbúnaður sem hafði enga ástæðu til að afturkalla hana. Göngin voru sýnilegi hlutinn, og líka eini hlutinn með hreina lokun. Allt annað er stilling í geymslu sem lifir ferlinu, svo að fjarlægja forritið er eina skrefið sem snýr við öllum þremur í einu. Það að lesa þessar geymslur fyrir enduruppsetningu er það sem gerir einkennið að greiningu.

Þrjú leifar, þrjú mismunandi bilun

Fyrsta leifin er proxy sem bendir á ekkert: LAN-proxy-reiturinn enn hakaður, eða slóð stillingaskriftu sem miðar á localhost-port þar sem ekkert ferli hlustar lengur. Vafrinn sendir hverja beiðni á það dauða port og stendur fastur þar til tímaútrunin líkist dauðu neti. Önnur er adapter sem á enn sjálfgefna leið, því TAP-Windows-tæki eða leiðarakreki framleiðanda er enn raunverulegt viðmót eftir uppsetningu. Hann heldur leiðinni sem honum var gefin og umferðin hverfur inn í göng sem eru ekki til. Hvorug leifin tilkynnir sig; báðar líta nákvæmlega út eins og truflun.

Þriðja er DNS, og hún bilar fyrr en hinar tvær. Ef listinn yfir leysa inniheldur aðeins netþjóna sem nást í gegnum göngin, þá rennur hver uppfletting út á tíma áður en ein síða er beðin, svo vafrinn tilkynnir óaðgengilegan stað frekar en dauðan proxy. Hvort sem þú átt, þá er ekkert þeirra truflun í netlegum skilningi. Hver er leif sem enginn afturkallaði, og hver er löguð á öðrum stað.

Farðu niður fjögur lögin

Byrjaðu næst forritinu og farðu niður, því lögin bila í þeirri röð sýnileika. Breyttu einu lagi í hverri prófun og prófaðu aftur eftir hverja. Að endurstilla allt í einu færir vafrið venjulega aftur og skilur þig eftir ófæran um að segja hvaða leif olli því, svo næsta uppsetning skapar sömu gátuna. Röðin er proxy, adapterar, leiðir, leysar.

Á Windows er hver athugun ein skipun sem fylgir stýrikerfinu, svo ekkert þarf að setja upp. Keyrðu þær í röð og haltu úttakinu saman, því fjögur svör hafa aðeins merkingu hlið við hlið. Þau greina frá proxy, adapterum, IPv4-leiðum og lista yfir leysa, í þeirri röð:

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

Linux og macOS þurfa sínar eigin skipanir og þær er ekki hægt að skipta út. Á Linux koma leiðirnar úr ip route og leysirinn úr resolvectl status þar sem systemd-resolved á hann, með varaleið í cat /etc/resolv.conf. Á macOS koma leiðirnar úr netstat -rn, leysarnir úr scutil --dns og kerfisproxyið úr scutil --proxy. Lesandi á macOS sem keyrir ip route fær command not found, og /etc/resolv.conf þar er búinn stoðull en ekki hið rétta stilling. Athugaðu vettvanginn áður en þú athugar lagið, annars verður fyrsta skipunin að niðurstöðu.

Fyrir hvert lag skaltu spyrja einnar spurningar: bendir þetta gildi enn á eitthvað sem er til á meðan forritið er lokað? Proxy á dauðu porti, adapter án ganga, sjálfgefin leið gegnum niðri viðmót og leysir inni í göngunum svara öll nei. Eitt nei er nóg til að útskýra einkennið, og þess vegna skiptir máli að gera eina breytingu í hverri prófun.

Proxy er ekki göng

Proxy tekur við beiðni, sækir hana annars staðar og skilar svarinu, sem þýðir að það þekkir áfangastaðinn og sér allt sem síðan dulkóðaði ekki sjálf. Það flytur ekki aðrar samskiptareglur. Það verndar ekki leiðina nema áfangastaðurinn noti þegar TLS. Og það getur breyst af hverju því sem setti það upp, án þátttöku þinnar.

Þessi greinarmunur breytir spurningunni sem vert er að spyrja. Þegar proxy verður eftir, finndu hvaða forrit stýrir enn vafranum þínum, frekar en hvort göngin séu uppi. Göngin geta verið fullkomlega heilbrigð og algjörlega óviðkomandi biluninni.

Ef þú vilt vita hvað slíkur biðlari gerði í raun, fylgstu með honum í stað þess að lesa mælaborðið hans. Process Monitor skráir hvaða skrár og skráarkerfi hann snertir, og pakkaskráning sýnir hvert umferð hans fór. Bæði eru venjuleg tól og bæði svara leifarspurningunni betur en nokkurt stöðuljós. Hvorugt krefst þess að forritið sé enn í gangi.

Fjarlægðu íhlutinn, ekki sönnunargögnin

Varanleg lausn er að fjarlægja það sem skrifaði stillinguna. Taktu forritið út, eyddu sýndaradapternum sem það bætti við, hreinsaðu proxy og listann yfir leysa, endurræstu svo og prófaðu á meðan forritið er enn fjarlægt. Ef vafrið virkar þá hefur þú fundið orsökina en ekki undankomu. Skrifaðu niður hvaða lag var úrelt, því sami söluaðili á það til að senda sömu mistök tvisvar.

Ef einkennið kemur aftur eftir að þú setur upp næsta biðlara, farðu aftur niður fjögur lögin áður en þú ályktar að þjónustan hafi brotið eitthvað. Sönnunargögnin eru venjulega enn þar, á einum af fjórum stöðum. Annað forrit skapar ekki fimmta lag; það breytir einu af þeim fjórum.

Enduruppsetning endurstillir proxy en ekki úreltan adapter, og hún getur skilið eftir tvo leysa á listanum. Þetta misræmi er ástæðan fyrir því að taka út og prófa gengur framar takknum sem endurstillir allt. Hún gefur þér líka grunn til að bera saman við næst þegar tengingin dettur út.