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 على النظير الذي يبدأ الاتصال.
• قواعد الوارد على الوجهة لا تزال تسمح بالمصدر الحقيقي بعد تغيّر المسار.