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

بررسی‌ها را به ترتیب انجام دهید. هر یک لایه متفاوتی را رد می‌کند، پس در نخستین موردی که ناهنجاری نشان می‌دهد توقف کنید.

نخست دو اتصال را جدا کنید

اتصال کنترل فرمان‌ها و پاسخ‌ها را روی پورت شنود سرور حمل می‌کند. اتصال داده فهرست پوشه یا بدنه فایل را حمل می‌کند، و در حالت غیرفعال سرور نقطه پایانی خود را برمی‌گزیند و آن را در پاسخ PASV یا EPSV اعلام می‌کند. اجازه دادن به پورت 21 هیچ چیزی درباره دسترس‌پذیری پورت داده نمی‌گوید، و دقیقاً به همین دلیل ورود موفق می‌شود در حالی که هر فهرست زمان‌بندی می‌شود. راهنمای WinSCP درباره حالت‌های FTP این تفکیک و الزامات شبکه‌ای آن را توضیح می‌دهد.

اگر کلاینت پشت VPN باشد، مسیر داده از همان تونل می‌گذرد اما نه لزوماً از همان سیاست.

آدرس را در پاسخ PASV بخوانید

یک کلاینت پرجزئیات اجرا کنید و به‌جای حدس زدن پاسخ را بخوانید. curl -v ftp://user@host/ خط PASV را با آدرس و پورتی که سرور می‌خواهد چاپ می‌کند، و کلاینت سپس به همان آدرس متصل می‌شود. اگر آدرسی خصوصی باشد که در سمت کلاینت تونل معنایی ندارد، اتصال داده به جایی نمی‌رود در حالی که کانال کنترل سالم می‌ماند.

آن آدرس را با آدرسی که کلاینت واقعاً به آن رسیده مقایسه کنید. ناهمخوانی پاسخ است، و معمولاً از NAT یا از سروری با آدرس داخلی می‌آید.

محدوده پورت و سیاست تونل را بررسی کنید

سرورهای غیرفعال پورت‌های داده را از محدوده‌ای پیکربندی‌شده تخصیص می‌دهند، و آن محدوده باید از طریق VPN و هر فایروال در مسیر مجاز باشد. سیاستی که 21 را مجاز می‌کند و هیچ چیز دیگر را، سیاستی فقط برای ورود است. محدوده را با کسی که سرور را اداره می‌کند تأیید کنید، سپس یک پورت از آن را آزمایش کنید نه اینکه فرض کنید کل محدوده یکسان رفتار می‌کند.

کانال‌های کنترل رمزنگاری‌شده این را دشوارتر می‌کنند، زیرا واسط دیگر نمی‌تواند آدرس اعلام‌شده را در حین انتقال بازنویسی کند.

بدانید چه زمانی EPSV یا گزینه جایگزین کمک می‌کند

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

TLS را فقط برای اینکه ابزاری کمکی نشست را بررسی کند غیرفعال نکنید. این یک پروتکل کارآمد را با مدل تهدیدی شکسته معاوضه می‌کند.

با فهرست و انتقال تأیید کنید

پس از تغییر سیاست آدرس یا پورت، نشست تازه‌ای روی همان مسیر VPN باز کنید و یک پوشه را فهرست کنید. سپس یک فایل کوچک منتقل کنید، زیرا فهرست و انتقال می‌توانند در برخی سرورها مسیرهای کد متفاوتی داشته باشند. در گزارش کلاینت اتصال داده به آدرس و پورت مورد انتظار را بررسی کنید و تأیید کنید که بایت‌ها رسیده‌اند.

در حین انجام این کار FTP و FTPS و SFTP را در ذهن جدا نگه دارید. تغییر پورت غیرفعال تنظیمی در SFTP نیست، و این اصلاح بین پروتکل‌ها منتقل نمی‌شود.

مقالات مرتبط