Nebula advertise_addrs یا static_host_map: بر اساس مالک انتخاب کنید
نقشه ایستا توسط هر همتایی نگهداری می‌شود که به آن شماره می‌گیرد؛ نشانی اعلام‌شده توسط میزبان منتشر می‌شود. بر اساس اینکه چه کسی نقطه پایانی را می‌شناسد انتخاب کنید.
تنظیمات static_host_map و advertise_addrs هر دو نشانی را جلوی یک همتا می‌گذارند و به پرسش‌های متفاوتی پاسخ می‌دهند. یکی پرونده محلی است که نشانی پوششی و نقطه پایانی شبکه زیرین برای شماره‌گیری را فهرست می‌کند. دیگری میزبانی است که به فانوس‌های خود می‌گوید کدام نقاط پایانی اضافی می‌توانند به آن برسند. تفاوت واقعی مالکیت است: نقشه را همه کسانی که به آن نیاز دارند نگهداری می‌کنند و اعلام را خود میزبان.
بر اساس اینکه چه کسی اطلاعات را در دست دارد تصمیم بگیرید
| 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 |
هر همتای متغیر در پرونده ایستای هر همتا کاری نگهداری است که با مربع ناوگان رشد می‌کند. این دلیل عملی روی آوردن به تنظیم دیگر است هرگاه خود میزبان پاسخ را بداند.
پرسش مالکیت همچنین پیش‌بینی می‌کند وقتی نشانی تغییر می‌کند چه می‌شود. با نقشه ایستا، کسی باید هر همتایی را که ورودی قدیمی را دارد به یاد بسپارد. با اعلام، میزبان نقطه پایانی جدید را منتشر می‌کند و فانوس‌هایش آن را انتقال می‌دهند، پس تغییر در همان ماشینی که جابه‌جا شده محلی می‌ماند.
بوت‌استرپ هنوز به ورودی‌های ایستا نیاز دارد
کارخواه باید پیش از آنکه بتواند از کسی درباره همتاهای دیگر بپرسد، دست‌کم به یک فانوس برسد. آن پرش نخست نمی‌تواند از کشف بیاید، پس از یک ورودی ایستا در پیکربندی کارخواه می‌آید. آن یک ورودی را درست کنید و بقیه پوشش را می‌توان آموخت.
ورودی نقشه یک نشانی Nebula را با یک یا چند نقطه پایانی IP یا DNS قابل دسترس و درگاه‌ها جفت می‌کند. نگه داشتن فانوس‌ها در آنجا عادی است؛ نگه داشتن هر همتا در آنجا الگویی است که بد پیر می‌شود، چون هر همتای تازه یعنی ویرایش پرونده‌ها روی ماشین‌هایی که شاید کنترلشان نکنید. فهرست را آنقدر کوتاه نگه دارید که یک نفر هنوز بتواند با خواندنش آن را بررسی کند.
وقتی میزبان نقطه پایانی را می‌شناسد اعلام کنید
میزبانی که پشت هدایت درگاه است، روی نشانی عمومی‌ای در دسترس است که به هیچ‌یک از رابط‌های خودش اختصاص نیافته است. نمی‌تواند آن نشانی را با نگاه به خودش کشف کند. advertise_addrs به آن اجازه می‌دهد نقطه پایانی را از طریق فانوس‌هایش منتشر کند تا همتاهای دیگر مسیری را بیاموزند که واقعاً کار می‌کند. این تنظیم دقیقاً به این دلیل هست که میزبان تنها طرفی است که می‌داند نگاشت انجام شده است.
از نشانی و درگاهی استفاده کنید که همتاهای دیگر واقعاً می‌توانند به آن برسند. همین استدلال برای میزبانی با چند مسیر شبکه‌ای صادق است، جایی که یک مسیر برای همتاهای یک شبکه مشخص ترجیح دارد. اعلام بیانیه‌ای درباره شبکه زیرین است، نه درخواستی برای چیزی. وقتی نگاشت تغییر می‌کند، اعلام را در میزبان به‌روز کنید و بگذارید کشف آن را حمل کند، به‌جای ویرایش پرونده‌های ایستا در سراسر ناوگان.
اعلام به معنای دسترسی‌پذیری نیست
انتشار یک نقطه پایانی قاعده هدایت روتر را نمی‌سازد، دیوار آتش بالادست را باز نمی‌کند و باعث نمی‌شود یک نام DNS تفکیک شود. اینها تکه‌های جداگانه کار هستند و اعلام درست با هدایت درگاه گمشده دقیقاً همان خرابی‌ای را تولید می‌کند که می‌خواستید درست کنید. اعلام ادعایی درباره دسترسی‌پذیری است، نه سازوکاری که آن را برقرار کند.
پیش از سرزنش کشف، مسیر را از بیرون بررسی کنید. همتایی که نقطه پایانی را می‌آموزد اما نمی‌تواند دست‌دهی را کامل کند، مشکل مسیریابی یا فیلتر در شبکه زیرین دارد و تکرار همان نشانی در هر دو تنظیم آن را عوض نمی‌کند.
نشانی پوششی را از نقطه پایانی جدا نگه دارید
گواهی گره نشانی Nebula آن را مشخص می‌کند. نشانی‌های اعلام‌شده به شبکه زیرین تعلق دارند و می‌توانند بدون دست زدن به گواهی تغییر کنند. صدور گواهی تازه با نشانی IP پوششی متفاوت عملیاتی متفاوت است، با پیامدهای خودش برای هر رابطه اعتمادی که نشانی قدیمی را سنجاق کرده بود. دو تغییر را در دفترچه اجرا جدا نگه دارید، وگرنه جابه‌جایی نقطه پایانی به‌عنوان صدور دوباره ثبت می‌شود.
وقتی تریاژ گیر می‌کند، دو لایه را صریح جدا کنید: آیا کشف نقطه پایانی مورد انتظار را برمی‌گرداند و آیا دست‌دهی به آن می‌رسد؟ اگر کشف درست است و بسته‌ها شکست می‌خورند، مشکل زیر پوشش است. اگر کشف نادرست است، مشکل در نقشه یا اعلام است و اصلاح به همان‌جا تعلق دارد.