“FTP прокси” може да описва шлюз, който сам говори FTP. Свързването с него е различно от искането към HTTP прокси за CONNECT или към SOCKS сървър да отвори TCP дестинация.

Шлюзът се нуждае от целевия хост и акаунт и може първо да поиска собствен вход. Продуктите изразяват този разговор по различни начини:

ПодредбаТипична форма на командата
Целта е кодирана в потребителско имеUSER target-user@target-host
Отделен вход в шлюзаUSER/PASS за шлюза, последван от входа за целта
Явна команда за дестинацияSITE target-host или OPEN target-host, след което изисквания вход

Това са семейства от конвенции, а не една стандартна последователност за всеки шлюз. Изберете метода, документиран от администратора и поддържан от клиента.

Дръжте двата акаунта видими в настройката

Паролата за целевия FTP и паролата за шлюза може да са различни. Някои шлюзове ги обединяват в едно представяне USER/PASS; други изискват отделни обмени. Поставянето на всяка стойност в един низ не може да пресъздаде клиент, който трябва да изпраща допълнителни команди.

Това обяснява полезна граница в стария код на FtpWebRequest. Обикновена FTP връзка към шлюза, с потребителско име, специфично за шлюза, може да пасне на някои подредби USER/PASS. Шлюз, който изисква отделен разговор SITE или OPEN, се нуждае от клиент, който наистина поддържа този поток. Свойството Proxy на WebRequest е отново друг интерфейс.

WinSCP например предлага отделни методи за вход през FTP прокси, вместо да третира всички шлюзове като едно поле за хост. Неговите числови стойности на суровите настройки принадлежат към документирания му API; използвайте името на метода и предвидения разговор, когато преглеждате конфигурация.

След входа прехвърлянето на файлове все още се нуждае от FTP връзка за данни и избрания TLS режим. Успешният вход в контролния канал е началото на този път, а не доказателство, че всеки трансфер на данни вече е разрешен.

Подобни статии