Mar*_*tin 1 firewall ftp sftp ftps
我已经使用本指南在 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.
Run Code Online (Sandbox Code Playgroud)
我读过一些有关 FTPS 和 NAT 问题的文章,但没有完全理解
啊,这更有意义。这里的问题是 FTP 的双通道性质,加上加密,加上(很可能)途中的自适应防火墙。
当 FTP 控制连接请求某些数据(包括目录列表)时,会建立一个新连接;从服务器到客户端以主动模式(不常见)或从客户端到服务器以被动模式(更常见)。
此连接的详细信息通过控制通道达成一致,新连接以适合模式的方向打开,然后数据流动(对于本答案的其余部分,我假设它是被动模式;事情是相似的,但是如果您尝试使用活动模式,则更加复杂)。
除非有防火墙。如果防火墙不允许从内到外的任意TCP连接,那么数据通道就无法建立。
除非防火墙很聪明,并且正在监视控制数据流,寻找作为PORT正在构建的数据通道的先驱的 FTP 命令。然后,聪明的防火墙将在该数据通道的持续时间内开放临时权限和/或端口映射。这通常称为自适应防火墙。
除非控制通道是端到端加密的,否则防火墙不知道正在协商数据通道,并且无法授予临时权限。
那有意义吗?基本上,您对 SSL 的使用很可能会阻止您的防火墙知道它应该对此进行巧妙处理,这就是为什么它在办公室无需 SSL 的情况下也能正常工作,而在您可能没有如此复杂的防火墙的家里也能正常工作。
在不放弃加密的情况下在办公室实现此功能的唯一方法是让防火墙管理员允许您从桌面到 ftp 服务器建立任意 TCP 出站连接。
| 归档时间: |
|
| 查看次数: |
5761 次 |
| 最近记录: |