文章/答案/技术大牛

发布

社区首页 >问答首页 >跟踪活动FTP会话(数据通道)

问跟踪活动FTP会话(数据通道)
EN

Server Fault用户

提问于 2019-07-09 01:31:19

回答 1查看 1.2K关注 0票数 1

要调试active FTP的问题，我们使用运行在GKE节点上的工具箱容器中的tcpdump跟踪活动FTP会话通信量。活动FTP会话在数据通道上失败。

我很熟悉主动模式和被动模式FTP之间的区别(我们的平台必须支持这两种模式，只要有可能我们就使用被动模式)。

为了调试失败的活动FTP数据通道，我们正在跟踪成功的活动FTP会话，以澄清在我们的环境中使用FTP服务器实现的流程。这里的问题是：

在成功的活动FTP会话

中从数据通道捕获数据包

看一看本期，尽管类似，它似乎没有解决，我们的情况可能会有所不同。跟踪运行时：

tcpdump -vnn -w 002.pcap -i eth0

然后在Wireshark中打开pcap。对FTP协议的筛选清楚地显示了会话的控制通道部分。FTP客户端/服务器通信在客户端的临时端口和服务器端口21之间都与预期的一样。该流程包括用于身份验证的预期命令、将类型I、CWD设置为正确的文件夹、大小、端口和文件名的RETR。

PORT命令看起来很好，包括服务器在会话的后续数据通道部分中使用的客户机IP和端口(用于下载一个文件)。例如：

PORT 1,2,3,4,51,105

它将( 51x256+105 )转换为端口13161。

然而，在Wireshark，之后：

client:27154 > server:21 RETR <filename>
server:21    > client:27154 150 File status okay; about to open data connection.

捕获的唯一附加数据包是：

server:21    > client:27154 226 Transfer complete.
client:27154 > server:21 6 QUIT
server:21    > client:27154 221 Goodbye.

我们的FTP服务器实现不使用端口20作为数据通道，它使用随机可用端口。无论如何，我们希望看到服务器建立数据通道，如下所示：

server:<random port> > client:13161

再加上一两行，显示实际的转移。

tcpdump本身是问题所在吗？
还有别的吗？

谢谢。

ftp

tcpdump

回答 1

Server Fault用户

回答已采纳

发布于 2019-07-10 13:56:05

这是我的错误。在检查RFC 959及其对I类(图像/二进制)数据通道的描述之后，调整Wireshark中的视图，使其按顺序(按时间)进行跟踪；数据通道的TCP数据包实际上是存在的。

对于在控制通道中使用活动FTP执行此操作的任何人：

给出这样的请求大小响应：

FTP ... Response: 213 3981

它表示文件大小为3981字节，以及如下所示的PORT命令：

FTP ... Request: PORT 1,2,3,4,51,105

它指示服务器在数据通道启动时与客户端建立TCP连接时要使用的IP和端口。

要将第5和第6八进制转换为端口号，请执行以下操作：

51x256+105 = 13161

Wireshark应该像这样显示数据通道数据包：

No. | Time      | Source    | Destination   | Protocol   | Length   | Info
----------------------------------------------------------------------------------------------------------------------------------------------------------------
89  | 6.982066  | 10.5.4.3  | 1.2.3.4       | TCP        | 76       | 33841 → 13161 [SYN] Seq=0 Win=28400 Len=0 MSS=1420 SACK_PERM=1 TSval=3979605739 TSecr=0 WS=128
93  | 7.390712  | 1.2.3.4   | 10.5.4.3      | TCP        | 64       | 13161 → 33841 [SYN, ACK] Seq=0 Ack=1 Win=64240 Len=0 MSS=1360 SACK_PERM=1
98  | 7.390818  | 10.5.4.3  | 1.2.3.4       | TCP        | 56       | 33841 → 13161 [ACK] Seq=1 Ack=1 Win=28400 Len=0
101 | 7.395054  | 10.5.4.3  | 1.2.3.4       | TCP        | 2776     | 33841 → 13161 [ACK] Seq=1 Ack=1 Win=28400 Len=2720
104 | 7.395068  | 10.5.4.3  | 1.2.3.4       | TCP        | 1317     | 33841 → 13161 [PSH, ACK] Seq=2721 Ack=1 Win=28400 Len=1261
107 | 7.395096  | 10.5.4.3  | 1.2.3.4       | TCP        | 56       | 33841 → 13161 [FIN, ACK] Seq=3982 Ack=1 Win=28400 Len=0

上面的TCP数据包显示了三种TCP握手方式: SYN，SYN，ACK，然后是实际的二进制传输.您可以将数据包101和104的有效负载长度(在Info列中)相加，以使文件大小在控制通道中得到确认。

Len=2720 + Len=1261 = 3981

然后，您应该在控制通道中看到最终的FTP 226确认：

FTP ... Response: 226 Transfer complete.

票数 0

页面原文内容由Server Fault提供。腾讯云小微IT领域专用引擎提供翻译支持

原文链接：

https://serverfault.com/questions/974455

复制

相似问题

问跟踪活动FTP会话(数据通道)
EN

在成功的活动FTP会话

回答 1

Server Fault用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问跟踪活动FTP会话(数据通道)EN

在成功的活动FTP会话

回答 1

Server Fault用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问跟踪活动FTP会话(数据通道)
EN