Я занимаюсь сетевой инфраструктурой уже больше десяти лет. За это время у меня выработался стойкий иммунитет к хайпу вокруг новых инструментов — слышал я эти «революции» раз сто. Но в какой-то момент я всё-таки попробовал описать рабочую задачу языковой модели не как поисковый запрос, а как объяснение коллеге. И понял, что это принципиально другой разговор.
Сегодня расскажу про три конкретных случая из своей практики, где Claude помог мне написать рабочий код быстрее, чем я бы сделал это сам. Без маркетинга — только задача, промпт и результат.
Задача первая: watchdog для зависших WireGuard-пиров
RouterOS 7 · WireGuard · Scheduler
Ситуация знакома каждому, кто держит WireGuard на MikroTik: клиент отключается некорректно, туннель «висит» — last-handshake давно просрочен, трафика ноль, но пир остаётся в таблице живым. Следующий клиент с тем же ключом не подключится. Проблема решается руками за минуту, но происходит это в самый неподходящий момент.
Я описал задачу Claude так, как объяснил бы новому коллеге:
Мой промпт
У меня MikroTik RouterOS 7, настроен WireGuard VPN.
Иногда клиенты отваливаются некорректно — last-handshake
устаревает (больше 3 минут), но пир не удаляется сам.
Напиши скрипт-планировщик, который каждые 5 минут
проверяет всех пиров и удаляет тех, у кого last-handshake
старше 180 секунд. Добавь запись в системный лог при
каждом удалении. RouterOS scripting language.
Первый ответ был почти верным, но Claude сразу предупредил о подводном камне — и это важно:
Ответ Claude (комментарий)
Важно: в RouterOS 7 значение last-handshake возвращается
как строка формата "Xm Ys", а не как число секунд.
Прямое арифметическое сравнение не сработает — нужен
парсинг. Вот исправленная версия с учётом этого...
Это не автодополнение — это знание специфики платформы. Итоговый скрипт с парсингом строки:
RouterOS Scriptwg-watchdog.rsc · запускать каждые 5 мин через Scheduler
# WireGuard Watchdog — удаляет зависшие пиры
# Добавить в Scheduler: интервал 00:05:00
# Требует: policy = read, write, test
:local maxAge 180 # секунд до признания пира мёртвым
:local removed 0
:foreach peer in=[/interface/wireguard/peers find] do={
:local lhs [/interface/wireguard/peers get $peer last-handshake]
:local name [/interface/wireguard/peers get $peer name]
# Парсим строку вида "3m 42s" → секунды
:local totalSec 0
:if ([:find $lhs "m"] > 0) do={
:local mPos [:find $lhs "m"]
:local mins [:tonum [:pick $lhs 0 $mPos]]
:set totalSec ($mins * 60)
:local rest [:pick $lhs ($mPos + 1) [:len $lhs]]
:local sPos [:find $rest "s"]
:if ($sPos > 0) do={
:set totalSec ($totalSec + [:tonum [:pick $rest 0 $sPos]])
}
} else={
:local sPos [:find $lhs "s"]
:if ($sPos > 0) do={
:set totalSec [:tonum [:pick $lhs 0 $sPos]]
}
}
:if ($totalSec > $maxAge) do={
/log info ("WG watchdog: удаляю зависший пир [" \
. $name . "], last-handshake " . $lhs)
/interface/wireguard/peers remove $peer
:set removed ($removed + 1)
}
}
:if ($removed > 0) do={
/log info ("WG watchdog: удалено пиров: " . $removed)
}
Скрипт работает в продакшне. Ключевое, что ИИ добавил сам, без моей просьбы — проверку прав планировщика в комментарии и счётчик удалённых пиров в лоне. Мелочь, но именно такие детали отличают «работает» от «работает правильно».
Что сэкономил: около 40 минут на разбор документации по парсингу строк в RouterOS и отладку сравнения типов. Плюс — Claude нашёл баг до того, как я его поймал бы в продакшне.
Задача вторая: аудит firewall-правил на ошибки логики
RouterOS 7 · Firewall · Security Audit
У меня была задача — проверить конфигурацию файрвола на клиентском MikroTik RB4011. Конфиг большой: больше семи тысяч строк. Смотреть глазами — долго и ненадёжно, потому что глаз замыливается и пропускает логические противоречия.
Я экспортировал только блок firewall filter и вставил его в Claude с таким запросом:
Мой промпт
Это экспорт firewall filter с MikroTik RouterOS 7.
Найди логические ошибки: правила, которые никогда не
срабатывают из-за порядка; правила, которые блокируют
или разрешают больше, чем задумано; дублирующиеся
условия. Объясни каждую найденную проблему простым
языком и предложи исправление.
«Правило №47 принимает входящий RDP (порт 3389) до того, как отрабатывает блок brute-force. Это означает, что цепочка защиты от брутфорса для RDP фактически не работает — трафик уходит в accept раньше, чем попадает в проверку.»
Это была реальная находка — критическая ошибка в логике. Правило accept стояло выше, чем цепочка brute-force, и полностью её нейтрализовало. Я бы нашёл это сам, если бы смотрел целенаправленно. Но при аудите 72 правил подряд — легко пропустить.
Итого Claude нашёл в том конфиге:
- Критическая: accept-правило для RDP стояло выше цепочки brute-force, нейтрализуя защиту
- Серьёзная: stages брутфорс-защиты были выстроены в обратном порядке — stage-3 срабатывал раньше stage-1
- Средняя: Hairpin NAT настроен на неправильный интерфейс — внутренние клиенты не могли обращаться к публичному IP изнутри сети
- Информационная: srcnat-правила в неоптимальном порядке — влияло на производительность, не на безопасность
На ручной аудит такого объёма у меня ушло бы полдня. С ИИ — час, включая проверку каждой находки и написание исправлений.
72
правила firewall в конфиге
28
проблем нашёл Claude
×6
быстрее ручного аудита
Задача третья: политика маршрутизации через WireGuard
RouterOS 7 · Mangle · Policy Routing
Это была самая сложная из трёх задач. Нужно было настроить policy routing: часть трафика — через WireGuard-туннель, часть — напрямую. Mangle-правила в RouterOS — вещь деликатная: неправильный порядок или отсутствие одного флага ломает всё, причём так, что трудно понять где.
У меня был рабочий черновик, но он вёл себя непредсказуемо при определённых условиях. Я вставил его в Claude и попросил найти проблемы:
Мой промпт
Это mangle-правила для policy routing на MikroTik RouterOS 7.
Часть трафика должна идти через WireGuard (routing-table=vpn),
часть — напрямую. При высокой нагрузке иногда теряются
пакеты для established/related соединений. Найди причину
и предложи исправленный набор правил с объяснением логики
каждого блока.
Claude нашёл три проблемы, которые я пропустил:
- Отсутствует passthrough=no на ключевых правилах — трафик размечался дважды, что приводило к конфликту меток
- Нет fast-path для established/related — каждый пакет существующего соединения проходил все правила заново, отсюда потери под нагрузкой
- Риск петли маршрутизации — при определённых условиях трафик мог зациклиться между таблицами
В итоге получил переписанный блок из 15 правил с комментарием к каждому — и объяснением, почему именно такой порядок. Это ценнее самого кода: понимаешь логику — значит сможешь отладить самостоятельно, когда что-то пойдёт не так.
RouterOS Scriptmangle — fast-path для established/related (фрагмент)копировать
# Блок 1: fast-path — established/related не трогаем
# Это первое правило — иначе всё ломается под нагрузкой
/ip firewall mangle add \
chain=prerouting \
connection-state=established,related \
action=accept \
comment="fast-path: established/related" \
passthrough=no
# Блок 2: метим трафик по src-адресу для VPN-таблицы
/ip firewall mangle add \
chain=prerouting \
src-address-list=route-via-vpn \
action=mark-routing \
new-routing-mark=vpn \
passthrough=no \
comment="policy: src из списка → vpn"
Три урока, которые я вынес из этих экспериментов
1. Описывай задачу как коллеге, а не как поисковику
Разница между «wireguard mikrotik script remove peers» и «у меня MikroTik RouterOS 7, WireGuard, пиры зависают, last-handshake больше 3 минут — напиши скрипт и объясни подводные камни» — это разница между ссылкой на документацию и готовым решением с предупреждением о нюансах.
2. Всегда проверяй критичные места в официальной документации
ИИ иногда уверенно называет несуществующий параметр или устаревший синтаксис. Для скриптов, которые идут в продакшн, обязательно тестируй на лабораторном стенде и сверяй ключевые вызовы с wiki.mikrotik.com. Не потому что Claude часто ошибается — а потому что иногда ошибается. Этого достаточно для правила.
3. Используй ИИ как первый проход, а не как финальный ответ
Лучший сценарий — это когда ИИ делает черновик или аудит, а ты его проверяешь и дорабатываешь. Скорость растёт многократно, качество не страдает, понимание процесса остаётся при тебе. Это не делегирование — это инструмент, который думает быстрее тебя в рутинных задачах.
За последние несколько месяцев я стал использовать Claude для всего, что связано с написанием и отладкой скриптов, аудитом конфигов и разбором незнакомых кусков чужого кода. Не потому что это модно — а потому что это экономит реальные часы каждую неделю. А часы сисадмина в продакшне стоят дорого.
Если вы работаете с сетевым железом или любой другой инфраструктурой — попробуйте описать следующую задачу не в поиск, а в Claude. Первый раз будет непривычно. Второй раз вы уже не захотите возвращаться.
Вопрос к читателям
А вы уже пробовали использовать ИИ в работе с железом или инфраструктурой? Что получилось — и на каком шаге возникли трудности? Пишите в комментариях — интересно сравнить опыт с разными платформами и задачами.