Kai internetas veikia tik su VPN programėle: keturi sluoksniai, kuriuos reikia patikrinti
Savaitę išbandžius nemokamą VPN klientą ar naršyklės plėtinį ir jį išjungus, internetas gali sustoti. Priežastis ne šifravimas, o programėlės palikta konfigūracija.
Savaitę naudojate nemokamą VPN klientą ar naršyklės plėtinį, jį išjungiate, ir internetas sustoja. Wi-Fi piktograma vis dar rodo ryšį, kiti to paties maršrutizatoriaus įrenginiai veikia, o vienintelis būdas atgauti naršymą — vėl įjungti arba pašalinti programėlę. Šis modelis nėra šifravimo sukurta priklausomybė. Tai konfigūracija, kurią programėlė įrašė ten, kur tunelis neturi nuosavybės.
Klientas keičia nustatymus, kurių tunelis nevaldo
Privatumo klientas sistemoje Windows ar macOS paprastai liečia tris vietas vienu metu. Jis nustato sistemos HTTP tarpinį serverį, tą patį lauką, kurį rodo interneto parinktys. Jis įdiegia virtualų adapterį, dažnai TAP tvarkyklę, kad galėtų užfiksuoti paketus. Ir jis perrašo resolverių sąrašą, nors atjungus dingsta tik tunelis.
Naršyklės plėtinys yra siauresnis dalykas. Paprastai jis keičia savo profilį arba tarpinį serverį, kurio laikosi viena naršyklė. Todėl viena naršyklė gali neveikti, kol komandinės eilutės įrankiai veikia toliau, arba atvirkščiai: plėtinys niekada neturėjo teisės liesti kitų sluoksnių. Kurį sluoksnį jis redagavo, lemia, kurie įrankiai lūš.
Kad ir kaip būtų, pasenusį sprendimą priėmė programinė įranga, kuri neturėjo priežasties jo atšaukti. Tunelis buvo matoma dalis ir kartu vienintelė dalis su švariu išjungimo keliu. Visa kita yra nustatymas saugykloje, kuri gyvena ilgiau nei procesas, todėl programėlės pašalinimas yra vienintelis žingsnis, atšaukiantis visus tris iš karto. Tų saugyklų skaitymas prieš ką nors diegiant iš naujo paverčia simptomą diagnoze.
Trys likučiai, trys skirtingi gedimai
Pirmas likutis — tarpinis serveris, kuris į nieką nenurodo: LAN tarpinio serverio žymė vis dar uždėta arba konfigūracijos scenarijaus URL nukreiptas į localhost prievadą, kuriame jau niekas neklauso. Naršyklė persiunčia kiekvieną užklausą į tą negyvą prievadą ir stringa, kol laukimo pabaiga atrodo kaip miręs tinklas. Antras — adapteris, kuris vis dar valdo numatytąjį maršrutą, nes TAP-Windows įrenginys arba gamintojo maršrutizavimo tvarkyklė po pašalinimo lieka tikra sąsaja. Jis išlaiko gautą maršrutą, o srautas dingsta tunelyje, kurio nėra. Nė vienas likutis savęs neskelbia; abu atrodo kaip visiškas nutrūkimas.
Trečias — DNS, ir jis žlunga anksčiau už kitus du. Jei resolverių sąraše yra tik serveriai, pasiekiami per tunelį, kiekviena paieška baigiasi laukimo pabaiga dar neprašius nė vieno puslapio, todėl naršyklė praneša apie nepasiekiamą svetainę, o ne apie negyvą tarpinį serverį. Kad ir kuris būtų, nė vienas nėra gedimas tinklo prasme. Kiekvienas yra likutis, kurio niekas neatšaukė, ir kiekvienas taisomas kitoje vietoje.
Pereikite keturis sluoksnius iš viršaus į apačią
Pradėkite nuo arčiausio programos sluoksnio ir eikite žemyn, nes sluoksniai žlunga būtent tokia matomumo tvarka. Keiskite vieną sluoksnį per bandymą ir po kiekvieno bandykite iš naujo. Visko iš karto atstatymas paprastai grąžina naršymą ir neleidžia pasakyti, kuris likutis buvo priežastis, todėl kitas diegimas vėl sukuria tą pačią mįslę. Tvarka: tarpinis serveris, adapteriai, maršrutai, resolveriai.
Windows kiekviena patikra yra viena komanda, kuri ateina su operacine sistema, todėl nieko diegti nereikia. Vykdykite jas iš eilės ir laikykite išvestį kartu, nes keturi atsakymai turi prasmę tik greta. Jos praneša tarpinį serverį, adapterius, IPv4 maršrutus ir resolverių sąrašą, būtent tokia tvarka:
netsh winhttp show proxy
Get-NetAdapter
route print -4
Get-DnsClientServerAddress
Linux ir macOS turi savo komandas, ir jos nėra keičiamos. Linux maršrutai gaunami iš ip route, o resolveris — iš resolvectl status, kai jį valdo systemd-resolved, kitu atveju iš cat /etc/resolv.conf. macOS maršrutai gaunami iš netstat -rn, resolveriai iš scutil --dns, o sistemos tarpinis serveris iš scutil --proxy. macOS skaitytojas, paleidęs ip route, gauna command not found, o /etc/resolv.conf ten yra sugeneruotas stuburas, o ne autoritetinga konfigūracija. Patikrinkite platformą prieš tikrindami sluoksnį, kitaip pirmoji komanda taps radiniu.
Kiekvienam sluoksniui užduokite vieną klausimą: ar ši reikšmė vis dar nurodo į ką nors, kas egzistuoja, kai programėlė uždaryta? Tarpinis serveris negyvame prievade, adapteris be tunelio, numatytasis maršrutas per išjungtą sąsają ir resolveris tunelio viduje — visi atsako ne. Vieno ne pakanka simptomui paaiškinti, todėl vienas pakeitimas per bandymą yra svarbus.
Tarpinis serveris nėra tunelis
Tarpinis serveris priima užklausą, atsiima ją kitur ir grąžina atsakymą, tai reiškia, kad jis žino paskirties vietą ir mato viską, ko svetainė pati neužšifravo. Jis neperduoda kitų protokolų. Jis neapsaugo kelio, nebent paskirties vieta jau naudoja TLS. Ir jį gali pakeisti tai, kas jį įdiegė, be jūsų dalyvavimo.
Šis skirtumas keičia klausimą, kurį verta užduoti. Kai tarpinis serveris lieka, išsiaiškinkite, kuri programa vis dar vadovauja jūsų naršyklei, o ne tai, ar tunelis įjungtas. Tunelis gali būti visiškai sveikas ir visiškai nesusijęs su gedimu.
Jei norite sužinoti, ką toks klientas iš tikrųjų padarė, stebėkite jį, o ne skaitykite jo prietaisų skydelį. Process Monitor įrašo, kuriuos registro raktus ir failus jis liečia, o paketų fiksavimas atskleidžia, kur nuėjo jo srautas. Abu yra įprasti įrankiai, ir abu atsako į likučio klausimą geriau nei bet kuri būsenos lemputė. Nė vienas nereikalauja, kad programėlė dar veiktų.
Pašalinkite komponentą, o ne įrodymą
Ilgalaikis sprendimas yra pašalinti tai, kas įrašė nustatymą. Pašalinkite programėlę, ištrinkite jos pridėtą virtualų adapterį, išvalykite tarpinį serverį ir resolverių sąrašą, tada paleiskite iš naujo ir bandykite su pašalinta programėle. Jei tada naršymas veikia, radote priežastį, o ne apėjimo kelią. Užsirašykite, kuris sluoksnis buvo pasenęs, nes tas pats gamintojas linkęs tą pačią klaidą padaryti du kartus.
Jei simptomas grįžta įdiegus kitą klientą, dar kartą pereikite keturis sluoksnius, prieš nuspręsdami, kad paslauga ką nors sulaužė. Įrodymai paprastai vis dar yra vienoje iš keturių vietų. Antra programėlė nesukuria penkto sluoksnio; ji redaguoja vieną iš keturių.
Pakartotinis diegimas atstato tarpinį serverį, bet ne pasenusį adapterį, ir sąraše gali likti du resolveriai. Ši asimetrija yra priežastis, kodėl pašalinti-tada-bandyti geriau nei mygtukas, atstatantis viską. Ji taip pat suteikia bazinę liniją palyginimui, kai ryšys kitą kartą nutrūks.