[kwlug-disc] reverse tunnel? vpn over ssh?

[unsolicited]

Richard Weait wrote, On 08/17/2009 10:47 PM:
> I have a box I can reach on my DMZ.  I allow incoming web requests
> through the firewall to the DMZ box.  It can then reply to the
> request. But if you do crack this box, it can't connect out.  The
> firewall won't allow it.  Great.  Defense in depth and all.
> 
> I can reach this box from my internal network and start/stop services.
>  Configure stuff.  Great.  But I can't get it to update from the web.
> It can't dial out.  I'd like to apply updates without unplugging eth
> cables.
> 
> Lots of examples cover connecting boxes that can't see each other but
> can each connect to another box.  When the configuration looks like
> 
> A --> public box <-- B
> 
> SSH reverse tunneling looks to be the right tool for the job.  That's
> the gotomypc-type solution.
> 
> My configuration is essentially:
> 
> internet  <-- desktop --> DMZ

Your desktop is the hub to the DMZ network? i.e. All internet traffic 
traverses your (desktop) to get to the DMZ upon which your web server is?

FWIW you might consider a VLAN instead. For that matter, you could 
enable outgoing www via the other vlan, where you could place 
controls, such as if requesting internet from this vlan, let it go 
through. More conditions would apply, but perhaps worth considering.

> I'd like to, from my desktop, say "Hi DMZ box, I'm logging in. Here is
> a temporary connection to the internet that will disappear when I log
> out."
> 
> Help me lazyweb?

I don't have the exact answer, not having done exactly this, but I 
think you're talking a web proxy (out) [or perhaps socks] on the web 
server, forwarding to your ssh tunnel. No ssh tunnel, it ain't going 
nowhere.

And, ssh will let you tunnel ports both ways. With the right 
local/remote port settings on the ssh command line, traffic to the 
designated port on your own PC is forwarded to the other end of the 
tunnel. e.g. 127.0.0.1 80 ->{tunnel ip}. This is somewhat standard. I 
do this, for example, to connect to my ssh server, then vnc 
localhost:{port}, and using different {port}s lets me hit different 
computers in the house.

	The reverse is also true: you might proxy 127.0.0.1:80 on the web 
server to your machine as gateway via the ssh tunnel. You should be 
able to test this with ssh alone, without diving into a proxy (if it's 
even necessary).

	Note: The proxy may really be necessary - you could ssh in, etc., but 
web requests would still go out your default gateway. Which isn't your 
tunnel. Whereas a proxy could have the hardcoded tunnel ip to forward 
web requests to. Or, iptables on the web server could say any 
non-internal web requests and replies go out your gateway, and then a 
gateway rule saying everything goes via your desktop (or ssh tunnel).


This really is no different than running an isolated vm (webserver), 
so if you do web research, answers to that should provide answers to 
your specifics.

On the other hand ... not as elegant, I know, couldn't you allow the 
webserver out to the repository ip's, only?

  Or, mirror the repository on your desktop, and have the web server 
use your desktop as a local repository? I know, there's an ick factor 
to that.