VPN 的保护在通往 FTP 服务器的路上止于何处

VPN 保护一条路径，而路径总有尽头。当隧道在公司网关处终止时，文件传输从那里继续，依赖其自身协议提供的保护。这一区别决定了传输是端到端受保护，还是只保护到网关。Connected 指示灯对这两种情况都不作说明。

两种部署，两条剩余路径

设想一台笔记本电脑接入公司 VPN，随后向另一台内部服务器发起 FTP 会话。隧道止于网关，而从网关到那台服务器的网段位于隧道之外。

明文 FTP 不会因为数据包经由隧道到达就获得加密。在剩余的那段路上，命令、凭据和文件内容完全按协议规定的方式传输，也就是明文。这是否要紧取决于拓扑以及该网段还有哪些防护，把地址称作私有并不能回答问题。当服务器位于网关还要再跳一次才能到达的云网络时，同样的推理反向成立。

把 VPN 端点与 FTP 服务放在同一台机器上，就不存在需要担心的后续网段。那是另一种部署，而不是证明主机上的进程、文件和凭据安全的依据。

明文 FTP、FTPS 与 SFTP 是三个决定

明文 FTP 不加密任何内容，连密码也不加密。FTPS 为 FTP 加上 TLS，因此控制通道以及协商后的数据通道受到保护。SFTP 是在 SSH 内部承载的另一种协议，并不是 FTPS 的另一种写法。

服务器必须支持这一选择，因为客户端无法凭空造出一个并不存在的监听。选择 SFTP 不会把仅支持 FTP 的服务变成 SSH 端点，重命名书签或更改端口也不能证明协商了什么。既要从服务器侧也要从客户端侧确认协议。文件管理器里的锁形图标只是对会话的声明，而不是对其背后监听的声明。

传输要紧时请看最后一列，因为意外的身份变化正是在那里显现。

数据连接是第二条连接

FTP 先打开控制连接，然后为列表和传输分别打开数据连接。受保护的登录并不能说明后续这些连接的情况，除非部署同样要求它们受保护。

使用 FTPS 时，客户端通过特定命令请求受保护的数据通道，而服务器策略可以拒绝明文替代方案。要核实策略确实要求这样做，而不是假定客户端默认值就够了。被动模式带来第二个麻烦，因为服务器会通告数据连接所用的地址和端口。重写或封锁该通告的防火墙或 NAT 设备，会造成一个通过认证却在首次列表时卡住的会话。

curl -vk ftps://files.corp.example/ --user alice --ftp-ssl-control
openssl s_client -connect files.corp.example:21 -starttls ftp
ss -tnp | grep -E ':21|:990'

第二条命令显示服务器在触碰任何文件之前于控制通道上呈现什么。第三条显示数据连接是否曾经建立，这就是认证失败与被动模式失败的区别。

身份核验能穿过隧道

FTPS 客户端会验证 TLS 服务器身份，而 SFTP 客户端会验证 SSH 主机密钥。两项核验都属于文件传输协议，VPN 一项都不做。

当中间有设备想检查会话时，这种分离就很重要。为了让网络设备读取命令而关闭 TLS，是在改变保护模型而不是补全它；因为隧道已建立就接受来路不明的主机密钥，也是同样的道理。保留既定的信任配置，并从运营方取得正确的材料。通过认证的隧道并不说明其远端服务器的情况。

这些协议的私钥与证书材料又是第三份秘密，与 VPN 凭据分开。

记录你实际核实了什么

选一个你有权移动的无害文件，记下这次尝试的四项事实：运行了哪种协议、核验了对方的哪个身份、预期走哪条路径，以及传输是否完成。

lftp -u alice -e "set ftp:ssl-protect-data true; ls; bye" ftps://files.corp.example
sftp -v [email protected]

目录列表、隧道登录和完成的传输是三种不同的观察，只有最后一项能说明这条路径对文件可用。如果设计在剩余的一跳上只靠 VPN 保证机密性，就把它当作一项决定写下来。一份写明这一跳及其信任假设的验收记录，比一张已连接客户端的截图更有价值。