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 دست‌دهی ندارد که رد کند. به همین دلیل ارزش دارد قالب ورودی را با مرجع static_host_map در Nebula بسنجید نه با حافظه. مرجع فهرست‌های نقطه پایانی و رفتار تازه‌سازی DNS را هم پوشش می‌دهد.

راه‌اندازی باید پیش از overlay کار کند

یک نام DNS در نقشه باید از طریق حل‌کننده‌ای که میزبان پیش از هر تونل دارد حل شود، یعنی همان حل‌کننده معمولی سامانه. آن را از همان ماشین، هنگام راه‌اندازی، با overlay متوقف آزمایش کنید. نامی که فقط از طریق DNS خود overlay حل می‌شود نمی‌تواند overlay را راه‌اندازی کند. همین آزمون برای مسیر هم صادق است: قاعده دیوار آتشی که overlay را مجاز می‌داند اما اولین تبادل UDP را نه، بسته آغازین را مسدود می‌کند.

درگاه را با ابزار UDP بررسی کنید نه اینکه فرض کنید باز است. تأیید کنید که هر ارسال درگاه در مسیر به میزبان داخلی درست اشاره می‌کند و مسیر بازگشتی وجود دارد. اگر نام میزبان به چند نشانی حل می‌شود، هر یک را آزمایش کنید، چون کلاینت ممکن است نشانی‌ای را انتخاب کند که هرگز بررسی نکرده‌اید.

ورودی‌های ثابت مستقیم شماره‌گیری می‌شوند و هرگز با فانوس مشورت نمی‌کنند. به همین دلیل شکست در اینجا مانند یک پایان مهلت ساده بدون هیچ همتایی دیده می‌شود.

پس از اولین دست‌دهی چه می‌شود

وقتی میزبانی به فانوس می‌رسد، بدون ورودی دستی بیشتر از همتاها و نشانی‌های قابل دسترسشان آگاه می‌شود. میزبان‌هایی که از آخرین اتصال جابه‌جا شده‌اند از طریق همان کانال قابل کشف می‌شوند. این پاداش کوچک نگه داشتن نقشه دستی است.

میزبان‌ها می‌توانند نشانی‌های قابل دسترس اضافی خود را هم اعلام کنند, و این‌گونه همتایی پشت یک نشانی عمومی شناخته‌شده به دیگران در یافتنش کمک می‌کند. آن اعلام‌ها آموخته می‌شوند، نه در نقشه ثابت تایپ.

رفتار تازه‌سازی برای نقاط پایانی که به‌صورت نام DNS نوشته می‌شوند مهم است، چون نشانی حل‌شده می‌تواند در حالی که فرایند همچنان اجرا می‌شود تغییر کند. تنظیمات Nebula کنترل می‌کند که آن جست‌وجوها چگونه انجام شوند، از جمله اینکه کدام حل‌کننده به کار رود، پس آن‌ها را بخوانید نه اینکه پیش‌فرض سامانه را فرض کنید. روی میزبانی که حل‌کننده‌اش با بالا آمدن تونل تغییر می‌کند، تنظیم نادرست می‌تواند راه‌اندازی کارآمد را به نامی تبدیل کند که در میانه نشست از حل شدن بازمی‌ایستد. سنجاق کردن جست‌وجو به یک حل‌کننده پایدار غالباً همان تفاوت میان یک overlay قابل اعتماد و یک overlay متناوب است.

وقتی کشف کار می‌کند و یک همتا نه

اگر فانوس‌ها قابل دسترس باشند و بیشتر همتاها متصل شوند، راه‌اندازی مشکل نیست. جفت باقی‌مانده یا نمی‌تواند مسیر قابل استفاده‌ای به یکدیگر پیدا کند یا بالاتر از دسترس‌پذیری شکست می‌خورد. افزودن املای دیگری از نشانی فانوس هیچ‌یک از دو حالت را درست نمی‌کند.

پیش از ویرایش نقشه‌ای که همه چیز دیگر از قبل به آن تکیه دارد، جفت را بررسی کنید. تغییر نقشه هر میزبانی را مختل می‌کند، پس آخرین چیزی است که باید لمس شود، نه اولین.

با گواهی‌هایی از همان مرجع شروع کنید، چون دست‌دهی ردشده از دور می‌تواند مانند همتای غیرقابل دسترس به نظر برسد. سپس بررسی کنید که جفت می‌تواند مسیر مستقیم بسازد و آیا رله‌ای برای شبکه‌هایی که ترافیک مستقیم را رد می‌کنند پیکربندی شده است. رله یک گام و یک وابستگی اضافه می‌کند، اما پاسخ پشتیبانی‌شده است، و درست کردن مسیر جفت کاری متفاوت از درست کردن کشف است.