如何判断 FTP 服务器实际记录的到底是哪个地址

一行日志只显示一个地址。笔记本带着隧道地址，连接可能从另一个出口离开，而你做的浏览器检查对 FTP 什么也证明不了。这三者可以全都不同，而日志行只记录其中一个。在比较任何东西之前，先确定你问的是哪条连接。

以下步骤假定的是有明确时间窗的授权调查，而不是翻阅别人的传输记录。

1. 确定你问的是哪条连接

FTP 使用两条连接。控制连接承载命令与应答，数据连接承载文件本身。登录事件属于前者，传输事件属于后者，因此日志中的一次会话可能包含来自两条不同网络路径的观测。在下结论之前，先写下地址字段属于哪个事件。

这种分离有实际后果。同一次会话的登录行和传输行可能带有两个不同的源地址，所以把其中任何一个说成“客户端地址”，都是在猜你读的是哪条连接。在把地址与任何东西对照之前，先核对事件类型。

2. 追踪控制连接

带调试输出运行客户端，或在客户端连接时抓包，记下它实际到达的对端。若 VPN 已建立且客户端经其路由，服务器看到的是 VPN 出口地址，而不是笔记本接入网络的地址。

如果客户端绕过隧道，服务器看到的是接入地址，而 VPN 接口自身的地址根本不会出现在链路上。这就是为什么笔记本的隧道地址通常是全图里最没用的值：它只存在于隧道内部。用 ss 或抓包确认客户端所呈现的源地址，而不是从配置界面上读。

两条命令覆盖了大部分：

ss -tnp state established "( sport = :21 or dport = :21 )"
tcpdump -ni any tcp port 21

第一条列出你自己协议栈使用的本地与对端端点。第二条显示写在链路上的地址，这更接近服务器的视角，但仍然止于你的接口，所以只有服务器的日志或它自己的抓包才能显示服务器记录了什么。

3. 检查数据连接是否一致

在被动模式下，服务器告诉客户端往哪里连；在主动模式下，服务器反向连接到客户端提供的地址。当路径中存在地址转换或代理时，两种模式都可能把数据连接送到与控制连接不同的地方。先从客户端日志确认模式，再检查数据连接是否走了同一条路径。

登录与传输记录的地址不同，是真实的观测而非损坏的记录，而且它通常说明了路径上的某些事。

4. 向运营方索要一份范围很窄的记录

把带时区的会话时间、账号、操作和目的地交给服务器运营方。询问地址字段由哪条连接产生，以及可信中间人是否改变了它的含义。

去读那台服务器实际的表结构，而不要假定每个产品都分别记录原始客户端、控制对端和数据对端，因为有些产品把整个会话汇总成一行。协议也要说清楚：SFTP 是基于 SSH 的协议，而不是换个端口的 FTP；FTPS 则是给 FTP 加上 TLS，所以日志里的服务身份取决于你部署的是哪一个。

5. 归属之前先核实

一个出口地址可以服务许多客户，而一个账号也可以从多个被允许的来源使用，所以地址和用户名并不指向同一个单位。日志记录是服务器的策略：VPN 改变了连接所呈现的来源，但不会抹掉账号名、文件名或接收服务处理过的操作。只归属记录所显示的内容，其余标为未知。WinSCP 的 FTP 说明是这种双连接模型的简明参考资料，如果你需要向别人解释的话。

两个普通情形说明这为何重要。一个办公室可以让所有用户都从同一个出口地址出去，于是一百个人在日志里只产生一个值。反过来也一样常见：同一个账号在同一周里从家庭线路和办公室线路各连一次，两条记录描述的是同一个人。