ربط الموجّهات خلف NAT بـFleetd: تسجيل العملاء والموافقة وإعادة الاتصال

ربط خادم سحابي بلوحة إدارة واضح غالبًا: تثبّت البرنامج وتحدد عنوان الاتصال ثم تتحقق منه. لكن موجّه المنزل قد لا يملك IPv4 عامًا، وتوجد أمامه شبكة المودم ومزود الخدمة. إعداد تحويل منافذ أو DNS ديناميكي أو خادم وسيط قد يجعل مدخل الإدارة نفسه مهمة صيانة إضافية.

في مقدمة Fleetd ذكرت أن العميل يبدأ الاتصال. هنا أشرح اتجاهه، والموافقة على الجهاز، وما يحدث عند الانقطاع، وفق تنفيذ v0.3.0.

Fleetd يربط خوادمك وموجّهاتك بلوحة إدارة. ليس خدمة أنفاق عامة، ولا يكشف تلقائيًا الشبكة المحلية بأكملها خلف الموجّه.

اعكس اتجاه الاتصال

بدل أن يبحث الخادم عن موجّه المنزل، يتصل العميل الموجود على الموجّه بالخادم. يوفر الخادم عنوانًا يمكن الوصول إليه، ويفتح العميل اتصال WebSocket لتقارير المراقبة والطلبات اللاحقة.

عملاء Linux والعملاء خلف NAT يتصلون جميعًا باتجاه fleetd-server. يحفظ الخادم البيانات في PostgreSQL، ويستخدم المسؤول واجهة الويب.

لا يحتاج الجهاز المُدار إلى منفذ وارد خاص بـFleetd، ولا يحتاج الخادم إلى اكتشاف العنوان العام الحالي لكل موجّه قبل التواصل معه.

يبقى الشرط الأساسي: يجب أن يستطيع العميل الوصول إلى الخادم. تؤثر DNS وقواعد الخروج والوكلاء وجودة الشبكة في النتيجة. يمكن استخدام نطاق عام أو شبكة خاصة متاحة للعملاء، بما فيها شبكة WireGuard موجودة.

العمل خلف NAT يعني تغيير الجهة التي تبدأ الاتصال. لا يتجاوز قيود الخروج ولا يجعل خادمًا غير قابل للوصول متاحًا تلقائيًا.

فتح اللوحة يثبت مسارًا واحدًا فقط

قد يستطيع المتصفح تسجيل الدخول بينما يفشل العميل. صفحات الإدارة وAPI لها مسار، والعميل يحتاج إلى عنوان WebSocket المضبوط، مثل:

wss://fleetd.example.com/agent/ws

هذا نطاق مثال يجب استبداله بعنوانك. وعلى الوكيل العكسي دعم ترقية WebSocket وعدم إغلاق الاتصالات الطويلة مبكرًا.

إذا عملت الصفحة الرئيسية وغاب تمرير WebSocket، فلن تعالج إعادة تثبيت العميل السبب غالبًا. ابدأ بالعنوان وسجلات الوكيل وخطأ المصافحة.

داخل WebSocket ينشئ Fleetd جلسة Noise مشفرة بين العميل والخادم. يثبت العميل المفتاح العام للخادم؛ مجرد الوصول إلى عنوان لا يعني الوثوق بأي خادم يجيب عليه.

شهادة HTTPS وهوية Noise المثبتة تؤديان وظيفتين مختلفتين. مفتاح خاطئ أو تغيير هوية الخادم أثناء النقل قد يمنع الاتصال. ينبغي استخدام HTTPS في النشر الفعلي؛ Noise لا يحمي وصول المتصفح بمفرده، والخادم بوصفه طرف الجلسة يستطيع قراءة بيانات المراقبة التي يتلقاها.

جهّز العميل قبل نسخ أمر التثبيت

مثال Compose في المقالة الأولى شغّل الخادم وPostgreSQL، لكنه لم يولّد تلقائيًا حزم العميل الموقعة.

للاستخدام المستمر، أنشئ مفتاح الإصدار وابنِ حزمة مناسبة وارفعها، ثم استخدم أمر التثبيت من اللوحة. ملفات v0.3.0 المنشورة تستهدف Linux amd64 وarm64؛ تحقق من معمارية الموجّه.

أنصح ببدء الجهاز الأول بصلاحية monitor، والتحقق من الشبكة والمراقبة قبل تمكين الأوامر. شكل الأمر هو:

curl -fsSL https://fleetd.example.com/install.sh | sh -s -- --permission monitor

لا تنفذ نطاق المثال كما هو. خذ الأمر من لوحتك وتحقق من مصدره. يحتاج المثبّت إلى صلاحيات مرتفعة، والثقة بمصدره جزء من البداية؛ التوقيعات اللاحقة لا تثبت بأثر رجعي أصالة أول سكربت نزلته.

يتعامل السكربت مع systemd أو procd، ويكتب الإعداد ويسجل الخدمة. للمفاتيح وظائف مختلفة:

المعلومة	السؤال الذي تجيب عنه
المفتاح العام للخادم	هل أتصل بخادم Fleetd المتوقع؟
مفتاح هوية العميل وبصمته	أي عميل يطلب الانضمام؟
المفتاح العام لتوقيع الأوامر	هل أجاز الأمر موقّع موثوق؟
المفتاح العام للإصدارات	هل وقّع التحديث ناشر موثوق؟

قد يكون فشل الاتصال ورفض الأمر مرتبطين بفحصين مختلفين. استبدال مفتاح عشوائي ليس حلًا عامًا.

انتظار الموافقة مرحلة مقصودة

عند التشغيل يحمّل العميل مفتاح هويته أو ينشئه. والهوية غير المعروفة التي تكمل المصافحة المناسبة تسجّل بانتظار الموافقة.

في هذه المرحلة تُحفظ معلومات التسجيل مثل الاسم وعنوان المصدر والمفتاح، ولم تبدأ جلسة المراقبة والأوامر الطبيعية. لذلك لا يعني غياب الرسوم عن جهاز معلّق وجود خلل في جمع البيانات.

اقرأ البصمة من طرفية تثبيت تتحكم بها أو اتصال موثوق سابقًا، ثم قارنها باللوحة. للعميل المثبت مع مسار إعداد صحيح:

fleetd-agent -config /etc/fleetd/agent.yaml fingerprint

وافق بعد التطابق فقط. الاسم الذي تعلنه جهة مجهولة لا يكفي. كذلك IP قرينة: قد تتشارك أجهزة عنوان خروج، وقد تتغير العناوين أو يؤثر الوكيل في المصدر المسجل. الأسماء والعناوين تساعد الإنسان على التمييز، لكن المطلوب هو التحقق من هوية العميل المقصود.

الموافقة لا تعني منح أوامر حرة. يبقى جهاز monitor للمراقبة فقط، وتتطلب العمليات توقيعًا وصلاحيات محلية. زر الموافقة لا يفتح طرفية root لكل الأجهزة.

لماذا لا يظهر الاتصال فور الموافقة؟

في v0.3.0 يعيد العميل المعلّق المحاولة بفاصل يقارب دقيقة. بعد الموافقة ينتظر عادة الاتصال التالي ليبدأ الجلسة والتقارير. لا تتحول الجلسة السابقة مباشرة بمجرد الضغط على الزر.

إذا لم تظهر بيانات بعد ثوانٍ، افحص السجل قبل الحذف وإعادة التثبيت. الدقيقة ليست ضمانًا للتوفر: قد تمنع DNS أو الشبكة أو المصافحة المحاولة التالية أيضًا. ميّز الانتظار حتى المحاولة عن محاولة حدثت وفشلت.

الانقطاع العادي له سياسة أخرى

بعد أخطاء الشبكة يستخدم العميل تراجعًا أسيًا مع تأخير عشوائي، لتخفيف اندفاع الجميع معًا عند عودة الخادم.

تبدأ قاعدة الانتظار بثانية وتصل إلى 60 ثانية، لكن المدة الفعلية تضيف مقدارًا عشوائيًا. لذلك لا يصح الوعد بإعادة الاتصال خلال 60 ثانية كحد أقصى. إذا استمرت الجلسة السابقة أكثر من دقيقة، تُعاد القاعدة إلى انتظار قصير بعد انتهائها.

يرسل الخادم رسائل إبقاء الاتصال، ويؤدي غياب التقدم في الاستقبال طويلًا إلى إنهاء الجلسة ثم إعادة الاتصال. هذه آلية لاستعادة القناة، وليست ضمانًا لاستئناف كل عملية.

عودة الجهاز متصلًا لا تثبت نجاح الأمر السابق ولا استمرار مهمة الطرفية. تحديث البرامج وتغيير الشبكة وإعادة تشغيل خدمة قد تقطع القناة بنفسها. تحقق من النتيجة الفعلية قبل تكرار عملية لأن رسالة اكتمالها لم تصل.

سنناقش عمر المهام في مقالة الأوامر؛ المهم هنا فصل استعادة الشبكة عن استعادة العمل.

تغيير الاسم والعنوان وإعادة التثبيت أمور مختلفة

تعتمد الهوية على المفتاح، لا اسم المضيف أو IP. الرجوع بالمفتاح نفسه من عنوان جديد يختلف عن التسجيل بمفتاح جديد.

إذا حذفت إعادة التثبيت المفتاح القديم، فقد يظهر الاسم نفسه كعميل جديد ويحتاج إلى تحقق آخر. وبالعكس، قد ينسخ استنساخ نظام مسجل مفتاحه إلى جهاز ثانٍ.

جهازان بالهوية نفسها ليسا عميلين مستقلين. التنفيذ الحالي يلغي الاتصال الأقدم عند وصول اتصال جديد للآلة المسجلة نفسها، وقد تبدو الهوية المكررة كحالة انقطاع متكرر.

لا توزع المفتاح الخاص لعميل مسجل ضمن قالب نظام. ينبغي أن تحافظ إعادة التشغيل المعتادة على الهوية، وأن تحصل الأجهزة الجديدة على هويات منفصلة. نسخ المجلد بأكمله لا يصلح للغرضين معًا.

حذف الجهاز لا يمنع عودته

يحذف أمر الإزالة سجل الجهاز وتاريخه من اللوحة. وإذا استمر العميل في العمل، فقد يظهر مرة أخرى بانتظار الموافقة؛ الخادم نسي الإذن، والجهاز لم يتوقف عن طلب الاتصال.

لتغيير اسم العرض استخدم إعادة التسمية. لإنهاء الإدارة أوقف العميل وأزله وفق الدليل. ولحظر هوية استخدم الرفض: يُمنع مفتاحها حتى إزالة الحظر.

الحظر يخص المفتاح. إنشاء مفتاح جديد يعني هوية أخرى ما زالت تحتاج إلى موافقة، وليس هذا منعًا دائمًا للعتاد الفيزيائي.

الحد الحالي لقائمة الانتظار 50 جهازًا. يحد ذلك من طابور التسجيل، ولا يشكل دفاعًا كاملًا ضد الهجمات. تبقى حماية المدخل وحسابات المسؤولين ونطاق التعرض للشبكة ضرورية.

شخّص المرحلة التي توقفت

العَرَض	ما تفحصه أولًا
الخدمة لا تعمل بعد التثبيت	المعمارية والتنزيل وأخطاء التثبيت وsystemd أو procd
لا يظهر طلب معلق	العنوان وDNS والخروج وWebSocket ومفتاح الخادم
طلب معلق بلا بيانات	البصمة والموافقة وموعد المحاولة التالية
انقطاع مستمر بعد الموافقة	آخر مصافحة وهل بدأت جلسة معتمدة
الجهاز متصل والأوامر مرفوضة	الصلاحيات ومفاتيح التوقيع والهدف والصلاحية الزمنية
عودة الطلب بعد الحذف	هل العميل ما زال يعمل ويحتاج إلى إيقاف أو رفض؟

في أنظمة systemd:

systemctl status fleetd-agent
journalctl -u fleetd-agent -n 80 --no-pager

وفي OpenWrt أو iStoreOS:

/etc/init.d/fleetd-agent status
logread | grep fleetd

قد تختلف المخرجات بين الإصدارات. حدد مرحلة الفشل وأزل النطاقات والعناوين والمعلومات الحساسة قبل مشاركة السجلات. لا ترسل مفاتيح الهوية الخاصة.

اجعل التجربة الأولى صغيرة

ابدأ بجهاز اختبار بصلاحية monitor. قارن البصمة عبر قناة موثوقة، وافق عليه، وشاهد بيانات جديدة. ثم نفّذ إعادة تشغيل مخططة للعميل وتحقق من رجوعه بالهوية نفسها.

يسهل فهم التسجيل بهذه الطريقة بدل منح full للجميع وتنفيذ أوامر جماعية فورًا. يفصل Fleetd بين قابلية الوصول وهوية الخادم وهوية العميل والسلطة المحلية، ما يوضح التشخيص والتفويض.

في المقالة التالية سنناقش سبب تحقق العميل من توقيع طلب مر بالفعل بالخادم، وحدود الثقة في توقيع المتصفح.