我已经使用本指南在 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 问题的文章,但没太明白
答案1
啊,这更有道理。这里的问题是 FTP 的双通道特性,加上加密,再加上(最有可能)自适应防火墙途中。
当 FTP 控制连接请求某些数据(包括目录列表)时,将建立一个新连接;以主动模式从服务器到客户端(不常见)或以被动模式从客户端到服务器(更常见)。
该连接的细节通过控制通道商定,新的连接以适合模式的方向打开,然后数据流动(对于这个答案的其余部分,我假设它是被动模式;如果你尝试使用主动模式,情况类似,但更加复杂)。
除非有防火墙。如果防火墙不允许从内部到外部的任意 TCP 连接,则无法建立数据通道。
除非防火墙很聪明,它正在监视控制数据流,寻找PORT
建立数据通道的前兆 FTP 命令。然后,一个聪明的防火墙将在该数据通道的持续时间内打开临时权限和/或端口映射。这通常称为自适应防火墙。
除非控制通道是端到端加密的,在这种情况下,防火墙不知道数据通道正在协商,并且无法授予临时权限。
这有道理吗?基本上,您使用 SSL 很可能使防火墙无法知道它应该对此采取巧妙措施,这就是为什么它在办公室无需 SSL 即可工作,而在家里工作正常,因为您可能没有如此复杂的防火墙。
在不放弃加密的情况下从办公室运行此功能的唯一方法是让防火墙管理员允许您从桌面到 ftp 服务器建立任意 TCP 连接。