الخلاصة

  • أنشأ UDP ASSOCIATE حالة الترحيل عبر اتصال TCP أتم تفاوض الطريقة، وأنهى تلك الحالة عند انتهاء اتصال التحكم؛ منح التدفق عمراً للسياق ولم ينقل بيانات UDP أو يضمنها.
  • كان عنوان المُرحِّل المعاد، وعنوان مصدر العميل، ووجهة كل رزمة، وطريقة الحماية، وحالة التجميع أقوالاً مستقلة. لم يكن أي منها إثباتاً كافياً للمستخدم أو المستلم النهائي أو الأثر.

لم تكن الحركة الجارية إذناً بالتجديد

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

لكن RFC 1928، الصادر في مارس 1996، اختار حداً أدق: ينتهي ارتباط UDP عندما ينتهي اتصال TCP الذي وصل عبره طلب UDP ASSOCIATE. معرفة منفذ الترحيل والقدرة على إرسال رزمة إليه تدلان على نشاط، لا على استمرار السياق الذي اختبر الطريقة والسياسة.

لم تمر الحمولات داخل TCP. بقيت UDP رُزماً منفصلة يمكن أن تضيع أو تتكرر أو تصل بغير ترتيب. حمل TCP اختيار طريقة المصادقة وطلب إنشاء الارتباط، ثم وفّر بقاؤه واقعة محلية يمكن للخادم ملاحظتها.

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

الصفر كان نقص معلومة لا غياب سياسة

قبل طلب الترحيل، عرض العميل طرقه عبر TCP، واختار الخادم واحدة، وأتم الطرفان التفاوض الفرعي الخاص بها. بعدها فقط أمكن إرسال CONNECT أو BIND أو UDP ASSOCIATE.

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

لم تعنِ الأصفار «اقبل أي مصدر». كانت تصريحاً بأن الطلب نفسه لا يملك قيمة محددة. بقي على الخادم استنتاج المصدر الفعلي من الاتصال والملاحظة والسياسة المحلية.

أعاد نجاح الطلب BND.ADDR وBND.PORT: نقطة UDP التي يجب أن يرسل العميل إليها أغلفة SOCKS. وقد يختار خادم متعدد الواجهات عنواناً غير عنوان اتصال TCP. لذا كانت القيمة مدخل المُرحِّل، لا هوية المضيف البعيد.

كان هناك إذن ثلاثة مواضع مختلفة: عنوان خادم التحكم، وعنوان إدخال UDP الذي خصصه الخادم، والوجهة المدرجة في كل رزمة. جمعها في خانة «عنوان البروكسي» يمحو سبب الفشل.

احتفظت كل رزمة بوجهتها

حمل غلاف UDP حقلي reserved، وحقل FRAG، ونوع العنوان، وعنوان الوجهة، ومنفذها، ثم البيانات. لم يربط الارتباط العميل بمقصد واحد؛ بل أتاح له تقديم قرار ترحيل جديد مع كل رزمة.

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

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

ولا يتحول BND.ADDR إلى قدرة دائمة. بعد موت TCP قد تبقى القيمة في ذاكرة العميل، لكن إرسال غلاف صحيح نحو العنوان القديم لا يعيد إنشاء الارتباط. بقاء المعلومة لا يعني بقاء الإذن.

قيد عنوان المصدر لم يكن هوية

ألزم RFC 1928 مُرحِّل UDP بالحصول من خادم SOCKS على عنوان IP المتوقع للعميل، وبإسقاط أي رزمة تأتي من عنوان آخر بصمت. يمنع ذلك مضيفاً مختلفاً من حقن رزم بسهولة في سياق أنشأه غيره.

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

المصادقة جاءت من الطريقة المختارة. عرّف RFC 1929 طريقة اسم المستخدم وكلمة المرور، لكنه نقل الاعتمادات بنص واضح داخل تفاوضه وحذر من استخدامها في بيئة قابلة للتنصت. أما RFC 1961 فعرّف GSS-API، مع إمكانية التفاوض على سلامة الرسائل وسريتها الاختيارية إلى جانب المصادقة.

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

كانت ذاكرة FRAG اختيارية وقابلة للمحو

في غلاف SOCKS تعني FRAG=0 أن الرزمة مستقلة. وتشير القيم من 1 إلى 127 إلى ترتيب الجزء، بينما تشير البتة العليا إلى النهاية. ليست هذه تجزئة IP، بل ترتيب داخل بروتوكول المُرحِّل.

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

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

ولهذا يجب فصل أسباب الغياب: مصدر غير مطابق، FRAG غير مدعوم، رجوع في الترتيب، انتهاء timer، رفض سياسة، أو ضياع بعد الخروج. عداد واحد باسم «فشل UDP» لا يحدد صاحب الإصلاح.

اختار المعيار الإلغاء بدلاً من التخمين

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

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

لهذا الاختيار ثمن: قد يقطع عطل TCP قصيراً مسار UDP سليماً، ويجعل التنقل يغير التحكم والمصدر معاً، ويستهلك socket إضافياً. غير أن الحد قابل للاختبار والاستعادة. أما مُرحِّل يتيم تطيل الرزم عمره فأسهل لحظياً وأصعب مساءلة.

لم تصبح بوابة IPv6/IPv4 موجهاً

وصف RFC 3089، وهو مستند Informational من 2001، بوابة قائمة على SOCKS بين IPv6 وIPv4. أنهت الاتصالات في طبقة التطبيق على الجانبين، وأمكنها تفويض حل DNS إلى عقدة dual-stack حين لا يستطيع التطبيق القديم تخزين عنوان IPv6.

ورثت البوابة أوامر SOCKS بما فيها UDP ASSOCIATE، لكنها لم تتحول إلى توجيه IP شفاف. ظل الاسم المطلوب، ونتيجة الحل، وارتباط التحكم، والبيانات المرحلة أشياء مختلفة.

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

المصادر