Nebula static_host_map: адресът, който фарът не може да даде

Всеки фар може да разкаже на даден хост за всеки друг партньор, освен за мястото, където живее самият фар. Нещо трябва да е известно преди овърлеят да съществува, и Nebula слага това нещо в една малка карта. Картата свързва овърлей идентичност с адрес, който работи в обикновената мрежа. Всичко научено по-късно зависи от това свързване да е правилно.

Два адреса с две задачи

Всеки хост на Nebula притежава овърлей адрес, който остава фиксиран, докато устройството се движи между мрежи. Този адрес е идентичността, използвана от сертификати, правила на защитната стена и партньорски връзки, и сам по себе си не маршрутизира никъде. Достъпната крайна точка е друго нещо: име на хост или адрес в подлежащата мрежа плюс UDP порт, и тя се променя, когато машината смени местоположението си. Статичната карта е връзката между двете.

В картата влизат само хостове, които трябва да се набират на студено, което обикновено означава фаровете и може би един релей. Краткият списък е цел на дизайна, защото всеки ръчен запис се превръща във факт, който някой трябва да поддържа. Объркването на двата типа адреси е обичайната конфигурационна грешка: публичен адрес, поставен в списъка на фаровете, не стартира откриването.

Идентичността отива там, където се очаква идентичност. Достъпността отива в картата.

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

lighthouse:
  am_lighthouse: false
  hosts:
    - "10.42.0.1"

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

Ключът е овърлей адресът, записан като низ в кавички, а стойността е списък от крайни точки, така че една идентичност може да има няколко входни точки. Всяка крайна точка носи хост и порт, а портът трябва да съвпада с това, което другата страна действително слуша. Стойността по подразбиране на Nebula е UDP 4242, което е отправна точка, а не обещание за вашето внедряване.

Няколко крайни точки са полезни, когато фарът има повече от един път навътре, например публичен адрес и частен адрес за хостове в същия сегмент. Клиентът ги опитва по ред, затова поставете най-надеждната първа. За IPv6 оградете адреса в скоби, преди да добавите порта; грешката тук дава грешка при разбор, която сочи към грешния ред.

Грешен порт дава тишина вместо грешка, защото UDP няма ръкостиск, който да откаже. Затова форматът на записа си струва да се провери спрямо справката на Nebula за static_host_map а не по памет. Справката покрива също списъци с крайни точки и поведението при обновяване на DNS.

Първоначалното зареждане трябва да работи преди овърлея

DNS име в картата трябва да се разреши чрез резолвера, който хостът има преди да съществува какъвто и да е тунел, тоест обикновения системен резолвер. Тествайте го от същата машина, при зареждане, със спрян овърлей. Име, което се разрешава само чрез собствения DNS на овърлея, не може да зареди овърлея. Същият тест важи за маршрута: правило на защитната стена, което разрешава овърлея, но не и първия UDP обмен, блокира началния пакет.

Проверете порта с UDP инструмент, вместо да предполагате, че е отворен. Потвърдете, че всяко пренасочване на порт по пътя сочи към правилния вътрешен хост и че има обратен път. Ако името на хоста се разрешава до няколко адреса, тествайте всеки, защото клиентът може да избере адрес, който никога не сте проверявали.

Статичните записи се набират директно и никога не питат фар. Затова отказ тук изглежда като обикновено изтичане на времето без участието на партньор.

Какво се случва след първия ръкостиск

Щом хост достигне фар, той научава за партньорите и техните достъпни адреси без повече ръчни записи. Хостовете, които са се преместили след последната връзка, стават откриваеми през този канал. Това е печалбата от това ръчната карта да остане малка.

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

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

Когато откриването работи, а един партньор не

Ако фаровете са достъпни и повечето партньори се свързват, зареждането не е проблемът. Останалата двойка или не може да намери използваем път един към друг, или се проваля над достъпността. Добавянето на още един вариант на адреса на фара не може да поправи нито един от двата случая.

Проверете двойката, преди да редактирате картата, на която вече разчита всичко останало. Промяната на картата смущава всеки хост, затова е последното нещо, което се пипа, а не първото.

Започнете със сертификати от същия орган, защото отказан ръкостиск може да изглежда отдалеч като недостъпен партньор. След това проверете дали двойката може да установи директен път и дали е настроен релей за мрежи, които отказват директен трафик. Релеят добавя скок и зависимост, но е поддържан отговор, а поправянето на пътя на двойката е различна задача от поправянето на откриването.