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. Калі выяўленне памылковае, праблема ў карце або аб'яве, і выпраўленне належыць туды.