انتقل إلى المحتوى الرئيسي انتقل إلى الملاحة انتقل إلى التذييل

الوسيط والمنفِّذ

كيف تعمل أوامر المتصفح والعميل الخفيف دون أن يحتفظ العميل أبداً بمفاتيح SSH أو عناوين الأجهزة

الوسيط والمنفِّذ

عادةً، يعمل rdc على جهازك بإعداداتك ومفاتيح SSH الخاصة بك، ويتصل بخوادمك مباشرة. يقسّم نموذج الوسيط هذا العملية إلى قسمين: عميل خفيف لا يحمل أي أسرار، ومنفِّذ يحملها وينفذ العمل. زر التشغيل في وحدة التحكم على الويب وعلامة --proxy في واجهة سطر الأوامر كلاهما عميل خفيف، ويتحدثان بروتوكول النقل نفسه.

نيّة الأمر، لا الأمر نفسه

لا يحمل العميل الخفيف أبداً مفتاح SSH، أو عنوان جهاز، أو إعدادات مفكوكة التشفير. حين يريد تنفيذ شيء، يرسل فقط نيّة الأمر: معرِّفاً للأمر (مساره في عقد واجهة سطر الأوامر، مثلاً repo up) مع المعاملات. يبحث المنفِّذ عن الأمر في العقد نفسه، ويحوّله إلى الدالة المقابلة على جانب الخادم، ويحدد الجهاز الهدف من الإعدادات المفكوكة التشفير، وينفذه عبر اتصال SSH الخاص به. يتدفق الناتج مرة أخرى إلى العميل.

المنفِّذ هو واجهة سطر الأوامر نفسها، مُشغَّلة كخادم عبر rdc serve. الملف التنفيذي ذاته الذي يشغله المشغّلون على حاسوبهم المحمول يصبح هو ما ينفذ الأوامر نيابةً عنهم. له موضعان:

  • ‎--mode daemon: يعمل على مضيف تتحكم فيه، ومسجَّل بدون واجهة كأي واجهة سطر أوامر (راجع تخزين الإعدادات)، بحيث يستطيع اشتقاق مفتاح الإعدادات بنفسه ولا يحتاج إلى منح لكل جلسة. هذه هي الفئة الصارمة: لا يغادر SSH شبكتك أبداً.
  • ‎--mode container: يعمل داخل حاوية مخصصة لمؤسستك ومستضافة نيابةً عنك. يبدأ بدون أي مفتاح على الإطلاق ولا يستطيع فعل شيء حتى يمنحه عميل مفتاحاً للجلسة. هذه هي فئة الراحة.

منح مفتاح CEK

تخزين الإعدادات بدون معرفة: يخزن الخادم دائماً بيانات مشفرة فقط، ولا يوجد مفتاح تشفير المحتوى (CEK) بنص واضح إلا على عميل فك قفله. لذلك يجب أن يُمنَح منفِّذ وضع الحاوية المفتاح، ويجب ألا يكشف المنح المفتاح للخادم في هذه الأثناء.

المسار كالتالي: يفتح متصفح مفكوك القفل جلسة مع المنفِّذ، ويستلم المفتاح العام لتلك الجلسة، ثم يُختِم مفتاح CEK لتلك الجلسة باستخدام X25519. تمر الكتلة المختومة عبر خادم الحساب، لكن الخادم لا يستطيع فتحها، فتبقى خاصية “بدون معرفة” قائمة من طرف إلى طرف. يفك المنفِّذ تشفير CEK في الذاكرة فقط، بمهلة خمول قدرها 30 دقيقة؛ ولا يُكتَب شيء إلى القرص أبداً. تشير طلبات الأوامر اللاحقة إلى الجلسة الممنوحة عبر رأس X-Config-Session.

هناك تفصيل مهم للتدقيق: هوية المستخدم نفسها تمتد عبر المراحل الثلاث جميعها (فتح الجلسة، منح المفتاح، تنفيذ الأوامر). لا يُعيد خادم الحساب أبداً توجيه بيانات اعتماده الخاصة إلى المنفِّذ. لكل مرحلة، يُصدِر رمزاً قصير الأجل منسوباً إلى المستخدم الفعلي، ويعيد التحقق من عضوية ذلك المستخدم في كل مرة. يتحقق المنفِّذ من أي رمز يُقدَّم له قبل التنفيذ. لا يمكن لمستخدم استخدام منح صادر عن مستخدم آخر.

النصف الآخر من الإعدادات، وهو “الحالة” (بيانات وقت التشغيل المحلية للمضيف)، لا يسافر أبداً ضمن كتلة الإعدادات، لذا لا يصل إلى أي منفِّذ عبر هذا المسار أيضاً.

ما يمكن تشغيله عبر الوسيط

ليس كل أمر منطقياً عن بُعد. يحمل كل أمر في العقد علامة proxyCapable، ويفرضها المنفِّذ من جانب الخادم، بمعزل عن أي إعداد سياسة:

  • أوامر مستوى الجهاز غير التفاعلية (النشر، النسخ الاحتياطي، الحالة، السجلات، وما شابه) قابلة للتشغيل عبر الوسيط.
  • أوامر مستوى الإعدادات ليست كذلك: فهي تعدّل الإعدادات، وهو أمر يقع على هذا المسار على عاتق المتصفح (توجّهها وحدة التحكم على الويب إلى محرر الإعدادات المدمج بدلاً من ذلك).
  • الأوامر التفاعلية (الطرفيات، جلسات VS Code) ليست كذلك: لا توجد طرفية (TTY) عبر هذا الاتصال.
  • أوامر النقل من جانب العميل (rdc repo sync) ليست كذلك: فهي تنقل بيانات بين نظام ملفات العميل وجهاز، ولا يملك المنفِّذ ملفات العميل.

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

المنفِّذ الوهمي

في بيئة التطوير، حين لا يوجد منفِّذ حقيقي مُهيَّأ، يجيب خادم الحساب على طلبات الأوامر بنفسه بتدفقات وهمية وبيانات مزيفة بوضوح (أسماء موارد تبدأ بـ mock-). هذا يجعل وحدة التحكم بأكملها قابلة للتجربة، بما في ذلك النماذج والتدفق وعرض النتائج، دون الحاجة إلى جهاز أو فك قفل. أما التنفيذ الحقيقي فيحتاج إلى منفِّذ حقيقي.

ذو صلة