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.