I have a situation in which one of my client have a few computers (MS Windows) behind a non routable box. They also have a tiny server (Debian).
Because the box is non routable, I cannot create any port forwarding :
neither on port 22 to the Debian server
nor on port 590X to each individual MS Windows client with TightVNC server.
I solved the problem of administrating the server remotely by creating a reversible tunnel from their Debian server to mine.
Note: The SSH tunnel is not continuously open. There's a cron job that checks every 5 minutes if I need to connect (because I create a file with a set name) and therefore create the reversible tunnel.
My second issue is the following. I read (and tried to understand) that one can create a TightVNC connection over an SSH tunnel. And I'm thinking :
Would it be possible to create a reversible tunnel from my customer's Debian server to my Debian server and use this tunnel to do VNC from my MS Windows workstation to my customer's MS Windows workstation ?
Sounds weird hey?
Well let's not be afraid to ask...
Is there anything I can do close to this fantasy?
How I would fix this issue would be by hosting a VPN on your debian server, and having the custom one connect to it. We use OpenVPN in this fashion (and in routing mode) to communicate with many servers behind NAT. All you need is to open one port on your internet router, the routable one, so that remote VPN clients can connect to it.
Connecting over VPN makes them part of an entirely new virtual network. What this does for us is creates a 172.16.x.x network branch between the server and the client(s), and a new IP address in the 172.16.x.x range for each client, which we can connect to them over with ssh. The VPN driver translates this into activity over the VPN connection itself.
Then you can just host whatever you want, and connect to the virtual IP's, without having to do torturous things to get a connection through.
And thanks so much for the idea. It sounds fantastic!
I'm now thinking of using this idea on a standard basis with all my clients.
I tried to get started with VPN in general.
And if I understand well, I can create sort of a global private network among all my customer's offices and mine. All controled by a VPN server that I'll choose to host public rather than behind my box.
It will have a public IP address (say 83.84.85.86).
Does it need to have a second NIC for the VPN address or is it just a setting in the service configuration.
Can I set it to route all traffic between my office and my customers and to route all traffic between my customers and me but not between my custmers?
All the network boxes.
If I understand well, there's nothing I need to configure given that the connection will be outgoing (from each network server to the VPN server). Is that correct?
All the network Debian servers.
I will install OpenVPN and set it to connect to the VPN server (83.84.85.86). That's it?
They usually just have one NIC. Do I just need to set them with a VPN compatible IP address?
At that point, will my Debian server be able to SSH connect to any client Debian server ?
All the network workstations.
I'd like to not set anything there. Just DHCP.
If I tell them the gateway is their local Debian server. And then if I tell the server to route requests through the VPN.
Will all the workstation look like they are in the same network?
This project seems very exciting!
I can't wait for another hint!
I know it's a lot of questions to ask so don't feel pressured and just answer whatever you have time for.
It doesn't need another real network card to work, though it does need a (fairly standard) kernel module, the "universal tun/tap" device driver (modprobe tun). That allows openvpn to create a 'tun0' network interface for it to funnel traffic through.
These tun devices are real as far as the kernel's concerned. It shows up in ifconfig and /sys/class/net, has an IP address, gets routed, and all of that. But its traffic doesn't come from a cable, it comes from openvpn.
Your remote clients would keep TCP connections open to your central server at all times. This one socket is enough to tunnel everything OpenVPN needs to act like an entire network, including connections in both directions. Traffic gets encoded and encrypted and sent across this socket where the other end decrypts and decodes it, then crams it in the tun device to turn it into an actual network request.
Sure you can divert traffic through it, just like you'd divert traffic through anything else. So probably not as easy as you were hoping.
It's not a networking override, it's just there, like any other network device is. It acts like an extra network device on your computer, plugged into a imaginary and private switch that's shared by all your VPN clients. Hence, "Virtual Private Network".
Networking-wise, the only thing your remote servers need is the ability to connect to your central server over TCP on port 1194. If they can do that, OpenVPN can operate.
They also need to be told what server to connect to, what keys to use and a few other small details. OpenVPN has a setup guide that is very straightforward for UNIX systems.
You have to set up some sort of authentication. I use static keys, myself, but there's other ways. The quick start guide shows you how.
You don't need another network card. OpenVPN uses traffic across your normal network interface to control a completely new, independent network interface. It will have its own IP address that only your VPN server and (optionally) other VPN clients can talk to.
It acts completely real. You could host an apache server on your VPN address, say, 172.16.0.22, and only things on the VPN could reach it.
Yes, though you'll need to ssh into their VPN IP addresses, not their physical IP addresses. OpenVPN will take care of the rest.
OpenVPN comes with that by default, your VPN server will auto-assign private IP's in the range you gave it to your VPN clients.
You can't route all traffic, remember? The VPN traffic itself, at least, needs to be real.
But the clients should be able to talk to each other across the VPN as if directly connected. You should be able to redirect traffic into the VPN with iptables, or set your VPN server's VPN IP as their HTTP proxy, or whatever you'd be able to do if you ran 9-mile cables between all your clients to get them on the same physical switch.
---------- Post updated at 01:50 PM ---------- Previous update was at 01:40 PM ----------
I'll try explaining in less detail how it'd work.
It's like giving your server and clients an extra "tun0" network card, assigning these cards 10.x.x.x addresses, and running long enough cables to physically connect these cards all to your server. What you do with those cables is wholly up to you -- it's just another network.
But tun0 is not a real network card, just a device driver. Kernel trickery converts traffic into tun0, to bytes read by openvpn; the same kernel trickery converts bytes written by openvpn into "real" requests emerging from tun0. Inbetween the two, all the data -- including everything needed to make connections in both directions -- is bundled through one single TCP connection on port 1194. Your real network must keep running uninterrupted for tun0 to function.
I should point out that it has some limits. In its usual mode of operation it handles pure IP traffic, so you get TCP and UDP and ping, as well as any service you could connect to TCP over. You can't put SMB, ARP, BOOTP, or other non-IP things through it. Broadcast traffic also doesn't work.
It also has a bridged mode, which can tunnel nearly anything, but that's complicated, tricky, and slow, so I don't recommend it.
