게이트웨이가 기대하는 FTP 프록시 로그인 방식을 선택하세요
네이티브 FTP 게이트웨이의 USER, SITE 또는 OPEN 대화를 이를 지원하는 클라이언트에 맞추고, 게이트웨이 계정은 대상 계정과 분리해 두세요.
“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 대화를 요구하는 게이트웨이는 그 흐름을 실제로 지원하는 클라이언트가 필요합니다. WebRequest의 Proxy 속성은 또 다른 인터페이스입니다.
예를 들어 WinSCP는 모든 게이트웨이를 하나의 호스트 필드로 취급하지 않고 FTP 프록시 로그인 방식을 별도로 제공합니다. 숫자로 된 원시 설정 값은 문서화된 API에 속합니다. 구성을 검토할 때는 방식 이름과 의도된 대화를 사용하세요.
로그인 후에도 파일 전송에는 FTP 데이터 연결과 선택한 TLS 모드가 필요합니다. 제어 채널의 로그인 성공은 그 경로의 시작일 뿐, 모든 데이터 전송이 이미 허용되었다는 증거는 아닙니다.