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۔
• راستہ بدلنے کے بعد بھی منزل کے اندر آنے والے قواعد اصل ماخذ کو اجازت دیتے ہیں۔