Nebula static_host_map: адреса коју светионик не може да да

Сваки светионик може домаћину рећи о сваком другом peer-у осим о месту на којем сам светионик живи. Нешто мора бити познато пре него што overlay постоји, а Nebula то нешто ставља у једну малу мапу. Мапа повезује overlay идентитет са адресом која ради на обичној мрежи. Све што се касније научи зависи од тога да то повезивање буде исправно.

Две адресе са два задатка

Сваки Nebula домаћин има overlay адресу која остаје фиксна док се уређај креће између мрежа. Та адреса је идентитет који користе сертификати, правила заштитног зида и peer односи, а сама по себи не усмерава никуда. Доступна крајња тачка је нешто друго: име домаћина или адреса на подложној мрежи плус UDP порт, и мења се кад год машина промени локацију. Статична мапа је спој између њих.

У мапу улазе само домаћини који се морају бирати хладно, што обично значи светионици и можда један relay. Држати тај списак кратким је дизајнерски циљ, јер сваки ручни унос постаје чињеница коју неко мора да одржава. Бркање двају типова адреса уобичајена је грешка у конфигурацији: јавна адреса стављена на списак светионика не покреће откривање.

Идентитет иде тамо где се идентитет очекује. Доступност иде у мапу.

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 нема handshake којим би одбио. Зато формат уноса вреди проверити према Nebula референци за static_host_map а не по сећању. Референца покрива и спискове крајњих тачака и понашање освежавања DNS-а.

Bootstrap мора да ради пре overlaya

DNS име у мапи мора се разрешити кроз resolver који домаћин има пре било ког тунела, а то је обични системски resolver. Тестирајте то са истог строја, при подизању, са заустављеним overlay-ом. Име које се разрешава само кроз сопствени DNS overlaya не може да покрене overlay. Исти тест важи за руту: правило заштитног зида које дозвољава overlay али не и прву UDP размену блокира почетни пакет.

Проверите порт UDP алатом уместо да претпоставите да је отворен. Потврдите да свако прослеђивање порта на путу циља на исправан интерни домаћин и да повратни пут постоји. Ако се име домаћина разрешава на више адреса, тестирајте сваку, јер клијент може изабрати адресу коју никад нисте проверили.

Статички уноси бирају се директно и никад не питају светионик. Зато квар овде изгледа као обичан timeout без укљученог peer-а.

Шта се дешава након првог handshake-а

Кад домаћин достигне светионик, сазнаје за peer-ове и њихове доступне адресе без додатних ручних уноса. Домаћини који су се померили од последње везе постају откривљиви кроз тај канал. То је награда за држање ручне мапе малом.

Домаћини могу и да оглашавају сопствене додатне доступне адресе, и тако peer иза познате јавне адресе помаже другима да га пронађу. Та оглашавања се уче, не уписују у статичку мапу.

Понашање освежавања важно је за крајње тачке записане као DNS имена, јер се разрешена адреса може променити док процес наставља да ради. Nebula подешавања контролишу како се та претраживања одвијају, укључујући који се resolver користи, па их читајте уместо да претпоставите системски default. На домаћину чији се resolver мења кад тунел устане, погрешна поставка може претворити радни bootstrap у име које престаје да се разрешава усред сесије. Причвршћивање претраживања на стабилан resolver често је разлика између поузданог overlaya и оног с прекидима.

Кад откривање ради а један peer не

Ако су светионици доступни и већина peer-ова се повезује, bootstrap није проблем. Преостали пар или не може наћи употребљив пут једно до другог или пада изнад доступности. Додавање још једног записа адресе светионика не може поправити ни један од та два случаја.

Проверите пар пре него што уредите мапу на коју се све остало већ ослања. Промена мапе узнемирава сваки домаћин, па је то последње што треба дирати, а не прво.

Почните са сертификатима истог ауторитета, јер одбијен handshake може издалека изгледати као недоступан peer. Затим проверите може ли пар успоставити директан пут и је ли relay конфигурисан за мреже које одбијају директан саобраћај. Relay додаје хоп и зависност, али је подржан одговор, а поправљање пута peer-а други је задатак од поправљања откривања.