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

این پرچم قصد را اعلام می‌کند؛ دسترس‌پذیری نمی‌سازد. رله باید از هر دو همتا در دسترس باشد، که در عمل یعنی نشانی عمومی، UDP ورودی روی درگاه Nebula باز در دیوار آتش میزبان و در هر گروه امنیتی ابری، و نبود 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 در دسترس باشد.
• relays: با نام‌بردن نشانی Nebula آن میزبان روی مقصد.
• use_relays: true روی همتایی که اتصال را آغاز می‌کند.
• قواعد ورودی روی مقصد پس از تغییر مسیر همچنان منبع واقعی را مجاز می‌دانند.