Вхід через FTP працює, але список каталогу зависає: чому

Ім'я користувача працює, пароль працює, і клієнт каже, що з'єднаний. Далі він вічно чекає на список теки або на перше передавання файлу, і ніщо в облікових даних цього не пояснює. 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, і виправлення не переноситься між протоколами.