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. Ако откривањето е погрешно, проблемот е во картата или објавата, и поправката припаѓа таму.