Nebula static_host_map: وہ پتہ جو روشن مینار نہیں دے سکتا

ہر روشن مینار کسی میزبان کو ہر دوسرے ساتھی کے بارے میں بتا سکتا ہے، سوائے اس کے کہ روشن مینار خود کہاں ہے۔ overlay کے وجود سے پہلے کچھ معلوم ہونا چاہیے، اور Nebula وہ کچھ ایک چھوٹے نقشے میں رکھتا ہے۔ نقشہ overlay شناخت کو عام نیٹ ورک پر کام کرنے والے پتے سے جوڑتا ہے۔ بعد میں جو کچھ سیکھا جاتا ہے وہ اسی جوڑ کے درست ہونے پر منحصر ہے۔

دو کاموں والے دو پتے

ہر Nebula میزبان کا overlay پتہ ہوتا ہے جو آلے کے نیٹ ورک بدلنے پر بھی مستقل رہتا ہے۔ وہ پتہ وہی شناخت ہے جو سرٹیفکیٹس، فائر وال قواعد اور ساتھی تعلقات استعمال کرتے ہیں، اور اکیلا وہ کہیں راستہ نہیں بناتا۔ قابلِ رسائی اینڈ پوائنٹ کچھ اور ہے: بنیادی نیٹ ورک پر میزبان نام یا پتہ اور ایک UDP پورٹ، اور مشین کا مقام بدلنے پر یہ بدل جاتا ہے۔ مستقل نقشہ دونوں کے درمیان جوڑ ہے۔

نقشے میں صرف وہی میزبان آتے ہیں جنہیں ٹھنڈے طریقے سے ڈائل کرنا پڑتا ہے، یعنی عام طور پر روشن مینار اور شاید ایک ریلے۔ اس فہرست کو چھوٹا رکھنا ڈیزائن کا ہدف ہے، کیونکہ ہر ہاتھ سے لکھی اندراج ایسی حقیقت بن جاتی ہے جسے کسی کو برقرار رکھنا ہوتا ہے۔ دو پتہ اقسام کو ملانا عام ترتیب کی غلطی ہے: روشن مینار کی فہرست میں رکھا گیا عوامی پتہ دریافت شروع نہیں کرتا۔

شناخت وہاں جاتی ہے جہاں شناخت کی توقع ہوتی ہے۔ رسائی نقشے میں جاتی ہے۔

static_host_map:
  "10.42.0.1": ["lighthouse-01.example.net:4242"]

lighthouse:
  am_lighthouse: false
  hosts:
    - "10.42.0.1"

نقشے کی اندراج کی ساخت

کلید وہ overlay پتہ ہے جو اقتباس کے نشانات میں بطور سٹرنگ لکھا گیا ہو، اور قدر اینڈ پوائنٹس کی فہرست ہے، لہذا ایک شناخت کے کئی داخلے ہو سکتے ہیں۔ ہر اینڈ پوائنٹ ایک میزبان اور ایک پورٹ رکھتا ہے، اور پورٹ کو اُس سے میل کھانا چاہیے جو دوسرا فریق واقعی سن رہا ہو۔ Nebula کی طے شدہ قدر UDP 4242 ہے، جو نقطہ آغاز ہے، آپ کی تعیناتی کے بارے میں وعدہ نہیں۔

جب روشن مینار کے اندر آنے کے ایک سے زیادہ راستے ہوں تو کئی اینڈ پوائنٹس مفید ہوتے ہیں، مثلاً عوامی پتہ اور اسی قطعے کے میزبانوں کے لیے نجی پتہ۔ کلائنٹ انہیں ترتیب سے آزماتا ہے، اس لیے سب سے قابلِ اعتماد پہلے رکھیں۔ IPv6 کے لیے پورٹ شامل کرنے سے پہلے پتے کو مربع بریکٹ میں رکھیں؛ غلطی کرنے پر ایسی تجزیاتی خرابی آتی ہے جو غلط سطر کی نشاندہی کرتی ہے۔

غلط پورٹ خرابی کے بجائے خاموشی دیتا ہے، کیونکہ UDP کے پاس انکار کے لیے ہینڈ شیک نہیں۔ اس لیے اندراج کی ساخت Nebula static_host_map حوالہ سے جانچنا چاہیے، یادداشت سے نہیں۔ حوالہ اینڈ پوائنٹ فہرستیں اور DNS تازہ کاری کے رویے کو بھی محیط ہے۔

بوٹ اسٹریپ overlay سے پہلے کام کرنا چاہیے

نقشے میں DNS نام کو کسی بھی ٹنل سے پہلے میزبان کے پاس موجود حل کنندہ کے ذریعے حل ہونا چاہیے، یعنی عام نظامی حل کنندہ۔ اسے اسی مشین سے، بوٹ کے وقت، overlay بند رکھ کر جانچیں۔ جو نام صرف overlay کے اپنے DNS سے حل ہوتا ہے وہ overlay کو بوٹ اسٹریپ نہیں کر سکتا۔ یہی آزمائش راستے پر بھی لاگو ہے: جو فائر وال قاعدہ overlay کی اجازت دیتا ہے مگر پہلے UDP تبادلے کی نہیں، وہ پہلا پیکٹ روکتا ہے۔

پورٹ کو کھلا فرض کرنے کے بجائے UDP اوزار سے جانچیں۔ تصدیق کریں کہ راستے پر کوئی بھی پورٹ فارورڈنگ درست اندرونی میزبان کی طرف ہے اور واپسی راستہ موجود ہے۔ اگر میزبان نام کئی پتوں میں حل ہوتا ہے تو ہر ایک جانچیں، کیونکہ کلائنٹ ایسا پتہ چن سکتا ہے جو آپ نے کبھی نہیں جانچا۔

مستقل اندراجات براہِ راست ڈائل ہوتی ہیں اور کبھی روشن مینار سے مشورہ نہیں کرتیں۔ اسی لیے یہاں ناکامی بغیر کسی ساتھی کے عام ٹائم آؤٹ جیسی لگتی ہے۔

پہلے ہینڈ شیک کے بعد کیا ہوتا ہے

جیسے ہی میزبان روشن مینار تک پہنچتا ہے، وہ مزید ہاتھ سے لکھی اندراجات کے بغیر ساتھیوں اور ان کے قابلِ رسائی پتوں کے بارے میں جان لیتا ہے۔ پچھلے رابطے کے بعد سے ہٹنے والے میزبان اسی چینل سے قابلِ دریافت ہو جاتے ہیں۔ ہاتھ سے لکھا نقشہ چھوٹا رکھنے کا یہی انعام ہے۔

میزبان اپنے اضافی قابلِ رسائی پتے بھی اعلان کر سکتے ہیں, اور اس طرح کسی معلوم عوامی پتے کے پیچھے کا ساتھی دوسروں کو اسے ڈھونڈنے میں مدد دیتا ہے۔ وہ اعلانات سیکھے جاتے ہیں، مستقل نقشے میں لکھے نہیں جاتے۔

DNS ناموں کے طور پر لکھے اینڈ پوائنٹس کے لیے تازہ کاری کا رویہ اہم ہے، کیونکہ عمل جاری رہنے کے دوران حل شدہ پتہ بدل سکتا ہے۔ Nebula کی ترتیبات کنٹرول کرتی ہیں کہ وہ تلاشیں کیسے ہوتی ہیں، کون سا حل کنندہ استعمال ہوتا ہے سمیت، لہذا نظام کی طے شدہ قدر فرض کرنے کے بجائے انہیں پڑھیں۔ جس میزبان کا حل کنندہ ٹنل اٹھنے پر بدل جاتا ہے، وہاں غلط ترتیب چلتی بوٹ اسٹریپ کو سیشن کے وسط میں حل ہونا بند کرنے والے نام میں بدل سکتی ہے۔ تلاش کو مستقل حل کنندہ سے باندھنا اکثر قابلِ بھروسا overlay اور وقفے وقفے سے چلنے والے overlay کے درمیان فرق ہوتا ہے۔

جب دریافت کام کرے اور ایک ساتھی نہ کرے

اگر روشن مینار قابلِ رسائی ہوں اور زیادہ تر ساتھی جڑیں، تو بوٹ اسٹریپ مسئلہ نہیں ہے۔ باقی جوڑی یا تو ایک دوسرے تک قابلِ استعمال راستہ نہیں ڈھونڈتی یا رسائی سے اوپر ناکام ہوتی ہے۔ روشن مینار کے پتے کی ایک اور ہجے شامل کرنا دونوں میں سے کوئی بھی حالت درست نہیں کرتا۔

جس نقشے پر باقی سب پہلے سے ٹکا ہے اسے تبدیل کرنے سے پہلے جوڑی جانچیں۔ نقشے کی تبدیلی ہر میزبان کو متاثر کرتی ہے، اس لیے یہ سب سے آخر میں چھونے والی چیز ہے، پہلی نہیں۔

ایک ہی اتھارٹی کے سرٹیفکیٹس سے شروع کریں، کیونکہ مسترد شدہ ہینڈ شیک دور سے ناقابلِ رسائی ساتھی جیسا لگ سکتا ہے۔ پھر جانچیں کہ جوڑی براہِ راست راستہ بنا سکتی ہے یا نہیں اور براہِ راست ٹریفک سے انکار کرنے والے نیٹ ورکس کے لیے ریلے ترتیب دیا گیا ہے یا نہیں۔ ریلے ایک ہاپ اور ایک انحصار بڑھاتا ہے، مگر یہ معاون جواب ہے، اور جوڑی کا راستہ درست کرنا دریافت درست کرنے سے الگ کام ہے۔