Quote:
Originally Posted by
chebarbudo
I got a few questions if you don't mind:
The public VPN server.[LIST][*]I will host it on a dedicated server at OVH.[*]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.
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.
Quote:
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?
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".
Quote:
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?
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.
Quote:
I will install OpenVPN and set it to connect to the VPN server (83.84.85.86). That's it?
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.
Quote:
They usually just have one NIC. Do I just need to set them with a VPN compatible IP address?
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.
Quote:
At that point, will my Debian server be able to SSH connect to any client Debian server?
Yes, though you'll need to ssh into their VPN IP addresses, not their physical IP addresses. OpenVPN will take care of the rest.
Quote:
I'd like to not set anything there. Just DHCP.
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.
Quote:
If I tell them the gateway is their local Debian server.
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.