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.
• Жол өзгөргөндөн кийин да максаттын кирүүчү эрежелери чыныгы булакка уруксат берет.