FTP 패시브 모드 디렉터리 목록 멈춤 해결 방법

FTP 로그인은 되지만 디렉터리 목록을 불러올 때 멈추는 이유

FTP 패시브 모드는 방화벽에서 차단되는데, 이는 FTP가 하나의 연결이 아닌 두 개의 TCP 연결을 사용하기 때문입니다. 포트 21로 연결하면 로그인과 명령이 처리되므로 사용자 이름과 비밀번호는 정상적으로 승인되고 방화벽도 올바르게 작동하는 것처럼 보입니다. 첫 번째 ls 연결 이후에는 다른 포트를 사용하는 두 번째 연결이 필요합니다. 방화벽 설정에 해당 포트를 허용하는 규칙이 없으면 클라이언트는 타임아웃이 발생할 때까지 대기하게 됩니다.

이 문제를 해결하려면 데이터 연결에 사용할 포트 범위를 고정하고, 방화벽에서 해당 범위를 허용하는 규칙을 추가해야 합니다. NAT(network address translation) 뒤에 있는 서버는 올바른 주소를 알릴 수 있도록 추가 설정이 하나 더 필요합니다. 과거에는 연결 추적 헬퍼(connection tracking helper)가 이 작업을 자동으로 수행했습니다. 하지만 더 이상은 그렇지 않으며, 오래된 가이드를 무작정 따라 하기 전에 그 이유를 알아두는 것이 좋습니다.

제어 채널과 데이터 채널

FTP(file transfer protocol)는 RFC 959에 명시되어 있으며 NAT와 상태 기반 방화벽보다 먼저 등장했습니다. 세션은 TCP 포트 21번으로 하나의 제어 연결을 열고 세션 전체 기간 동안 이를 유지합니다. 명령어는 일반 텍스트로 전송됩니다. 응답은 세 자리 코드와 텍스트 한 줄로 돌아옵니다. 이 연결을 통해 파일 콘텐츠가 전송되는 일은 없습니다.

모든 데이터는 각기 별도의 TCP 연결을 사용합니다. 디렉터리 목록 조회(LIST)에 하나, 다운로드(RETR)마다 하나, 업로드(STOR)마다 하나씩 연결이 생성됩니다. 연결은 생성되고, 한 번 사용된 뒤 종료됩니다. 인증은 전적으로 제어 채널에서 이루어지므로, 데이터 경로에 문제가 생기면 항상 동일한 현상이 나타납니다. 즉, 로그인은 성공하지만 이후 응답이 없는 상태가 됩니다. 클라이언트가 230 응답을 출력한 뒤 목록 조회 단계에서 멈춘다면, 이는 자격 증명 문제가 아니라 데이터 채널의 문제입니다.

액티브 모드: 서버가 클라이언트에 역으로 연결

액티브 모드에서는 클라이언트가 포트를 선택하여 대기한 뒤, 서버에 접속할 위치를 알립니다.

PORT 192,168,1,50,195,80

앞의 숫자 4개는 클라이언트의 IP 주소입니다. 뒤의 숫자 2개는 2바이트로 인코딩된 포트 번호로, 195 * 256 + 80 = 50000이 됩니다. 그러면 서버는 자신의 20번 포트에서 클라이언트의 50000번 포트로 데이터 연결을 엽니다.

이 연결은 클라이언트 입장에서 외부에서 들어오는 요청이며 사전에 승인되지 않은 것이므로, 클라이언트 방화벽이 이를 차단합니다. 클라이언트가 가정용 공유기 뒤에 있다면 PORT 명령에 포함된 주소는 서버가 전혀 접근할 수 없는 사설 IP 주소입니다. 액티브 모드는 FTP가 제대로 작동하지 않는다는 악명을 얻게 된 원인입니다.

패시브 모드: 클라이언트가 두 연결을 모두 시작

패시브 모드는 데이터 연결의 방향을 반대로 바꿉니다. 클라이언트가 PASV을 보내면 서버는 자신의 주소와 포트 번호로 응답합니다.

227 Entering Passive Mode (203,0,113,10,195,80)

인코딩 방식은 동일하므로 클라이언트는 203.0.113.10의 50000번 포트로 연결을 시도합니다. 이제 클라이언트가 두 연결을 모두 시작하므로 패시브 모드는 클라이언트 측 NAT 환경에서도 정상적으로 작동하며, 현재 사용되는 모든 클라이언트가 이를 우선적으로 요청합니다.

하지만 문제가 해결된 것이 아니라 위치만 바뀌었습니다. 이제 서버 측으로 예기치 않은 인바운드 연결이 들어오며, 이때 사용하는 높은 번호의 포트는 전송할 때마다 변경됩니다. 해당 방화벽은 서버 관리자의 소관이므로, 이제 이 문제는 서버 관리자가 해결해야 합니다.

EPSV(확장 패시브 모드, RFC 2428)은 동일한 개념을 더 깔끔한 응답 형식으로 처리합니다.

229 Entering Extended Passive Mode (|||50000|)

응답에 주소 정보가 포함되지 않습니다. 클라이언트는 제어 연결에 이미 사용 중인 주소를 재사용하며, 이 덕분에 IPv6 환경에서도 작동하고 NAT 관련 버그 유형 하나가 완전히 제거됩니다. curl 매뉴얼에 따르면 curl은 일반적으로 PASV보다 EPSV를 먼저 시도합니다. 포트는 여전히 런타임에 결정되므로 EPSV을 사용하더라도 방화벽 규칙 설정에는 아무런 변화가 없습니다.

일반적인 방화벽 규칙으로 데이터 채널을 허용할 수 없는 이유

규칙을 작성하는 시점에는 포트 번호가 아직 존재하지 않기 때문입니다. 서버는 전송할 때마다 포트를 선택합니다. 기본값으로 두면 vsftpd는 pasv_min_port와 pasv_max_port을 0로 설정하는데, 이는 "아무 포트나 사용"한다는 의미이므로 데이터 연결은 1023 이상의 모든 포트로 들어올 수 있습니다. sudo ufw allow 21/tcp는 제어 채널만 허용하며 다른 것은 아무것도 허용하지 않는데, 바로 이 설정 때문에 로그인은 성공하지만 목록 조회는 실패하게 됩니다. 하나의 고정 포트에서 서비스가 대기하는 개념이 아직 모호하다면 Linux에서 포트와 리스닝 소켓이 작동하는 방식을 배경 지식으로 참고하십시오.

상태 저장(stateful) 방화벽은 연결을 추적하며, 커널은 기존 연결에 대한 RELATED으로 새로운 연결을 허용할 수 있습니다. FTP의 경우 제어 스트림을 읽어 227 또는 PORT 라인에서 포트 번호를 추출하는 과정이 필요합니다. 기본적으로는 이러한 기능을 수행하는 것이 없습니다.

FTP 연결 추적 헬퍼가 더 이상 해결책이 아닌 이유

이전 가이드들은 커널 모듈 nf_conntrack_ftp를 사용하라고 안내합니다. 이 모듈은 평문 제어 채널을 읽어 통보된 포트를 찾고, 기대(expectation)를 등록하여 포트를 명시하는 규칙 없이도 데이터 연결을 허용합니다. 하지만 해당 가이드들이 작성된 이후 네 가지가 변경되었습니다.

자동 헬퍼 할당 기능은 꺼져 있으며, 최신 커널에서는 다시 켤 수 없습니다. 커널은 2016년부터 이를 기본적으로 비활성화했습니다. Pablo Neira Ayuso의 커밋 "netfilter: remove nf_conntrack_helper sysctl and modparam toggles"(2022년 8월)는 해당 스위치를 완전히 제거하며 "사용자는 이제 규칙 집합을 통한 명시적인 conntrack 헬퍼 설정에 의존해야 한다"고 명시했습니다. nf_conntrack_helper sysctl은 Linux 5.19까지 존재하다가 Linux 6.0부터 제거되었으며, 커널의 conntrack sysctl 문서에서도 더 이상 나열되지 않습니다. 따라서 모듈을 로드하는 것만으로는 아무런 효과가 없습니다.

사용 중인 커널의 종류는 sysctl net.netfilter.nf_conntrack_helper 명령으로 확인할 수 있습니다. sysctl: cannot stat /proc/sys/net/netfilter/nf_conntrack_helper: No such file or directory라는 응답이 나오면 해당 커널에는 켤 수 있는 자동 헬퍼 할당 기능이 남아있지 않은 것입니다. 만약 숫자가 반환된다면 6.0 미만의 커널을 사용 중인 것이며, 스위치가 여전히 존재하고 기본값은 0입니다.

방화벽 프론트엔드들 또한 이 기능을 더 이상 지원하지 않습니다. Ubuntu 24.04의 man ufw-framework는 /etc/default/ufw 내의 IPT_MODULES 라인에 대해 "이런 방식의 연결 추적 모듈(nf_conntrack_*) 무조건적 로드는 더 이상 사용되지 않는다(deprecated)"고 언급하며, 헬퍼 규칙은 "규칙 파일(RULES FILES)을 통해 관리해야 한다"고 덧붙입니다. firewalld는 firewalld.conf에서 AutomaticHelpers을 "더 이상 사용되지 않음(Deprecated). 이 옵션은 무시되며 더 이상 사용되지 않는다"고 설명합니다. 이제 헬퍼를 연결하려면 CT 타겟을 사용하는 명시적 규칙을 직접 작성해야 하는데, 이는 아래의 해결책보다 번거로울 뿐만 아니라 TLS를 활성화하는 순간 작동을 멈춥니다. Ubuntu의 iptables 및 nftables에서 해당 규칙들이 실제로 어디에 위치하는지 확인할 수 있습니다.

TLS는 이 논쟁을 종결시킵니다. 헬퍼는 제어 채널을 텍스트로 읽어 작동합니다. 채널을 암호화하면 헬퍼는 암호문만 보게 되므로 포트를 찾을 수 없습니다. 이에 대한 해결책은 없으며, 있어서도 안 됩니다. 제어 채널을 읽을 수 있는 중간 장비(middlebox)는 곧 사용자의 비밀번호를 읽을 수 있는 장비이기 때문입니다.

서버에 패시브 포트 범위 선언하기

모든 FTP 서버는 사용자가 지정한 범위 내에서 패시브 포트를 선택하도록 설정할 수 있습니다. 옵션 명칭은 서버마다 다르므로 운영 중인 서버의 문서를 확인하십시오.

vsftpd의 경우, /etc/vsftpd.conf에서 설정합니다:

pasv_enable=YES
pasv_min_port=30000
pasv_max_port=30099

pasv_enable는 이미 YES를 기본값으로 사용합니다. 두 포트 옵션은 기본적으로 0로 설정되어 있으며, 이는 앞서 설명한 "아무 포트나 사용"하는 동작을 의미합니다. sudo systemctl restart vsftpd으로 설정을 적용한 뒤, systemctl status vsftpd을 사용하여 서비스가 정상적으로 재시작되었는지 확인하십시오. vsftpd는 구문 분석이 불가능한 설정 줄이 있으면 무시하지 않고 시작을 거부하므로, 재시작에 실패하면 journalctl -u vsftpd -n 20에서 방금 입력한 옵션이 포함된 500 OOPS: 줄을 확인하십시오.

ProFTPD의 경우, proftpd.conf에서 설정합니다:

PassivePorts 30000 30099

ProFTPD는 이 부분에 대한 기본값을 명시하지 않습니다. 지시어가 없으면 커널이 포트를 선택합니다. ProFTPD 문서에 따르면 지정한 범위 내의 포트가 모두 사용 중일 경우, 서버는 커널이 할당한 포트로 대체하고 메시지를 로그에 남깁니다. 따라서 범위가 너무 작으면 가끔씩 오류가 발생하여 깔끔하게 실패하지 않으므로 문제 진단이 훨씬 어려워집니다. 1024 이상의 비특권 포트를 사용하십시오.

Pure-FTPd는 -p first:last 플래그를 사용합니다. man pure-ftpd에는 이를 "패시브 모드 다운로드를 위해 first부터 last까지의 포트 범위만 사용"하며, 이 설정이 "pure-ftpd를 패킷 필터와 더 호환되게 만든다"고 설명되어 있습니다. 패키지 빌드 버전은 보통 이 플래그를 설정 파일 내부에 포함하므로, 추측하기보다는 배포판의 자체 문서를 확인하여 파일 이름을 찾으십시오.

얼마나 많은 포트가 필요할까요? 진행 중인 데이터 연결당 하나가 필요합니다. 닫힌 TCP 포트는 재사용되기 전까지 TIME_WAIT 상태로 수 분간 머무르므로, 예상되는 최대 사용량의 몇 배를 할당하십시오. 사용자 수가 적다면 100개의 포트로 충분하지만, 바쁜 공용 서버라면 훨씬 더 많은 포트가 필요합니다. vsftpd는 ProFTPD보다 엄격합니다. 소스 코드에서 범위 내의 무작위 포트 몇 개를 시도해보고 모두 사용 중이면 범위 밖의 포트를 빌려오는 대신 500 OOPS: vsf_sysutil_bind 오류와 함께 세션을 종료합니다. 어느 서버를 사용하든 범위가 너무 작으면 가장 바쁜 순간에 전송이 중단됩니다.

범위는 어디에 위치해야 할까요? 먼저 sysctl net.ipv4.ip_local_port_range를 실행하십시오. 기본 Ubuntu 환경에서는 32768 60999이 출력되는데, 이는 커널이 아웃바운드 연결을 위해 할당하는 포트 범위입니다. 이 범위 내에 패시브 포트를 설정하면 이미 해당 포트를 점유 중인 아웃바운드 연결과 충돌할 수 있으므로, 이보다 낮은 범위를 유지하십시오. 기본 설정에서는 30000에서 30099 사이가 안전합니다. 해당 숫자를 맹신하지 말고 직접 서버에서 확인하십시오.

방화벽에서 동일한 범위 개방

ufw는 콜론을 사용하여 범위를 표기하며, 매뉴얼에 따르면 범위나 목록을 사용하여 여러 포트를 지정할 때는 반드시 프로토콜을 명시해야 합니다.

sudo ufw allow 21/tcp
sudo ufw allow 30000:30099/tcp
sudo ufw status verbose

ufw status verbose 명령을 실행하면 이제 두 항목이 모두 나열되어야 합니다. /tcp 옵션 없이 동일한 명령을 실행하면 ufw가 프로토콜을 추측하지 않으므로 tcp 또는 udp를 지정하라는 오류 메시지와 함께 거부됩니다. VPS에서의 ufw 규칙 문법에서 나머지 내용을 다룹니다.

firewalld는 하이픈을 사용하여 범위를 표기하며, 적용을 위해 리로드(reload)가 필요합니다.

sudo firewall-cmd --permanent --add-service=ftp
sudo firewall-cmd --permanent --add-port=30000-30099/tcp
sudo firewall-cmd --reload
sudo firewall-cmd --list-all

--add-service=ftp 명령은 21/tcp 포트를 개방하고 기본 서비스 정의에 명시된 ftp 헬퍼를 요청합니다. 이 명령만으로는 패시브 포트 범위를 개방하지 않으므로, 설정 전과 동일한 상태가 유지됩니다. VPS에서의 firewalld 영역 및 서비스에서 더 자세한 내용을 확인할 수 있습니다.

nftables를 직접 사용하는 경우, input 체인 내부에 다음을 추가합니다.

tcp dport { 21, 30000-30099 } accept

기억해야 할 방화벽이 하나 더 있습니다. 대부분의 클라우드 제공업체는 운영체제 외부의 제어 패널에서 네트워크 방화벽을 운영합니다. 서버 내부의 규칙이 올바르게 설정되었음에도 패킷이 도달하지 않는다면, 해당 제어 패널에서도 동일한 범위를 개방해야 합니다.

NAT 뒤에 있는 서버에 공인 IP 주소 알리기

서버에서 ip -4 addr show을 실행합니다. 인터페이스의 주소가 클라이언트가 접속하는 주소와 같다면 이 섹션을 건너뛰어도 됩니다. 인터페이스가 사설 주소(10.x, 172.16에서 172.31.x, 192.168.x)를 가지고 있고 플랫폼이 이를 공인 주소로 매핑하는 경우, 서버는 자신의 공인 주소를 알지 못합니다. vsftpd는 pasv_address의 기본값을 "수신된 연결 소켓에서 주소를 가져옴"으로 정의하므로, 227 응답에는 사설 주소가 포함되며 클라이언트는 도달할 수 없는 곳으로 안내됩니다.

FileZilla는 이 문제를 정확하게 명시합니다:

Server sent passive reply with unroutable address. Using server address instead.

FileZilla는 이를 수정하여 계속 진행하지만, 다른 많은 클라이언트는 그렇지 않습니다. 이들은 10.0.0.5에 연결을 시도하다가 멈춥니다.

curl 또한 이 문제를 숨기는데, curl을 테스트 도구로 사용할 경우 문제가 됩니다. 매뉴얼에 따르면 --ftp-skip-pasv-ip는 "기본적으로 활성화됨(7.74.0 버전에서 추가됨)"이므로, curl은 227 응답의 주소를 무시하고 제어 연결의 주소를 재사용합니다. curl로 작동하는 전송이 이 이유 하나만으로 그래픽 클라이언트에서는 실패할 수 있습니다.

주소를 명시적으로 설정하십시오. vsftpd는 pasv_address=203.0.113.10을 사용하며, 호스트 이름을 작성하려면 pasv_addr_resolve=YES(기본값 NO)을 함께 사용합니다. ProFTPD는 주소, DNS 이름 또는 인터페이스 이름을 허용하는 MasqueradeAddress를 사용합니다. Pure-FTPd는 "서버가 매스커레이딩(NAT) 박스 뒤에 있는" 경우를 위해 문서화된 -P을 사용합니다. EPSV은 응답에 주소 필드가 없으므로 이 문제를 완전히 피할 수 있지만, 클라이언트가 보낼 명령을 결정하므로 이에 의존할 수는 없습니다.

TLS 변경 사항

FTPS는 TLS(transport layer security)를 사용하는 FTP입니다. 클라이언트는 평소처럼 21번 포트에 연결한 뒤 AUTH TLS를 전송하여 제어 채널을 보안 상태로 만들고, 이어서 PROT P을 전송하여 데이터 채널까지 암호화합니다. 일반 FTP는 비밀번호를 평문으로 전송하므로, FTP를 반드시 사용해야 한다면 FTPS를 운영하십시오. vsftpd는 기본적으로 ssl_enable가 NO로 설정되어 있습니다.

이로 인해 두 가지 결과가 발생합니다. 첫째, 연결 추적(connection tracking) 헬퍼가 작동하지 않는데, 이는 앞서 언급한 내용을 다른 관점에서 본 것입니다. 둘째, sudo tcpdump -nAi any 'tcp port 21'은 더 이상 227 응답을 보여주지 않습니다. 따라서 서버가 어떤 주소와 포트를 알렸는지 확인해야 할 때는 네트워크 패킷을 캡처하는 대신 서버의 로그를 직접 읽어야 합니다.

외부에서 변경 사항 테스트하기

다른 머신에서 다음 명령을 실행하십시오. 서버 자체에서 테스트하면 해결하려는 방화벽을 거치지 않게 됩니다.

sudo ss -ltnp | grep :21
curl -v --disable-epsv --user ftpuser:secret ftp://example.com/
nc -vz example.com 30000

ss 명령은 FTP 데몬이 21번 포트에서 대기 중임을 보여주어야 합니다. 서버가 유휴 상태일 때는 패시브 포트 범위에서 대기 중인 항목이 없습니다. 해당 소켓은 데이터 전송을 위해 생성된 후 전송이 끝나면 닫히기 때문입니다.

--disable-epsv 명령은 curl이 PASV 경로를 강제로 사용하게 만듭니다. 이 경로는 주소 문제를 노출하는 경로입니다. 추적 결과에는 서버의 응답과 curl이 연결을 시도한 주소 및 포트가 출력됩니다.

< 227 Entering Passive Mode (203,0,113,10,117,52)

117 * 256 + 52 = 30004이며, 이는 선언된 범위 내에 있습니다. 해당 줄에 사설 주소가 표시된다면 pasv_address 설정이 누락된 것입니다. 설정한 범위 밖의 포트가 표시된다면 서버가 구성 변경 사항을 읽지 못한 것이므로, 실행 중인 서비스가 참조하는 파일을 올바르게 수정했는지 확인하십시오.

nc 명령은 방화벽 문제를 스스로 해결해 줍니다. 즉시 Connection refused 응답이 온다면 패킷이 서버에 도달했으나 대기 중인 서비스가 없다는 뜻이며, 이는 유휴 패시브 포트에서 정상적인 결과입니다. 즉, 규칙이 올바르게 작동하고 있습니다. nc가 포기할 때까지 응답이 없는 것은 패킷이 어딘가에서 조용히 폐기되었음을 의미합니다. 이는 서버 내부 방화벽이나 제공업체 패널의 방화벽 때문입니다. 이러한 차이는 SSH의 거부됨 대 시간 초과에서 설명한 것과 동일하며, 모든 포트에 동일하게 적용됩니다.

여전히 FTP를 사용해야 할까요?

새로운 작업이라면 사용하지 마십시오. SFTP(SSH file transfer protocol)는 포트 22번을 사용하는 단일 SSH 연결 내에서 실행됩니다. 두 번째 채널이나 패시브 범위, NAT 설정이 필요 없으며, OpenSSH가 이미 보안을 제공하므로 추가적인 데몬을 보호할 필요도 없습니다. sftp user@example.com는 파일 전송 서비스를 전혀 설정하지 않은 서버에서도 작동합니다. 다른 사람에게 파일만 제공하려면 sshd_config에 ForceCommand internal-sftp과 ChrootDirectory를 함께 사용하십시오. 해당 디렉터리는 root 소유여야 하며 사용자가 쓰기 권한을 가져서는 안 됩니다. 그렇지 않으면 sshd가 세션을 거부하고 bad ownership or modes for chroot directory 줄을 로그에 남깁니다.

FTP는 상대방이 환경을 변경할 수 없을 때 여전히 유용합니다. 스캐너나 다기능 프린터는 FTP만 지원하는 펌웨어를 탑재하고 있습니다. 실험실이나 산업용 장비는 아무도 재인증을 해주지 않는 고정된 이미지를 실행하는 경우가 많습니다. 비즈니스 파트너가 FTPS 드롭박스를 공개하고 특정 공급업체를 위해 프로토콜을 추가해주지 않을 때도 마찬가지입니다. 이러한 각 사례에서 패시브 범위와 일치하는 방화벽 규칙을 설정하는 것이 작업의 전부이며, 일반 FTP보다는 FTPS를 사용하는 것이 좋습니다. 두 개의 채널을 사용하는 설계는 1980년에 결정된 것으로, RFC 959가 이를 계승하기 5년 전인 RFC 765에 이미 등장했습니다. 현재 이 프로토콜은 예상치 못했던 환경에서 운영되고 있으며, 이에 대한 이야기는 파일 전송 프로토콜의 역사에서 다룹니다.

FAQ

FTP 로그인은 되는데 디렉터리 목록을 불러오다가 멈추는 이유는 무엇입니까?

로그인은 포트 21의 제어 연결만 사용하며, 이는 방화벽에서 허용된 상태입니다. 디렉터리 목록을 불러오려면 다른 포트에서 두 번째 TCP 연결이 필요한데, 이 연결이 차단된 것입니다. FTP 서버에 패시브 포트 범위를 지정하고 방화벽에서도 동일한 범위를 개방하면 목록이 정상적으로 표시됩니다. 목록 불러오기가 멈추는 현상은 데이터 채널 문제이며, 비밀번호와는 무관합니다.

FTP 패시브 모드를 위해 어떤 포트를 열어야 합니까?

제어 채널을 위한 포트 21과 패시브 데이터 연결을 위해 설정한 포트 범위를 열어야 합니다. 표준 범위는 없으며 사용자가 직접 선택합니다. 예를 들어 30000에서 30099 사이의 범위를 사용할 수 있습니다. 동시 전송량의 최대치를 고려하여 범위를 정하고, sysctl net.ipv4.ip_local_port_range으로 확인할 수 있는 커널의 아웃바운드 포트 범위와 겹치지 않게 설정하십시오. 클라우드 제공업체의 제어판에서 네트워크 방화벽을 운영 중이라면 해당 방화벽에도 동일한 범위를 개방해야 합니다.

여전히 nf_conntrack_ftp가 필요합니까?

아니요, 최신 커널에서는 이 모듈에 의존할 수 없습니다. 자동 헬퍼 할당은 기본적으로 비활성화되어 있으며, Linux 6.0부터는 net.netfilter.nf_conntrack_helper 스위치가 제거되어 sysctl를 실행하면 파일이 존재하지 않는다는 오류가 발생합니다. ufw 매뉴얼에서는 해당 모듈을 무조건 로드하는 방식을 권장하지 않으며, firewalld는 AutomaticHelpers 설정을 완전히 무시합니다. 또한 헬퍼는 제어 채널을 평문으로 읽어야 하므로 FTPS를 활성화하는 순간 작동이 중단됩니다. 대신 패시브 포트 범위를 명시적으로 설정하십시오.

FTP 클라이언트에서 패시브 응답 주소를 라우팅할 수 없다고 나오는 이유는 무엇입니까?

서버가 PASV 응답으로 자신의 인터페이스에 할당된 사설 IP 주소를 보냈기 때문입니다. 이는 플랫폼이 공인 IP를 사설 IP로 매핑할 때 발생합니다. 공인 IP를 명시적으로 설정하십시오. vsftpd는 pasv_address, ProFTPD는 MasqueradeAddress, Pure-FTPd는 -P 설정을 사용합니다. FileZilla는 이미 연결된 주소를 재사용하여 "Using server address instead"라는 로그를 남기며 우회하므로, 일부 클라이언트는 설정 오류에도 작동하지만 다른 클라이언트는 멈추게 됩니다.

FTPS와 SFTP 중 무엇을 사용해야 합니까?

양쪽 끝을 모두 제어할 수 있다면 SFTP를 사용하십시오. 포트 22의 SSH 연결 하나만 사용하므로 별도의 데이터 채널을 열 필요가 없으며 이미 실행 중인 경우가 많습니다. FTPS는 TLS 기반의 FTP이므로 두 개의 채널을 사용하는 구조와 그에 따른 모든 방화벽 문제를 그대로 안고 있습니다. 상대방이 다른 프로토콜을 지원하지 않을 때만 FTPS를 선택하십시오. 인터넷을 통해 일반 FTP를 사용하는 것은 비밀번호가 평문으로 전송되므로 절대 권장하지 않습니다.