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.