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. Жодна з двох схем не приховує облікового запису зі сеансом, cookie чи відбитка браузера.

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 може збоїти відкрито або закрито залежно від клієнта й того, чи активний аварійний вимикач або правило брандмауера.

Перевірте випадок збою навмисно: зупиніть службу проксі й перезавантажте сторінку; якщо замість прямого завантаження з'являється сторінка помилки, спрямуйте URL PAC на недосяжний хост, щоб побачити резервну поведінку. Якщо сторінка все ще завантажується вашим звичайним маршрутом, проксі не дає жодного захисту від власного збою, і це властивість, яку варто знати перед тим, як на нього покладатися.

Порядок визначає, що бачить сайт. Проксі, вихідний трафік якого йде через VPN, залишає сайтові адресу кінцевої точки VPN; поставте проксі поза тунелем (VPN до проксі на віддаленому хості), і сайт побачить натомість адресу виходу цього проксі. У будь-якому разі два переходи можуть записувати різне.

П'ять перевірок, за порядком

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

Потім підтвердьте результат тим застосунком, який спричинив зміну. Завантажте сторінку в налаштованому браузері, отримайте ту саму сторінку через curl і порівняйте адресу, яку повідомляє кожен. Якщо вони розходяться, досі діє розширення, правило PAC або перевизначення на рівні застосунку, і жодне налаштування тунелю це не виправить.

Запишіть, що ви налаштували: які застосунки використовують проксі, локальний DNS чи віддалений, чи заблоковано UDP і якою є поведінка під час збою. Саме цей невеликий перелік уможливлює наступне порівняння, бо «IP змінився» ніколи не казало, яку з цих п'яти перевірок пройдено.