حل مشکل توقف لیست دایرکتوری در FTP Passive Mode

چرا FTP وارد می‌شود اما لیست دایرکتوری متوقف می‌ماند

حالت passive در FTP به دلیل استفاده از دو اتصال TCP (به‌جای یک اتصال) توسط فایروال مسدود می‌شود. اتصال به پورت 21 وظیفه انتقال اطلاعات ورود و دستورات را بر عهده دارد، بنابراین نام کاربری و رمز عبور پذیرفته می‌شوند و فایروال وضعیت را صحیح تشخیص می‌دهد. اولین ls سپس به یک اتصال دوم روی پورتی متفاوت نیاز دارد. هیچ قانونی در فایروال اجازه این کار را نمی‌دهد، بنابراین کلاینت تا زمان اتمام مهلت (timeout) منتظر می‌ماند.

راه حل، تعیین یک محدوده مشخص از پورت‌ها برای این اتصالات داده‌ای و افزودن یک قانون فایروال برای مجاز کردن همان محدوده است. سروری که پشت NAT (ترجمه آدرس شبکه) قرار دارد، به یک تنظیم اضافی نیاز دارد تا آدرس صحیح را اعلام کند. در گذشته، ماژول‌های connection tracking این کار را به‌صورت خودکار انجام می‌دادند. امروزه دیگر این‌طور نیست و دانستن دلیل آن پیش از کپی کردن راهنماهای قدیمی، اهمیت دارد.

کانال کنترل و کانال داده

پروتکل FTP (مخفف file transfer protocol) در RFC 959 تعریف شده و پیش از ظهور NAT و فایروال‌های stateful ایجاد شده است. یک نشست (session) یک اتصال کنترلی به پورت TCP 21 باز می‌کند و آن را برای کل مدت نشست باز نگه می‌دارد. دستورات به‌صورت متن ساده (plain text) ارسال می‌شوند. پاسخ‌ها به‌صورت یک کد سه رقمی و یک خط متن بازگردانده می‌شوند. آن اتصال هرگز محتوای فایل را منتقل نمی‌کند.

هر قطعه داده، اتصال TCP مختص به خود را دارد: یکی برای لیست کردن دایرکتوری (LIST)، یکی برای هر دانلود (RETR) و یکی برای هر آپلود (STOR). این اتصال باز می‌شود، یک‌بار استفاده شده و سپس بسته می‌شود. احراز هویت کاملاً در کانال کنترل انجام می‌شود، بنابراین مسیر دادهٔ معیوب همیشه به یک شکل بروز می‌کند: ورود موفقیت‌آمیز و سپس توقف (hang). اگر کلاینت یک پاسخ 230 چاپ کند و سپس در مرحله لیست کردن متوقف شود، مشکل از کانال داده است و نه اعتبارنامه‌ها.

حالت فعال: سرور به کلاینت متصل می‌شود

در حالت فعال (Active mode)، کلاینت یک پورت را انتخاب کرده، روی آن گوش می‌دهد و به سرور می‌گوید که به کجا متصل شود:

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

چهار عدد اول، آدرس IP کلاینت هستند. دو عدد آخر، پورت را نشان می‌دهند که به صورت دو بایت کدگذاری شده است: 195 * 256 + 80 = 50000. سپس سرور اتصال داده را از پورت 20 خود به پورت 50000 روی کلاینت برقرار می‌کند.

این اتصال از دیدگاه کلاینت، ورودی و ناخواسته است؛ بنابراین فایروال کلاینت آن را مسدود می‌کند. اگر کلاینت پشت یک روتر خانگی باشد، آدرس موجود در دستور PORT یک آدرس خصوصی است که سرور به هیچ وجه نمی‌تواند به آن دسترسی پیدا کند. حالت فعال همان جایی است که FTP شهرت خود را به دلیل کار نکردن به دست آورده است.

حالت Passive: کلاینت هر دو اتصال را برقرار می‌کند

حالت Passive جهت اتصال داده را معکوس می‌کند. کلاینت دستور PASV را ارسال می‌کند و سرور با یک آدرس و پورت اختصاصی پاسخ می‌دهد:

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

کدگذاری مشابه است، بنابراین کلاینت به آدرس 203.0.113.10 روی پورت 50000 متصل می‌شود. اکنون کلاینت هر دو اتصال را برقرار می‌کند؛ به همین دلیل است که حالت Passive از NAT سمت کلاینت عبور می‌کند و هر کلاینت امروزی ابتدا آن را درخواست می‌کند.

مشکل به‌جای حذف شدن، جابه‌جا شده است. اتصال ورودی ناخواسته اکنون به سرور شما می‌رسد، آن هم روی یک پورت بالا که با هر انتقال تغییر می‌کند. این فایروال متعلق به شماست، بنابراین اکنون مشکل نیز متعلق به شماست.

دستور EPSV (حالت Passive توسعه‌یافته، RFC 2428) همان ایده با پاسخی تمیزتر است:

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

در این حالت هیچ آدرسی وجود ندارد. کلاینت از همان آدرسی که برای اتصال کنترل در اختیار دارد استفاده مجدد می‌کند؛ این همان چیزی است که باعث می‌شود پروتکل روی IPv6 کار کند و یک دسته کامل از باگ‌های NAT را حذف می‌کند. راهنمای curl بیان می‌کند که curl معمولاً پیش از PASV، دستور EPSV را امتحان می‌کند. پورت همچنان در زمان اجرا انتخاب می‌شود، بنابراین EPSV هیچ تغییری در قوانین فایروال شما ایجاد نمی‌کند.

چرا یک قانون فایروال معمولی نمی‌تواند کانال داده را مجاز کند

دلیل این است که هنگام نوشتن قانون، شماره پورت هنوز وجود ندارد. سرور این پورت را برای هر انتقال انتخاب می‌کند. در تنظیمات پیش‌فرض، vsftpd در pasv_min_port و pasv_max_port از 0 استفاده می‌کند که به معنای «استفاده از هر پورتی» است؛ بنابراین اتصال داده می‌تواند روی هر پورتی بالاتر از 1023 برقرار شود. sudo ufw allow 21/tcp فقط کانال کنترل را مجاز می‌کند و نه چیز دیگری، و دقیقاً همین پیکربندی است که باعث می‌شود ورود به سیستم موفقیت‌آمیز باشد اما لیست کردن فایل‌ها با شکست مواجه شود. اگر مفهوم سرویسی که روی یک پورت ثابت گوش می‌دهد هنوز برایتان مبهم است، نحوه عملکرد پورت‌ها و سوکت‌های listening در لینوکس پیش‌زمینه لازم برای درک این موضوع است.

یک فایروال stateful اتصالات را ردیابی می‌کند و هسته سیستم‌عامل می‌تواند یک اتصال جدید را به عنوان RELATED برای یک اتصال موجود بپذیرد. برای FTP، این کار مستلزم آن است که چیزی جریان کنترل را بخواند و شماره پورت را از یک خط 227 یا PORT استخراج کند. به‌صورت پیش‌فرض، هیچ ابزاری این کار را انجام نمی‌دهد.

چرا helper مربوط به ردیابی اتصال FTP دیگر راه‌حل مناسبی نیست

ماژول هسته nf_conntrack_ftp همان چیزی است که راهنماهای قدیمی به آن اشاره می‌کنند. این ماژول کانال کنترل متن‌ساده (plaintext) را می‌خواند، پورت اعلام‌شده را پیدا می‌کند و یک expectation ثبت می‌کند تا اتصال داده بدون نیاز به قانونی که نام پورت آن را ذکر کند، پذیرفته شود. از زمانی که آن راهنماها نوشته شده‌اند، چهار مورد تغییر کرده است.

تخصیص خودکار helper غیرفعال است. مستندات هسته، sysctl مربوط به nf_conntrack_helper را به عنوان "0 - غیرفعال (پیش‌فرض)" معرفی کرده و اضافه می‌کند: "در صورت غیرفعال بودن، لازم است قوانین iptables برای تخصیص helperها به اتصالات تنظیم شود." بارگذاری ماژول به تنهایی هیچ کاری انجام نمی‌دهد.

در هسته‌های فعلی، این سوئیچ حذف شده است. دستور sysctl net.netfilter.nf_conntrack_helper را اجرا کنید. پاسخ sysctl: cannot stat /proc/sys/net/netfilter/nf_conntrack_helper: No such file or directory به این معنی است که هسته دیگر هیچ تخصیص خودکار helper برای فعال‌سازی ندارد. اگر به جای آن عددی دریافت کردید، سوئیچ همچنان وجود دارد و مقدار پیش‌فرض آن 0 است.

رابط‌های کاربری فایروال نیز آن را منسوخ کرده‌اند. man ufw-framework در Ubuntu 24.04 درباره خط IPT_MODULES در /etc/default/ufw می‌گوید: "بارگذاری بی‌قید و شرط ماژول‌های ردیابی اتصال (nf_conntrack_*) به این روش منسوخ شده است" و اضافه می‌کند که قوانین helper "باید از طریق RULES FILES مدیریت شوند". مستندات firewalld، گزینه AutomaticHelpers در firewalld.conf را به عنوان "منسوخ شده. این گزینه نادیده گرفته می‌شود و دیگر استفاده نمی‌شود" معرفی می‌کند. پیوست کردن یک helper اکنون به معنای نوشتن دستی یک قانون صریح با target مربوط به CT است که از راه‌حل زیر پرزحمت‌تر بوده و به محض فعال‌سازی TLS از کار می‌افتد. iptables و nftables در Ubuntu به محل واقعی قرارگیری این قوانین می‌پردازد.

TLS به این بحث پایان می‌دهد. یک helper با خواندن کانال کنترل به صورت متن کار می‌کند. اگر آن کانال را رمزنگاری کنید، helper فقط متن رمزنگاری‌شده (ciphertext) را می‌بیند و نمی‌تواند پورت را پیدا کند. هیچ راه‌حلی برای این موضوع وجود ندارد و نباید هم داشته باشد: یک middlebox که بتواند کانال کنترل شما را بخواند، همان middleboxی است که رمز عبور شما را خوانده است.

تعیین محدوده پورت‌های passive روی سرور

هر سرور FTP می‌تواند طوری تنظیم شود که پورت‌های passive خود را از محدوده‌ای که شما انتخاب می‌کنید، برگزیند. نام گزینه‌ها متفاوت است، بنابراین مستندات سروری که در حال حاضر اجرا می‌کنید را بررسی کنید.

در 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 در اینجا هیچ پیش‌فرضی ندارد: بدون این دستور، هسته سیستم‌عامل پورت را انتخاب می‌کند. مستندات آن همچنین بیان می‌کند که وقتی هیچ پورتی در محدوده انتخابی شما آزاد نباشد، سرور به پورت‌های تخصیص‌یافته توسط هسته بازمی‌گردد و پیامی را لاگ می‌کند. بنابراین، محدوده‌ای که بیش از حد کوچک باشد، به‌جای شکستِ تمیز، گاه‌به‌گاه دچار خطا می‌شود که عیب‌یابی آن بسیار دشوارتر است. از پورت‌های غیرمجاز (non-privileged)، یعنی 1024 و بالاتر استفاده کنید.

Pure-FTPd از یک فلگ به نام -p first:last استفاده می‌کند که در man pure-ftpd به‌عنوان «استفاده از پورت‌ها فقط در محدوده first تا last به‌صورت فراگیر برای دانلودهای حالت passive» مستند شده است؛ این کار «سازگاری pure-ftpd با فیلترهای بسته (packet filters) را افزایش می‌دهد». نسخه‌های بسته‌بندی‌شده معمولاً این فلگ را در یک فایل پیکربندی قرار می‌دهند، بنابراین به‌جای حدس زدن، مستندات توزیع خود را برای یافتن نام فایل بررسی کنید.

به چند پورت نیاز دارید؟ برای هر اتصال داده‌ای که در لحظه برقرار است، یک پورت نیاز دارید. یک پورت TCP بسته، قبل از اینکه بتواند دوباره استفاده شود، برای چند دقیقه در وضعیت TIME_WAIT باقی می‌ماند، بنابراین محدوده‌ای چند برابر اوج مصرف مورد انتظار خود در نظر بگیرید. صد پورت برای چند کاربر کافی است، اما یک سرور عمومی پرتردد به تعداد بسیار بیشتری نیاز دارد.

این محدوده کجا باید قرار بگیرد؟ ابتدا sysctl net.ipv4.ip_local_port_range را اجرا کنید. در یک سیستم Ubuntu استاندارد، این دستور 32768 60999 را نشان می‌دهد که همان پورت‌هایی است که هسته برای اتصالات خروجی اختصاص می‌دهد. یک محدوده passive در داخل این بازه ممکن است با یک اتصال خروجی که قبلاً پورت را اشغال کرده است تداخل پیدا کند، بنابراین محدوده خود را پایین‌تر از آن نگه دارید. بازه 30000 تا 30099 در یک سیستم پیش‌فرض آزاد است. به‌جای اعتماد به این اعداد، سیستم خود را بررسی کنید.

باز کردن همان محدوده در فایروال

ابزار ufw محدوده را با استفاده از دونقطه (colon) می‌نویسد و در راهنمای آن ذکر شده است که برای مشخص کردن چندین پورت می‌توان از محدوده یا لیست استفاده کرد، که در این صورت تعیین پروتکل الزامی است:

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

دستور ufw status verbose اکنون باید هر دو ورودی را فهرست کند. همان دستور بدون /tcp با خطا مواجه می‌شود و از شما می‌خواهد که tcp یا udp را مشخص کنید، زیرا ufw حدس نمی‌زند. بخش سینتکس قوانین ufw روی VPS بقیه موارد را پوشش می‌دهد.

ابزار firewalld محدوده را با خط تیره (hyphen) می‌نویسد و نیاز به reload دارد:

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 helper می‌کند که در تعریف سرویس پیش‌فرض ذکر شده است. این دستور محدوده passive شما را باز نمی‌کند، بنابراین به‌تنهایی شما را در همان وضعیت اولیه نگه می‌دارد. بخش زون‌ها و سرویس‌های 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) است و پلتفرم یک آدرس عمومی را روی آن نگاشت (map) می‌کند، سرور آدرس عمومی خود را نمی‌شناسد. مستندات 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 را نادیده می‌گیرد و از آدرس اتصال کنترل (control connection) استفاده مجدد می‌کند. انتقالی که با curl کار می‌کند، ممکن است به همین دلیل در یک کلاینت گرافیکی با شکست مواجه شود.

آدرس را به‌صورت صریح تنظیم کنید. vsftpd از pasv_address=203.0.113.10 استفاده می‌کند، به‌علاوه pasv_addr_resolve=YES (پیش‌فرض NO) اگر ترجیح می‌دهید از نام میزبان (hostname) استفاده کنید. 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 عرضه می‌شود.

دو نکته در اینجا حائز اهمیت است. اول اینکه هیچ helper مربوط به connection tracking نمی‌تواند کار کند، که این همان نکته‌ای است که در بالا از زاویه‌ای دیگر به آن اشاره شد. دوم اینکه sudo tcpdump -nAi any 'tcp port 21' دیگر پاسخ 227 را به شما نشان نخواهد داد؛ بنابراین زمانی که نیاز دارید بدانید سرور چه آدرس و پورتی را اعلام (advertise) کرده است، به‌جای بررسی ترافیک شبکه، لاگ‌های خودِ سرور را مطالعه کنید.

تست تغییرات از خارج از شبکه

این دستورات را از یک ماشین دیگر اجرا کنید. تست کردن از روی خود سرور، فایروالی که قصد اصلاح آن را دارید دور می‌زند.

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

ss باید نشان دهد که دیمون FTP روی پورت 21 در حال گوش دادن است. در حالت بیکار سرور، هیچ چیزی روی محدوده passive گوش نمی‌دهد، زیرا آن سوکت‌ها فقط برای یک انتقال ایجاد شده و پس از آن بسته می‌شوند.

--disable-epsv ابزار curl را مجبور می‌کند از مسیر PASV استفاده کند، که همان مسیری است که مشکل آدرس را نمایان می‌کند. این trace پاسخ سرور و سپس آدرس و پورتی که curl به آن متصل می‌شود را چاپ می‌کند:

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

117 * 256 + 52 = 30004، که داخل محدوده اعلام‌شده است. وجود یک آدرس خصوصی در آن خط به این معنی است که pasv_address تنظیم نشده است. پورتی خارج از محدوده شما به این معنی است که سرور هرگز تغییرات پیکربندی را نخوانده است، بنابراین بررسی کنید که آیا فایلی که ویرایش کرده‌اید همان فایلی است که سرویس در حال اجرا از آن استفاده می‌کند یا خیر.

nc به تنهایی به پرسش مربوط به فایروال پاسخ می‌دهد. یک Connection refused فوری به این معنی است که بسته به سرور رسیده و چیزی برای گوش دادن پیدا نکرده است، که نتیجه صحیح برای یک پورت passive در حالت بیکار است: قانون شما کار می‌کند. معلق ماندن تا زمانی که nc از تلاش دست بکشد، به این معنی است که چیزی بسته را به‌صورت خاموش دور انداخته است؛ این یعنی یک فایروال، چه فایروال موجود روی خود سیستم و چه فایروال موجود در پنل ارائه‌دهنده سرویس شما. این تفاوت همان چیزی است که در refused versus timed out for 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 تنها زمانی جایگاه خود را حفظ می‌کند که سمت دیگر قادر به تغییر نباشد. اسکنرها و چاپگرهای چندکاره با firmwareای عرضه می‌شوند که فقط از FTP پشتیبانی می‌کند. تجهیزات آزمایشگاهی و صنعتی اغلب از یک image ثابت استفاده می‌کنند که هیچ‌کس حاضر به تأیید مجدد آن نیست. شرکای تجاری یک دراپ‌باکس FTPS ارائه می‌دهند و حاضر نیستند پروتکل جدیدی برای یک تأمین‌کننده اضافه کنند. در هر یک از این موارد، تعیین محدوده passive به همراه قانون فایروال متناظر، تمام کاری است که باید انجام شود و نسخه مورد استفاده باید FTPS باشد، نه FTP ساده. طراحی دو کاناله، تصمیمی مربوط به سال 1985 است که اکنون در دنیایی اجرا می‌شود که هرگز برای آن پیش‌بینی نشده بود؛ داستانی که در تاریخچه پروتکل‌های انتقال فایل پوشش داده شده است.

FAQ

چرا FTP وارد می‌شود اما لیست کردن دایرکتوری متوقف می‌ماند؟

ورود به سیستم فقط از کانال کنترل روی پورت 21 استفاده می‌کند که فایروال شما آن را مجاز دانسته است. لیست کردن دایرکتوری به یک کانکشن TCP دوم روی پورتی متفاوت نیاز دارد و آن کانکشن مسدود شده است. یک محدوده پورت passive روی سرور FTP تعریف کنید، همان محدوده را در فایروال باز کنید تا لیست کردن کامل شود. توقف در لیست کردن، مشکل کانال داده است و هرگز به رمز عبور مربوط نمی‌شود.

برای حالت passive در FTP چه پورت‌هایی را باید باز کنم؟

پورت 21 برای کانال کنترل، به علاوه هر محدوده‌ای که برای کانکشن‌های داده passive پیکربندی کرده‌اید. هیچ محدوده استانداردی وجود ندارد، زیرا انتخاب آن با شماست. چیزی مانند 30000 تا 30099 مناسب است: اندازه آن را بر اساس حداکثر تعداد انتقال‌های همزمان خود تنظیم کنید و آن را از محدوده پورت‌های خروجی کرنل دور نگه دارید؛ این محدوده را می‌توانید با sysctl net.ipv4.ip_local_port_range مشاهده کنید. اگر ارائه‌دهنده شما یک فایروال شبکه در پنل مدیریتی خود دارد، همان محدوده را در آنجا نیز باز کنید.

آیا هنوز به nf_conntrack_ftp نیاز دارم؟

خیر، و در کرنل‌های فعلی نمی‌توانید به آن تکیه کنید. تخصیص خودکار helper به‌صورت پیش‌فرض غیرفعال است و در کرنل‌های جدید، سوئیچ net.netfilter.nf_conntrack_helper حذف شده است، بنابراین sysctl گزارش می‌دهد که فایل وجود ندارد. راهنمای ufw بارگذاری بی‌قید و شرط این ماژول‌ها را منسوخ می‌داند و firewalld نیز AutomaticHelpers را کاملاً نادیده می‌گیرد. همچنین یک helper باید کانال کنترل را به صورت متن ساده بخواند، بنابراین به محض فعال کردن FTPS، از کار می‌افتد. به جای آن، یک محدوده پورت passive تعریف کنید.

چرا کلاینت FTP من می‌گوید پاسخ passive دارای یک آدرس غیرقابل مسیریابی است؟

سرور در پاسخ PASV، آدرسی را ارسال کرده که روی اینترفیس خودش می‌بیند و آن آدرس خصوصی است. این اتفاق زمانی می‌افتد که پلتفرم یک آدرس عمومی را روی یک آدرس خصوصی نگاشت می‌کند. آدرس عمومی را به‌طور صریح تنظیم کنید: pasv_address در vsftpd، MasqueradeAddress در ProFTPD یا -P در Pure-FTPd. نرم‌افزار FileZilla با استفاده مجدد از آدرسی که قبلاً به آن متصل شده، این مشکل را دور می‌زند و پیام "Using server address instead" را لاگ می‌کند؛ به همین دلیل است که برخی کلاینت‌ها با وجود پیکربندی نادرست کار می‌کنند و برخی دیگر متوقف می‌شوند.

آیا باید از FTPS استفاده کنم یا SFTP؟

برای هر چیزی که در هر دو سمت کنترل آن را در دست دارید، از SFTP استفاده کنید: یک کانکشن روی SSH در پورت 22، بدون نیاز به باز کردن کانال داده، و از قبل هم در حال اجراست. FTPS همان FTP روی TLS است، بنابراین طراحی دو کاناله و تمام مشکلات فایروالی که به همراه دارد را حفظ می‌کند. زمانی آن را انتخاب کنید که سمت دیگر فقط از آن پشتیبانی می‌کند. از FTP ساده در اینترنت استفاده نکنید، زیرا رمز عبور به صورت متن خوانا در شبکه منتقل می‌شود.