ZeroTier до локальної мережі: правила маршруту UFW, а не дозвіл порту

Дістатися до принтера в офісній локальній мережі через учасника ZeroTier звучить як одне правило, але насправді це три рішення в трьох різних місцях. Оверлей має знати, де розташована локальна мережа, хост Linux має бути готовий пересилати пакети, а локальна мережа має знати, як надіслати відповідь назад. Вхідне правило, яке відкриває порт на шлюзі, не торкається нічого з цього. Це неправильний інструмент на правильному хості.

Три завдання, три власники

Керований маршрут належить конфігурації мережі ZeroTier. Він повідомляє учасникам, що префікс доступний через певну адресу учасника.

Пересилання належить ядру Linux і тому, хто володіє політикою його міжмережевого екрана. Воно вирішує, чи пакет, що надійшов оверлеєм, знову вийде через фізичний інтерфейс. Хост, який не пересилає, мовчки відкине пакет після його прийняття. Відправник бачить тайм-аут, і в журналі служби нічого не з’являється.

Зворотний шлях належить локальній мережі. Її хости та її маршрутизатор мають знати, що префікс оверлею доступний через адресу шлюзу в локальній мережі, інакше щось має транслювати трафік, щоб це питання взагалі не виникало.

Кожне з цього може бути правильним, поки інші не працюють, і тому перевірка, яка лише пінгує шлюз, нічого не доводить про службу за ним.

Спрямуйте керований маршрут на учасника

Додайте маршрут для потрібного префікса локальної мережі через адресу оверлею шлюзу, а не через його адресу в локальній мережі. Адреса оверлею — та, до якої можуть дістатися інші учасники; адреса локальної мережі має сенс лише на кабелі.

Щоб схема працювала, учасники мають приймати керовані маршрути, а їхні власні локальні мережі не повинні вже використовувати префікс, який ви оголошуєте. Віддалений ноутбук, який удома перебуває в 192.168.60.0/24, теж не може маршрутизувати 192.168.60.0/24 через оверлей.

Тримайте оголошений префікс настільки вузьким, наскільки дозволяє завдання. Оголошення більшого агрегату заради впливу на перевагу може також претендувати на адресний простір, який вам не належить, і конфлікт, що виник, проявляється на пристроях, під’єднаних до обох мереж. Це може також змусити учасника віддати перевагу шляху, який нікуди не веде. Тримайте маршрут чесним, а решту хай робить політика.

Запишіть префікс і адресу учасника в ту саму нотатку, що й правила міжмережевого екрана, бо найчастіша несправність — маршрут, що вказує на неправильного учасника.

Увімкніть транзит у ядрі

Прочитайте поточне значення пересилання, перш ніж щось змінювати, потім зробіть налаштування постійним через механізм, який ваша система вже використовує, а не через разову команду, що зникає під час перезавантаження.

Якщо політикою володіє UFW, його правила маршруту виражають пересилання для пари джерела, призначення та інтерфейсу. Вони відокремлені від вхідних правил, що відкривають службу на самому шлюзі:

sysctl net.ipv4.ip_forward
sudo ufw route allow in on zt3f2a1c9d out on eth0 proto tcp to 192.168.60.20 port 443
sudo ufw status verbose

Назва інтерфейсу — це реальний пристрій оверлею на цьому хості, який можна прочитати за допомогою ip link; це не фіксований рядок у всіх інсталяціях. Якщо хост пересилає за замовчуванням, а UFW не на шляху, правило маршруту буде проігноровано, і важливими є налаштування ядра.

Виберіть, як повертаються відповіді

Зі збереженням джерела служба в локальній мережі бачить справжню адресу оверлею і відповідає на неї. Для цього потрібен маршрут на хості локальної мережі або на його маршрутизаторі, що спрямовує префікс оверлею на ваш шлюз, а це зміна поза межами Linux-машини.

Коли такий маршрут додати неможливо, обмежена трансляція джерела робить запит таким, ніби він прийшов зі шлюзу в локальній мережі. Тоді відповіді повертаються локально, і змінювати маршрутизацію локальної мережі не потрібно, але ціною цього стає втрата початкового джерела в журналах служби.

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

Жоден із варіантів не дає небажаного доступу з локальної мережі назад до довільних учасників оверлею. Якщо це потрібно, це окреме правило з власним розглядом.

Перевіряйте зі справжнього учасника

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

Учасник, який повідомляє ONLINE, або успішний пінг адреси оверлею шлюзу не підтверджують ні маршрут, ні правило пересилання, ні зворотний шлях:

zerotier-cli listnetworks
ip -4 route get 192.168.60.20
sudo ufw status numbered

Друга команда показує, який інтерфейс використав би пакет до хоста локальної мережі, а третя — чи існує правило маршруту в задуманому вигляді. Якщо обидві виглядають правильно, а служба все одно завершується тайм-аутом, залишений підозрюваний — зворотний шлях.