Фреймворк, который видит, куда ушёл трафик

Раньше проверка выглядела так. Поднимаешь на сервере 12 UDP- и 12 TCP-слушателей. Шлёшь с клиента пакеты на порты 5056–5067. Потом глазами читаешь лог и решаешь, чей IP стоит в поле from.

Полчаса на прогон. Ручная работа. Ошибки от усталости.

Ключевой инсайт пришёл, когда мы разобрали роль агента. Агент — MITM-прокси. Он перехватывает соединение и решает: заблокировать (block), пропустить мимо себя (ignore) или завернуть в прокси-ноду (redirect). Проверять доставку бессмысленно. Проверять нужно адрес источника.

Сервер видит IP клиента — трафик прошёл мимо. Видит IP slave-ноды — трафик перехвачен. Не видит ничего — трафик отброшен.

Одна таблица на 24 строки. Из неё вырос фреймворк.

Слои

Каждый слой знает только о соседе снизу.

tests → steps → services → core → Windows

core — драйверы ОС: файлы, реестр, процессы, службы, сеть. services — логика агента: установщик, управление службой. steps — одно действие, обёрнутое в allure.step, плюс проверка. tests — сценарий.

Правило закрепили жёстко: шаг не читает .env и сам не ходит в Windows. Шаг принимает драйвер. Иначе через полгода никто не вспомнит, что делал конкретный тест.

Пять протоколов

У каждого своя роль.

WinRM 5985 — управление клиентом. NTLM и basic. Медленно, зато им можно всё. SMB 445 — загрузка MSI напрямую. smbprotocol вместо base64-чанков по 50 КБ. SSH 22 — Linux-ноды кластера и серверы со слушателями. fabric поверх paramiko. SOCKS5 и HTTP-прокси — каналы, через которые агент заворачивает трафик. Аутентификация noauth, basic или kerberos. На каждой ноде своя. Kerberos и NTLM — требование безопасности: доменный вход вместо пароля.

Плюс MITM. Адрес вида mitm.it:2281. Агент сам выпускает сертификат и подменяет TLS. Без этого перехваченный HTTPS не прочитать.

Конфиг вместо API

С агентом работаем через конфиг. У агента нет команды «заблокировать порт». Агент получает config.json и сам решает.

rules.block, rules.ignore, rules.redirect — что делать с портом. disable_system_proc — не трогать системные процессы. proxy.proxy_list — семь нод: адрес, имя, метод аутентификации, протокол, SPN. proxy.networks — какая нода обслуживает какую подсеть. check_interval_sec — как часто опрашивать состояние нод.

Тест применяет конфиг целиком и читает логи. Проверяет: маркеры загрузки есть, ошибок применения нет. Дальше логика чистая. block важнее ignore, ignore важнее redirect. Правило без поля transport работает только для TCP. ANY — для обоих.

Отказоустойчивость

Для одной подсети в proxy.networks описано пять нод. Пять нод образуют пул. Одну ноду мы намеренно вывели из строя как заведомо нерабочую. Никто не знает, какая нода ответит в конкретный момент. Так и задумано.

Тест проверяет принадлежность адреса пулу. Тест, прибитый к одной ноде, завтра сломается сам.

Фреймворк, который видит, куда ушёл трафик | Сетка — социальная сеть от hh.ru