Дві локальні мережі в 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 зі зламаним ім'ям читається точно як зламаний шлях. Якщо маршрутизуючий партнер працює в хмарній мережі, перегляньте також правила пересилання й міжмережевого екрана провайдера, бо реєстрація їх не скасовує. Тримайте спостереження з тесту поряд із планом, бо наступній людині, яка це налагоджуватиме, знадобляться політика, що збіглася, і записана адреса джерела, а не опис топології.