Интернет ради само са укљученом VPN апликацијом? Проверите четири слоја

Пробате бесплатни VPN клијент или наставак за прегледач недељу дана, искључите га, и интернет стане. Икона Wi-Fi још показује везу, други уређаји на истом рутеру раде, а једино што враћа прегледање је поновно укључивање апликације или њено деинсталирање. Тај образац није шифровање које ствара зависност. То је конфигурација коју је апликација уписала негде где тунел није њен власник.

Клијент мења подешавања која тунел не поседује

Клијент за приватност на Windows-у или macOS-у обично дира три места истовремено. Поставља системски HTTP прокси, исто поље које приказује Internet Options. Инсталира виртуелни адаптер, често TAP драјвер, да би могао да хвата пакете. И преписује листу резолвера, док при притиску на прекид везе нестаје само тунел.

Наставак за прегледач је ужа ствар. Он обично мења свој профил или прокси који прати један прегледач. Зато један прегледач може да закаже док алати командне линије наставе да раде, или обрнуто: наставак никада није имао овлашћење да дира друге слојеве. Који је слој изменио одређује који алати се кваре.

У сваком случају, застарелу одлуку донео је софтвер који није имао разлога да је опозове. Тунел је био видљиви део, и био је и једини део са чистим путем за гашење. Све остало је подешавање у складишту које надживљава процес, па је уклањање апликације једини корак који окреће сва три одједном. Читање тих складишта пре било какве поновне инсталације претвара симптом у дијагнозу.

Три остатка, три различита отказа

Први остатак је прокси који не показује ни на шта: LAN прокси поље још штиклирано, или адреса конфигурационе скрипте усмерена на localhost порт на ком више ништа не слуша. Прегледач прослеђује сваки захтев том мртвом порту и застаје док тајмаут не изгледа као мртва мрежа. Други је адаптер који још поседује подразумевану руту, јер TAP-Windows уређај или добављачки драјвер за рутирање остаје стварни интерфејс после деинсталације. Задржава руту која му је дата, а саобраћај нестаје у тунелу кога нема. Ни један остатак се не најављује; оба изгледају тачно као прекид рада.

Трећи је DNS, и он отказује раније од друга два. Ако листа резолвера садржи само сервере доступне кроз тунел, свако претраживање истиче пре него што се затражи иједна страница, па прегледач пријављује недоступан сајт уместо мртвог проксија. Који год да имате, ниједан од њих није прекид у мрежном смислу. Сваки је остатак који нико није опозвао, и сваки се поправља на другом месту.

Прођите кроз четири слоја

Почните најближе апликацији и идите надоле, јер слојеви отказују тим редом видљивости. Мењајте један слој по тесту и поново тестирајте после сваког. Ресетовање свега одједном обично врати прегледање, и остави вас неспособним да кажете који је остатак то изазвао, па следећа инсталација ствара исту загонетку. Ред је прокси, адаптери, руте, резолвери.

На Windows-у је свака провера једна команда која долази с оперативним системом, па ништа не треба инсталирати. Покрените их по реду и држите излаз заједно, јер четири одговора имају смисла само један поред другог. Пријављују прокси, адаптере, IPv4 руте и листу резолвера, тим редом:

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

Linux и macOS траже сопствене команде и оне нису заменљиве. На Linux-у руте долазе из ip route а резолвер из resolvectl status тамо где га поседује systemd-resolved, уз пад на cat /etc/resolv.conf. На macOS-у руте долазе из netstat -rn, резолвери из scutil --dns, а системски прокси из scutil --proxy. Читалац на macOS-у који покрене ip route добија command not found, а /etc/resolv.conf тамо је генерисани стаб а не ауторитативна конфигурација. Проверите платформу пре него што проверите слој, иначе прва команда постаје сам налаз.

За сваки слој поставите једно питање: показује ли ова вредност још на нешто што постоји док је апликација затворена? Прокси на мртвом порту, адаптер без тунела, подразумевана рута кроз оборен интерфејс и резолвер унутар тунела сви одговарају не. Једно не је довољно да објасни симптом, зато је важна једна промена по тесту.

Прокси није тунел

Прокси прихвата захтев, добавља га другде и враћа одговор, што значи да зна одредиште и види све што сајт сам није шифровао. Не преноси друге протоколе. Не штити пут осим ако одредиште већ користи TLS. И може га променити све што га је инсталирало, без вашег учешћа.

Та разлика мења питање које вреди поставити. Када прокси остане, откријте који програм још усмерава ваш прегледач, а не да ли је тунел подигнут. Тунел може бити потпуно здрав и потпуно небитан за отказ.

Ако желите да знате шта је такав клијент стварно радио, посматрајте га уместо да читате његову контролну таблу. Process Monitor бележи које регистарске кључеве и датотеке дира, а хватање пакета открива куда је отишао његов саобраћај. Оба су обични алати, и оба одговарају на питање остатка боље од било ког статусног светла. Ниједан не захтева да апликација још ради.

Уклоните компоненту, не доказ

Трајно решење је уклонити ствар која је уписала подешавање. Деинсталирајте апликацију, избришите виртуелни адаптер који је додала, очистите прокси и листу резолвера, затим поново покрените и тестирајте док је апликација још деинсталирана. Ако прегледање тада ради, нашли сте узрок а не привремено решење. Забележите који је слој био застарео, јер исти продавац обично двапут испоручи исту грешку.

Ако се симптом врати после инсталације следећег клијента, прођите кроз четири слоја поново пре него што закључите да је услуга нешто покварила. Доказ је обично још тамо, на једном од четири места. Друга апликација не ствара пети слој; она мења један од четири.

Поновна инсталација ресетује прокси али не и застарели адаптер, и може оставити два резолвера на листи. Та асиметрија је разлог зашто деинсталирај-па-тестирај побеђује дугме за ресетовање свега. Оно вам даје и основу за поређење следећи пут када веза падне.