لماذا ينجح تسجيل FTP وتتوقف قائمة المجلدات؟

لماذا يسجّل FTP الدخول، لكن تتعطل قائمة المجلدات

يتعطل الوضع النشط في FTP خلف جدار ناري لأن FTP يستخدم اتصالين عبر TCP، وليس اتصالاً واحداً. ينقل الاتصال إلى المنفذ 21 بيانات تسجيل الدخول والأوامر، لذلك يُقبل اسم المستخدم وكلمة المرور ويبدو إعداد الجدار الناري صحيحاً. لكن ls يحتاج بعد ذلك إلى اتصال ثانٍ عبر منفذ مختلف. لا تسمح قواعد الجدار الناري بهذا الاتصال، لذلك ينتظر العميل حتى تنتهي مهلة الاتصال.

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

قناة التحكم وقناة البيانات

يُحدَّد بروتوكول FTP (بروتوكول نقل الملفات) في RFC 959، وقد ظهر قبل كلٍّ من NAT وجدار الحماية ذي الحالة. تفتح الجلسة اتصال تحكم واحداً بمنفذ TCP 21، وتبقيه مفتوحاً طوال الجلسة. تُرسل الأوامر كنص عادي. وتعود الردود في صورة رمز من ثلاثة أرقام وسطر من النص. لا ينقل هذا الاتصال محتوى الملفات مطلقاً.

يحصل كل عنصر من عناصر البيانات على اتصال TCP مستقل: اتصال واحد لعرض محتويات الدليل (LIST)، واتصال لكل عملية تنزيل (RETR)، واتصال لكل عملية رفع (STOR). يُفتح الاتصال، ويُستخدم مرة واحدة، ثم يُغلق. تحدث المصادقة بالكامل عبر قناة التحكم، لذلك يظهر تعطل مسار البيانات دائماً بالطريقة نفسها: تسجيل دخول ناجح، ثم توقف. إذا طبع العميل رد 230 ثم توقف عند عرض القائمة، فأنت تتعامل مع قناة البيانات، لا مع بيانات الاعتماد.

الوضع النشط: يتصل الخادم مجدداً بالعميل

في الوضع النشط، يختار العميل منفذاً ويستمع عليه، ثم يخبر الخادم بالمنفذ الذي يجب أن يتصل به:

PORT 192,168,1,50,195,80

الأرقام الأربعة الأولى هي عنوان IP الخاص بالعميل. أما الرقمان الأخيران فهما المنفذ، بترميزه على شكل بايتين: 195 * 256 + 80 = 50000. بعد ذلك يفتح الخادم اتصال البيانات من المنفذ 20 الخاص به إلى المنفذ 50000 على العميل.

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

الوضع السلبي: يفتح العميل كلا الاتصالين

يعكس الوضع السلبي اتجاه اتصال البيانات. يرسل العميل PASV، ويرد الخادم بعنوان ومنفذ خاصين به:

227 Entering Passive Mode (203,0,113,10,195,80)

الترميز هو نفسه، لذلك يتصل العميل بالعنوان 203.0.113.10 على المنفذ 50000. يفتح العميل الآن كلا الاتصالين، ولذلك يستمر الوضع السلبي في العمل عبر NAT من جهة العميل، ولأن كل عميل حالي يطلبه أولاً.

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

EPSV (الوضع السلبي الممتد، RFC 2428) هو الفكرة نفسها، لكن مع استجابة أبسط:

229 Entering Extended Passive Mode (|||50000|)

لا يحتوي على عنوان. يعيد العميل استخدام العنوان الذي لديه مسبقاً لاتصال التحكم، وهذا ما يجعله يعمل عبر IPv6 ويزيل فئة كاملة من أخطاء NAT. يذكر دليل curl أن curl يحاول عادةً EPSV قبل PASV. يظل المنفذ يُختار أثناء التشغيل، لذلك لا يغيّر EPSV شيئاً في قواعد الجدار الناري لديك.

لماذا لا يمكن لقاعدة جدار ناري عادية السماح بقناة البيانات

لأن رقم المنفذ لا يكون موجوداً بعد عند كتابة القاعدة. يختار الخادم المنفذ لكل عملية نقل. عند ترك إعداداته الافتراضية، يوثّق vsftpd pasv_min_port وpasv_max_port على أنهما 0، أي «استخدم أي منفذ»، ولذلك يمكن أن يصل اتصال البيانات عبر أي منفذ أعلى من 1023. يسمح sudo ufw allow 21/tcp بقناة التحكم ولا يسمح بأي شيء آخر، وهذا هو تحديداً الإعداد الذي ينتج عنه تسجيل دخول ناجح وقائمة ملفات لا تُحمَّل. إذا كانت فكرة استماع خدمة على منفذ ثابت واحد لا تزال غير واضحة، فراجع كيفية عمل المنافذ ومقابس الاستماع في Linux لفهم الخلفية.

يتتبع جدار ناري يعتمد على الحالة الاتصالات فعلاً، ويمكن للنواة قبول اتصال جديد باعتباره RELATED لاتصال قائم. لكن ذلك يتطلب في FTP وجود مكوّن يقرأ دفق التحكم ويستخرج المنفذ من سطر 227 أو PORT. لا ينفذ أي مكوّن ذلك افتراضياً.

لماذا لم يعد مساعد تتبّع اتصال FTP هو الحل

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

تعيين المساعد تلقائياً معطّل. توثّق النواة متغيّر nf_conntrack_helper بالقيمة "0 - disabled (default)"، وتضيف: "If disabled it is required to set up iptables rules to assign helpers to connections." لا يحقق تحميل الوحدة أي نتيجة بمفرده.

في النوى الحالية، أُزيل مفتاح التبديل. شغّل sysctl net.netfilter.nf_conntrack_helper. تعني استجابة sysctl: cannot stat /proc/sys/net/netfilter/nf_conntrack_helper: No such file or directory أن النواة لم تعد تحتوي على تعيين تلقائي للمساعد يمكن تفعيله. إذا أعاد الأمر رقماً بدلاً من ذلك، فلا يزال مفتاح التبديل موجوداً، وقيمته الافتراضية هي 0.

كما أوقفت واجهات الجدار الناري الأمامية دعمها. يذكر man ufw-framework في Ubuntu 24.04، بشأن السطر IPT_MODULES في /etc/default/ufw، ما يلي: "Unconditional loading of connection tracking modules (nf_conntrack_*) in this manner is deprecated"، ويضيف أن قواعد المساعد "must be managed in via the RULES FILES". يوثّق firewalld الخيار AutomaticHelpers في firewalld.conf بالعبارة التالية: "Deprecated. This option is ignored and no longer used." يعني إسناد مساعد الآن كتابة قاعدة صريحة يدوياً باستخدام الهدف CT، وهذا يتطلب عملاً أكثر من الإصلاح أدناه، كما يتوقف عن العمل فور تفعيل TLS. يوضح iptables وnftables على Ubuntu موضع هذه القواعد فعلياً.

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

صرّح بنطاق المنافذ السلبية على الخادم

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

في vsftpd، داخل /etc/vsftpd.conf:

pasv_enable=YES
pasv_min_port=30000
pasv_max_port=30099

يكون pasv_enable مضبوطاً افتراضياً على YES. وتكون قيمتا خياري المنافذ افتراضياً 0، أي سلوك «استخدام أي منفذ» الموضح أعلاه. طبّق التغيير باستخدام sudo systemctl restart vsftpd، ثم تأكد من عودة الخدمة إلى العمل باستخدام systemctl status vsftpd. يرفض vsftpd بدء التشغيل عند وجود سطر إعداد لا يمكنه تحليله، بدلاً من تجاهله. لذلك، إذا فشلت إعادة التشغيل، اقرأ journalctl -u vsftpd -n 20 للعثور على السطر 500 OOPS: الذي يذكر الخيار الذي أدخلته للتو.

في ProFTPD، داخل proftpd.conf:

PassivePorts 30000 30099

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

يستخدم Pure-FTPd الراية -p first:last، الموثقة في man pure-ftpd بالنص التالي: «استخدم فقط المنافذ الواقعة ضمن النطاق من الأول إلى الأخير، مع شمول الطرفين، لتنزيلات الوضع السلبي». ويؤدي ذلك إلى «جعل pure-ftpd أكثر توافقاً مع مرشحات الحزم». عادةً ما تضع الحزم المجمّعة هذه الراية داخل ملف إعداد، لذلك راجع وثائق توزيعتك لمعرفة اسم الملف بدلاً من التخمين.

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

أين يجب وضع النطاق؟ شغّل sysctl net.ipv4.ip_local_port_range أولاً. في Ubuntu بالإعدادات الافتراضية، يعرض الأمر 32768 60999، أي المنافذ التي تمنحها النواة للاتصالات الصادرة. يمكن أن يتعارض نطاق سلبي يقع داخل هذه النافذة مع اتصال صادر يحتفظ بالمنفذ بالفعل، لذلك أبقِ النطاق أسفلها. ويكون النطاق من 30000 إلى 30099 متاحاً في الخادم ذي الإعدادات الافتراضية. افحص خادمك بدلاً من الاعتماد على هذه القيمة.

افتح النطاق نفسه في جدار الحماية

يكتب ufw النطاق باستخدام نقطتين، وينص دليله على أنه «يمكن أيضاً استخدام نطاق أو قائمة لتحديد منافذ متعددة، وفي هذه الحالة يكون البروتوكول مطلوباً»:

sudo ufw allow 21/tcp
sudo ufw allow 30000:30099/tcp
sudo ufw status verbose

يجب أن يعرض ufw status verbose الإدخالين الآن. يرفض ufw الأمر نفسه من دون /tcp مع رسالة خطأ تطلب تحديد tcp أو udp، لأن ufw لا يخمّن البروتوكول. يشرح صيغة قواعد ufw على VPS بقية التفاصيل.

يكتب firewalld النطاق باستخدام شرطة، ويحتاج إلى إعادة تحميل:

sudo firewall-cmd --permanent --add-service=ftp
sudo firewall-cmd --permanent --add-port=30000-30099/tcp
sudo firewall-cmd --reload
sudo firewall-cmd --list-all

يفتح --add-service=ftp المنفذ 21/tcp ويطلب مساعد ftp الذي يحدده تعريف الخدمة المضمّن. لكنه لا يفتح نطاق المنافذ السلبية، ولذلك لا يغيّر هذا الأمر وحده الوضع الذي بدأت منه. يشرح مناطق وخدمات firewalld على VPS الصورة الأوسع.

استخدام nftables مباشرةً، داخل input chain:

tcp dport { 21, 30000-30099 } accept

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

أخبر الخادم بعنوانه العام عندما يكون خلف NAT

نفّذ ip -4 addr show على الخادم. إذا كان العنوان على الواجهة هو العنوان الذي يتصل به العملاء، فتجاوز هذا القسم. إذا كانت الواجهة تحتوي على عنوان خاص (10.x، أو 172.16 إلى 172.31.x، أو 192.168.x) وكانت المنصة تربط به عنواناً عاماً، فلن يعرف الخادم عنوانه العام. يوضّح توثيق vsftpd أن الإعداد الافتراضي لـ pasv_address هو «يُؤخذ العنوان من المقبس المتصل الوارد»، لذلك تحمل استجابة 227 العنوان الخاص، ويُرسَل العميل إلى عنوان لا يمكنه الوصول إليه.

يسمّي FileZilla هذه الحالة بالاسم التالي:

Server sent passive reply with unroutable address. Using server address instead.

يصحّح FileZilla المشكلة ويتابع العمل. لكن العديد من العملاء الآخرين لا يفعلون ذلك. إذ يتصلون بـ 10.0.0.5 ويتوقفون عن الاستجابة.

يخفي curl المشكلة أيضاً، وهذا مهم إذا كنت تستخدم curl للاختبار. يذكر الدليل الخاص به أن --ftp-skip-pasv-ip «مفعّل افتراضياً (أُضيف في 7.74.0)»، لذلك يتجاهل curl العنوان الموجود في استجابة 227 ويعيد استخدام عنوان اتصال التحكم. قد تنجح عملية النقل باستخدام curl، لكنها تفشل في عميل رسومي لهذا السبب وحده.

اضبط العنوان صراحةً. يقبل vsftpd pasv_address=203.0.113.10، إضافةً إلى pasv_addr_resolve=YES (الافتراضي NO) إذا كنت تفضّل كتابة اسم مضيف. ويقبل ProFTPD MasqueradeAddress، الذي يدعم عنواناً أو اسم DNS أو اسم واجهة. ويقبل Pure-FTPd -P، وقد وُثّق هذا الخيار للحالة التي «يكون فيها الخادم خلف جهاز masquerading (NAT)». يتجنب EPSV المشكلة بأكملها لأن استجابته لا تحتوي على حقل عنوان، لكن لا يمكنك الاعتماد على ذلك، لأن العميل هو الذي يقرر الأمر الذي سيرسله.

ما الذي يتغير مع TLS

FTPS هو بروتوكول FTP عبر TLS (أمان طبقة النقل). يتصل العميل بالمنفذ 21 كالمعتاد، ويرسل AUTH TLS لتأمين قناة التحكم، ثم يرسل PROT P لتشفير قناة البيانات أيضاً. يرسل FTP العادي كلمة المرور عبر الشبكة كنص قابل للقراءة، لذلك إذا اضطررت إلى الإبقاء على FTP، فاستخدم FTPS. يأتي vsftpd مع ssl_enable مضبوطاً افتراضياً على NO.

ينتج عن ذلك أمران. لا يمكن لأي مساعد لتتبّع الاتصالات أن يعمل، وهذه هي النقطة السابقة من الجانب الآخر. كما أن sudo tcpdump -nAi any 'tcp port 21' لن يعرض لك رد 227 بعد الآن. لذلك، عندما تحتاج إلى معرفة العنوان والمنفذ اللذين أعلنهما الخادم، اقرأ سجل الخادم نفسه بدلاً من قراءة حركة الشبكة.

الاختبار من خارج الخادم

نفّذ هذه الأوامر من جهاز آخر. يؤدي الاختبار من الخادم نفسه إلى تجاوز الجدار الناري الذي تحاول إصلاحه.

sudo ss -ltnp | grep :21
curl -v --disable-epsv --user ftpuser:secret ftp://example.com/
nc -vz example.com 30000

يجب أن يعرض ss خدمة FTP daemon وهي تستمع على المنفذ 21. لا تستمع أي خدمة على نطاق المنافذ السلبية عندما يكون الخادم خاملاً، لأن هذه المقابس تُنشأ لعملية نقل ثم تُغلق بعدها.

يفرض --disable-epsv على curl استخدام مسار PASV، وهو المسار الذي يكشف مشكلة العنوان. يطبع التتبع رد الخادم، ثم العنوان والمنفذ اللذين يتصل بهما curl:

< 227 Entering Passive Mode (203,0,113,10,117,52)

117 * 256 + 52 = 30004، وهو ضمن النطاق المعلن. يعني ظهور عنوان خاص في ذلك السطر أن pasv_address غير مضبوط. ويعني ظهور منفذ خارج نطاقك أن الخادم لم يقرأ تغيير الإعدادات قط، لذا تحقق من أنك عدّلت الملف الذي تستخدمه الخدمة قيد التشغيل.

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

هل لا تزال بحاجة إلى تشغيل FTP؟

بالنسبة إلى الأعمال الجديدة، لا. يعمل SFTP (بروتوكول نقل الملفات عبر SSH) داخل اتصال SSH واحد على المنفذ 22. لا توجد قناة ثانية، ولا نطاق passive، ولا إعدادات NAT، ولا daemon إضافي لتأمينه، لأن OpenSSH يوفّر ذلك بالفعل. يعمل sftp user@example.com على خادم لم تُعدّ عليه خدمة لنقل الملفات مطلقاً. لمنح شخص ما ملفات دون أي شيء آخر، يستخدم sshd_config ForceCommand internal-sftp مع ChrootDirectory. يجب أن يكون ذلك الدليل مملوكاً للحساب root، وألا يكون قابلاً للكتابة من المستخدم، وإلا يرفض sshd الجلسة ويسجّل سطراً يتضمن bad ownership or modes for chroot directory.

يظل FTP مناسباً عندما يتعذر تغيير الطرف الآخر. تصل أجهزة المسح الضوئي والطابعات متعددة الوظائف ببرامج ثابتة لا تتحدث إلا FTP. وغالباً ما تعمل المعدات المخبرية والصناعية بصورة ثابتة لن يعيد أحد اعتمادها. ينشر الشركاء التجاريون نقطة إسقاط عبر FTPS ولا يضيفون بروتوكولاً من أجل مورّد واحد. في كل حالة من هذه الحالات، يكون إعداد نطاق passive وقاعدة الجدار الناري المطابقة هو العمل كله، ويكون FTPS، لا FTP العادي، هو الإصدار الذي ينبغي تشغيله. تصميم القناتين قرار يعود إلى عام 1985، ويُستخدم الآن في بيئة لم يتوقعها، وهي قصة يتناولها تاريخ بروتوكولات نقل الملفات.

FAQ

لماذا يسجّل FTP الدخول لكن تتعطل قائمة الأدلة؟

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

ما المنافذ التي أحتاج إلى فتحها لاستخدام الوضع السلبي في FTP؟

المنفذ 21 لقناة التحكم، إضافة إلى النطاق الذي ضبطته لاتصالات البيانات السلبية. لا يوجد نطاق قياسي، لأنك تختاره بنفسك. يعمل نطاق مثل 30000 إلى 30099: اضبط حجمه وفقاً لأقصى عدد متوقع من عمليات النقل المتزامنة، وتأكد من عدم تعارضه مع نطاق المنافذ الصادرة للنواة، الذي يمكنك قراءته باستخدام sysctl net.ipv4.ip_local_port_range. إذا كان مزود الخدمة يشغّل جدار حماية للشبكة في لوحة التحكم الخاصة به، فافتح النطاق نفسه هناك أيضاً.

هل ما زلت بحاجة إلى nf_conntrack_ftp؟

لا، ولا يمكنك الاعتماد عليه في نواة حديثة. يكون التعيين التلقائي للمساعدات معطلاً افتراضياً، وفي النوى الحديثة أزيل مفتاح net.netfilter.nf_conntrack_helper، لذلك يعرض sysctl أن الملف غير موجود. يصف الدليل اليدوي لـufw التحميل غير المشروط لهذه الوحدات بأنه مهجور، ويتجاهل firewalld AutomaticHelpers تماماً. يجب على المساعد أيضاً قراءة قناة التحكم كنص عادي، لذلك يتوقف عن العمل فور تمكين FTPS. حدّد نطاقاً للمنافذ السلبية بدلاً من ذلك.

لماذا يقول عميل FTP إن رد الوضع السلبي يحتوي على عنوان غير قابل للتوجيه؟

أجاب الخادم على PASV بالعنوان الذي يراه على واجهته الخاصة، وهذا العنوان خاص. يحدث ذلك عندما تعيّن المنصة عنواناً عاماً إلى عنوان خاص. اضبط العنوان العام صراحةً: pasv_address في vsftpd، أو MasqueradeAddress في ProFTPD، أو -P في Pure-FTPd. يتجاوز FileZilla المشكلة بإعادة استخدام العنوان الذي اتصل به مسبقاً، ويسجّل "Using server address instead"، ولذلك تتجاوز بعض العملاء سوء الإعداد بينما تتعطل عملاء أخرى.

هل أستخدم FTPS أم SFTP؟

استخدم SFTP لأي شيء تتحكم فيه من الطرفين: اتصال واحد عبر SSH على المنفذ 22، ولا توجد قناة بيانات تحتاج إلى فتحها، وهو يعمل لديك بالفعل. FTPS هو FTP عبر TLS، لذلك يحتفظ بتصميم القناتين وبكل مشكلات جدار الحماية المرتبطة به. اختره عندما لا يدعم الطرف الآخر أي خيار سواه. لا تستخدم FTP العادي عبر الإنترنت، لأن كلمة المرور تنتقل عبر الشبكة كنص قابل للقراءة.