跟踪活動 FTP 會話（數據通道）
為了調試活動 FTP 的問題，我們正在使用在 GKE 節點上的工具箱容器中執行的 tcpdump 跟踪活動的 FTP 會話流量。活動 FTP 會話在數據通道上失敗。
我熟悉主動模式和被動模式 FTP 之間的區別（我們的平台必須同時支持這兩種模式，並且我們盡可能使用被動模式）。
為了調試失敗的活動 FTP 數據通道，我們正在跟踪成功的活動 FTP 會話，以通過我們的 FTP 伺服器實現來闡明我們環境中的流。這裡的問題是：
在成功的活動 FTP 會話中從數據通道擷取數據包
看過這個問題，雖然類似，但似乎沒有解決，我們的情況可能會有所不同。跟踪執行：
tcpdump -vnn -w 002.pcap -i eth0然後在 Wireshark 中打開 pcap 文件。過濾 FTP 協議清楚地顯示了會話的控制通道部分。客戶端的臨時埠和伺服器埠 21 之間的 FTP 客戶端/伺服器通信完全符合預期。此流程包括預期的身份驗證命令、設置 TYPE I、到正確文件夾的 CWD、SIZE、PORT 和 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 過濾本身是問題嗎？
- 還有什麼？
謝謝你。
這是我的錯誤。檢查RFC 959及其對 TYPE I（圖像/二進制）數據通道的描述，並調整 Wireshark 中的視圖以簡單地按順序（按時間）跟踪；數據通道的 TCP 數據包實際上就在那裡。
對於在控制通道中使用活動 FTP 遇到此問題的任何人：
給定對 REQUEST SIZE 的響應，如下所示：
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 數據包顯示了 3 次 TCP 握手：SYN、SYN-ACK、ACK，然後是實際的二進制傳輸。您可以將數據包 101 和 104 中的有效負載長度（在 Info 列中）相加，以獲得在控制通道中較早確認的文件大小。
Len=2720 + Len=1261 = 3981然後您應該在控制通道中看到最終的 FTP 226 確認：
FTP ... Response: 226 Transfer complete.