![SVN通过端口转发隧道“网络连接意外关闭”](https://linux22.com/image/799967/SVN%E9%80%9A%E8%BF%87%E7%AB%AF%E5%8F%A3%E8%BD%AC%E5%8F%91%E9%9A%A7%E9%81%93%E2%80%9C%E7%BD%91%E7%BB%9C%E8%BF%9E%E6%8E%A5%E6%84%8F%E5%A4%96%E5%85%B3%E9%97%AD%E2%80%9D.png)
我所在的组织对安全要求(不必要地)严格。去年,我们在一台云机器上设置了一个 SVN 服务器。这台机器的要求规定,唯一批准的访问方法是通过 RSA 令牌进行双因素身份验证。
这意味着我们不能使用 svn+ssh://,因为开发人员必须使用不方便的 RSA 令牌执行每个 SVN 操作。但我们也不能天真地使用 svn://,因为(但愿不会)人们可以在不使用双因素令牌的情况下访问 SVN 服务器上的数据。
最终,我们开发了一个复杂的端口转发系统。服务器有一个典型的svnserve
守护进程监听 3690 上的连接,但防火墙阻止了除 之外的所有到该端口的连接localhost
。如果用户不在中心,他们必须先通过 VPN 进入网络。用户将创建到服务器的 SSH 隧道,并将端口(例如)6789 转发到服务器上的端口 3690(SVN 端口)(换句话说ssh user@server -L 6789:localhost:3690
)。只要 SSH 会话保持打开状态,用户就可以通过引用该端口使用常规 svn URL:例如svn://localhost:6789/path/to/repository/trunk
。
这种方法已经使用了大约一年,适用于 *nix 系统和 Windows(使用 PuTTY 和 TortoiseSVN)。现在,我们遇到了一个问题,因为有一位新团队成员使用 Windows/TortoiseSVN。她可以通过 VPN 进入并启动带端口转发的 SSH 会话,但当她实际检查某些内容时(参见上面的示例路径),她收到以下消息:“网络连接意外关闭。”PuTTY 会话没有显示任何错误消息或结束,所以我不太确定这是服务器的问题。我已经独立测试了她的机器通过 6789 端口监听自身的能力。
我不确定系统中的哪个组件出了问题:TortoiseSVN、PuTTY、她电脑的防火墙设置、她网络的防火墙设置、我们服务器的防火墙设置,还是 svnserve 进程。我怀疑是她的防火墙设置出了问题,因为这是她与其他人唯一不同的地方。但是防火墙怎么能阻止通过 SSH 端口转发隧道的流量呢?所有流量都应该通过端口 22,所以如果 SSH 连接一开始就能成功建立,流量就应该通过。我被难住了。
所以:
- 你们中有人在隧道上观察到过 SVN 的类似行为或遇到过类似的情况吗?如果是这样,问题的原因是什么?如何解决?(我怀疑会有很多人遇到类似的问题,因此以下是更普遍的问题。)
- 防火墙是否有可能阻止通过已建立的 SSH 隧道的流量?
- 如果不是,那么哪个组件可能有问题?