Как программа направляет трафик в прокси без настроек приложения

Зачем перехватывать трафик, если у программ есть настройки прокси

Перехват трафика Windows нужен там, где настройка прокси внутри каждой программы перестаёт работать. У браузера есть поле для прокси, у Telegram Desktop тоже, а у клиента 1С, игрового лаунчера, консольной утилиты или корпоративного мессенджера его может не быть вовсе. Даже там, где поле есть, часто нельзя указать SOCKS5 с логином и паролем. Когда программ пять, каждую приходится настраивать отдельно, а после обновления настройка иногда сбрасывается.

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

Что делает WinDivert

WinDivert это открытый драйвер и библиотека для Windows, которые позволяют обычной программе перехватывать сетевые пакеты. Драйвер встраивается в сетевой стек через Windows Filtering Platform, штатный механизм фильтрации, на котором построены брандмауэр Windows и многие антивирусы. Программа передаёт драйверу фильтр, например «исходящие TCP-пакеты, кроме таких-то адресов». Всё, что подходит под фильтр, драйвер изымает из обычного пути и отдаёт программе.

Из этого следуют две практические вещи. Во-первых, для загрузки драйвера нужны права администратора, поэтому ProxyBridge устанавливается и запускается с ними. Во-вторых, перехват происходит ниже уровня приложений: программе не нужно поддерживать прокси, достаточно, что она пользуется обычным сетевым стеком Windows. Сам WinDivert ничего не знает о прокси. Он только даёт доступ к пакетам, а вся логика маршрутизации живёт в прокси-клиенте.

• фильтр задаётся выражением по протоколу, направлению, адресам и портам;
• подходящий пакет можно пропустить без изменений, изменить его заголовки или отбросить;
• изменённый пакет повторно отправляется в стек и идёт дальше как обычный;
• пакеты, не попавшие под фильтр, драйвер не трогает вовсе.

Локальный ретранслятор и таблица исходных адресов

Пакет нельзя просто «переслать в прокси»: прокси ждёт не сырые пакеты, а отдельное TCP-соединение, в начале которого клиент сообщает, куда хочет попасть. Поэтому прокси-клиент поднимает на компьютере локальный ретранслятор (relay), небольшой сервер, который слушает порт на адресе самого компьютера. Когда программа открывает соединение, например, с сайтом на порту 443, перехватчик видит первый пакет, запоминает пару «локальный порт источника и исходный адрес назначения» и переписывает заголовок так, чтобы пакет ушёл в ретранслятор.

Ретранслятор принимает соединение как обычный сервер. Чтобы понять, куда программа хотела попасть, он смотрит в таблицу по порту источника и находит исходный адрес и порт. Дальше ретранслятор сам подключается к прокси и отправляет запрос в формате протокола: для HTTP это метод CONNECT с адресом и портом, для SOCKS5 команда CONNECT после авторизации логином и паролем. Когда прокси отвечает, что туннель открыт, ретранслятор перекачивает байты в обе стороны. Ответные пакеты перехватчик тоже переписывает, подставляя адрес сайта, поэтому программа уверена, что разговаривает с сервером напрямую.

• программа открывает TCP-соединение с сервером;
• драйвер отдаёт первый пакет прокси-клиенту, тот записывает исходное назначение в таблицу;
• заголовок переписывается, и соединение приходит в локальный ретранслятор;
• ретранслятор находит исходный адрес по порту и открывает туннель через прокси;
• данные идут по туннелю, а ответы возвращаются программе с адресом сервера в заголовке.

Как клиент понимает, какая программа открыла соединение

В пакете нет имени процесса, там только адреса и порты. Чтобы применить правило вида «chrome.exe через один прокси, telegram.exe через другой», клиент запрашивает у Windows таблицу активных TCP-соединений с идентификаторами процессов. По локальному порту из пакета находится процесс-владелец, по идентификатору его имя, а затем имя сравнивается со списком правил.

В ProxyBridge это используется в режиме по программам (его ещё называют split tunneling): на вкладке «Главная» каждой программе по имени процесса назначается свой прокси, а строка «Все остальные программы» остаётся на «Напрямую». Если строк с программами нет, а у «Все остальные программы» выбран прокси, проверка проще: весь TCP-трафик компьютера отправляется через один выбранный прокси. Отсюда ограничение, о котором стоит помнить: правило привязано к имени исполняемого файла, поэтому два окна одной программы получат один и тот же прокси. Если нужны разные IP для разных профилей одного браузера, это задача настроек самого браузера или антидетекта.

Почему адрес самого прокси исключается из перехвата

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

Поэтому в фильтр драйвера сразу добавляется исключение: пакеты к IP-адресу прокси и от него идут мимо перехватчика. Для этого клиенту нужно заранее знать адрес прокси, и если прокси указан доменным именем, его сначала разрешают в IP. Похожим образом отдельно обрабатываются служебные пакеты самого ретранслятора, иначе его ответы снова попадали бы в обработку как новые соединения. Забытое исключение частая причина, почему самодельные решения на базе WinDivert «вешают» интернет целиком.

Почему UDP и DNS обрабатываются отдельно

Схема с ретранслятором опирается на понятие соединения. У TCP оно есть: рукопожатие, порт источника, поток байтов, который можно направить в туннель. У UDP соединений нет, это отдельные датаграммы. HTTP-прокси с методом CONNECT работает только с TCP. В SOCKS5 есть команда UDP ASSOCIATE, но поддерживают её далеко не все серверы, и она требует отдельного канала. ProxyBridge с версии 3.6.0 открывает такой канал для каждой программы: если SOCKS5-прокси принимает UDP ASSOCIATE, звонки, игры и WebRTC идут через него. Если прокси UDP не принимает (или это HTTP-прокси), UDP программы блокируется, а не уходит напрямую: так WebRTC не раскрывает реальный IP. В настройках можно выбрать и старое поведение, UDP напрямую.

С DNS отдельная история. Запрос имени обычно уходит по UDP на порт 53 ещё до того, как программа откроет TCP-соединение. ProxyBridge по умолчанию отправляет DNS-запросы через прокси как DNS over TCP, поэтому сервер имён провайдера не видит, какие домены ты запрашиваешь, а CDN подбирает узел под регион прокси. Переключатель «DNS через прокси» в настройках позволяет вернуть прямые запросы, если какой-то прокси не пропускает соединения к DNS-серверу.

Ограничения, о которых стоит знать заранее

Механика объясняет почти все типичные вопросы о поведении таких программ. Если что-то работает не так, как ожидалось, причина обычно в одном из пунктов ниже.

• VPN выключать не нужно: ProxyBridge работает вместе с VPN-клиентами вроде WireGuard, AmneziaWG и подобными, так что оба инструмента можно держать включёнными одновременно.
• Перехват не меняет содержимое трафика: защиту данных по-прежнему даёт HTTPS сайта, а прокси меняет только точку выхода в интернет.
• Скорость и задержку определяют прокси-сервер и маршрут до него, сам ретранслятор добавляет лишь немного работы процессору.
• Программы, которые ходят в сеть через собственный драйвер или туннель, могут не попасть под обычный фильтр.
• Без прав администратора драйвер не загрузится, и перехват не начнётся.

Читайте также