Две локальные сети в NetBird: какие партнёры маршрутизируют и кому разрешено говорить

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

Сначала прочитайте сбой с рабочей станции

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

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

Выберите одного маршрутизирующего партнёра на площадку

Маршрутизирующий партнёр — это хост, который представляет свою локальную сеть в наложенной сети, поэтому выбирайте машину Linux со стабильной доступностью подсети, а не чей-то настольный компьютер. Зарегистрируйте её обычным порядком и поместите в группу, названную по роли, потому что сетевой ресурс и политика оба будут ссылаться на эту группу. Один представитель на площадку остаётся понятным; толпа добровольцев, объявляющих один и тот же префикс, превращает каждый следующий вопрос в сеанс отладки. Адрес партнёра в локальном сегменте так же важен, как его идентичность в наложенной сети, потому что этот адрес становится следующим переходом, который сообщают каждому обычному устройству.

Запишите план до того, как трогать консоль, потому что имена и префиксы — это место, где такие проекты уходят в сторону: префикс, шлюз, адрес партнёра и группа, для каждой площадки. Запад — 10.52.0.0/24, его обслуживает 10.52.0.5, а восток — 10.63.0.0/24, его обслуживает 10.63.0.5; две группы — west-routers и east-routers, и ни один префикс не должен пересекаться с другим, с диапазоном наложения или с другим маршрутизируемым назначением.

Создайте ресурс, оставьте маскирование включённым

В развёрнутой панели создайте один сетевой ресурс на площадку и прикрепите к нему группу маршрутизирующих партнёров этой площадки. Ресурс — это префикс, а группа — хост, который за него отвечает, и оба должны существовать, прежде чем что-то объявят. Убедитесь, что развёрнутая самостоятельно размещённая версия вообще имеет рабочий процесс «Сети», потому что более старый интерфейс с похожим по названию объектом маршрута — другая функция.

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

Давайте права инициаторам, а не префиксам

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

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

Научите каждый шлюз следующему переходу, затем проверьте отказ

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

Два описания маршрута принадлежат конфигурации шлюза каждой площадки, а не переопределению на хосте. Оба — обычные статические маршруты, и ни один не касается маршрута по умолчанию:

west gateway: 10.63.0.0/24 via 10.52.0.5
east gateway: 10.52.0.0/24 via 10.63.0.5

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

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