”FTP-proxy” kan beteckna en gateway som själv talar FTP. Att ansluta till den skiljer sig från att be en HTTP-proxy om CONNECT eller be en SOCKS-server öppna en TCP-destination.

Gatewayen behöver målvärden och kontot, och kan först behöva sin egen inloggning. Produkter uttrycker samtalet på olika sätt:

OrdningVanlig kommandofasong
Målet kodat i ett användarnamnUSER target-user@target-host
Separat gateway-inloggningGateway USER/PASS, därefter mål-inloggningen
Uttrycklig destinationskommandoSITE target-host eller OPEN target-host, därefter den nödvändiga inloggningen

Detta är familjer av konventioner, inte en enda standardsekvens för varje gateway. Välj den metod som administratören dokumenterat och som klienten stöder.

Håll båda kontona synliga i konfigurationen

Målets FTP-lösenord och gatewayens lösenord kan skilja sig. Vissa gateways slår ihop dem i en enda USER/PASS-representation; andra kräver separata utbyten. Att lägga alla värden i en enda sträng kan inte återskapa en klient som måste skicka ytterligare kommandon.

Detta förklarar en användbar gräns i äldre FtpWebRequest-kod. En vanlig FTP-anslutning till gatewayen, med ett gatewayspecifikt användarnamn, kan passa vissa USER/PASS-ordningar. En gateway som kräver ett separat SITE- eller OPEN-samtal behöver en klient som verkligen stöder det flödet. Egenskapen Proxy i WebRequest är återigen ett annat gränssnitt.

WinSCP till exempel erbjuder separata metoder för FTP-proxyinloggning i stället för att behandla alla gateways som ett enda värdvfält. Dess numeriska råinställningsvärden hör till dess dokumenterade API; använd metodnamnet och det avsedda samtalet när du granskar en konfiguration.

Efter inloggning behöver filöverföringen fortfarande sin FTP-dataanslutning och det valda TLS-läget. En lyckad inloggning på kontrollkanalen är början på den vägen, inte bevis för att varje dataöverföring redan är tillåten.

Relaterade artiklar