Nebula static_host_map: адрес, который маяк не может дать

Каждый маяк может рассказать хосту о любом другом узле, кроме того, где находится сам маяк. Что-то должно быть известно до того, как появится overlay, и Nebula помещает это что-то в одну небольшую карту. Карта связывает overlay-идентичность с адресом, который работает в обычной сети. Всё, что изучается позже, зависит от правильности этой связки.

Два адреса с двумя задачами

Каждый хост Nebula имеет overlay-адрес, который остаётся неизменным, пока устройство перемещается между сетями. Этот адрес — идентичность, которую используют сертификаты, правила межсетевого экрана и отношения узлов, и сам по себе он никуда не маршрутизирует. Достижимая конечная точка — другое: имя хоста или адрес в нижележащей сети плюс порт UDP, и она меняется каждый раз, когда машина меняет местоположение. Статическая карта — это соединение между ними.

В карту входят только хосты, которые нужно вызывать холодными, что обычно означает маяки и, возможно, один релей. Держать этот список коротким — цель дизайна, потому что каждая ручная запись становится фактом, который кто-то должен поддерживать. Путать два типа адресов — обычная ошибка конфигурации: публичный адрес, помещённый в список маяков, не запускает обнаружение.

Идентичность идёт туда, где её ждут. Достижимость идёт в карту.

static_host_map:
  "10.42.0.1": ["lighthouse-01.example.net:4242"]

lighthouse:
  am_lighthouse: false
  hosts:
    - "10.42.0.1"

Анатомия записи в карте

Ключ — это overlay-адрес, записанный как строка в кавычках, а значение — список конечных точек, поэтому у одной идентичности может быть несколько входов. Каждая конечная точка несёт хост и порт, и порт должен совпадать с тем, что другая сторона действительно слушает. Значение по умолчанию в Nebula — UDP 4242, это отправная точка, а не обещание о вашем развёртывании.

Несколько конечных точек полезны, когда у маяка больше одного пути внутрь, например публичный адрес и приватный адрес для хостов в том же сегменте. Клиент пробует их по порядку, поэтому самый надёжный ставьте первым. Для IPv6 заключите адрес в квадратные скобки перед добавлением порта; ошибка здесь даёт ошибку разбора, указывающую на неверную строку.

Неверный порт даёт тишину вместо ошибки, потому что у UDP нет рукопожатия, которым можно отказать. Поэтому формат записи стоит проверять по справочнику Nebula по static_host_map а не по памяти. Справочник также охватывает списки конечных точек и поведение обновления DNS.

Загрузка должна работать до overlay

DNS-имя в карте должно разрешаться через резолвер, который есть у хоста до любого туннеля, то есть через обычный системный резолвер. Проверьте это с той же машины, при загрузке, с остановленным overlay. Имя, которое разрешается только через собственный DNS overlay, не может загрузить overlay. Та же проверка относится к маршруту: правило межсетевого экрана, разрешающее overlay, но не первый обмен UDP, блокирует первый пакет.

Проверьте порт инструментом UDP, а не предполагайте, что он открыт. Убедитесь, что любое перенаправление порта на пути ведёт к правильному внутреннему хосту и что обратный путь существует. Если имя хоста разрешается в несколько адресов, проверьте каждый, потому что клиент может выбрать адрес, который вы никогда не проверяли.

Статические записи вызываются напрямую и никогда не спрашивают маяк. Поэтому сбой здесь выглядит как обычный тайм-аут без участия узла.

Что происходит после первого рукопожатия

Как только хост достигает маяка, он узнаёт об узлах и их достижимых адресах без дополнительных ручных записей. Хосты, переместившиеся с момента последнего соединения, становятся обнаружимыми через этот канал. Это награда за то, что ручная карта остаётся небольшой.

Хосты также могут объявлять собственные дополнительные достижимые адреса, и так узел за известным публичным адресом помогает другим найти его. Эти объявления изучаются, а не вписываются в статическую карту.

Поведение обновления важно для конечных точек, записанных как DNS-имена, потому что разрешённый адрес может измениться, пока процесс продолжает работать. Настройки Nebula управляют тем, как выполняются эти запросы, включая то, какой резолвер используется, поэтому читайте их, а не предполагайте системное значение по умолчанию. На хосте, чей резолвер меняется при поднятии туннеля, неверная настройка может превратить работающую загрузку в имя, которое перестаёт разрешаться посреди сеанса. Привязка запроса к стабильному резолверу часто и есть разница между надёжным overlay и прерывистым.

Когда обнаружение работает, а один узел нет

Если маяки достижимы и большинство узлов подключается, загрузка не является проблемой. Оставшаяся пара либо не находит рабочего пути друг к другу, либо терпит сбой выше достижимости. Добавление ещё одного написания адреса маяка не исправит ни один из двух случаев.

Проверьте пару, прежде чем редактировать карту, на которую уже опирается всё остальное. Изменение карты затрагивает каждый хост, поэтому это последнее, к чему стоит прикасаться, а не первое.

Начните с сертификатов от одного и того же центра, потому что отклонённое рукопожатие издалека может выглядеть как недостижимый узел. Затем проверьте, может ли пара установить прямой путь и настроен ли релей для сетей, которые отказываются от прямого трафика. Релей добавляет один переход и одну зависимость, но это поддерживаемый ответ, и починка пути пары — другая задача, нежели починка обнаружения.