通過 SSL (ftps) 連接到被動 FTP
我已經使用本指南在 Windows Azure 中設置了 FTP 服務http://www.itq.nl/blogs/post/Walkthrough-Hosting-FTP-on-IIS-75-in-Windows-Azure-VM.aspx
當我在辦公室防火牆後面工作時不使用 SSL 連接時，FTP 伺服器執行良好。
但是當我嘗試連接 SSL（埠 21，AUTH TLS - Explicit，CuteFTP）時，我得到了超時。當我在家裡做同樣的事情時，連接工作（SSL）。我究竟做錯了什麼？SSL 連接是否使用其他埠？
身份驗證工作正常，當客戶端發送 LIST 命令時超時
STATUS:> [11.02.2013 12:56:28] Using UTF-8. STATUS:> [11.02.2013 12:56:28] This site can resume broken downloads. COMMAND:> [11.02.2013 12:56:28] REST 0 [11.02.2013 12:56:28] 350 Restarting at 0. COMMAND:> [11.02.2013 12:56:28] PBSZ 0 [11.02.2013 12:56:28] 200 PBSZ command successful. COMMAND:> [11.02.2013 12:56:28] PROT P [11.02.2013 12:56:28] 200 PROT command successful. COMMAND:> [11.02.2013 12:56:28] PASV [11.02.2013 12:56:28] 227 Entering Passive Mode (***,**,**,201,27,92). COMMAND:> [11.02.2013 12:56:28] LIST STATUS:> [11.02.2013 12:56:28] Connecting FTP data socket... ***.**.**.201:7004... ERROR:> [11.02.2013 12:56:49] The connection failed due to an error or timeout.我讀過一些關於 FTPS 和 NAT 的問題，但沒有完全理解
啊，這更有意義。這裡的問題是 FTP 的雙通道特性，加上加密，加上（很可能）一個自適應防火牆。
當 FTP 控制連接請求一些數據（包括目錄列表）時，會發生什麼情況是建立了一個新連接；從伺服器到客戶端以 ACTIVE 模式（不常見）或從客戶端到伺服器以 PASSIVE 模式（更常見）。
此連接的詳細資訊在控制通道上達成一致，新連接以適合模式的方向打開，然後數據流動（我將假設在此答案的其餘部分是被動模式；事情類似，但如果您嘗試使用 ACTIVE 模式，則更複雜）。
除非有防火牆。如果防火牆不允許從內部到外部的任意 TCP 連接，則無法建立數據通道。
除非防火牆很聰明，並且正在監視控制數據流，尋找作為
PORT正在建構數據通道的前兆的 FTP 命令。然後，一個聰明的防火牆將在該數據通道的持續時間內打開一個臨時權限和/或埠映射。這通常稱為自適應防火牆。除非控制通道是端到端加密的，否則防火牆不知道正在協商數據通道，因此無法授予臨時權限。
那有意義嗎？基本上，您使用 SSL 很可能會阻止您的防火牆知道它應該對此變得聰明，這就是為什麼它可以在辦公室沒有 SSL 的情況下工作，並且在您可能沒有如此復雜的防火牆的家裡也可以正常工作。
在不放棄加密的情況下在辦公室工作的唯一方法是讓防火牆管理員允許您從桌面到 ftp 伺服器進行任意 TCP 連接。