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 на пире, который начинает соединение.
  • Входящие правила на получателе по-прежнему разрешают настоящий источник после смены пути.

Похожие статьи