Summary

  • كان FTP يتفاوض على الأوامر عبر اتصال تحكم وينقل الملفات عبر اتصال بيانات منفصل.
  • أعاد RFC 1579 استخدام PASV لتغيير الجهة التي تبدأ الاتصال الثاني: سهّل المرور عبر مرشح جهة العميل، لكنه ألزم الخادم بقبول اتصالات واردة على منافذ البيانات.

قد تقول جلسة FTP «أرسل هذا الملف» من دون أن يمر الملف في اتصال الأمر نفسه. كان هذا الفصل جزءاً من تصميم البروتوكول. وله نتيجة عملية: نجاح تسجيل الدخول والحصول على رد إيجابي على RETR لا يضمن وصول البيانات؛ إذ لا يزال على FTP إنشاء اتصال TCP ثانٍ في الاتجاه الذي يحدده.

فصل RFC 959، المنشور عام 1985، بين عملية التحكم التي تتعامل مع الأوامر والردود وعمليات البيانات التي تنفذ النقل. في الترتيب المعتاد، يفتح العميل اتصال التحكم إلى الخادم، غالباً على المنفذ 21. وقبل النقل، يمكنه إرسال PORT لإبلاغ الخادم بعنوانه والمنفذ الذي سيستمع عليه. عندئذ يبدأ الخادم اتصال البيانات عائداً إلى العميل. ولأن مقبس البيانات منفصل عن قناة الأوامر، فإن الجدار الناري الذي يسمح بالأولى لا يلزم أن يسمح بالثانية.

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

بحلول 1994، لم يكن السلوك العملي يطابق دائماً النموذج الافتراضي الأصلي. كتب Steven Bellovin في RFC 1579 أن العملاء آنذاك كانوا غالباً يفتحون اتصال بيانات جديداً لكل عملية نقل، ويختارون منفذاً جديداً لتفادي انتظار TCP TIME-WAIT، ثم يعلنونه بأمر PORT. ويرى مرشح الحزم في ذلك اتصالاً وارداً إلى منفذ غير متوقع. وكانت الجدران النارية تسمح عادة ببعض الخدمات الواردة وتحجب تلك المكالمات، حتى بعد مصادقة المستخدم عبر اتصال التحكم.

أوصى RFC 1579 مزودي البرامج بتعديل عملاء FTP، بما في ذلك وكلاء Gopher الوسيطة، لاستخدام PASV بدلاً من PORT. وبذلك يصبح اتصال البيانات اتصالاً صادراً من العميل. ويسهل على الجدار الناري لدى المستخدم السماح باتصال بدأه العميل مقارنة بقبول اتصال وارد غير مطلوب إلى منفذ عشوائي. لم تقترح المذكرة تغيير البروتوكول السلكي: فالأمر موجود أصلاً، وكلا النمطين يتطلب تبادلاً تمهيدياً متشابهاً قبل النقل.

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

تساعد الوثائق المعيارية على الفصل بين القدرة المطلوبة والسلوك المنتشر. ألزم RFC 1123، المنشور عام 1989، خوادم FTP بتنفيذ PASV ووضح تفسير الرد، مع الإشارة إلى أن تنسيق الرد لم يكن محدداً جيداً. وذكر RFC 1579 لاحقاً وجود عميلين مستقلين معدلين على الأقل. لا يقيس أي من النصين نسبة المستخدمين أو المواقع التي غيرت نمطها. ما تثبته مذكرة 1994 هو توصية وتنفيذ محدود، لا انتقال شامل.

كان لFTP سطحان تشغيليان. تحمل قناة التحكم بيانات الاعتماد والأوامر والردود؛ وتحمل قناة البيانات قوائم الملفات أو محتواها. والرد «فتح اتصال البيانات» ليس هو الملف، كما أن نجاح المصادقة لا يثبت اكتمال النقل. يتطلب التشخيص تتبع المقبسين وتحديد الطرف الذي يفترض أن يبدأ كل اتصال.

درس RFC 1579 أدق من القول إن «الجدران النارية عطّلت FTP». كان البروتوكول يتيح اختيار اتجاه اتصال البيانات؛ وجعل الترشيح هذا الاختيار ذا أثر تشغيلي. سمح PASV ببدء الاتصال من الجانب الأرجح أن تسمح به سياسة جدار العميل، مقابل أن يدير مشغل الخادم نطاقاً محدوداً من المنافذ الواردة. لم يتغير البروتوكول؛ بل انتقل عبء التشغيل.

Sources