حل مشکل توقف لیست دایرکتوری در 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 مربوط به connection tracking در FTP دیگر راه‌حل مناسبی نیست

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

تخصیص خودکار helper غیرفعال شده است و در هسته‌های فعلی نمی‌توان آن را دوباره فعال کرد. هسته لینوکس از سال 2016 این قابلیت را به‌صورت پیش‌فرض غیرفعال کرد. کامیت Pablo Neira Ayuso با عنوان "netfilter: remove nf_conntrack_helper sysctl and modparam toggles" (اوت 2022) این سوئیچ را به‌طور کامل حذف کرد و اعلام نمود که "کاربران اکنون باید به پیکربندی صریح conntrack helper از طریق ruleset تکیه کنند." پارامتر sysctl مربوط به nf_conntrack_helper در لینوکس 5.19 وجود دارد اما از لینوکس 6.0 به بعد حذف شده است و مستندات sysctl مربوط به conntrack در هسته دیگر آن را فهرست نمی‌کند. بارگذاری این ماژول به‌تنهایی هیچ نتیجه‌ای ندارد.

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

رابط‌های کاربری فایروال نیز این قابلیت را منسوخ کرده‌اند. دستور man ufw-framework در Ubuntu 24.04 درباره خط IPT_MODULES در /etc/default/ufw می‌گوید: "بارگذاری بی‌قید و شرط ماژول‌های connection tracking (مانند nf_conntrack_*) به این روش منسوخ شده است" و اضافه می‌کند که قوانین helper "باید از طریق فایل‌های RULES مدیریت شوند." مستندات firewalld در firewalld.conf گزینه AutomaticHelpers را "منسوخ" می‌نامد و می‌گوید: "این گزینه نادیده گرفته می‌شود و دیگر استفاده نمی‌شود." امروزه پیوست کردن یک 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 در اینجا هیچ پیش‌فرضی ندارد: بدون این دستور، هسته سیستم‌عامل پورت را انتخاب می‌کند. مستندات ProFTPD همچنین بیان می‌کنند که وقتی هیچ پورتی در محدوده شما آزاد نباشد، سرور به پورت تخصیص‌یافته توسط هسته بازمی‌گردد و یک پیام در لاگ ثبت می‌کند. بنابراین، محدوده‌ای که بیش از حد کوچک باشد، به‌جای شکست کامل و مشخص، گاهی اوقات دچار اختلال می‌شود که عیب‌یابی آن بسیار دشوارتر است. از پورت‌های غیرمجاز (non-privileged)، یعنی 1024 و بالاتر استفاده کنید.

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

به چند پورت نیاز دارید؟ برای هر اتصال داده‌ای که در حال انجام است، یک پورت. یک پورت TCP بسته، قبل از اینکه بتواند دوباره استفاده شود، برای چند دقیقه در وضعیت TIME_WAIT باقی می‌ماند، بنابراین چند برابرِ اوجِ مورد انتظار خود را در نظر بگیرید. صد پورت برای چند کاربر کافی است و یک سرور عمومی شلوغ به تعداد بسیار بیشتری نیاز دارد. vsftpd در اینجا نسبت به ProFTPD سخت‌گیرتر است: کد منبع آن تعدادی پورت تصادفی را در محدوده مشخص‌شده امتحان می‌کند و اگر همه آن‌ها اشغال باشند، به‌جای قرض گرفتن پورتی خارج از محدوده، نشست را با 500 OOPS: vsf_sysutil_bind پایان می‌دهد. در هر دو سرور، محدوده‌ای که بیش از حد کوچک باشد، انتقال داده‌ها را در شلوغ‌ترین لحظات شما مختل می‌کند.

محدوده باید کجا قرار بگیرد؟ ابتدا دستور 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 تنها زمانی جایگاه خود را حفظ می‌کند که طرف مقابل امکان تغییر نداشته باشد. اسکنرها و چاپگرهای چندکاره با فریم‌وری عرضه می‌شوند که فقط از FTP پشتیبانی می‌کند. تجهیزات آزمایشگاهی و صنعتی اغلب از یک ایمیج ثابت استفاده می‌کنند که هیچ‌کس حاضر به تأیید مجدد آن نیست. شرکای تجاری یک دراپ‌باکس FTPS ارائه می‌دهند و حاضر نیستند پروتکل دیگری برای یک تأمین‌کننده اضافه کنند. در هر یک از این موارد، تعیین محدوده passive به همراه قانون فایروال متناظر، تمام کاری است که باید انجام شود و نسخه مورد استفاده باید FTPS باشد، نه FTP ساده. طراحی دو کاناله، تصمیمی مربوط به سال 1980 است که پنج سال پیش از RFC 959 در RFC 765 وجود داشت و اکنون در دنیایی اجرا می‌شود که هرگز برای آن پیش‌بینی نشده بود؛ داستانی که در تاریخچه پروتکل‌های انتقال فایل به آن پرداخته شده است.

FAQ

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

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

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

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

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

خیر، و در یک کرنل به‌روز نمی‌توانید به آن تکیه کنید. تخصیص خودکار helper به‌صورت پیش‌فرض غیرفعال است و از زمان Linux 6.0 سوئیچ 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 ساده در اینترنت استفاده نکنید، زیرا رمز عبور به صورت متن خوانا از شبکه عبور می‌کند.