Subversion through a tunnel

问题:

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 user1@1.1.1.1
ssh user2@1.1.1.2

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 user1@1.1.1.1 -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?

回答1:

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 this svn 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

ssh -f [e-mail] -L 3690:your.internal.svn.server:3690 -N

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.

回答2:

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.