Nebula advertise_addrs или static_host_map: выбирайте по владельцу
Статическая карта поддерживается каждым peer, который к ней обращается; объявленный адрес публикует хост. Выбирайте по тому, кто знает конечную точку.
Параметры static_host_map и advertise_addrs оба ставят адрес перед peer, и они отвечают на разные вопросы. Один — это локальный файл со списком overlay-адреса и конечной точки underlay, к которой нужно подключиться. Другой — это хост, который сообщает своим маякам, какие дополнительные конечные точки могут до него добраться. Настоящее различие — владение: карту поддерживают все, кому она нужна, а объявление — сам хост.
Решайте по тому, кому принадлежит информация
| Setting | Where it lives | Best for |
|---|---|---|
static_host_map | Every peer that needs the entry | Bootstrap endpoints, deliberately fixed paths |
advertise_addrs | The host's own config | Endpoints the host cannot otherwise discover |
Каждый меняющийся peer в статическом файле каждого peer — это работа по обслуживанию, которая растёт как квадрат флота. Это практическая причина обратиться к другому параметру, когда сам хост знает ответ.
Вопрос владения также предсказывает, что произойдёт при смене адреса. Со статической картой кто-то должен помнить каждого peer, у которого есть старая запись. С объявлением хост публикует новую конечную точку, и его маяки передают её дальше, поэтому изменение остаётся локальным на машине, которая переехала.
Bootstrap по-прежнему нужны статические записи
Клиент должен достичь хотя бы одного маяка, прежде чем сможет кого-либо спросить о других peer. Этот первый прыжок не может прийти из обнаружения, поэтому он опирается на статичной записи в конфигурации клиента. Сделайте эту единственную запись правильной, и остальной overlay можно выучить.
Запись карты связывает адрес Nebula с одной или несколькими доступными конечными точками IP или DNS и портами. Держать там маяки — нормально; держать там каждый peer — это шаблон, который плохо стареет, потому что каждый новый peer означает правку файлов на машинах, которыми вы, возможно, не управляете. Держите список достаточно коротким, чтобы человек ещё мог проверить его чтением.
Объявляйте, когда хост знает конечную точку
Хост за переадресацией портов доступен по публичному адресу, который не назначен ни одному из его собственных интерфейсов. Он не может обнаружить этот адрес, глядя на себя. advertise_addrs позволяет ему опубликовать конечную точку через свои маяки, чтобы другие peer узнали путь, который действительно работает. Параметр существует именно потому, что хост — единственная сторона, которая знает, что сопоставление было сделано.
Используйте адрес и порт, до которых другие peer действительно могут добраться. Те же рассуждения применимы к хосту с несколькими сетевыми путями, где один путь предпочтительнее для peer в определённой сети. Объявление — это утверждение о underlay, а не запрос чего-либо. Когда сопоставление меняется, обновите объявление на хосте и позвольте обнаружению его нести, вместо того чтобы править статические файлы по всему флоту.
Объявление — это не доступность
Публикация конечной точки не создаёт правило переадресации маршрутизатора, не открывает вышестоящий firewall и не заставляет имя DNS разрешаться. Это отдельные части работы, и правильное объявление с отсутствующей переадресацией порта производит ровно тот сбой, который вы пытались исправить. Объявление — это утверждение о доступности, а не механизм, который её устанавливает.
Проверьте путь снаружи, прежде чем винить обнаружение. У peer, который узнаёт конечную точку, но не может завершить handshake, есть проблема маршрутизации или фильтрации в underlay, и повторение того же адреса в обоих параметрах этого не изменит.
Держите overlay-адрес отдельно от конечной точки
Сертификат узла идентифицирует его адрес Nebula. Объявленные адреса принадлежат нижележащей сети, и их можно менять, не трогая сертификат. Выпуск нового сертификата с другим overlay-IP — это другая операция, со своими последствиями для каждого доверительного отношения, которое закрепило старый. Держите два изменения отдельно в runbook, иначе перемещение конечной точки будет записано как переиздание.
Когда триаж застревает, явно разделите два слоя: возвращает ли обнаружение ожидаемую конечную точку, и достигает ли её handshake? Если обнаружение верно, а пакеты не проходят, проблема ниже overlay. Если обнаружение неверно, проблема в карте или объявлении, и исправление принадлежит туда.