This shows you the differences between two versions of the page.
Both sides previous revisionPrevious revisionNext revision | Previous revision | ||
computing:vpnserver-debian [2023/05/21 20:49] – oemb1905 | computing:vpnserver-debian [2024/02/17 19:43] (current) – created oemb1905 | ||
---|---|---|---|
Line 3: | Line 3: | ||
* **Jonathan Haack** | * **Jonathan Haack** | ||
* **Haack' | * **Haack' | ||
- | * **netcmnd@jonathanhaack.com** | + | * **webmaster@haacksnetworking.org** |
------------------------------------------- | ------------------------------------------- | ||
Line 11: | Line 11: | ||
------------------------------------------- | ------------------------------------------- | ||
- | This tutorial is for installing a simple openvpn server on a public facing VPS and/or self-hosted virtualization stack. In my case, I am using a slim Debian boot OS, with two zfs pools in RAID10 or two-way mirror setups. I use virsh primarily and/or virt-manager with qemu/kvm to manage the stack. The full setup can be found here [[https:// | + | This tutorial is for installing a simple openvpn server on a public facing VPS and/or self-hosted virtualization stack. In my case, I am using a slim Debian boot OS, with two zfs pools in RAID10 or two-way mirror setups. I use virsh primarily and/or virt-manager with qemu/kvm to manage the stack. The full setup can be found here [[https:// |
sudo apt update | sudo apt update | ||
Line 21: | Line 21: | ||
cp -r / | cp -r / | ||
| | ||
- | Navigate inside of the easy-rsa directory (the one you just made by copying) and start building the server by initializing the pki tool, building your certificate authority, generating diffyhelmen for strong key exchange, and then building sudo ufw allow from 192.168.123.0/24 to any port 22 | + | Navigate inside of the easy-rsa directory (the one you just made by copying) and start building the server by initializing the pki tool, building your certificate authority, generating diffyhelmen for strong key exchange, and then building sudo ufw allow from 192.168.147.0/24 to any port 22 |
the openvpn server itself which will leverage these: | the openvpn server itself which will leverage these: | ||
Line 47: | Line 47: | ||
nano / | nano / | ||
- | < | + | < |
Note that for the above static assignment to work on the client, you must add '' | Note that for the above static assignment to work on the client, you must add '' | ||
Line 61: | Line 61: | ||
Let's make sure the firewall only permits vpn server traffic and ssh from a private subnet as per the design mentioned at the outset: | Let's make sure the firewall only permits vpn server traffic and ssh from a private subnet as per the design mentioned at the outset: | ||
- | ufw allow 1184/udp | + | ufw allow 1194/udp |
- | ufw allow from 192.168.123.0/24 to any port 22 | + | ufw allow from 192.168.147.0/24 to any port 22 |
+ | sudo ufw allow from 73.42.113.16 to any port 22 proto tcp [optional allowance from static external] | ||
| | ||
+ | The server is now setup, so time to build the client files on the server, build a client configuration file and test the connection. Copy all the generated files to a dedicated client directory for safekeeping/ | ||
+ | cd / | ||
+ | ./easyrsa build-client-full client nopass | ||
+ | cp -p / | ||
+ | cp -rp / | ||
+ | cp -rp / | ||
+ | | ||
+ | From your client, pull the files: | ||
+ | scp -r user@remotehost.com:/ | ||
+ | |||
+ | On your localhost, create a client configuration file to leverage these files and connect to the openvpn server. I also included my config as an example below. | ||
+ | |||
+ | nano / | ||
| | ||
+ | [[https:// | ||
+ | To test if everything is working, run openvpn against the config file as follows: | ||
+ | |||
+ | sudo openvpn remotehost.com.ovpn | ||
+ | | ||
+ | If everything works, you will get a final message of '' | ||
+ | |||
+ | chmod 600 client.key | ||
+ | chmod 640 ca.crt. client.crt. remotehost.com.ovpn | ||
+ | |||
+ | That should be it! To test, try shelling into the physical host of the virtualization stack: | ||
+ | |||
+ | ssh root@192.168.122.1 | ||
+ | | ||
+ | For traffic redirection, | ||
+ | |||
+ | nano / | ||
+ | < | ||
+ | nano / | ||
+ | < | ||
+ | <: | ||
+ | <-A POSTROUTING -s 192.168.147.0/ | ||
+ | < | ||
+ | nano / | ||
+ | < | ||
+ | sysctl -p | ||
+ | |||
+ | This enables masquerading, | ||
+ | |||
+ | redirect-gateway def1 | ||
+ | | ||
+ | I wrote some scripts to automate some of the aspects of server and client generation: | ||
+ | * [[https:// | ||
+ | --- // |