Slashdot Mirror

I'm assuming that you've already discussed this with the local überBOFH and decided that ssh is not acceptable, but a tunnel is. My personal opinion of your situation is that a tunnel is only acceptable if the remote endpoint is behind a firewall with a ruleset as least as restrictive as the home network's firewall and is subject to usage rules (who has access, what is each user allowed to do, etc) at least as restrictive as those of the home network. Remember that establishing a tunnel between two nets is equivalent to connecting the two networks behind their firewalls - if someone has access to one network, he won't be bothered by the firewall on the other.

That said...

At a client site I'm currently tunneling past a NAT router (because I want to run a protocol that the router can't masquerade) by having a machine behind the router establish a connection to a machine outside. I'm using a program called Tunnel Vision (http://www.worldvisions.ca/tunnelv/, or package tunnelv on Debian), but since your firewall probably won't allow it past you should use a protocol that your firewall does allow in ways that it dosen't expect.

If your firewall allows https through, you should be able to run anything you please through port 443 as long as it's SSL-wrapped (so the firewall dosen't think anything's amiss). You could use the stunnel package (http://www.stunnel.org/, or package stunnel on Debian) for this - set a server running on port 443 of a machine outside the firewall, and start the client running inside. This will establish a stream between the two endpoints, and you can run anything you please over it - I'd choose to run pppd.

If your firewall dosen't allow https but does allow http, you can use httptunnel (http://www.nocrew.org/software/httptunnel.html, or package httptunnel on Debian). I haven't used httptunnel, so I don't know if you need to run pppd inside it. If it dosen't do strong authentication and encryption, you'll need something inside it for that, too.

These solutions require that an IP be reserved inside the firewall for the machine on the outside end. The machine inside should proxy-ARP for the machine outside.

You could also tunnel traffic over DNS queries - see http://nstx.dereference.de/nstx/ for a program that will do that - but it's doubtful that you'll need to do that.

There is a generic "hibernate" patch for the Linux kernel, but it doesn't seem to have ever made it into the main kernel tree. Too bad.

Li n4W in
WinLinux2000
All the distributions
WvDial

HTH.

If you're looking for a really easy way to get PPP up and running, have a look at WvDial. It'll auto-detect your modem, and figure out how to talk to your ISP. All you should have to give it is your username, password and phone number.

I'll take this opportunity to plug a program written by Dave Coombs and myself. WvDial automatically does the work of chat scripts, menu handling, and PAP/CHAP authentication when necessary. It works for almost everyone, the first time.

Visit the wvdial page.

Someone's working on a KDE version, and it should be available in a week or two... for now, it's just text mode, but it's really easy.

Wvdail (available here) solved all my ppp problems. When my ISP went from Ascend to Bay Networks hardware, I couldn't figure out for the life of me why my ppp script stopped working. wvdial generated a script that works with my ISP and configured ppp & my modem correctly.


BTW, I am not some linux newbie who doesn't know how to write scripts, configure software, etc. However, ppp under linux can be MUCH harder to configure than W95/98/NT. Tools like wvdial help linux become easier for people to use.