Internetek VPN aplikazioa piztuta bakarrik funtzionatzen du? Egiaztatu lau geruza

VPN bezero libre bat edo nabigatzailearen luzapen bat probatzen duzu astebetez, itzaltzen duzu, eta internetek funtzionatzeari uzten dio. Wi-Fi ikonoak konexioa erakusten du oraindik, router bereko beste gailuak ondo daude, eta nabigatzea itzultzen duten gauza bakarrak aplikazioa berriro gaitzea edo desinstalatzea dira. Eredu hori ez da zifratzeak sortutako mendekotasuna. Aplikazioak tunelak kudeatzen ez duen leku batean idatzitako konfigurazioa da.

Bezeroak tunelak kudeatzen ez dituen ezarpenak aldatzen ditu

Windows edo macOSeko pribatutasun bezero batek hiru leku ukitzen ditu normalean aldi berean. Sistemaren HTTP proxya ezartzen du, Interneteko aukeretan ikusten den eremu bera. Txartel birtual bat instalatzen du, askotan TAP kontrolatzailea, paketeak harrapatu ahal izateko. Eta resolver zerrenda berridazten du, baina deskonektatzean tunela bakarrik desagertzen da.

Nabigatzailearen luzapen bat gauza estuagoa da. Normalean bere profila edo nabigatzaile bakarreko proxy-a aldatzen du. Horregatik nabigatzaile bakar batek huts egin dezake komando-lerroko tresnek funtzionatzen duten bitartean, edo alderantziz: luzapenak ez zuen beste geruzak ukitzearen autoritaterik. Zein geruza editatu zuen, horrek erabakitzen du zein tresnak hausten diren.

Edozein modutan, erabaki zaharkitua atzera botatzeko arrazoirik ez zuen softwareak hartu zuen. Tunela zati ikusgai bakarra zen, eta itzaltze-bide garbia zuen zati bakarra ere bai. Gainerako guztia prozesua baino gehiago irauten duen biltegiko ezarpena da, beraz aplikazioa kentzea da hirurak batera atzera botatzen dituen urrats bakarra. Biltegi horiek berriro instalatu aurretik irakurtzea da sintoma diagnostiko bihurtzen duena.

Hiru hondar, hiru hutsegite desberdin

Lehen hondarra ezeri seinalatzen ez dion proxy bat da: LAN proxyaren laukia oraindik markatuta, edo localhosteko portu batera zuzendutako konfigurazio-script baten URLa, non jada ez dagoen prozesurik entzuten. Nabigatzaileak eskaera guztiak portu hilera bidaltzen ditu eta blokeatu egiten da, denbora-muga sare hila bezala ikusten den arte. Bigarrena default bide bat oraindik duen txartela da, TAP-Windows gailu bat edo saltzailearen bideratze kontrolatzaile bat desinstalatu ondoren benetako interfazea izaten jarraitzen baitu. Eman zitzaion bidea mantentzen du, eta trafikoa ez dagoen tunel batera desagertzen da. Inongo hondarrek ez du bere burua iragartzen; biek itzalaldi baten itxura zehatza dute.

Hirugarrena DNSa da, eta beste biek baino lehenago huts egiten du. Resolver zerrendak tunelaren bidez bakarrik irisgarriak diren zerbitzariak baino ez baditu, bilaketa guztiek denbora-muga gainditzen dute orri bat ere eskatu aurretik, beraz nabigatzaileak iristezin den gune bat salatzen du, ez proxy hila. Zein duzun, ez da horietako bat ere itzalaldi bat sarearen zentzuan. Bakoitza inork baliogabetu ez zuen hondar bat da, eta bakoitza leku desberdin batean konpontzen da.

Jaitsi lau geruzak

Hasi aplikaziotik gertuen eta jaitsi, geruzek ikusgaitasun-orden horretan huts egiten dutelako. Aldatu geruza bat proba bakoitzeko, eta berriro probatu bakoitzaren ondoren. Dena aldi berean berrezartzeak nabigatzea leheneratzen du normalean, eta ezin duzu esan zein hondarrek eragin zuen, beraz hurrengo instalazioak asmakizun bera sortzen du berriro. Ordena hau da: proxy-a, txartelak, bideak, resolverrak.

Windowsen egiaztapen bakoitza sistema eragilearekin datorren komando bakarra da, beraz ez dago ezer instalatu beharrik. Exekutatu ordenan eta eduki irteera elkarrekin, lau erantzunek elkarren ondoan baino ez dute zentzurik. Proxy-a, txartelak, IPv4 bideak eta resolver zerrenda jakinarazten dituzte, ordena horretan:

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

Linuxek eta macOSek beren komandoak behar dituzte, eta ez dira trukagarriak. Linuxen bideak ip route komandotik datoz eta resolverra resolvectl status komandotik, systemd-resolvedek kudeatzen duenean, eta cat /etc/resolv.conf komandora jotzen du bestela. macOSen bideak netstat -rn komandotik datoz, resolverrak scutil --dns komandotik eta sistema proxy-a scutil --proxy komandotik. ip route exekutatzen duen macOS irakurle batek command not found jasotzen du, eta han /etc/resolv.conf stub sortu bat da, ez konfigurazio autoritatiboa. Egiaztatu plataforma geruza egiaztatu aurretik, bestela lehen komandoa bilakatzen da aurkikuntza.

Geruza bakoitzeko galdera bat egin: balio honek oraindik existitzen den zerbaiti seinalatzen dio aplikazioa itxita dagoela? Portu hil bateko proxy-ak, tunelik gabeko txartelak, behera dagoen interfaze batetik doan default bideak eta tunelaren barruko resolverrak ezetz erantzuten dute guztiek. Ezetz bakarra nahikoa da sintoma azaltzeko, eta horregatik da garrantzitsua proba bakoitzeko aldaketa bat.

Proxy bat ez da tunel bat

Proxy batek eskaera bat onartzen du, beste nonbait lortzen du eta erantzuna itzultzen du, hau da, helmuga ezagutzen du eta guneak berak zifratu ez zuen edozer ikusten du. Ez ditu beste protokoloak garraiatzen. Ez du bidea babesten, helmugak jada TLS erabiltzen ez badu behintzat. Eta instalatu zuen edozerk alda dezake, zure parte-hartzerik gabe.

Bereizketa horrek galdera aldatzen du. Proxy bat atzean geratzen denean, jakin zein programak gidatzen duen oraindik zure nabigatzailea, eta ez ea tunela martxan dagoen. Tunela erabat osasuntsu egon daiteke eta hutsegitearekiko erabat garrantzirik gabea.

Halako bezero batek benetan zer egin zuen jakin nahi baduzu, behatu ezazu, ez irakurri bere panelak. Process Monitorrek ukitzen dituen erregistro-gakoak eta fitxategiak erregistratzen ditu, eta pakete-harrapaketak bere trafikoa nora joan zen erakusten du. Biak tresna arruntak dira, eta biek hondarraren galderari edozein egoera-argik baino hobeto erantzuten diote. Biek ez dute aplikazioa martxan egotea eskatzen.

Kendu osagaia, ez froga

Konponbide iraunkorra ezarpena idatzi zuen gauza kentzea da. Desinstalatu aplikazioa, ezabatu gehitu zuen txartel birtuala, garbitu proxy-a eta resolver zerrenda, gero berrabiarazi eta probatu aplikazioa oraindik desinstalatuta. Nabigatzeak orduan funtzionatzen badu, kausa aurkitu duzu, ez saihesbide bat. Idatzi zein geruza zegoen zaharkituta, saltzaile berak akats bera bitan bidaltzeko joera baitu.

Sintoma hurrengo bezeroa instalatu ondoren itzultzen bada, ibili lau geruzak berriro zerbitzuak zerbait hautsi zuela erabaki aurretik. Ebidentzia normalean oraindik han dago, lau leku horietako batean. Bigarren aplikazio batek ez du bosgarren geruza bat sortzen; lauetako bat editatzen du.

Berriro instalatzeak proxy-a berrezartzen du, baina ez txartel zaharkitu bat, eta bi resolver utz ditzake zerrendan. Asimetria horregatik da desinstalatu-eta-probatu botoi bat dena berrezarri baino hobea. Oinarri bat ere ematen dizu, konexioa hurrengoan erortzen denean alderatzeko.