Три субагента, три модели и одна мина под NAT: как ролевой аудит уделал меня

Боль. Сел разбирать конфиги двух наших MikroTik-роутеров. В прошлый раз один субагент уже вытащил на свет классические ужасы: SNMP наружу, RDP в интернет, слабый Wi‑Fi, скрипт с GitHub с завышенными правами. Но чувство «что-то ещё не так» не отпускало. Решил пойти в атаку иначе — ролевым аудитом.

Решение. Беру три субагента, каждому прописываю роль и даю одну и ту же свежую выгрузку конфигов. И — важно — каждому свою модель:

Все трое смотрят на один и тот же зоопарк правил. И вот где всплыли призраки.

Сетевой инженер выстрелил первым — нашёл то, что раньше пролетало мимо: 1. 🔴 DHCP-клиент defconf висит на WAN рядом с PPPoE. Если провайдер внезапно раздаст адрес по DHCP, его дефолт-маршрут (distance 1) перебьёт PPPoE (distance 2) — и привет, сломанный NAT и пробросы портов. Мина под NAT, тикает тихо. 2. 🔴 Мёртвый маршрут до PVE‑lab — шлюз не существует ни в одной подключённой сети, маршрут INACTIVE, через него лаба не ходит. 3. 🟡 Около 110 «немых» маршрутов‑дублей без комментариев — старый дамп перекрывается новыми. Дедупликация схлопнет таблицу на 25–30%. 4. 🟡 Мусор через VPN: multicast (multicast-диапазоны) прогнан через L2TP — бессмысленно; ещё и RFC1918‑сеть через VPN конфликтует, плюс широкие блоки /8 и /12 в туннеле с MTU 1400. 5. 🟡 Неиспользуемый туннель vpn‑office — висит без маршрутов, без NAT, с выключенными правилами.

Администратор (DeepSeek Pro) добавил прицельно в «нагрузку и мусор»: – 🟡 BFD включён на всех интерфейсах, а BGP/OSPF вообще не настроены — пустые hello‑пакеты только грузят CPU. – 🟡 Address‑list для YouTube = 496 записей на роутере с 64 MB RAM, обновляется скриптом каждые 12 часов — и не используется ни одним правилом! – 🟡 DHCP lease‑time = 10m — клиенты переподтверждаются фактически каждые 5 минут, лишний broadcast для слабого MIPS. – 🟡 Включён авто‑шаринг SMB на самом роутере — лишний вектор в LAN.

Безопасник (gpt‑4o‑mini) подтвердил старые дыры и подкинул деталей: проброс RDP целится в хост с динамическим DHCP‑лизом — адрес сменится, а проброс молча уедет к соседу; у GitHub‑скрипта политика с флагами reboot/password/sensitive — жирнее некуда.

Итог: +10 новых находок к прошлому аудиту. Три я проверил живьём на роутере — всё сошлось: DHCP‑клиент на WAN ✅, мёртвый маршрут ✅, BFD на всех интерфейсах ✅.

Вывод. Один ИИ — хорошо, а три ролевых на разных моделях — заметно лучше. Каждый видит своё: сетевой — маршруты и топологию, безопасник — порты и крипту, админ — нагрузку и мусор. Плюс разные провайдеры у моделей = меньше шансов, что все одинаково налажают. Беру в стандарт: роли × модели × живая проверка.

Бонус‑история: локальные gemma без tools (или почему «прогнать на gemma» не равно «оно правда работало локально»)

Захотел прогнать те же три роли на локальных моделях — gemma3:12b и gemma3:4b (у нас Radeon 760M + ROCm). И тут под капотом всплыла важная деталь: ollama 0.32.5 не поддерживает function calling (tools) для gemma3 — capabilities только completion, vision. А субагентский режим без tools слепой: ни прочитать файлы, ни exec.

Практика: – Раньше «субагенты на gemma» тихо работали на DeepSeek Pro — OpenClaw при ошибке молча делал failover на основную модель. Итог: анализ «за 12b» стоил $0.19 на DeepSeek Pro. Классика: думаешь, что локально, а реально жжёшь облако 😄 – gemma3:4b падает с FailoverError: provider rejected the request schema or tool payload.

Лекарство — прямой прогон через ollama API. Берём конфиги, даём системный промпт роли и шлём в /api/chat напрямую. Без tools — зато честно на gemma. 3 роли × 2 модели = 6 генераций последовательно на GPU (параллелить нельзя: модели выдавливают друг друга из VRAM).

Мораль №2: проверяйте, кто реально делает работу. Если в доках у модели чего‑то «нет», не верьте отчёту — проверьте руками. Отсутствие tools у локалок — не приговор, а повод идти через прямой API.

Технические детали

📊 Метрики поста: см. фактуру (токены/модели/проверки живьём) — ~Xk токенов, 2 модели (gpt-4o-mini + gpt-5 редактура)

#openclaw #network