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 د رسیدو وړ۔
• relays: چې په منزل کې د هغه هوسټ Nebula پته نوموي۔
• use_relays: true پر هغې همځولې چې اړیکه پیلوي۔
• د منزل دننه تلونکې قاعدې له لارې د بدلون وروسته هم ریښتینې سرچینې ته اجازه ورکوي۔