Шаг 1. Перехват на уровне драйвера. Агент встраивается в сетевой стек Windows. В основе лежит библиотека NetFilter SDK, использующая технологию WFP (Windows Filtering Platform). Драйвер перехватывает все TCP- и UDP-подключения до того, как они покинут сетевую карту.

В момент создания соединения Агент собирает данные: IP и порт отправителя и получателя, ID процесса (например, chrome.exe) и транспортный протокол. На основе этого начинается проверка.

Шаг 2. Кэш принятия решений Сначала Агент смотрит в кэш. Это таблица в памяти с записями о ранее принятых решениях (IP, порт, процесс, действие). При совпадении Агент применяет старое решение мгновенно.

Кэш живет один час. Сбрасывается при перезагрузке Агента или применении новой конфигурации. Это критически важный механизм. Он экономит ресурсы CPU. Но создает проблемы при тестировании: если поменять конфиг, а кэш не сбросить, старые соединения продолжат работать по старым правилам.

Шаг 3. Логика обработки правил Если в кэше пусто, Агент читает конфигурационный файл. Иерархия правил строгая:

1. block — высший приоритет. Соединение уничтожается. Правила ignore и redirect на него не действуют. 2. ignore — режим BYPASS. Трафик идет напрямую в интернет, минуя прокси. Нужно для системных служб или банковских приложений. 3. redirect — трафик нужно завернуть на прокси-сервер. 4. default_rule — применяется, если ни одно правило не сработало. Может быть block, ignore или redirect.

Шаг 4. Выбор прокси-сервера Соединение нужно отправить на прокси. В конфиге есть два списка: networks и proxy_list.

Агент смотрит на IP клиента и проверяет раздел networks (списки подсетей, закрепленных за нодами). Проверка идет сверху вниз. Если IP входит в подсеть 10.201.16.0/24, берется прокси master. Если нет — проверяется следующая.

Если клиент не попал в networks или нода недоступна, Агент идет в proxy_list. Он опрашивает серверы по порядку, проверяя работоспособность (порт открыт, авторизация проходит). Интервал проверки задается в check_interval_sec. Если сервер жив, соединение уходит на него.

Шаг 5. Определение FQDN и DNS-сенсор Правила работают не только по IP, но и по доменам. Как Агент понимает, что ya.ru — это 87.250.250.242? Внутри работает DNS-сенсор. Он перехватывает запросы к системной службе DNS и строит кэш соответствия IP и доменов (записи А и CNAME).

Если кэш пуст, но приложение использует HTTPS, Агент анализирует поле SNI в пакете. Имя домена передается открытым текстом при рукопожатии. Так Агент понимает, куда идет трафик, даже без ответа системного DNS.

Шаг 6. Аутентификация Соединение выбрало прокси. Теперь нужна авторизация. В конфиге есть метод: noauth (без пароля), basic (логин/пароль) или kerberos (доменный вход через тикеты). Для Kerberos Агент передает SPN (Service Principal Name), и прокси проверяет подлинность.

Шаг 7. Отказоустойчивость и BYPASS Если все прокси упали, включается режим BYPASS: трафик идет напрямую через шлюз. Но в версии 2.2 появилась возможность блокировать трафик в этом режиме. Если в default_rule прописан block, при падении всех прокси Агент не пропустит трафик, а заблокирует его. Это нужно для жестких политик безопасности.

Шаг 8. Конфигурация и самосохранение Агент читает config.json при запуске и подписывается на события файловой системы. При сохранении файла изменения применяются мгновенно.

Если в JSON ошибка, Агент не упадет. Файл сохранится как config_error.json, а Агент продолжит работать со старой рабочей конфигурацией. В версии 2.2 добавили строгую валидацию: если поле process или hosts пустое, конфигурация не применится.

Итог Логика Агента — содержит строгую иерархию правил, кэширование решений и мониторинг доступности прокси. Перехват идет на уровне драйвера. FQDN определяется через SNI и DNS. Понимание этой логики — фундамент для автоматизации. Мы знаем, где Агент кэширует решения и как выбирает ноду. Значит, можем написать тесты, которые проверят конкретные ветки этого алгоритма.

заглядывали под капот продуктов, которые тестируете, или проверяете только внешнее поведение?