Nebula: ретранслятор налаштовано, але не використовується — три параметри для перевірки

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

Зіставте три ролі, перш ніж редагувати конфігурацію

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

# on the discovery host
lighthouse:
  am_lighthouse: true
  hosts: []

# on every other host, point at the discovery host's Nebula address
lighthouse:
  hosts:
    - 10.42.0.1

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

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

systemctl cat nebula | grep ExecStart
nebula -version
journalctl -u nebula -n 20 --no-pager

Рядок версії важливий у змішаному парку. Обробка ретрансляції, поведінка пробивання та прийнятні ключі конфігурації не однакові між випусками, тому не припускайте, що стара збірка розуміє розділ, для якого вона не писалася. Вирівняйте хости за однією мінорною серією, потім запустіть nebula -test -config /etc/nebula/config.yml на кожному хості та порівняйте вивід, перш ніж налагоджувати транспорт, який код не реалізує.

Увімкніть роль пересилання на хості-ретрансляторі

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

relay:
  am_relay: true

Цей прапорець заявляє намір; він не створює досяжності. Ретранслятор має бути досяжним з обох пірів, що на практиці означає публічну адресу, вхідний UDP на порту Nebula, відкритий у міжмережевому екрані хоста та в будь-якій хмарній групі безпеки, і відсутність подвійного NAT перед ним. Перевірте слухаючий сокет, потім спостерігайте за надходженням пакетів піра:

ss -lunp | grep nebula
tcpdump -ni any udp port 4242 and host 198.51.100.7

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

Оголошуйте ретранслятор з боку призначення, а не клієнта

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

# on the DESTINATION host: relays others may use to reach me
relay:
  relays:
    - 10.42.0.5

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

Дайте призначенню початковий шлях у тому ж проході. Статична карта хостів прив’язує адресу Nebula до публічної кінцевої точки, щоб першому рукостисканню було куди йти, і їй потрібен запис для ретранслятора, якщо призначення має приймати переданий трафік від хостів, до яких не може дістатися напряму:

static_host_map:
  "10.42.0.5": ["203.0.113.10:4242"]

Дозвольте піру, що підключається, використовувати ретранслятор

Ініціюючій стороні потрібен власний дозвіл. relay.use_relays увімкнено за замовчуванням, тому шукати варто явний false, часто скопійований із шаблону, написаного до появи функції ретрансляції, або залишений від попередньої спроби нав’язати прямі шляхи:

relay:
  use_relays: true

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

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

Перевірте на парі, яка не працювала, потім перезавантажте

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

journalctl -u nebula -f | grep -iE "relay|handshake"
ping -c 3 10.42.0.9

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

sudo systemctl kill -s HUP nebula
# same signal when nebula runs in the foreground
kill -HUP $(pidof nebula)

systemctl reload працює лише тоді, коли локальний юніт визначає ExecReload, а юніт, що постачається з проєктом, цього не робить, тому на стандартному встановленні успішним кроком буде systemctl kill -s HUP. Після перезавантаження прочитайте журнал для шляху конфігурації, який відкрив процес, щоб знати, що прочитано новий файл, а не той, який ви припускали.

Налаштування ретранслятора і пробивання NAT діють і на шлях; ні те, ні інше не діє на ідентичність. Якщо пара все ще не проходить рукостискання після того, як am_relay, relays і use_relays підтверджено в робочій конфігурації, перевірте, що обидва хости пред’являють сертифікати, видані для імен, з якими вони налаштовані, і що CA з обох боків той самий. Тримайте сертифікат і конфігурацію міжмережевого екрана незмінними, змінюючи по одному параметру транспорту за раз, бо правка сертифіката і правка ретранслятора в одному тесті не кажуть, яка з них зрушила рукостискання. Незбіг імені або CA падає в тому самому місці, що й ретранслятор, який так і не був знайдений, тому ця зустрічна перевірка належить до того ж проходу.

Потім переконайтеся, що кожне твердження лежить у тому файлі, якому належить:

• am_relay: true на хості пересилання, і цей хост досяжний за UDP з обох боків.
• relays: із зазначенням адреси Nebula цього хоста на призначенні.
• use_relays: true на пірі, який починає з’єднання.
• Вхідні правила на призначенні все ще дозволяють справжнє джерело після зміни шляху.