الخلاصة

  • لأن UDP بروتوكول بلا اتصال، لا يملك الوكيل مصافحة تخبره بأن الوجهة قابلة للوصول. لذلك يطلب RFC 9298 منه الرد من دون انتظار رزمة من الهدف.
  • تعني الاستجابة الناجحة أن الوكيل فتح مقبساً نحو الهدف المطلوب وأنه مستعد لتمرير حمولات UDP. ولا تعني أن رزمة وصلت أو أن التطبيق البعيد موجود أو موثّق أو قبل العملية.
  • تكمن أهمية صياغة David Schinazi في أنها تمنع الشهادة المستعارة. على التشغيل أن يفصل إثبات التفويض وحل الاسم وحالة المقبس وحركة الرزم ونتيجة البروتوكول الداخلي.

من يملك حق الكلام في كل مرحلة؟

يمكن لمنصة مراقبة أن ترى استجابة HTTP ناجحة فتكتب أن «الخدمة البعيدة متاحة». الجملة سهلة، لكنها تجمع شاهدين في شاهد واحد. الوكيل يعرف أنه قبل الطلب وأنشأ حالة محلية؛ أما الهدف فلا يلزمه في UDP أن يرسل أي إقرار عند إنشاء المقبس.

يحدد RFC 9298 طريقة لنقل UDP عبر وكيل HTTP. يضع العميل target_host وtarget_port في قالب URI مطلق، ثم يطلب نفق CONNECT-UDP. يستخرج الوكيل القيم، يطبق سياسته، ويفتح مقبس UDP نحو الهدف. وتحمل HTTP Datagrams الحمولات فوق الآلية التي يشرحها RFC 9297، مع اختلاف بدء النفق باختلاف نسخة HTTP.

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

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

الضيق هنا فضيلة. فالوثيقة لا تجعل الوكيل يتحدث باسم جهة لم ترسل دليلاً.

حل الاسم يثبت نتيجة لحظية فقط

إذا كان الهدف اسماً في DNS، يجب على الوكيل حله قبل الرد. وإذا فشل الحل، يرفض الطلب ويمكنه استخدام Proxy-Status من RFC 9209 لبيان dns_error أو سبب مناسب آخر.

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

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

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

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

مطابقة العنوان والمنفذ ليست هوية تطبيق

يستطيع الوكيل استخدام مقبس UDP متصل ليجعل النواة تسلمه الرزم المطابقة للخماسية الصحيحة فقط. وإذا استخدم مقبساً غير متصل، يلزمه RFC 9298 بالتحقق من عنوان IP ومنفذ المصدر في كل رزمة واردة، وإسقاط كل ما لا يطابق الطلب.

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

يرتبط عمر المقبس بمسار طلب HTTP. يبقيه الوكيل مفتوحاً ما دام المسار مفتوحاً، ويغلق المسار إذا أخبره نظام التشغيل بأن المقبس لم يعد صالحاً. قد تكون رسالة ICMP Destination Unreachable سبباً لذلك. ويجوز الإغلاق بسبب الخمول، مع توصية بألا يقل الحد عن دقيقتين.

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

قد ينجح النفق وتُسقط الرزمة وفق المواصفة

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

يستطيع العميل الإرسال بتفاؤل قبل تلقي استجابة CONNECT-UDP. يوفر ذلك وقتاً في المسار السليم، لكنه يعني أن الرزم الأولى قد لا تعالج إذا فشل الطلب أو لم يختر الوكيل تخزينها.

للحجم حد آخر. لا تتجاوز حمولة UDP ذات Context ID صفر 65,527 بايت، وقد يفرض MTU الفعلي رقماً أصغر. لا يجوز للوكيل أن يضيف تجزئة IP أثناء التمرير، ولذلك قد يضطر إلى إسقاط HTTP Datagram كبيرة بصمت.

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

وضع Schinazi داخل عمل جماعي

نُشر RFC 9298 في أغسطس 2022 على مسار معايير IETF ويسمي David Schinazi مؤلفاً. ويصفه ملف Datatracker المكتوب، الذي حُفظ في 2 سبتمبر 2026، بأنه مهندس برمجيات رئيسي كبير ومدير كبير في Google، يركز على Privacy Proxy وMASQUE وOHTTP. كما يذكر قيادته السابقة المشتركة لـQUIC، وإدارته Chrome Networking، وعمله على تقنيات الشبكات في Apple. الوظائف والأدوار وعدد RFCs معلومات مؤرخة قابلة للتغير.

تثبت الصورة الرسمية هويته البصرية العامة ولا تثبت سيطرته على نشر بعينه. كذلك لا ينبغي نسب بنية MASQUE كلها إلى شخص واحد. شارك Lucas Pardue في تأليف RFC 9297 معه، ولـRFC 9484 خمسة مؤلفين، وهو يوسع العائلة إلى تمرير IP ويحدث تسجيل URI المعروف masque. أما مجموعة MASQUE فهي عمل IETF جماعي.

المساهمة المقصودة هنا أدق: كتب Schinazi حدود ما يستطيع وكيل CONNECT-UDP إثباته. لم يحوّل اسم الهدف في الطلب إلى سلطة تمنح الوكيل يقيناً عن حالة الهدف.

يلتقي ذلك مع Running-Code Primacy لدى Heng Lu: لا ينال النظام سلطة أوسع من الوظيفة الحتمية التي ينفذها. ويضيف Minimum Initial Specification أن الطبقة المشتركة ينبغي أن تظل صغيرة؛ فالنفق يوفر قابلية التشغيل البيني، بينما تبقى المصادقة والإقرار والنتيجة عند التطبيق الذي يعرف معناها.

سلسلة شهادات لا شهادة واحدة مطاطية

تبدأ السلسلة بالتفويض. يسجل الوكيل هوية العميل أو فئة صلاحياته، والهدف، وإصدار السياسة، وحدود المعدل والحجم، والقرار. هذا مهم لأن الهدف يرى عادة عنوان الوكيل، وقد يسمح نفق غير مقيد بإسناد الإساءة إلى الوكيل أو الوصول إلى loopback وlink-local وmulticast وbroadcast.

بعده يأتي إيصال DNS، ثم إيصال المقبس الذي يحتوي عنوان الخروج، ونمط الاتصال، وخماسية النظير، ومسار الطلب وسبب الإغلاق.

الإيصال الرابع لحركة الرزم: عدد وبايتات كل اتجاه، أول وآخر رزمة، الإسقاط بسبب الحجم أو المصدر أو Context ID أو حدود التخزين، وأخطاء النظام. ولا يلزم حفظ الحمولة الحساسة لإثبات الحركة.

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

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

الصدق التشغيلي أقوى من ضوء أخضر واحد

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

لا يحتاج RFC 9298 إلى توسيع معنى النجاح كي يكون مفيداً. الوكيل يشهد لاستعداده، والمحلل لنتيجته، ونظام التشغيل للمقبس، والعدادات للحركة، والتطبيق للهوية والنتيجة.

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

المصادر