Nebula advertise_addrs یا static_host_map: مالک کے مطابق چنیں
اسٹیٹک نقشہ ہر وہ peer برقرار رکھتا ہے جو اسے کال کرتا ہے؛ اعلان شدہ پتہ میزبان شائع کرتا ہے۔ اس بنیاد پر چنیں کہ کون آخری نقطہ جانتا ہے۔
static_host_map اور advertise_addrs دونوں ترتیبات ایک peer کے سامنے پتہ رکھتی ہیں، اور وہ مختلف سوالوں کے جواب دیتی ہیں۔ ایک مقامی فائل ہے جو overlay پتہ اور کال کرنے والا underlay آخری نقطہ درج کرتی ہے۔ دوسری میزبان ہے جو اپنے روشن میناروں کو بتاتی ہے کہ کون سے اضافی آخری نقطے اس تک پہنچ سکتے ہیں۔ اصل فرق ملکیت ہے: نقشہ وہ سب برقرار رکھتے ہیں جنہیں اس کی ضرورت ہے، اور اعلان خود میزبان۔
فیصلہ کریں کہ معلومات کس کے پاس ہے
| Setting | Where it lives | Best for |
|---|---|---|
static_host_map | Every peer that needs the entry | Bootstrap endpoints, deliberately fixed paths |
advertise_addrs | The host's own config | Endpoints the host cannot otherwise discover |
ہر peer کی اسٹیٹک فائل میں ہر بدلتا peer ایک دیکھ بھال کا کام ہے جو بیڑے کے مربع کے ساتھ بڑھتا ہے۔ یہی عملی وجہ ہے کہ جب میزبان خود جواب جانتا ہو تو دوسری ترتیب کی طرف جائیں۔
ملکیت کا سوال یہ بھی بتاتا ہے کہ پتہ بدلنے پر کیا ہوتا ہے۔ اسٹیٹک نقشے کے ساتھ، کسی کو ہر وہ peer یاد رکھنا ہوتا ہے جس کے پاس پرانا اندراج ہے۔ اعلان کے ساتھ، میزبان نیا آخری نقطہ شائع کرتا ہے اور اس کے روشن مینار اسے آگے بھیجتے ہیں، لہٰذا تبدیلی منتقل شدہ مشین پر ہی مقامی رہتی ہے۔
Bootstrap کو اب بھی اسٹیٹک اندراجات درکار ہیں
کلائنٹ کو دوسرے peer کے بارے میں کسی سے پوچھنے سے پہلے کم از کم ایک روشن مینار تک پہنچنا ہوتا ہے۔ وہ پہلی چھلانگ کھوج سے نہیں آ سکتی، اس لیے یہ کلائنٹ کی ترتیب میں اسٹیٹک اندراج پر منحصر ہے۔ اس ایک اندراج کو درست کریں اور باقی overlay سیکھا جا سکتا ہے۔
نقشے کا اندراج Nebula پتے کو ایک یا زیادہ قابل رسائی IP یا DNS آخری نقطوں اور پورٹوں کے ساتھ جوڑتا ہے۔ روشن مینار وہاں رکھنا معمول ہے؛ ہر peer وہاں رکھنا وہ نمونہ ہے جو بری طرح بوڑھا ہوتا ہے، کیونکہ ہر نیا peer ایسی مشینوں پر فائلیں تبدیل کرنا ہے جنہیں آپ شاید کنٹرول نہیں کرتے۔ فہرست کو اتنا چھوٹا رکھیں کہ کوئی شخص پڑھ کر اس کی تصدیق کر سکے۔
جب میزبان آخری نقطہ جانتا ہو تو اعلان کریں
پورٹ فارورڈنگ کے پیچھے میزبان ایک عوامی پتے پر قابل رسائی ہوتا ہے جو اس کے اپنے کسی بھی انٹرفیس کو مختص نہیں۔ وہ خود کو دیکھ کر وہ پتہ دریافت نہیں کر سکتا۔ advertise_addrs اسے اجازت دیتا ہے کہ وہ اپنے روشن میناروں کے ذریعے آخری نقطہ شائع کرے تاکہ دوسرے peer ایسا راستہ سیکھیں جو واقعی کام کرتا ہے۔ یہ ترتیب اسی لیے ہے کہ نقشہ بننے کا علم صرف میزبان کو ہے۔
وہ پتہ اور پورٹ استعمال کریں جہاں دوسرے peer واقعی پہنچ سکتے ہیں۔ یہی دلیل کئی نیٹ ورک راستوں والے میزبان پر بھی لاگو ہوتی ہے، جہاں کسی خاص نیٹ ورک کے peer کے لیے ایک راستہ بہتر ہے۔ اعلان underlay کے بارے میں ایک بیان ہے، کسی چیز کی درخواست نہیں۔ جب نقشہ بدلے تو میزبان پر اعلان کو تازہ کریں اور کھوج کو اسے لے جانے دیں، پورے بیڑے میں اسٹیٹک فائلیں تبدیل کرنے کے بجائے۔
اعلان رسائی نہیں ہے
آخری نقطہ شائع کرنے سے روٹر کا فارورڈنگ قاعدہ نہیں بنتا، اوپر کا فائر وال نہیں کھلتا اور DNS نام حل نہیں ہوتا۔ یہ کام کے الگ حصے ہیں، اور غائب پورٹ فارورڈنگ کے ساتھ درست اعلان بھی وہی ناکامی پیدا کرتا ہے جسے آپ ٹھیک کرنا چاہتے تھے۔ اعلان رسائی کے بارے میں ایک دعویٰ ہے، اسے قائم کرنے والا کوئی طریقہ نہیں۔
کھوج کو قصوروار ٹھہرانے سے پہلے باہر سے راستہ جانچیں۔ جو peer آخری نقطہ سیکھتا ہے مگر handshake مکمل نہیں کر سکتا اسے underlay پر روٹنگ یا فلٹرنگ کا مسئلہ ہے، اور دونوں ترتیبات میں وہی پتہ دہرانے سے یہ نہیں بدلے گا۔
overlay پتے کو آخری نقطے سے الگ رکھیں
نوڈ کا سرٹیفکیٹ اس کا Nebula پتہ شناخت کرتا ہے۔ اعلان شدہ پتے بنیادی نیٹ ورک سے تعلق رکھتے ہیں، اور سرٹیفکیٹ کو چھوئے بغیر بدل سکتے ہیں۔ مختلف overlay IP کے ساتھ نیا سرٹیفکیٹ جاری کرنا ایک مختلف کارروائی ہے، جس کے اپنے نتائج ہر اس اعتماد کے رشتے کے لیے ہیں جس نے پرانے کو پن کیا تھا۔ runbook میں دونوں تبدیلیاں الگ رکھیں، ورنہ آخری نقطے کی منتقلی دوبارہ اجرا کے طور پر درج ہوگی۔
جب triage رک جائے تو دونوں تہوں کو واضح طور پر الگ کریں: کیا کھوج متوقع آخری نقطہ واپس دیتی ہے، اور کیا handshake وہاں پہنچتا ہے؟ اگر کھوج درست ہے اور پیکٹ ناکام ہوتے ہیں، مسئلہ overlay کے نیچے ہے۔ اگر کھوج غلط ہے، مسئلہ نقشے یا اعلان میں ہے، اور اصلاح وہیں ہے۔