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 і переривчастим.

Коли виявлення працює, а один вузол ні

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

Перевірте пару, перш ніж редагувати карту, на яку вже спирається все інше. Зміна карти зачіпає кожен хост, тож це останнє, чого варто торкатися, а не перше.

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