Чем отличается VPN от прокси

Прокси и VPN выводят трафик через промежуточный узел, но работают на разных уровнях: прокси обслуживает отдельное приложение и сам ничего не шифрует, а VPN поднимает системный сетевой интерфейс и шифрует IP-пакеты всего устройства. Различий по существу три: уровень обработки, область действия и криптография.

Коротко. SOCKS5 (RFC 1928) — прослойка между прикладным и транспортным уровнями, алгоритмов шифрования в стандарте нет. HTTP-прокси при методе CONNECT (RFC 9110) слепо пересылает байты. WireGuard упаковывает IP-пакеты в UDP и шифрует их связкой ChaCha20-Poly1305. Прокси включается в одной программе, туннель — для всей системы. Анонимности не даёт ни один из механизмов.

Что такое прокси и что такое туннель?

Прокси — посредник, которого клиент выбирает сам своими настройками (RFC 9110, раздел 3.7); там же он отделён от шлюза (обратного прокси) и от перехватывающего прокси, неотличимого от постороннего в середине маршрута. Туннель в смысле VPN — виртуальный сетевой интерфейс: по документации Android сервис создаёт его сам, настраивает адреса и маршруты, а пакеты внутри начинаются с IP-заголовка. Подробнее — что такое ВПН.

На каком уровне работает каждый механизм?

Туннель обрабатывает IP-пакеты, прокси — TCP-поток или отдельный HTTP-запрос. Номер уровня OSI первоисточники не называют: RFC 1928 описывает SOCKS5 как shim-прослойку между прикладным и транспортным уровнями, Chromium — как транспортный прокси. Следствие: SOCKS не даёт услуг шлюза сетевого уровня и не пересылает ICMP, поэтому ping и traceroute через прокси не проходят, а WireGuard инкапсулирует любые IP-пакеты поверх UDP.

Чем HTTP-прокси отличается от SOCKS5?

HTTP-прокси разбирает запрос и видит его целиком, SOCKS5 знает только адрес назначения. Соединение по SOCKS5 идёт в четыре шага:

1. Клиент открывает TCP-соединение (по традиции порт 1080) и шлёт поле VER = X’05’ со списком методов аутентификации.
2. Сервер выбирает метод: X’00’ — без аутентификации, X’02’ — пароль по RFC 1929, X’01’ — GSSAPI.
3. Клиент передаёт команду CMD: CONNECT = X’01’, BIND = X’02’, UDP ASSOCIATE = X’03’; адрес задаёт ATYP — X’01’ для IPv4, X’03’ для домена, X’04’ для IPv6.
4. Сервер соединяется с целевым узлом и работает трубой, не разбирая содержимого.

У HTTP-прокси иначе: для запросов по http:// цель передаётся в абсолютной форме (RFC 9112, раздел 3.2) — GET http://example.org/pub/page.html HTTP/1.1. Посредник получает схему, домен, путь с параметрами и заголовки Host, Cookie, User-Agent, обязан добавить Via и запрашивает пароль статусом 407.

Почему CONNECT не равен шифрованию?

Потому что CONNECT просит посредника открыть туннель и слепо пересылать данные — таково его определение в RFC 9110. Шифрует TLS внутри туннеля; для ресурса по http:// пойдёт открытый текст. Цель задаётся особой формой, только хост и порт: CONNECT server.example.com:443 HTTP/1.1 — домен и порт видны, URL и заголовки нет. Пароль защитой не является: Basic по RFC 7617 передаёт данные в Base64, а RFC 1929 предупреждает, что пароль SOCKS5 идёт открытым текстом.

Кто разрешает доменное имя в адрес?

Ответ зависит от клиента, а не от протокола — отсюда и недоумение «прокси включён, а DNS-запросы уходят провайдеру».

• curl. --socks5 резолвит имя локально, --socks5-hostname — на прокси; то же задают схемы socks5:// и socks5h://.
• Chrome. По документации Chromium у HTTP-прокси имя разрешает прокси, у SOCKSv4 — клиент и только в IPv4, у SOCKSv5 — снова прокси. Аутентификация SOCKSv5 не поддерживается, UDP не ретранслируется.
• Firefox. В актуальных исходниках network.proxy.socks5_remote_dns по умолчанию true, а network.proxy.socks_remote_dns для SOCKS4 — false.

У туннеля развилки нет: wg-quick принимает ключ DNS = и вызывает resolvconf — резолвер меняется системно.

Сводная таблица различий

Девять осей, по которым они расходятся.

Как включается прокси и как туннель?

Прокси включается настройкой приложения: расширение Chrome управляет им через API chrome.proxy с разрешением proxy и схемами http, https, quic, socks4, socks5. Браузерные «VPN-расширения» так и работают — меняют настройки одного браузера, а мессенджеры, игры и обновления системы идут мимо. Системный канал иной: на Android сервис объявляется с разрешением BIND_VPN_SERVICE, активным может быть лишь одно подключение, а списки addAllowedApplication и addDisallowedApplication взаимоисключающие. Практика — как пользоваться ВПН.

Когда уместен каждый механизм?

Прокси уместен, когда нужно увести трафик одной программы. Пример без стороннего сервиса — ssh -D: OpenSSH поднимает локальный SOCKS-сервер (SOCKS4 и SOCKS5) и пробрасывает соединения по каналу SSH. Туннель уместен, когда важен охват: один канал для всех приложений, поддержка UDP и ICMP, предсказуемая точка выхода, защита в публичном Wi-Fi, безопасный удалённый доступ. Границы есть и у него: туннелирование поверх TCP WireGuard не поддерживает, маскировкой трафика проект не занимается. Как поднять канал — настройка WireGuard на своём VPS.

Чего не делают оба механизма?

Ни прокси, ни туннель не дают анонимности: меняется видимый адрес, а не личность. Прокси способен раскрыть вас сам — RFC 7239 определяет заголовок Forwarded с параметром for, куда подставляется исходный адрес клиента. Раздел 4 рекомендует держать заголовок выключенным по умолчанию, а раздел 8.3 признаёт адрес клиента чувствительными данными и требует обфусцированных идентификаторов в for и by по умолчанию. Что от смены точки выхода не зависит вовсе — вход в аккаунт и фишинг — разобрано в материале что такое ВПН. Исходный адрес известен владельцу узла и там, и там; что попадает в логи — в материале про безопасность.

Частые вопросы

Короткие ответы на частые вопросы о прокси и туннеле.

Материал носит научно-технический характер и посвящён шифрованию трафика и настройке собственного защищённого канала. Прямой ответственности за использование VPN физическим лицом законодательство РФ не устанавливает. Сайт не рекламирует сервисы и не публикует рейтинги.