В двух филиалах одинаковая сеть 192.168.1.0/24: как завести её в NetBox и не перепутать адреса

Одинаковая подсеть 192.168.1.0/24 в двух филиалах — это не ошибка адресации, а обычное следствие того, что оба офиса настраивали независимо и по шаблону производителя роутера. Проблема начинается, когда всё это нужно свести в один NetBox: без разделения адресных пространств второй префикс просто не даст себя создать. Разделяет их VRF — отдельная таблица маршрутизации, а не Site и не Tenant, как многие пробуют сначала. Разберу, как это устроено и что важно проверить перед тем, как заводить два одинаковых префикса.

Почему Site и Tenant не решают проблему одинаковых адресов

Первая интуитивная попытка развести два одинаковых префикса — присвоить им разные Site или разные Tenant. Это не сработает: Site и Tenant в NetBox — это организационная принадлежность объекта, а не пространство имён адресации. Модель Prefix физически не проверяет уникальность в привязке к сайту или арендатору — она проверяет уникальность в привязке к VRF (или к глобальной таблице, если VRF не назначен). Когда я делаю внедрение NetBox для компании с несколькими филиалами и обнаруживаю совпадающую адресацию, я сразу объясняю клиенту: сайт останется как был, а вот пространство адресов придётся явно разделить отдельной сущностью.

В обсуждении на GitHub (discussion #13492) разбирали ровно такую ситуацию — несколько площадок с одинаковыми приватными диапазонами. Ответ участника сообщества однозначен: IP-адреса, префиксы и диапазоны напрямую привязаны к VRF, а VRF в NetBox по сути — «зона уникальности»; каждой площадке нужен свой VRF и свой экземпляр префикса. Там же показано, что бывает без этого: адрес, добавленный для площадки А, виден внутри префиксов обеих площадок, а под одним 172.16.30.0/24 лежит смесь адресов из двух разных сетей. Автор вопроса замечает, что связь адреса с сайтом в NetBox косвенная, через префикс, и IPAM скорее рассчитан на несколько сайтов одного владельца, чем на изоляцию независимых компаний — но для двух филиалов одной компании это ровно тот сценарий, который VRF решает штатно.

Что такое VRF в модели данных NetBox

VRF — Virtual Routing and Forwarding — представляет отдельную таблицу маршрутизации, как это реализовано и на реальном сетевом оборудовании. Обязательное поле модели — name, административное имя VRF. Поле rd (route distinguisher) опционально: документация прямо говорит, что назначение route distinguisher необязательно, а в самой модели это поле уникально на уровне всей базы (если заполнено) — то есть два разных VRF не могут иметь одинаковый route distinguisher, хотя оставить поле пустым можно.

У VRF также есть необязательный tenant — документация описывает его назначение так: VRF можно привязать к конкретному арендатору, чтобы упорядочить доступное адресное пространство по клиенту или внутреннему пользователю. Для сценария с двумя филиалами одной компании tenant обычно не нужен — сами филиалы естественнее развести через Site, а VRF используется именно как техническая изоляция таблиц маршрутизации, а не как организационная метка. Здесь та же логика, что и в обычной VLAN-сегментации офисной сети: изоляция трафика и организационная принадлежность — разные вещи, и путать их означает рано или поздно упереться в конфликт, который система не даст обойти.

Отдельно у VRF есть import_targets и export_targets — один или несколько route target, которые применяются к VRF: это поля для описания обмена маршрутами между VRF в сценарии L3VPN у операторов связи. Для внутреннего разделения двух филиалов с одинаковой адресацией без реального MPLS/VPN между ними эти поля обычно остаются пустыми — они нужны, когда VRF реально участвует в обмене маршрутами с внешней сетью, а не просто изолирует адресное пространство внутри учётной системы.

Как Prefix, IPRange и IPAddress привязываются к VRF

Все три модели адресного пространства — Prefix, IPRange и IPAddress — имеют собственное поле vrf, ссылку на конкретный VRF. Назначение VRF у префикса опционально: документация формулирует это так — «VRF assignment is optional. Prefixes with no VRF assigned are considered to exist in the global table». Иными словами, объекты без явного VRF не остаются «ничьими» — они автоматически относятся к одной общей глобальной таблице, и именно поэтому два одинаковых префикса без VRF конфликтуют между собой: они оба претендуют на одно и то же место в global table.

На практике это значит, что префикс, диапазон IP и отдельный IP-адрес всегда нужно связывать с одним и тем же VRF для конкретного филиала — если завести 192.168.1.0/24 с VRF филиала А, а отдельный адрес 192.168.1.10 внутри него оставить без VRF, адрес формально попадёт в global table, а не внутрь префикса VRF филиала А. Для корректной модели я всегда сначала фиксирую в документации, каким объектам какой VRF назначается, а не полагаюсь на то, что NetBox сам логически свяжет их по совпадению диапазона — этого не происходит, привязка к VRF у каждого объекта своя, отдельная.

enforce_unique и ENFORCE_GLOBAL_UNIQUE: два разных выключателя

В модели есть два разных механизма проверки уникальности, и их легко перепутать. Первый — поле enforce_unique прямо на самом VRF, оно управляет проверкой дублей префиксов и IP-адресов внутри этого конкретного VRF. Тут есть ловушка в самой документации: на странице VRF до сих пор написано, что по умолчанию NetBox разрешает дубли внутри VRF. Код говорит обратное — поле объявлено как BooleanField(default=True), так оно выглядит ещё в ветке 2.10, и в форме создания VRF чекбокс «Enforce unique space» стоит включённым. Проверка в Prefix.clean() и IPAddress.clean() прямо смотрит на self.vrf.enforce_unique. Поэтому на практике новый VRF дубли запрещает, а разрешать их нужно осознанно, сняв флаг. Я всё равно выставляю его явно и описываю в поле description VRF — чтобы следующий администратор не гадал, чему верить.

Второй механизм — системный параметр ENFORCE_GLOBAL_UNIQUE. Он отвечает не за VRF, а за глобальную таблицу — объекты, у которых VRF не назначен вовсе. Документация формулирует это так: «By default, NetBox will prevent the creation of duplicate prefixes and IP addresses in the global table (that is, those which are not assigned to any VRF)». Значение True по умолчанию стало только в NetBox 3.7.0 (issue #14536), а до этого было False — на старых инсталляциях второй 192.168.1.0/24 без VRF молча создавался, и адреса двух офисов перемешивались под одним префиксом. Это динамический параметр: если он не задан в configuration.py, его можно менять в интерфейсе конфигурации без перезапуска. Именно из-за него на актуальной версии попытка завести второй 192.168.1.0/24 без VRF завершится ошибкой валидации — это ожидаемое, задокументированное поведение, а не баг.

Из двух переключателей для сценария «два филиала, одна и та же подсеть» реально важен второй: как только для каждого филиала заведён свой VRF и оба префикса привязаны каждый к своему VRF, они физически больше не претендуют на общую global table, и ENFORCE_GLOBAL_UNIQUE их уже не касается. Проверка enforce_unique в этой схеме важна для другого — чтобы внутри одного филиала (внутри одного VRF) администратор случайно не завёл тот же префикс дважды.

Пошагово: заводим два филиала с одинаковой сетью

Порядок действий, которым я пользуюсь при объединении инфраструктуры нескольких филиалов в одном NetBox. Сначала создаю по одному VRF на каждый филиал с говорящим именем, например VRF-Branch-Msk и VRF-Branch-Spb; route distinguisher оставляю пустым, если между филиалами нет реального MPLS L3VPN с операторской стороны, — поле опционально именно для таких случаев. Затем создаю префикс 192.168.1.0/24 дважды — по одному разу для каждого VRF, явно указывая vrf при создании, а не полагаясь на значение по умолчанию.

Через REST API это выглядит как два похожих запроса с разными VRF в теле:

curl -s -X POST https://netbox.example.local/api/ipam/prefixes/ \
  -H "Authorization: Token $NETBOX_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"prefix": "192.168.1.0/24", "vrf": 3, "site": 1, "description": "Офис Москва"}'

curl -s -X POST https://netbox.example.local/api/ipam/prefixes/ \
  -H "Authorization: Token $NETBOX_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"prefix": "192.168.1.0/24", "vrf": 4, "site": 2, "description": "Офис Санкт-Петербург"}'

ID VRF и сайтов здесь условные — их нужно взять из /api/ipam/vrfs/ и /api/dcim/sites/ конкретной инсталляции. Оба запроса создадут два разных объекта Prefix с одинаковым значением prefix, потому что уникальность проверяется в пределах VRF, а не глобально.

После этого все конкретные адреса — шлюзы, серверы, точки доступа — завожу через IPAddress с обязательным указанием того же vrf, что и у родительского префикса. Отдельно фиксирую в описании VRF или в комментарии к сайту, какой VRF за каким филиалом закреплён — это не проверяется NetBox автоматически, но критично для новых администраторов, которые впервые видят два одинаковых префикса в списке и должны сразу понимать, что это не ошибка дублирования.

Кейс: централизация учёта двух филиалов у «ЛитСтарт»

Условный клиент — самиздат-лаборатория «ЛитСтарт», 23 рабочих места в двух офисах: основной штат в головном офисе и небольшая редакция на удалённой площадке в другом городе. Оба офиса разворачивались в разное время разными подрядчиками, и оба получили одинаковую сеть 192.168.1.0/24 — просто потому что это первый диапазон, который предлагает мастер настройки почти любого домашнего или SOHO-роутера. Пока в компании не было единой системы учёта, это никому не мешало: два независимых офиса, два независимых роутера, пересечения адресации никто не замечал.

Когда компания решила завести единый NetBox для обоих офисов, первая же попытка добавить второй префикс 192.168.1.0/24 для удалённой площадки закончилась ошибкой валидации — сработал ENFORCE_GLOBAL_UNIQUE, потому что оба префикса пытались занять одно и то же место в глобальной таблице без VRF. Часть сетевых объектов удалённой площадки на тот момент уже была заведена без VRF, и часть IP-адресов из неё формально пересекалась с адресами головного офиса, которые тоже лежали в global table.

Решение заняло меньше дня: я создал VRF-Head-Office и VRF-Remote-Office, перенёс префиксы и адреса каждой площадки в свой VRF — около сорока объектов на удалённой площадке и чуть больше сотни в головном офисе, массовым редактированием по фильтру сайта. Global table я оставил пустой: если со временем офисы свяжут VPN, туннельные адреса и NAT-диапазоны лягут туда, и ENFORCE_GLOBAL_UNIQUE будет охранять именно их. Итог — оба офиса корректно учтены в одной базе, отчёты по адресному пространству строятся раздельно по VRF, и при подключении третьего возможного филиала в будущем компания уже знает, что делать в первую очередь: не переименовывать подсеть, а завести под неё отдельный VRF.

Частые ошибки при разведении пересекающихся подсетей

Самая частая ошибка — пытаться развести адреса через Site или Tenant, решив, что раз объекты организационно принадлежат разным сущностям, NetBox сам поймёт, что адреса не конфликтуют. Не поймёт: уникальность проверяется строго по VRF, и без него оба префикса конкурируют за одну и ту же global table независимо от того, к каким сайтам они привязаны. С похожей путаницей я сталкивался и в PostgreSQL, когда UNIQUE неожиданно пропускал дубли с NULL — в обоих случаях причина одна: администратор предполагает, что ограничение уникальности работает интуитивно, а на самом деле у него своя, отдельно описанная логика области действия.

Вторая ошибка — завести VRF для префикса, но забыть указать тот же VRF у вложенных IPAddress. Формально ничего не сломается сразу, но такой адрес окажется в global table, а не внутри VRF родительского префикса, и при следующем пересечении с адресом другого филиала валидация снова заблокирует создание — просто потому что конкретный адрес забыли привязать, а не сам префикс.

Третья ошибка — не документировать, какой VRF за каким филиалом закреплён, полагаясь на то, что имя VRF всё объяснит само. Через год, когда в компании появится третий филиал или сменится администратор, два одинаковых префикса 192.168.1.0/24 в списке без внятного описания снова создадут путаницу — просто уже не на уровне валидации NetBox, а на уровне человека, который должен понять, какой из двух объектов относится к его задаче.

Частые вопросы