익명 FTP 세션에서 "ls" 명령을 사용하려고 하는데 "ls" 명령을 입력하면 다음과 같은 결과가 나타납니다.
200 PORT 명령이 성공했습니다. PASV 사용을 고려해보세요.
그리고 이렇게 멈춥니다(ftp 프롬프트로 돌아가지 않음).
FTP 세션을 다시 시작하고 패시브 모드로 들어갔지만(PASV 인용) 또 다른 문제가 발생합니다: "호스트에 대한 경로 없음"
어떤 제안이 있나요?
답변1
quote PASV 그렇지 않다생각하는 대로 수동 모드에 들어갑니다. "PASV"는 영구적인 모드 전환 명령이 아니라 즉각적인 명령(모든 전송에 앞서 수행됨)입니다.
오히려,고객ls파일 전송을 요청하거나 요청할 때 마다 PORT 대신 PASV를 사용하도록 지시해야 합니다 .
와 함께inetutils-ftp, 사용passive명령을 실행하거나 클라이언트를 pftp또는 ftp --passive.
답변2
방화벽에서 포트 20을 여는 것을 잊었을 때 이 문제를 본 기억이 납니다. 일반적으로 FTP와 연결된 포트는 21이지만 데이터는 일반적으로 포트 20을 통해 전송됩니다.
포트 20에서 연결을 시작하는 사람이 연결할 수 있도록 클라이언트와 서버 모두에서 20과 21이 모두 열려 있는지 확인하십시오.
답변3
어떤 제안이 있나요?
응, FTP는 버려라.
나는 그것이 아마도 당신이 듣고 싶어하는 대답이 아닐 것이라는 것을 알고 있습니다. 그러나 그것이 실제로 필요한 이유를 설명하겠습니다. 그러면 당신은 이렇게 하고 싶은 마음이 더 커질 것입니다. 또 다른 대안도 제시하겠습니다.
FTP는 인터넷이 실험적인 프로젝트로 간주되었을 때 작성되었습니다. 주요 대학과 대규모 조직에는 존경받는 기관에 의해 시행되는 행동 규칙이 있었기 때문에 인터넷(실제로 당시 ARPAnet이라고 불림)의 사람들은 신뢰를 받았습니다.
FTP는 클라이언트가 TCP 연결을 사용하여 파일에 대한 요청을 보내도록 설계되었습니다. 그런 다음 서버는 요청을 수신하고 클라이언트에 대한 별도의 TCP 연결을 시작했습니다.
클라이언트가 자신의 물건을 보호하기 위해 방화벽을 사용하기 시작하면서 이러한 문제가 발생했습니다. 따라서 FTP 클라이언트는 나가는 연결을 만들 수 있지만 들어오는 연결은 차단되었습니다.
이를 해결하는 방법은 수동 모드였습니다. 클라이언트가 TCP 포트 21을 사용하여 요청을 보낸 다음 서버는 임의의 TCP 포트(예: 43728)를 사용하여 다른 연결을 원한다고 말한 다음 클라이언트는 지정된 임의 TCP를 사용하여 두 번째 연결을 만듭니다. 포트(예: 43728).
클라이언트에 방화벽이 있으면 작동했습니다. 많은 사람들이 "수동 모드"가 FTP 문제를 해결한다는 사실을 배우기 시작했습니다. 그러나 "패시브 모드"가 실제로 수정한 것은 바로 그 특정 문제였습니다. 서버에 FTP의 포트 21과 같은 특정 포트 번호로 들어오는 트래픽만 허용하는 방화벽이 있는 경우 "수동 모드"라도 작동하는 데 필요한 모든 기능을 수정하지는 않습니다.
이론적으로 FTP 서버의 방화벽이 트래픽을 모니터링하고 필요한 경우 다른 포트를 여는 FTP 프록시를 지원하면 이 문제를 해결할 수 있습니다. 많은 사람들이 설정하기가 조금 어렵다고 생각합니다.
더 많은 조직이 보안에 더 관심을 갖고 FTP에 대해 덜 관심을 가지면서 사람들은 FTP가 일반적으로 손상되고 있다는 사실을 배우기 시작했습니다. 즉, 사람들이 FTP를 사용하려고 시도할 수 있는 점점 더 많은 위치에서 점점 더 많은 FTP 서버를 사용하기가 어려워지고 있음을 의미합니다. 클라이언트). FTP 문제가 더욱 널리 퍼지기 시작했습니다.
한동안 사람들은 "수동 모드"가 FTP 문제를 해결하는 마법의 "만병통치" 기술인 것처럼 보인다는 사실을 알게 되었습니다. (많은 사람들이 FTP 작동이 중단된 이유를 이해하지 못했습니다. FTP가 이상하게 작동하기 시작하면 "수동 모드"가 FTP가 경험한 이상한 문제를 해결하는 것처럼 보인다는 사실을 알게 되었습니다. 나중에 "수동 모드"가 마법의 "치료"라고 믿었습니다. "모두"는 일반적으로 FTP가 더 이상 작동하지 않는 것 같다는 다른 믿음으로 대체되었습니다(예전만큼 좋지는 않습니다). 많은 사람들이 FTP가 중단된 이유를 이해하지 못하더라도 그들이 이해한 것은 무엇입니까? 다른 프로토콜을 사용하기 시작하는 다른 기술을 시도했을 때 인생이 더 성공적으로 작동하는 것 같았습니다. HTTPS 업로드가 더 대중화되기 시작하면서 사람들은 FTP 사용을 거의 중단했습니다.
따라서 가장 좋은 해결책은 실제로 최신 인터넷 보안 조치와 작동하지 않는 기존 FTP 프로토콜을 버리는 것입니다. FTP는 그런 용도로 설계되지 않았습니다. NAT는 여러 장치가 하나의 IP 주소를 사용하도록 돕는 데도 사용됩니다.
NAT는 보안 이외의 목적(예: 지원되는 장치 수 증가)을 가질 수도 있지만 방화벽으로 구현되는 경우가 많습니다. NAT를 사용하는 목적이 무엇이든, 최종 결과는 NAT가 기본적으로 동일한 이유로 FTP 연결을 끊는 것입니다(연결이 원하는 장치에 도달하는 것을 허용하지 않음). 따라서 FTP도 NAT를 지원하도록 설계되지 않았습니다.
과거에 FTP는 파일 전송이 작동하도록 하기 위한 실험적인 노력에 불과했습니다. FTP는 원래 목표를 달성했습니다. 따라서 오늘날 설계된 인터넷에서는 잘 작동하지 않지만 FTP는 실제로 잘못 설계되지 않았습니다. 그 디자인은 당시 정말 큰 성공을 거두었습니다. 이는 오늘날의 일반적인 기술을 사용하는 것과는 다른 스타일의 인터넷을 위해 설계되었습니다.
HTTP는 여러 개의 TCP 연결 대신 하나의 TCP 연결을 사용하므로 많은 문제가 없습니다. HTTPS, SFTP, FTPS, SCP 등 많은 보안 대안도 마찬가지입니다.
나는 다른 대안을 약속했다. 그것은 FTP를 작동하게 만드는 것입니다. 전략은 다음과 같습니다. * 클라이언트측 방화벽이 FTP 프록시를 실행하도록 합니다. * FTP 서버의 방화벽이 FTP 프록시를 실행하도록 합니다.
문제는 연결의 한쪽을 제어할 수 없는 경우가 많다는 것입니다. 따라서 그 중 하나가 귀하에게 선택 사항이 아닐 수도 있습니다.
방화벽을 완전히 제거해 볼 수도 있습니다. 그러나 이로 인해 대부분의 사람들이 효과가 없다고 생각하는 보안 위험이 발생할 가능성이 있습니다. 대신, 최신 인터넷에서 잘 작동하지 않는 기존 FTP 프로토콜을 사용하려는 아이디어를 폐기하고 HTTPS나 FTPS(또는 SCP)를 통한 파일 전송을 사용하는 최신 소프트웨어를 구입하세요. 일반적으로 방화벽과 더 잘 작동하고 NAT와 더 잘 작동하며 개인 정보 보호의 이점을 제공합니다. (당신은 인터넷을 통해 암호화되지 않은 비밀번호를 공개하고 싶지 않았습니까?)
공개 파일을 가져오려는 경우가 아니라면 HTTPS나 HTTP가 더 쉬운 경로일 수 있습니다.