VPN срещу прокси: какво покрива всяко от тях и какво не

И VPN, и препращащото прокси променят адреса, който сайтът вижда, и точно там повечето сравнения спират. Разликата, която определя вашата настройка, е обхватът: препращащото прокси е посредник, който вашето приложение избира да използва, за разлика от обратното прокси, което стои пред сайт, а VPN премества всичко, което операционната система насочва в тунел. Криптирането, работата с DNS и поведението при отказ следват от това разделение. Изпълнете тези пет проверки по ред и първата, която се провали, ще ви каже кой инструмент всъщност ви трябва.

Кои приложения покрива посредникът?

Разширението за прокси в браузъра се отнася само за този профил на браузъра. Пощенските клиенти, мениджърите на пакети и вторият браузър продължават да използват собствените си настройки, а някои приложения напълно пренебрегват системните променливи за прокси. VPN покрива това, което таблицата за маршрутизация изпраща в тунела, което може да са всички приложения или подмножество при разделен тунел в зависимост от маршрутите и политиката на клиента.

Тествайте приложенията, които имат значение, вместо да правите изводи от едно зареждане на страница. curl https://ifconfig.me следва променливите за прокси в средата; настолно приложение може да не го прави. В Windows netsh winhttp show proxy отпечатва проксито WinHTTP, което използват услугите, а това е различна настройка от тази на браузъра.

Криптиран ли е преходът и къде завършва TLS?

Протоколът на проксито е място за среща, а не гаранция. SOCKS5 препредава TCP без криптиране, а обикновеното HTTP прокси носи реда на заявката и заглавките в открит текст. HTTPS през прокси използва CONNECT, така че TLS сесията ви все още завършва в дестинацията, а не в проксито. Ръководството на MDN за прокси сървъри и тунелиране описва тази разлика от страната на протокола.

VPN криптира сегмента между устройството ви и неговата крайна точка. Отвъд крайната точка важат същите правила, както в която и да е друга мрежа, поради което един тунел не защитава приложение, което изпраща идентификационни данни по обикновен HTTP. Нито един от двата дизайна не скрива влязъл в системата акаунт, бисквитка или отпечатък на браузъра.

curl -v -x http://127.0.0.1:3128 https://example.com/ -o /dev/null
curl -v -x socks5h://127.0.0.1:1080 https://example.com/ -o /dev/null

Подробният изход показва дали curl е издал CONNECT към порт 443, или обикновен GET с пълен URL. С socks5h:// името на хоста се предава на проксито в заявката SOCKS5 и то препраща TLS, което не може да прочете, така че вижда името и броя байтове. През прокси http:// адрес https:// е CONNECT, така че това прокси също вижда името и обема на дестинацията, но не заявката или тялото на отговора.

Кой резолвер вижда името?

Разрешаването на имена може да се случи локално, преди заявката да тръгне, или отдалечено в проксито. С curl socks5h:// изпраща името на хоста към проксито, докато socks5:// първо го разрешава локално. Настройките за прокси в браузъра предлагат сравнима опция за DNS, а PAC файловете могат да насочват различните хостове по различни начини.

Два протокола могат да заобиколят прокси без никаква грешна конфигурация. WebRTC събира кандидати през STUN, а QUIC работи HTTP/3 върху UDP, което TCP прокси не може да пренесе. Браузърът ще се върне към TCP, ако UDP 443 е блокиран, затова блокирането на UDP 443 във защитната стена на хоста (или на рутера за цяла мрежа), а не флаг на браузъра, е надеждният начин да задържите HTTP/3 в пътя на проксито.

Проверете резолвера от гледна точка на дестинацията, а не на вашия лаптоп. Заявка, която пристига с адреса на изхода на проксито, но с локално разрешено име, все още казва на локалния резолвер кои сайтове посещавате.

Какво се случва, когато посредникът се провали?

Явното прокси се проваля затворено: спрете процеса на проксито и браузърът или приложението връща грешка при свързване вместо да премине директно. Настройките PAC и WPAD са тези, които се провалят отворено - ако скриптът не може да бъде изтеглен, клиентът се връща към DIRECT и сайтът отново вижда истинския ви адрес. VPN може да се провали отворено или затворено в зависимост от клиента и дали е активен прекъсвач или правило на защитната стена.

Тествайте случая на отказ нарочно: спрете услугата прокси и презаредете; ако получите страница с грешка вместо директно зареждане, насочете PAC URL към недостъпен хост, за да видите резервния вариант. Ако страницата все още се зарежда по обичайния ви маршрут, проксито не предлага защита срещу собствения си престой и това е свойство, което трябва да знаете, преди да разчитате на него.

Редът определя какво вижда сайтът. Прокси, чийто изходящ трафик минава през VPN, оставя сайта да вижда адреса на крайната точка на VPN; поставете проксито извън тунела (VPN към прокси на отдалечен хост) и сайтът ще види вместо това адреса на изхода на това прокси. И в двата случая двата прехода могат да записват различни неща.

Пет проверки, по ред

Контролният списък по-долу е цялото решение на едно място. Обхватът е първи, защото елиминира повечето несъответствия: ако приложението, което трябва да бъде покрито, не спазва настройката, нищо по-нататък в списъка не го спасява.

След това потвърдете резултата с приложението, което предизвика промяната. Заредете страница в конфигурирания браузър, изтеглете същата страница с curl и сравнете адреса, който всяко от тях съобщава. Ако се различават, разширение, правило на PAC или замяна на ниво приложение все още действат и никакво настройване на тунела няма да го поправи.

Запишете какво сте конфигурирали: кои приложения използват проксито, дали DNS е локален или отдалечен, блокиран ли е UDP и какво е поведението при отказ. Именно този малък опис прави възможно следващото сравнение, защото „IP адресът се промени“ никога не ви е казвало коя от тези пет проверки е минала.