Nebula: реле конфигурацияланған, бірақ пайдаланылмайды — тексеруге тұрарлық үш параметр

Сіз реле хостын қостыңыз, оның Nebula мекенжайын конфигурацияға жаздыңыз, бірақ екі теңдес әлі сөйлеспейді. Бұл реле жолы үш жеке мәлімдеменің сәйкес келуін талап ететіндіктен болады, ал олардың тек біреуі ғана сіз түзеткен машинада орналасқан. Мен бұның соңына екі рет түстім: бірде қайта жіберуші хостқа реле рөлі ешқашан берілмеген, енді бірде параметрлер қосылымның дұрыс емес жағына жазылған. Төмендегі реттілік рөлді, жариялауды және рұқсатты дәл осы тәртіппен тексереді, әр қадамда жалғастыру керек пе, жоқ па деп айтатын команда бар.

Конфигурацияны түзетуден бұрын үш рөлді картаға түсіріңіз

Nebula әр хостқа бір тапсырма береді, ал тапсырмалар мұраланбайды. Шамшырақ «бұл теңдес қайда» деген сұрақтарға жауап береді, сондықтан хосттар бір-бірін таба алады. Реле жұмыс істейтін тікелей жолы жоқ екі теңдес арасында трафикті жібереді. Қарапайым хост екеуін де жасамайды. Маңызды үш параметр үш түрлі машинада орналасқан, сондықтан толық көрінетін клиент конфигурациясы екі теңдесті де күтуде қалдыруы мүмкін.

# 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 немесе желіаралық қалқанмен жабылған. Егер теңдес екіншісінің мекенжайын мүлде білмесе, мәселе шамшырақта немесе оның статикалық хост картасында, ал реле параметрлері мұны түзете алмайды.

Басқа нәрсені түзетуден бұрын әр хост нақты қай конфигурацияны жүктегенін растаңыз. Сіз түзеткен файлдан өзге жолды оқитын юнит «өзгеріс ештеңе жасамады» дегеннің кең тараған және ұятты себебі:

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

Аралас паркте нұсқа жолы маңызды. Релені өңдеу, тесудің мінез-құлқы және қабылданатын конфигурация кілттері шығарылымдар арасында бірдей емес, сондықтан ескі құрылым өзіне жазылмаған бөлімді түсінеді деп ойламаңыз. Хосттарды бір кіші серияға теңестіріңіз, содан кейін әр хостта nebula -test -config /etc/nebula/config.yml іске қосыңыз және код жүзеге асырмайтын тасымалды жөндеуге кіріспес бұрын шығысты салыстырыңыз.

Реле хостта қайта жіберу рөлін қосыңыз

Реле рөлі қайта жіберуші хосттағы бір жалауша, ол шамшырақ болудан бөлек. Анықтау қосылған, ал реле жіберуі өшірілген хост әлі де тек анықтау қызметі. Реледе:

relay:
  am_relay: true

Бұл жалауша ниетті жариялайды; ол қолжетімділік жасамайды. Реле екі теңдестен де қолжетімді болуы керек, бұл іс жүзінде жария мекенжай, хосттың желіаралық қалқанында және кез келген бұлттық қауіпсіздік тобында Nebula портында ашық кіріс UDP және оның алдында қос 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

Теңдестер шамшырақта тіркелген кезде бұл тізімді өз мекенжайларымен бірге хабарлайды, сондықтан жариялау тікелей алмасу арқылы емес, анықтау арқылы таралады. Егер мақсат шамшыраққа жете алмаса, оның реле тізімі ешқашан таралмайды және дұрыс конфигурацияланған реле бос тұрады. Бұл ақау дәл сынған релеге ұқсайды, бірақ ол олай емес.

Сол өтуде мақсатқа жүктеу жолын беріңіз. Статикалық хост картасы 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 жергілікті юнит ExecReload анықтағанда ғана жұмыс істейді, ал жобамен бірге келетін юнит оны анықтамайды, сондықтан стандартты орнатуда сәтті болатын қадам — systemctl kill -s HUP. Қайта жүктегеннен кейін процесс ашқан конфигурация жолы үшін журналды оқыңыз, сонда сіз болжаған файл емес, жаңа файл оқылғанын білесіз.

Реле параметрлері мен NAT тесуі екеуі де жолға әсер етеді; ешқайсысы сәйкестікке әсер етпейді. Егер жұмыс істеп тұрған конфигурацияда am_relay, relays және use_relays расталғаннан кейін де жұп қол алысуда сәтсіз болса, екі хосттың да конфигурацияланған атаулары үшін берілген сертификаттарды ұсынатынын және екі жақта CA бірдей екенін тексеріңіз. Сертификат пен желіаралық қалқан конфигурациясын өзгеріссіз ұстап, тасымал параметрін бір уақытта біреуін ғана өзгертіңіз, өйткені бір тестке түскен сертификат түзетуі мен реле түзетуі қол алысуды қайсысы жылжытқанын айтпайды. Атау немесе CA сәйкессіздігі ешқашан табылмаған релемен бір жерде сәтсіз болады, сондықтан бұл қарсы тексеру де сол өтуге жатады.

Содан кейін әр мәлімдеменің өзіне тиесілі файлда тұрғанын растаңыз:

• Қайта жіберуші хостта am_relay: true және сол хост екі жақтан да UDP арқылы қолжетімді.
• Мақсатта сол хосттың Nebula мекенжайын атайтын relays:.
• Қосылымды бастайтын теңдесте use_relays: true.
• Жол өзгергеннен кейін де мақсаттың кіріс ережелері нақты көзге рұқсат береді.