Nebula релеј конфигурисан, али неискоришћен: три поставке за проверу

Додали сте хост релеја, уписали његову Nebula адресу у конфигурацију, а два партнера и даље не разговарају. То се дешава зато што пут преко релеја захтева три одвојене изјаве које морају да се слажу, а само једна од њих се налази на машини коју сте вероватно уређивали. Пратио сам то двапут: једном хост за прослеђивање никада није добио улогу релеја, а други пут су поставке биле записане на погрешној страни везе. Редослед у наставку проверава улогу, објаву и дозволу тим редом, а сваки корак има наредбу која вам каже да ли да наставите.

Мапирајте три улоге пре него што уредите конфигурацију

Nebula даје сваком хосту задатак, а задаци се не наслеђују. Lighthouse одговара на питања попут где је овај партнер како би хостови могли да пронађу један другог. Релеј прослеђује саобраћај између два партнера који немају радни директан пут. Обичан хост не чини ни једно ни друго. Три важне поставке живе на три различите машине, и зато конфигурација клијента која изгледа целовито може да остави оба партнера на чекању.

# on the discovery host
lighthouse:
  am_lighthouse: true
  hosts: []

# on every other host, point at the discovery host's Nebula address
lighthouse:
  hosts:
    - 10.42.0.1

Један симптом раздваја две класе квара. Ако оба партнера наводе један другог и записник показује покушаје руковања који никада не заврше, откривање ради, а податковни пут блокира NAT или заштитни зид. Ако партнер уопште не сазна адресу оног другог, проблем је у lighthouse-у или у његовој статичкој мапи хостова, а поставке релеја то не могу да поправе.

Потврдите коју је конфигурацију сваки хост стварно учитао пре него што промените било шта друго. Unit који чита другу путању од датотеке коју сте уредили чест је и неугодан узрок томе да „промена није учинила ништа”:

systemctl cat nebula | grep ExecStart
nebula -version
journalctl -u nebula -n 20 --no-pager

Ред верзије је важан у мешовитој флоти. Руковање релејима, понашање пробијања и прихваћени конфигурацијски кључеви нису једнаки међу издањима, зато не претпостављајте да старија градња разуме одељак за који није написана. Поравнајте хостове на исту мању серију, затим покрените nebula -test -config /etc/nebula/config.yml на сваком хосту и упоредите излаз пре него што почнете да отклањате грешке у транспорту који код не имплементира.

Омогућите улогу прослеђивања на хосту релеја

Улога релеја једна је заставица на хосту за прослеђивање и одвојена је од тога да буде lighthouse. Хост са укљученим откривањем и искљученим прослеђивањем преко релеја и даље је само услуга откривања. На релеју:

relay:
  am_relay: true

Та заставица изражава намеру; не ствара достижност. Релеј мора бити достижан са оба партнера, што у пракси значи јавну адресу, долазни UDP на вратима Nebula отворен у заштитном зиду хоста и у било којој безбедносној групи облака, и без двоструког NAT-а испред. Проверите утичницу која слуша, а затим посматрајте да ли долазе пакети партнера:

ss -lunp | grep nebula
tcpdump -ni any udp port 4242 and host 198.51.100.7

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

Објавите релеј са одредишта, не са клијента

То је обрт који поједе највише сати. Листа релеја припада хосту који покушавате да достигнете, јер другим партнерима говори који се релеји смеју користити за достизање тог хоста. Сместити је на клијент који започиње везу не чини ништа за смер који клијент треба:

# on the DESTINATION host: relays others may use to reach me
relay:
  relays:
    - 10.42.0.5

Партнери ту листу пријављују заједно са својим адресама када се пријаве lighthouse-у, па се објава шири откривањем, а не изравном разменом. Ако одредиште не достигне ниједан lighthouse, његова листа релеја се никада не прошири и исправно конфигурисан релеј остаје беспослен. Тај квар изгледа тачно као покварен релеј и није.

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

static_host_map:
  "10.42.0.5": ["203.0.113.10:4242"]

Дозволите партнеру који се повезује да користи релеј

Страна која започиње треба сопствену дозволу. relay.use_relays је према подразумеваном укључен, па је случај који вреди тражити изричит false, често копиран из шаблона написаног пре него што је функција релеја постојала или остављен од ранијег покушаја да се директни путеви присиле:

relay:
  use_relays: true

Дозвола на овој страни није једина капија. Долазна правила одредишта и даље се примењују на прослеђени пакет, а извор са којим се упоређују јесте идентитет унутар тунела, а не адреса самог релеја. Када прослеђено руковање заврши, а апликација и даље не ради, прочитајте у записнику одредишта који је извор забележен пре него што препишете правило.

Поставке проласка кроз NAT делују заједно са свим овим. punchy.punch помаже двама партнерима да отворе директан пут, и када то успе, нема прослеђеног саобраћаја за посматрање; то је успех, а не релеј који недостаје. Пар који ради с прекидима обично значи да пробијање успева само понекад, зато тај пар тестирајте неколико пута уместо да из једног покушаја извучете закључак.

Проверите са паром који је заказао, а затим поново учитајте

Тестирајте она два хоста која су заиста заказала, са апликацијом која им је потребна. Успешан ping са ваше радне станице на услугу самог релеја не доказује ништа о прослеђивању између два друга партнера, и то је најчешћи лажни позитив у целом овом поступку.

journalctl -u nebula -f | grep -iE "relay|handshake"
ping -c 3 10.42.0.9

Поново учитајте уместо поновног покретања и потврдите да је покренути процес преузео датотеку коју сте уредили. Поновно покретање руши сваки тунел и чини следећи тест теже читљивим, док SIGHUP задржава процес и даје му да поново прочита конфигурацију:

sudo systemctl kill -s HUP nebula
# same signal when nebula runs in the foreground
kill -HUP $(pidof nebula)

systemctl reload ради само када локални unit дефинише ExecReload, а unit који се испоручује са пројектом то не чини, зато је systemctl kill -s HUP корак који успева на стандардној инсталацији. Након поновног учитавања прочитајте у записнику путању конфигурације коју је процес отворио, како бисте знали да је прочитана нова датотека, а не она коју сте сматрали учитаном.

Поставке релеја и пробијање NAT делују обоје на пут; ниједно не делује на идентитет. Ако пар и даље закаже у руковању када су am_relay, relays и use_relays потврђени у покренутој конфигурацији, проверите да ли оба хоста представљају сертификате издате за имена са којима су конфигурисани и да ли је CA исти на обе стране. Држите конфигурацију сертификата и заштитног зида непромењеном док мењате једну транспортну поставку одједном, јер промена сертификата и промена релеја у истом тесту не говоре ништа о томе која је од њих померила руковање. Неусклађеност имена или CA закаже на истом месту као релеј који никада није пронађен, и зато ова противпровера припада истом пролазу.

Затим потврдите да је свака изјава у датотеци којој припада:

• am_relay: true на хосту за прослеђивање, и тај хост достижан преко UDP-а са обе стране.
• relays: са Nebula адресом тог хоста на одредишту.
• use_relays: true на партнеру који започиње везу.
• Долазна правила на одредишту која и након промене пута дозвољавају стварни извор.