Nebula advertise_addrs или static_host_map: избор според собственика

Настройките static_host_map и advertise_addrs и двете поставят адрес пред peer и отговарят на различни въпроси. Едната е локален файл, който изброява overlay адрес и крайната точка на underlay за свързване. Другата е хост, който казва на своите маяци кои допълнителни крайни точки могат да го достигнат. Истинската разлика е собствеността: картата се поддържа от всеки, който се нуждае от нея, а обявяването — от самия хост.

Решете според това кой притежава информацията

Всеки променящ се 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. Ако откриването е грешно, проблемът е в картата или обявлението, и поправката принадлежи там.