NetBird Networks вместо Network Routes: как перенести доступ филиалов

Представьте карту филиала в Казани. Бухгалтеру нужна CRM на одном сервере, администратору нужна служебная панель на другом, а принтеры, камеры и рабочие станции в этой же подсети им совершенно ни к чему. Тем не менее в старой схеме часто выглядит так: один маршрут на всю подсеть 10.20.0.0/24, и каждый, кто допущен к маршруту, потенциально видит весь диапазон. Человеку нужен сервис, а получил он адресное пространство.

Переход с Network Routes на Networks в NetBird удобно использовать как повод нарисовать эту карту заново: не «какие подсети мы публикуем», а «какие ресурсы и кому нужны». Ниже разобран один условный филиал с двумя сервисами. Все адреса, группы и названия в примере вымышлены для иллюстрации, это не отчёт о реальном внедрении.

Сначала карта: ресурсы и люди, а не подсети

Прежде чем трогать настройки, выпишите существующий доступ. Для каждого старого маршрута зафиксируйте пять вещей: какой диапазон он публикует, через какой узел идёт трафик, какие группы к нему привязаны, включена ли маскировка (masquerade) и какие политики на него опираются. Это не бюрократия: именно из этой таблицы потом получается список ресурсов нового устройства.

В документации по старой модели есть два момента, которые стоит держать в голове при инвентаризации. Во-первых, маршрут без ACL Groups допускает широкий доступ. Во-вторых, если masquerade отключён, требуется обратный маршрут, то есть сеть филиала должна знать, как вернуть ответы обратно в VPN (документация NetBird Routes). Если в вашем филиале masquerade выключали ради того, чтобы серверы видели настоящие адреса клиентов, это надо отметить отдельно: такая особенность потом потребует отдельной проверки на новой схеме.

Там же сказано, что на дату проверки Routes помечены как deprecated, а для новых конфигураций, кроме exit nodes, рекомендованы Networks. Из этого следует практический вывод: если у вас есть exit node, он в этой миграции не участвует, трогать его не нужно. Речь только о публикации внутренних ресурсов филиала.

Для нашего примера инвентаризация даёт такую картину.

А нужно на самом деле иначе:

• CRM на 10.20.0.10, порт 443 — бухгалтерия и администраторы;
• служебная панель на 10.20.0.20, порт 8443 — только администраторы.

Разрыв между этими двумя картинами и есть реальная работа миграции.

Чтобы увидеть этот разрыв в числах, сравним два описания одного и того же филиала. В старой схеме достижимыми считаются все адреса подсети 10.20.0.0/24, то есть 254 хоста, и ограничивает их только политика. В нужной схеме осмысленных назначений два: 10.20.0.10 и 10.20.0.20. Остальные 252 адреса (принтеры, камеры, рабочие станции и всё, о чём никто не вспомнил) не должны быть целью ни для одной группы. Именно эти 252 адреса и составляют то, что в старой схеме держалось на негласном «туда никто не ходит».

Полезно добавить в инвентаризацию ещё один столбец: кто фактически обращается к каждому адресу. Если администратор говорит, что ходит только на панель, а бухгалтер только в CRM, это и есть исходный материал для групп. Если же выясняется, что кто-то ходит к третьему адресу, например к файловому хранилищу, у вас появляется третий ресурс и третья строка в карте, а не повод оставить широкий диапазон «на всякий случай». Лучше обнаружить такое сейчас, чем после отключения старого маршрута.

Как устроены три части: network, resource, policy

По документации, Network объединяет ресурсы, routing peers и политики доступа, а ресурсом может быть один IP, CIDR или домен (документация NetBird Networks). Попробуем разложить это на простом языке на нашем примере.

Network — контейнер для одного логического участка: «Филиал Казань». Всё, что относится к этому участку, живёт внутри.

Routing peer — узел внутри филиала, через который идёт трафик к ресурсам. В старой схеме эту роль играл тот же узел, что был маршрутизатором для подсети. Скорее всего, на первом этапе вы оставите тот же самый хост: он уже стоит в нужной сети и умеет до всего дотянуться.

Resource — то, к чему нужен доступ. Вместо одной записи «вся подсеть» вы создаёте две: CRM по адресу 10.20.0.10 и панель по адресу 10.20.0.20. Каждый ресурс можно описать как одиночный IP, как CIDR или как домен, и для нашей задачи пригодятся одиночные адреса.

Policy — разрешение, связывающее источник с ресурсом. Документация подчёркивает, что доступ к ресурсу за routing peer требует разрешающей политики, а ресурс можно ограничить одним хостом вместо всей подсети (там же). Это ключевая мысль всей миграции: сам по себе новый объект не делает доступ уже, это делает ваша разметка.

Здесь важна честность: если создать ресурс с CIDR на всю подсеть и выдать политику всем сразу, вы получите ровно тот же широкий доступ, только под новыми названиями. Networks — это инструмент, который позволяет описать доступ точнее. Точнее он станет лишь тогда, когда вы действительно опишете его точнее.

Разницу удобно показать на двух вариантах описания одного филиала. В первом вы создаёте один ресурс с CIDR 10.20.0.0/24 и одну политику для двух групп: формально вы перешли на Networks, но достижимы по-прежнему все 254 адреса, и карта читается так же плохо, как раньше. Во втором вы создаёте два ресурса с одиночными адресами и две политики с разными источниками: теперь из карты видно, что панель недоступна бухгалтерии, а любой адрес вне двух ресурсов не опубликован вовсе. Оборудование, routing peer и сама сеть в обоих вариантах одни и те же, отличается только то, насколько точно вы описали потребность (документация NetBird Networks допускает как CIDR, так и одиночный хост).

Из этого следует практическое правило для миграции: CIDR как ресурс оправдан там, где вам действительно нужен весь диапазон, например для небольшого сегмента, все узлы которого равноценны по доступу. Для смешанной подсети, где рядом живут CRM, панель и периферия, одиночные адреса дают больше пользы, а цена за это одна: придётся заранее перечислить, что именно нужно людям.

Группы: на чём всё держится

Политики в NetBird задают источники, назначения, протоколы и порты, а разрешения суммируются (документация по группам и политикам). Слово «суммируются» стоит перечитать дважды. Это значит, что запрет в одной политике не перекрывает разрешение в другой: если хотя бы одна активная политика пускает пользователя к цели, он пройдёт. Сужая доступ в новой политике, вы ничего не добьётесь, пока старая, более широкая, всё ещё работает.

Та же страница напоминает, что широкая Default policy сохраняет общий доступ. Поэтому перед тестом надо ответить себе на неприятный вопрос: а не открывает ли что-то из уже существующего всё то, что мы хотим закрыть? Если Default policy у вас включена и пускает «всех ко всем», то любые узкие правила Networks для проверки запрета будут бессмысленны. Либо вы заранее решаете, что с ней делать, либо тестируете запреты на фоне открытой двери и получаете ложное «всё работает».

И ещё одно: членство в группах влияет на фактические разрешения. Человек, который случайно попал в группу «Админы», получит доступ к панели, как бы красиво ни была написана политика. Для нашего филиала заведём группы так:

• kazan-accounting — сотрудники бухгалтерии;
• kazan-admins — администраторы филиала;
• kazan-test — одна учётная запись для проверки, о ней дальше.

Отдельная тестовая группа нужна, чтобы проверять новую схему на одном человеке, а не на всём отделе. Если вам интересно, как защитить сами входы пользователей в NetBird, это отдельная тема, которую разбирает материал про двухфакторную аутентификацию в Tailscale и Netbird.

Собираем тестовый филиал: два сервиса, три группы

Теперь соберём новую схему рядом со старой, не выключая её. Порядок такой.

1. Создаём network «Филиал Казань» и добавляем в него routing peer, тот узел, который уже стоит в сети филиала.
2. Добавляем ресурс «CRM» с адресом 10.20.0.10. Это одиночный хост, а не диапазон.
3. Добавляем ресурс «Служебная панель» с адресом 10.20.0.20.
4. Создаём политику «CRM»: источники — kazan-accounting, kazan-admins и kazan-test; назначение — ресурс CRM; протокол TCP, порт 443.
5. Создаём политику «Панель»: источники — только kazan-admins; назначение — ресурс панели; протокол TCP, порт 8443.

Тестовая группа входит в политику CRM, но не входит в политику панели. Так один человек может проверить сразу и разрешённый, и запрещённый сценарии. Если дать ему обе политики, вы проверите только то, что «открывается», а это самая лёгкая половина теста.

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

Разберём это на нашем примере. Допустим, CRM отвечает на порту 443, но выгрузка отчётов у неё сделана отдельным сервисом на другом порту. Политика «CRM» с единственным правилом TCP 443 откроет интерфейс, бухгалтер войдёт и увидит данные, а кнопка выгрузки не сработает. Со стороны это выглядит как «CRM сломалась», хотя причина в том, что в политике описан не весь набор портов, которые нужны сервису. Чтобы выяснить это заранее, попросите пользователя из бухгалтерии пройти полный рабочий сценарий, а администратора сервера назвать все порты, на которых слушает приложение.

Второй вопрос касается протокола. Политики задают не только порты, но и протокол, поэтому для сервиса, которому нужен ещё и UDP (например, для какого-нибудь вспомогательного обмена), одной записи с TCP будет мало (документация по группам и политикам). Если окажется, что нужен дополнительный порт, добавьте его в ту же политику, а не заводите отдельную с более широким охватом: так карта останется читаемой, а доступ не расползётся.

Проверка: что должно открыться и что обязано не открыться

Теперь самое важное. Новая схема заработала, когда она пускает куда надо, и не пускает куда не надо. Проверять придётся оба направления. Для этого составим таблицу ожиданий до начала тестов, чтобы не подгонять оценку под результат.

Последние три строки важнее первой. Если «запрещённое» открывается, причин обычно две, и обе вытекают из того, что мы уже разобрали. Либо разрешения суммируются, и где-то есть более широкая политика. Либо пользователь состоит в лишней группе. Разбирайтесь сначала с группами: это самая частая причина, и она не требует менять политики.

Проверку стоит проводить с отдельного устройства тестового сотрудника, а не с администраторской машины. Администратор обычно состоит в нескольких группах, и результат у него будет искажён. Фиксируйте не ощущения, а факты: что открылось, что нет, в какое время. Так вам будет с чем сравнить результат после отключения старого маршрута.

Чтобы результат нельзя было истолковать двояко, заведите простой протокол проверки: для каждой строки таблицы ожиданий записывайте время, адрес с портом, ожидаемый и фактический итог. В нашем примере это четыре строки, и если хоть одна расходится с ожиданием, переключение откладывается. Особенно внимательно относитесь к строке «любой другой адрес подсети»: проверьте не один случайный адрес, а два-три разных, например адрес соседнего сервера и адрес принтера. Один адрес мог случайно оказаться недоступным по другим причинам, например потому, что хост выключен, и тогда «запрет» окажется ложным.

Такой же осторожности требует и положительная проверка. Открывшаяся страница CRM говорит о том, что политика и routing peer работают, но не говорит, что трафик идёт именно по новому пути: пока активен старый маршрут, пользователя может пропускать он. Поэтому результат «открылось» окончательно доказателен только на фоне отключённого для тестовой группы старого доступа. Если в вашем филиале такое разделение невозможно, делайте положительную проверку и после выключения старого правила в согласованное окно, а не только до него.

Если masquerade в старой схеме был выключен, отдельно проверьте, видит ли сервер в CRM прежние адреса источников и работает ли у вас логика, которая на них опирается: белые списки, журналы доступа, лимиты. Документация по старой модели говорит лишь о том, что при отключённом masquerade нужен обратный маршрут. Как именно это поведёт себя в новой схеме для вашей сети, не следует предполагать: проверьте на тестовом пользователе, а не по аналогии.

Переключение: старое правило гасим только после проверки нового

Когда таблица ожиданий выполнена, наступает самый неприятный момент: надо отключить то, что работало годами. Порядок действий здесь строится вокруг одной идеи: ничего не удалять, пока не убедились, что без него всё в порядке.

1. Добавьте реальные группы в новые политики. Бухгалтерия и администраторы получают доступ к CRM, администраторы — к панели. Пока старый маршрут активен, пользователи этого не заметят, потому что старый путь по-прежнему их пускает.
2. Отключите старую политику или маршрут, а не удаляйте. Политику можно выключить переключателем Active или удалить (документация по политикам). Выключение полностью обратимо: если что-то пошло не так, вы просто включаете её обратно. Удаление оставляет вас с необходимостью восстанавливать настройки по памяти.
3. Наблюдайте. Попросите тестового сотрудника и одного-двух пользователей из каждой группы повторить типовые рабочие действия: открыть CRM, выгрузить отчёт, зайти в панель, если у них есть такое право.
4. Только через несколько рабочих дней удаляйте. Срок выбирайте по ритму вашего филиала: если есть месячные закрытия, подождите до них, там часто всплывают редкие обращения к сервисам, о которых не вспомнили в начале.

Путь отката прост: включить обратно старую политику и, если нужно, вернуть группам прежнее членство. Поэтому так важно, что вы ничего не удаляли. Новые ресурсы и политики при этом можно оставить на месте, они не мешают: пока старое широкое разрешение активно, итоговый доступ определяется суммой.

Заметьте обратный эффект. Пока вы не выключили старый маршрут, любые результаты проверки запретов ненадёжны, потому что широкое старое правило всё перекрывает. Поэтому честная последовательность такая: новая схема создана, старая отключена для тестовой группы или целиком в окно проверки, запреты проверены, затем решение о полном переходе. Если отключать старый маршрут для всех сразу вам страшно, а разделить его по группам нельзя, на время проверки заведите временную копию политики только для тестовой группы и сравнивайте результаты на ней.

Где у всего этого место для сервера

Routing peer в филиале и сам по себе не требует много. Если же вы решите вынести часть служебных сервисов вокруг этой схемы на отдельный сервер, например развернуть там тестовый стенд, на котором можно безопасно прогнать новые политики до выхода в филиал, подойдёт обычный VPS. На VPS MAATRIX доступны NVMe-диски, процессоры AMD EPYC и root-доступ; в публичном предложении указаны локации UK, US, RU и FR, а оплата возможна картой РФ и через СБП, с автоматическим созданием сервера в течение пары минут после оплаты.

Тарифы в линейке начинаются с Ba (1 vCPU, 2 ГБ RAM, 40 ГБ NVMe) и идут через Uab (2 vCPU, 4 ГБ, 80 ГБ), Heka (4 vCPU, 8 ГБ, 160 ГБ) и Maat (8 vCPU, 16 ГБ, 240 ГБ) до Djed (16 vCPU, 32 ГБ, 320 ГБ). Для стенда с двумя тестовыми сервисами, на котором вы отрабатываете политики, логично начать с небольшого тарифа и смотреть на реальную загрузку. Это отправная точка для эксперимента, а не обещание ёмкости: сколько пользователей и сервисов потянет конкретная конфигурация, показывает только замер на вашей нагрузке.

Что получится на выходе

Если пройти путь аккуратно, у филиала появится не новое название старого доступа, а документ, который читается без пояснений. Вместо строки «маршрут на 10.20.0.0/24, доступ у двух групп» появляется карта из четырёх понятных фактов.

Последняя строка и есть главный результат. Раньше она была невидимой и держалась на предположении «ну, туда никто не ходит». Теперь это явное свойство схемы, которое можно проверить одним запросом от тестового сотрудника. Когда в филиале появится третий сервис, вы добавите в таблицу ещё одну строку и ещё одну политику, и карта останется читаемой: каждый, кто откроет её через год, сразу поймёт, почему у бухгалтера нет доступа к панели.