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 изменился» никогда не говорило, какая из этих пяти проверок пройдена.