通过隧道颠覆
对于工作，我在一个封闭的网络中工作。我们设置了一些只能从我们的网络内部访问的 IP 地址。不过，有一个盒子，我们可以通过 SSH 进入并通过隧道到达我们各自的开发者盒子。
我知道我可以通过使用 ssh 的 -L 参数从我们的开发者盒子获取流量。我想知道是否有一种方法可以穿过我们打开的盒子，进入一个存储了 Subversion (SVN) 存储库的封闭盒子？
My computer --> Open box --> Developer boxes/SVN repository
我无法通过 ssh 进入 SVN 盒子，但是有没有办法像代理一样使用 ssh 来访问私有 Subversion 盒子？
更新：
1.1.1.1 ->开箱 1.1.1.2-> SVN 盒子
在通过打开的盒子进行隧道传输后，我可以通过 SSH 进入 SVN 盒子：
ssh [email protected]
ssh [email protected]
这将允许我访问 SVN 盒子。我想，ssh 进入打开的盒子，将 SVN 盒子的本地端口 22 转发到我的端口 22。因此
ssh [email protected] -L 22:1.1.1.2:22
，然后在命令行中使用 SVN：
svn co svn+ssh://user2@localhost/path
这会返回
svn：网络连接意外关闭
为什么会发生这种情况？ svn+ssh 是否使用了另一个我不知道的端口？
For work, I work in a closed network. There are a few IP addresses that we have set up that are only accessible from inside our network. There is one box, though, that we can SSH into and tunnel through to get to our respective developer boxes.
I know I can get traffic from our developer box by using the -L argument of ssh. I was wondering if there was a way I could tunnel through our open box, to get into a closed box were our Subversion (SVN) repository is stored?
My computer --> Open box --> Developer boxes/SVN repository
I can't ssh into the SVN box, but is there a way to use ssh like a proxy to get access to the private Subversion box?
UPDATE:
1.1.1.1 -> Open Box
1.1.1.2 -> SVN Box
I can SSH into the SVN box after I tunnel through the open box:
ssh [email protected]
ssh [email protected]
This will allow me access to the SVN box. I figure, ssh into open box, local forward port 22 of SVN box to my port 22. Thus
ssh [email protected] -L 22:1.1.1.2:22
Then using SVN in command line:
svn co svn+ssh://user2@localhost/path
This returns
svn: Network connection closed unexpectedly
Why is this happening? Does svn+ssh use another port that I am not aware of?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
是的，您应该能够进行隧道传输。我不确定您在工作时是否使用类似
svn co http://.....或类似svn checkout svn:// 的内容连接到 SVN ......我认为你想要隧道到端口 80（如果通过 http 使用）、端口 443（如果使用 https）和端口 3690（如果你只使用 svn（不使用 apache）） 。所以你的命令应该看起来像这样
然后你应该能够从本地主机签出/提交/更新/等，就好像你的本地主机是svn服务器一样。
-f 使其进入后台，这样当您想要它进行隧道传输时，您就不会看到终端卡在公共服务器 shell 提示符处。 -N 表示不执行远程命令。
Yes, you should be able to tunnel. I'm not sure if you're connecting to SVN when at work using something like this
svn co http://.....or something like thissvn checkout svn://......I think you want to tunnel to either port 80 (if using over http), port 443 (if using https), and port 3690 if you're using just svn (not using apache). So your command should look something like this
Then you should be able to check out/commit/update/etc from your localhost as though your localhost was the svn server.
The -f makes it go background so you don't see the terminal stuck at your public servers shell prompt when all you wanted it for was tunneling. The -N says to not execute a remote command.
我们公司也有同样的情况。如果不使用 VPN 访问“内部”网络，我能想到的唯一选择是在网络上打一个洞以允许访问您的特定盒子。我们通常在 netscalar 中创建一个指向内部盒子的虚拟 IP 地址，以保护内部盒子免受“命名”暴露。
我建议与您的网络团队合作创建此设置，或者如果您没有网络团队，请查看路由器设置以创建此连接。
We have the same in my company. Short of using VPN to access the "internal" network, your only option I can think of would be to punch a hole in the network to allow access to your specific box. We typically create a virtual IP address in netscalar that points to the internal box to shield the internal box from "named" exposure.
I recommend working with your networking team to create this setup or if you don't have a network team, look into router settings to create this connection.