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:// URL е 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-то се смени“ никогаш не ви кажала која од овие пет проверки успеала.