Вузол виходу ZeroTier не працює? Перевірте маршрут, NAT і клієнт

Маршрут 0.0.0.0/0 у клієнті ще не вихід. Вузол має пересилати й транслювати, мережа має анонсувати маршрут, а клієнт — приймати його.

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

Маршрут є, але нічого не виходить

Спершу перевірте таблицю маршрутів клієнта. Рядок на кшталт default via 10.147.20.5 dev zt0 доводить, що маршрут встановлено, а не те, що призначення прийме трафік. Наступним хопом має бути учасник, готовий і здатний його переслати.

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

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

Три частини, які всі мають виконуватися

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

PartWhere it livesWhat a failure looks like
Forwarding and NATExit node kernel and firewallTraffic arrives, no reply
Managed default routeZeroTier network controllerNo default via the tunnel on the member
Client acceptanceMember's per-network settingRoute offered but not installed
DNS behaviorClient resolver configurationPages fail by name, IP works

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

Рядок контролера — це дозвіл, а не конфігурація. Анонс 0.0.0.0/0 через учасника повідомляє кожному клієнту, де розташований вихід; це не робить учасника здатним нести трафік. Це також не перевіряє, чи має учасник робочий шлях до інтернету. Документація ZeroTier про вузол виходу описує той самий поділ між вузлом, маршрутом і клієнтом.

Налаштуйте вузол виходу на пересилання й трансляцію

Увімкніть пересилання IPv4 постійно, потім додайте NAT джерела для трафіку, що залишає інтерфейс WAN. Правила фільтра мають дозволяти пересланий потік в обох напрямках, бо пересилання й трансляція відокремлені від дозволу:

sysctl -w net.ipv4.ip_forward=1
iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
iptables -A FORWARD -i zt0 -o eth0 -j ACCEPT
iptables -A FORWARD -i eth0 -o zt0 -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT

Замініть zt0 і eth0 на імена на хості; правило, збережене для прикладу інтерфейсу, не відстежує пакети на реальному. Зробіть зміни постійними через менеджер брандмауера, якому належать правила, бо команда в інтерактивній оболонці зникає під час наступного перезавантаження.

Якщо на хості працює менеджер брандмауера, наприклад UFW або firewalld, додавайте правила через цей менеджер, а не складайте рядки iptables поруч. Два власники, які редагують ті самі ланцюги, створюють політику, що залежить від порядку завантаження. Порядок важливий, коли менеджер генерує власні ланцюги. Тестуйте з клієнта після перезавантаження менеджера, а не до нього.

Анонсуйте маршрут і прийміть його на клієнті

На контролері мережі додайте керований маршрут для 0.0.0.0/0, наступним хопом якого є адреса ZeroTier учасника виходу. Потім на учаснику, який має його використовувати, дозвольте перевизначення для цієї мережі. Дозвіл локальний: він не переналаштовує інших учасників і не змінює контролер.

zerotier-cli listnetworks
zerotier-cli set <network-id> allowDefault=1
ip route get 1.1.1.1

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

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

Перевірте вихід і огляньте інші родини адрес

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

Клієнт із подвійним стеком може далі використовувати власний шлях IPv6, поки IPv4 виходить через ZeroTier. Якщо мета — приховати або контролювати весь трафік, потрібні окремий маршрут ::/0 і пересилання IPv6 на виході, а тест IPv4 нічого про них не каже.

Зворотна фільтрація шляху в Linux теж може відкидати дійсний трафік виходу на клієнті. ZeroTier документує міркування щодо rp_filter для учасників; змінюйте це налаштування свідомо і лише після підтвердження маршруту й NAT, а не як перший експеримент.

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

Схожі статті