VLAN и старая мечта: с чего началась моя Visual IDE для сетей
Иногда одна ночная задача способна поселиться в голове на годы и тихо точить изнутри. Для меня такой задачей стал "простой" VLAN-туннель - тот самый, который на словах звучит как галочка в чек-листе, а в реальности превращается в длинную дорогу, холодную площадку на высоте и ощущение, что ты разговариваешь с сетью исключительно через узкую щель консоли.
Я тогда был обычным системным администратором, который уверенно держится за Linux и сервисы, но в сетях ещё не чувствует "картину целиком". И вот настал момент, когда в команде фактически остался один я, а меня отправили на объект примерно в трёхстах километрах от базы - на вышку. Задача была сформулирована максимально лаконично: поднять VLAN-туннель. Это как "просто сделай, чтобы работало", только с ветром, ограниченным временем и чужой инфраструктурой, где каждое неверное движение может стоить очень долгих объяснений.
Ночь на объекте прошла под шум оборудования и бесконечные проверки. Старый ноутбук, RouterOS Torch, постоянные созвоны с инженерами другой стороны - и в какой-то момент оно действительно заработало. Тогда я впервые остро почувствовал: сети - это не набор команд. Это пространство, по которому должен пройти пакет. И самое раздражающее - ты не видишь это пространство глазами.
Конфигурация - это не текст, а схема поведения
С тех пор меня не отпускала мысль: почему мы до сих пор пытаемся объяснять сеть через километры строк, таблицы и "поверь, так надо"? Перед тобой конфиг на сотни строк, но нигде нет честного ответа на базовый вопрос: *куда пойдёт пакет и почему он вообще туда пойдёт*.
Да, опыт со временем приходит. Спустя годы я мог открыть 20 строк конфигурации Cisco или Eltex и примерно восстановить топологию. Но в начале пути для меня было почти нереально даже на уровне ощущений понять разницу между trunk и access - не потому, что "не тянул", а потому что мне показывали сеть в формате текста, а не в формате движения.
Мне всегда казалось, что конфигурация должна читаться как карта:
- если есть проблема - она должна быть красной, и красный должен означать именно ошибку, а не "так дизайнер захотел";
- режим trunk/access должен быть виден сразу, а не вычисляться по косвенным признакам;
- VLAN'ы должны быть не числом в строке, а слоем в модели;
- а главное - пакет должен проходить не только через оборудование, но и через твои глаза.
История с CCR: когда железо бодрое, а механика - нет
В моём хозяйстве в какой-то момент появилась MikroTik CCR1036-8G-2S+. Для своего времени это была мощная штука: 36 ядер по 1,2 ГГц, два SFP+, RouterOS Level 6. Абонентов - чуть больше тысячи, биллинг завязан на MikroTik, а ограничения по скорости сделаны на простых очередях.
Те, кто сталкивался с большим количеством Simple Queue, уже понимают, где начинается боль. У простых очередей есть неприятная особенность: они проверяются последовательно. То есть если "твоя" очередь стоит где-нибудь в самом хвосте списка из тысячи - пакет может пройти через сотни проверок прежде, чем попадёт куда нужно. Это не страшилка и не художественное преувеличение, это реальная механика.
И как только в конфигурации добавлялось чуть больше обработки (например, через mangle), процессор мог улетать в потолок. В этот момент во мне снова включилось старое желание: не латать симптомы, а сделать так, чтобы вся конструкция стала понятной и управляемой.
Я не из тех, кто спокойно "просто покупает железку подороже и забывает". Во‑первых, деньги на условный идеальный ASIC не всегда лежат в тумбочке. Во‑вторых, даже дорогая коробка не отменяет вопроса: *что именно происходит с трафиком и где сеть ведёт себя не так, как ты ожидаешь*.
У нас был x86‑сервер с двумя Intel X520, и от скуки (и злости на ограничения) я полез копать DPDK. Тогда же я поймал себя на мысли: иногда написать кодек проще, чем разобраться, почему пакет "не должен был тут оказаться", но оказался.
Идея Visual IDE: сеть как проект, а не как свиток заклинаний
Так и родилась основная задумка: сделать визуальную IDE для сетей - среду, где конфигурация перестаёт быть линейным текстом и превращается в модель с понятными связями и проверками. Не "рисовалку ради красоты", а инструмент инженера, который:
1) показывает топологию и связи устройств;
2) визуализирует VLAN'ы, trunk/access, точки разрыва и места, где теряется доступ;
3) даёт "прогнать пакет глазами" по предполагаемому пути;
4) подсвечивает конфликты и ошибки до того, как ты нажмёшь "применить".
Отдельная, принципиальная вещь: конфигурация не должна мгновенно улетать в роутер. Между "я придумал" и "я применил в прод" должен быть слой валидации, предпросмотра и безопасного сравнения. В сетях цена ошибки обычно выше, чем в обычном коде: не тот порт - и ты отрезал себе удалённый доступ, а иногда и целый сегмент.
Зачем существует "режим Артура"
Внутри я давно называю один из ключевых режимов "режимом Артура". Это не про магию и не про юмор ради юмора. Это про ситуацию, когда инженер делает всё правильно, но сомневается, потому что не видит подтверждения.
"Режим Артура" - это когда инструмент обязан объяснить, *почему он считает, что всё будет работать*, и на чём держится эта уверенность: какие VLAN'ы проходят, где тег снимается, где добавляется, какие ACL/фильтры/правила могут вмешаться, где есть неоднозначность.
Сети часто ломаются не из-за "глупой ошибки", а из-за маленькой недосказанности между слоями: тут access, там trunk, здесь native VLAN, а здесь где-то в середине неожиданно включён фильтр, о котором забыли.
Немного о безопасности: не ломать, не светить, не терять контроль
Любой инструмент, который приближается к сетевой конфигурации, обязан быть параноиком. Я для себя сразу зафиксировал несколько правил:
- никакого автоматического пуша в оборудование "по умолчанию";
- обязательный дифф и история изменений: кто, что и когда хотел изменить;
- разделение окружений (черновик/тест/боевое);
- минимизация секретов в проекте: пароли, ключи и токены не должны превращаться в "комментарий в конфиге";
- предохранители от самоотстрела: если изменения могут лишить тебя управления устройством, инструмент должен предупредить, а лучше - предложить план отката.
В идеале Visual IDE должна вести себя как хороший DevOps-пайплайн, только для сетей: сначала анализ, затем проверка, затем безопасное применение с возможностью быстро вернуться назад.
Что уже получилось собрать (и почему это важно)
Я не верю в разработку "в стол". Поэтому всё, что появляется, стараюсь оформлять как работающие кирпичики: парсер конфигураций, модель интерфейсов, связи, правила VLAN, отображение trunk/access, базовые проверки целостности.
И каждый такой кирпичик на самом деле отвечает на один вопрос: *как превратить текстовую конфигурацию в структуру, по которой можно ходить, проверять и симулировать*.
Отдельно отмечу роль нейросетей в этой истории. Они реально ускоряют добивание мелких и очевидных багов, помогают быстрее проходить по рутине и держать темп там, где раньше я бы увяз в мелочах. Это не "автопилот", который делает за тебя архитектуру. Но это хороший усилитель, когда у тебя есть направление и критерии качества.
Новые параграфы: как я вижу идеальную Visual IDE для сетей
1) Симуляция пути пакета как базовая функция.
Я хочу, чтобы можно было выбрать "источник → назначение", указать VLAN/подсеть/тип трафика и получить маршрут: где тегируется, где разметка меняется, где вступают в силу правила, где возможен дроп. Это должно быть понятнее, чем вручную раскручивать клубок из таблиц и правил.
2) Визуальная диагностика вместо охоты по логам.
Когда что-то не работает, инженер обычно собирает картину из косвенных улик: counters, логи, зеркала, torch, tcpdump. IDE должна собирать эти признаки в единый "рентген": на каком участке начались потери, где внезапно меняется MTU, где L2 живёт, а L3 уже умер.
3) Конфиг как граф, а не как простыня.
В тексте легко потерять контекст: одно правило зависит от другого, но они разбросаны по разным разделам. В графе можно показать зависимости явно: этот интерфейс участвует в bridge, на нём VLAN filtering, вот таблица VLAN, вот PVID, вот список tagged/untagged.
4) Проверки здравого смысла (lint для сетей).
Например: "на trunk нет нужного VLAN", "native VLAN конфликтует", "на access-порту включён лишний tagged", "STP выключен там, где нельзя", "ACL перекрывает нужный сервис". Это не заменяет инженера, но снимает класс ошибок "не заметил".
5) Безопасные шаблоны и генераторы без фанатизма.
Шаблоны нужны, но ровно до момента, пока они не превращают сеть в копипасту, которую никто не понимает. Я за подход: шаблон объясняет, что он делает, и оставляет возможность собрать вариант руками, не воюя с абстракциями.
6) Режим обучения: показывать не только "что", но и "почему".
Новичкам сложно потому, что сети объясняют уверенным тоном, но редко - причинно-следственно. IDE может стать тренажёром: навёл на trunk - увидел, какие VLAN'ы реально проходят и где они нужны дальше по цепочке.
7) Совместимость как стратегия: не один вендор.
Реальные сети почти всегда разношёрстные: MikroTik, Cisco, Eltex, иногда ещё что-то. Поэтому цель - не "идеальный мир одного производителя", а общий слой модели, куда можно приводить разные конфиги и сравнивать их поведение.
8) Контроль изменений как в разработке.
Хочется нормального процесса: ветки изменений, ревью, понятные диффы, "план применения", список затрагиваемых устройств и сервисов. Чтобы сети перестали быть областью, где всё держится на памяти одного человека.
Почему я вообще этим занимаюсь
Потому что мне надоело, что сеть традиционно живёт в формате: "вот тебе конфиг, разберись". Я хочу инструмент, который переводит сетевую реальность в наглядную, проверяемую форму. Чтобы инженер видел не только команды, но и смысл: как устроены сегменты, как идут VLAN'ы, где точки риска, и что будет, если изменить одну строчку.
Та самая ночная вышка давно закончилась. Но ощущение, что пакет должен проходить "глазами", - осталось. И, похоже, именно из этого ощущения и выросла моя Visual IDE для сетей.
