لماذا تتوقف قوائم FTP عن العمل خلف بوابة VPN تُجري NAT
نجاح تسجيل الدخول وPWD بينما يتعطل LIST وRETR عندما تعيد NAT كتابة الترويسات فقط. اعرف أين يجب أن يستقر مساعد FTP وكيف تصلح الوضع السلبي.
تسجيل الدخول يعمل، وPWD يعمل، ثم يتعلق LIST حتى ييأس العميل أو ينتقل إلى نمط بيانات آخر. هذا الانفصال هو البصمة: اتصال التحكم إلى المنفذ 21 سليم، بينما اتصال البيانات يُبنى من عنوان أو منفذ لا يستطيع الطرف الآخر الوصول إليه. خلف بوابة VPN تؤدي أيضاً وظيفة NAT، يكون السبب المعتاد أمر FTP يحمل في حمولته عنوان نفق مثل 10.8.0.6. ترجمة الترويسات لا تلمس تلك القيمة أبداً.
ما يأتي هو من أين تأتي تلك القيمة، وأي جهاز يُسمح له بتغييرها.
ما ينكسر هو الحمولة، لا النفق
يضع FTP نقطة نهاية البيانات داخل تدفق التحكم. في النمط النشط يرسل العميل أمر PORT بعنوانه ومنفذه، ويعاود الخادم الاتصال بذلك الثنائي. في النمط السلبي يجيب الخادم بـ 227 مع ثنائي، ويتصل العميل بذلك بدلاً منه.
يحمل الشكلان العبارة نفسها: اتصل بهذا العنوان على هذا المنفذ. الجهاز الذي يعيد كتابة ترويسات IP وTCP فقط يترك العبارة كما هي، فيظل أحد الطرفين يحاول الوصول إلى عنوان لا وجود له إلا على الجانب الآخر من نفق. يتعطل اتصال البيانات بعد أن يكون اتصال التحكم قد أُعلن سليماً بالفعل.
ثلاثة أنماط، ثلاث حمولات
يبين الجدول أدناه أي جانب يُطلب منه الاتصال، وما يمكن لـ NAT يترجم الترويسات فقط أن يفعله حيال ذلك.
اقرأ العمود الأخير على أنه الشيء الذي يفشل أولاً. في النمط النشط يكون الخادم هو من يتصل بعنوان خاص؛ وفي النمط السلبي يكون العميل؛ وفي FTPS تكون الحمولة نصاً مشفراً ولا يجد الوسيط ما يعمل عليه أقل من ذلك.
| Mode | Value in the control stream | Who dials whom | Header-only NAT leaves |
|---|---|---|---|
| Active (PORT) | client address and port | server dials the client | a server dialing an unreachable tunnel address |
| Passive (227) | server address and port | client dials the server | a client dialing an address it cannot route to |
| FTPS | the same values, inside TLS | as above | ciphertext, so no rewrite happens at all |
ضع المساعد حيث تحدث الترجمة
على لينكس يتولى مساعد nf_conntrack_ftp إعادة كتابة الحمولة. يراقب اتصال التحكم، ويتعلم المنفذ الذي تم التفاوض عليه، وينشئ توقعاً لتدفق البيانات، وعلى جهاز NAT يعيد كتابة العنوان والمنفذ داخل الحمولة. وهو لا يفيد إلا على الجهاز الذي يترجم عنوان العميل. تحميله على العميل، أو على موجّه يمرر التدفق فقط، لا يغير شيئاً في الجلسة.
تُظهر هذه الأوامر الثلاثة هل الوحدة موجودة، وهل هي مرتبطة، وهل يوجد توقع أثناء فتح جلسة:
modprobe nf_conntrack_ftp
lsmod | grep nf_conntrack_ftp
conntrack -L expect | grep ftpتحميل الوحدة ليس مثل ربطها. نوى لينكس من 4.7 فصاعداً تأتي مع net.netfilter.nf_conntrack_helper=0، لذا ينتظر المساعد قاعدة صريحة، مثلاً iptables -t raw -A PREROUTING -p tcp --dport 21 -j CT --helper ftp. إذا بقيت قائمة التوقعات فارغة أثناء محاولة نقل، فالربط هو ما يجب فحصه، لا الوحدة.
النمط السلبي: أخبر الخادم بما يجب أن يعلنه
النمط السلبي أسهل في جعله حتمياً لأن الخادم يمكن أن يُخبر بما يضعه في رد 227. في vsftpd هذا هو pasv_address، مع pasv_min_port وpasv_max_port؛ ويستخدم ProFTPD كلاً من MasqueradeAddress وPassivePorts. اضبط هذه أولاً، لأن العنوان المعلن الصحيح يزيل الحاجة إلى إعادة كتابة أي شيء على ذلك الجانب.
ثم اسمح لنطاق المنافذ ذلك بالمرور عبر البوابة، مثلاً -A FORWARD -i tun0 -p tcp --dport 30000:30100 -j ACCEPT، حتى تطابق القاعدة ما يعلنه الخادم.
يجب أن يتفق الإعدادان. خادم يُطلب منه إعلان 30000-30100 بينما تسمح البوابة بـ 40000-40100 يفشل بأقل طريقة مفيدة: تبدو محادثة التحكم سليمة ويموت كل اتصال بيانات. قارن الأرقام قبل تنقيح أي شيء آخر.
بصمتان للفشل، وما يزيله FTPS
التعلق عند LIST يشير إلى أول اتصال بيانات في الجلسة، وهو الموضع الذي يجب أن تعمل فيه إعادة كتابة العنوان والتوقع معاً. التعلق عند RETR بعد LIST ناجح يشير إلى النقل نفسه، أي نطاق النمط السلبي أو وحدة MTU للنفق. تلك البصمة الثانية ليست مشكلة حمولة، ولن تصلحها إعدادات المساعد.
يزيل FTP عبر TLS الحمولة التي يقرأها المساعد. لا يستطيع الوسيط إعادة كتابة قيمة PORT أو PASV لا يستطيع فك تشفيرها، لذا تبقى الخيارات: وكيل ينهي TLS، أو خادم يعلن عنواناً يمكن الوصول إليه ضمن نطاق محدود، أو بروتوكول نقل آخر.
ترتيب قصير للفحوص
اعمل من العَرَض إلى الخارج. تأكد أن LIST يفشل بينما ينجح PWD، والتقط العنوان داخل حمولة PORT أو 227، واسأل أي جهاز يترجم ذلك العنوان. اربط المساعد هناك، وراقب قائمة التوقعات خلال نقل واحد، ثم أصلح النمط السلبي على الخادم وطابق النطاق في قاعدة البوابة.
أبقِ عطل مسار البيانات منفصلاً عن عطل النقل الكمي، لأنهما يقودانك إلى إعدادات مختلفة.