我所在的组织对安全要求（不必要地）严格。去年，我们在一台云机器上设置了一个 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 隧道的流量？
- 如果不是，那么哪个组件可能有问题？