الخلاصة

  • قبول إعداد الوكيل لا يثبت استخدامه، واستخدامه لا يثبت نجاح طلب التطبيق. تميز بنية مخازن البيانات بين الإعداد المقصود والإعداد المطبّق، لكن إثبات الوصول يحتاج إلى مشاهدات مرتبطة بمحاولة محددة وبالإعداد الذي استُخدم فيها، لا إلى جمع إعداد حديث ونجاح قديم في حكم واحد. يضع RFC 8342 أساس هذا الفصل.
  • نجاح المصادقة لدى الوكيل ليس إذنًا عامًا بالتمرير، ونجاح التمرير ليس تحققًا من هوية الخدمة أو إنجازًا للعملية المطلوبة. وحتى رد فحص البقاء في TCP يخص قرين الاتصال الذي أجاب، لا بالضرورة التطبيق البعيد. تتضح هذه الحدود عند قراءة مراحل SOCKS في RFC 1928 إلى جانب قواعد فحوص البقاء في RFC 9293.

المغالطة تبدأ عند تغيير معنى «نجاح»

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

وتحتاج عبارة «قُبل الإعداد» نفسها إلى تحديد. عند استخدام NETCONF، يتيح مخزن <candidate> إعداد تغييرات دون تعديل الإعداد الجاري فورًا. أما قدرة التحقق فتفحص الإعداد بحثًا عن أخطاء نحوية ودلالية قبل تطبيقه. لذلك يختلف نجاح التحقق عن اعتماد التغيير، كما تشرح الفقرتان 8.3 و8.6 من RFC 6241.

ليس المطلوب التقليل من قيمة إقرار الإدارة؛ بل الحفاظ على معناه. السؤال الذي يجب أن يرافق كل حالة نجاح هو: نجحت أي عملية، عند أي طرف، وعلى أي إصدار من الإعداد؟ من دون هذه الحدود، تصبح كلمة «نجاح» وسيلة لنقل المسؤولية من فريق إلى آخر، بدل أن تكون وصفًا قابلًا للفحص.

ثلاث وحدات إعداد، وليست سجلًا للاتصال

تعرّف المواصفة ثلاث وحدات: ietf-tcp-common وفيها tcp-common-grouping للمعلمات المشتركة، وأساسها فحوص البقاء؛ وietf-tcp-client وفيها tcp-client-grouping للوجهة والربط المحلي الاختياري والوكيل؛ وietf-tcp-server وفيها tcp-server-grouping للربط المحلي للخادم. وتستخدم مجموعتا العميل والخادم المجموعة المشتركة، ولا تعرّف المواصفة عقدًا من نوع config false، وفق RFC 9643.

هذه وحدات تتضمن مجموعات قابلة لإعادة الاستخدام، وليست ثلاث مراحل تثبت بعضها بعضًا. ففي YANG، لا تنشئ عبارة grouping وحدها عقدًا في شجرة المخطط؛ تدخل بنيتها عند استعمال uses في السياق المناسب. كذلك تجعل feature وif-feature أجزاء من المخطط مشروطة بدعم التنفيذ، بحسب الفقرات 7.12 و7.13 و7.20 من RFC 7950.

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

ومن المهم أيضًا ألا يُقرأ غياب عقد الحالة المستقلة بوصفه نفيًا لإمكان الاطلاع على القيم المطبّقة. فهذا سؤال تحسمه بنية مخازن البيانات، لا اسم الوحدة وحده.

الإعداد المقصود لا يساوي الإعداد المستخدم

يمثل <intended> الإعداد الذي يحاول النظام تطبيقه بعد التحويلات على الإعداد الجاري. ويجمع <operational> الإعداد المستخدم فعليًا وحالة النظام. وقد يختلف المطبّق عن المقصود بسبب تأخير أو موارد مفقودة أو إعدادات أخرى يوردها النظام. يشرح RFC 8342 هذه العلاقة في الفقرتين 5.1.4 و5.3، ويجيز استثناء عقد من مخطط الحالة التشغيلية عندما يتعذر الإبلاغ عنها بدقة.

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

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

عنوان الوكيل ليس عنوان الوجهة

داخل proxy-server يقع اختيار واحد مشروط بالدعم بين SOCKS4 وSOCKS4a وSOCKS5. ويخص remote-address الخارجي الوجهة، بينما يخص الداخلي الوكيل. يقبل عنوان الوكيل عنوان IP في فرع SOCKS4، واسم مضيف أيضًا في الفرعين الآخرين؛ ومنفذه الافتراضي 1080. وتوضح المواصفة أن SOCKS4a يضيف إمكان استخدام اسم المضيف مقارنةً بـSOCKS4، في RFC 9643.

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

وفي SOCKS5، يمكن تمثيل الوجهة بعنوان IPv4 أو IPv6 أو اسم نطاق، وفق الفقرتين 4 و5 من RFC 1928. لذلك ينبغي أن يوضح سجل المحاولة ما إذا كان طلب التمرير يحمل اسمًا أم عنوانًا، لا أن يكتفي بالاسم الموجود في واجهة الإدارة.

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

اختيار المصادقة لا ينفذها

حاوية authentication-parameters اختيارية؛ وعند استعمالها يُختار GSS-API أو اسم المستخدم وكلمة المرور، بحسب الدعم. وحاوية gss-api الأساسية فارغة لاستكمالها بامتدادات، بينما يستخدم فرع كلمة المرور password-grouping، كما يبين تعريف العميل في RFC 9643.

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

عند استخدام اسم المستخدم وكلمة المرور، يتحقق الوكيل من القيم المرسلة ويعيد حالة نجاح أو فشل مستقلة. وتحذر الفقرة 3 من RFC 1929 من أن هذا التبادل يحمل كلمة المرور بصورتها الصريحة. ومن ثم يجب التمييز بين حماية السر في الإدارة وحمايته على مسار المصادقة.

أما GSS-API، فيحتاج إلى إنشاء سياق أمني ثم الاتفاق على مستوى حماية الرسائل. ويتيح التفاوض مستويات تختلف في ضمان السلامة والسرية، وفق الفقرتين 3 و4 من RFC 1961. اسم الطريقة، وحده، لا يثبت أن السرية قد اتُّفق عليها أو استُخدمت.

هذا الفصل يحدد أيضًا مسؤولية الرصد: لا يكفي حقل يقول «المصادقة مفعّلة». ينبغي معرفة الطريقة التي استُخدمت، ونتيجتها، ومستوى الحماية عند انطباقه، مع عدم تحويل سجل التشخيص إلى نسخة من بيانات الاعتماد.

حماية القيمة المحفوظة ليست حماية التبادل

يقدم RFC 9640، في تعريف password-grouping، بديلين لكلمة المرور: قيمة صريحة أو قيمة مشفرة، بحسب الميزات المدعومة. ويخصص المجموعة لإعداد بيانات اعتماد تُستخدم للمصادقة لدى نظام بعيد، ويميز ذلك عن إعداد كلمة مرور للتحقق من حساب محلي.

هذا التمييز مهم لأن قيمة محفوظة بصورة مشفرة لا تجيب عن سؤالين آخرين: هل يستطيع التنفيذ استخدامها عند الحاجة؟ وكيف ستُحمل في البروتوكول الذي اختير؟ قبول البنية ليس تجربة ناجحة لاستخدام السر، كما أن تشفير الحفظ لا يبدل طريقة نقل كلمة المرور التي يحددها بروتوكول المصادقة.

ويتيح نموذج التحكم في الوصول NACM فصل صلاحيات القراءة والكتابة والتنفيذ والوصول إلى العمليات والبيانات، وفق RFC 8341. هذه أدوات لضبط سلطة الإدارة، وليست تفويضًا يصدر من الوكيل البعيد. فصاحب حق تعديل بيانات الاعتماد محليًا لا يكتسب بذلك حق المرور لدى نظام آخر.

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

اتصالان TCP وقرار مستقل بالتمرير

في مسار SOCKS5، يفتح العميل أولًا اتصال TCP إلى الوكيل، ثم يجري تفاوض الطريقة والمصادقة المطلوبة، ويرسل طلب التمرير الذي يقيّمه الوكيل. وعند نجاح طلب CONNECT توجد وصلة بين العميل والوكيل وأخرى يقيمها الوكيل إلى الوجهة. يحدد RFC 1928 هذا التسلسل.

ويعني REP=0x00 نجاح الطلب بحسب تقرير الوكيل وتنفيذه للبروتوكول، لا توثيق هوية التطبيق. أما BND.ADDR وBND.PORT في رد CONNECT فيصفان الربط المستخدم من جهة الوكيل للاتصال بالهدف، لا هوية الهدف نفسه، وفق الفقرة 6 من المواصفة ذاتها.

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

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

من فتح المنفذ ليس بالضرورة الخدمة الموثوقة

ينتهي سؤال عنوان النقل قبل سؤال هوية القرين في الطبقة الأعلى. ففي نموذج SSH، تفصل client-identity بيانات هوية العميل عن server-authentication التي تضبط الثقة بالخادم. ويصمم RFC 9644 هذه الإعدادات لتستخدم إلى جانب إعداد النقل، لا لتحويل عنوان TCP إلى هوية موثقة.

وفي تبادل المفاتيح الموضح في الفقرة 8 من RFC 4253، يفحص العميل نسبة مفتاح المضيف إلى الخادم، ويتحقق من توقيع التبادل. وتحذر المواصفة من أن قبول المفتاح دون التحقق من نسبته يجعل البروتوكول غير آمن في مواجهة هجمات نشطة. لذلك لا تكفي عبارة «بدأ SSH» لوصف قرار الثقة الذي اتُّخذ.

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

وفي TLS، يفصل RFC 9645 أيضًا إعداد هوية العميل عن إعداد التحقق من الخادم، ويتضمن بدائل لا تقتصر على الشهادات. لذلك يجب وصف نمط المصادقة المستخدم بدل افتراض أن كل جلسة ناجحة استندت إلى المسار نفسه.

عند استخدام شهادة في TLS 1.3، تقدم CertificateVerify إثبات امتلاك المفتاح الخاص الموافق لها، وتؤدي Finished دورًا في توثيق المصافحة والمفاتيح المحسوبة. ويلزم التحقق من الرسالتين وفق الفقرتين 4.4.3 و4.4.4 من RFC 8446. لكن إثبات امتلاك مفتاح ليس، بمفرده، جوابًا عن كون صاحبه الخدمة المقصودة.

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

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

الوصول إلى التطبيق ليس إنجاز العملية

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

عندما تكون الوجهة خادم NETCONF، مثلًا، يربط message-id رد <rpc-reply> بالطلب، وقد يحمل الرد بيانات أو <rpc-error> أو <ok/> بحسب نتيجة العملية وطبيعتها. توضح الفقرات 4.2 إلى 4.4 من RFC 6241 هذه الدلالات. المقصود هنا طلب إلى الخدمة البعيدة عبر القناة المنشأة، لا معاملة الإدارة السابقة التي ضبطت الوكيل محليًا.

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

لهذا ينبغي تعريف طلب الاختبار قبل الاستناد إليه: ما المورد المقصود، وبأي هوية وصلاحية، وما النتيجة التي تُعد كافية؟ أما عبارة «الخدمة تعمل» من دون تحديد الوظيفة، فتسمح لكل فريق بأن ينسب إليها معنى يلائم مسؤوليته.

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

فحوص البقاء: أي قرين أجاب؟

تضبط حاوية keepalives معلمات idle-time وmax-probes وprobe-interval، ويشير وجودها، عند دعم الميزات اللازمة، إلى تفعيل فحوص البقاء، وفق RFC 9643. هذه معلمات لفحص اتصال، وليست تعريفًا لمهلة إنجاز طلب التطبيق.

وتقرر الفقرة 3.8.4 من RFC 9293 أن تضمين الآلية اختياري، وأنها تكون معطلة افتراضيًا، وأن فقد الرد على مسبار معين لا يجوز اعتباره وحده دليلًا على موت الاتصال. والمسبار مصمم لاستثارة رد من قرين TCP في اتصال خامل.

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

وتوصي إرشادات RFC 9643 باختيار طبقات فحص ذات معنى للتطبيق، مع مراعاة الموارد والازدحام. ليست الاستجابة المنطقية لنقص الدليل إذًا مضاعفة المجسات نفسها، بل اختيار مشاهدة تجيب عن السؤال الناقص.

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