Easy Rsa Command to Build Sha Signed Keys
Tech —
How to build your own VPN if you're (rightfully) wary of commercial options
While not perfect, either, cloud hosting providers have a better customer data record.
Enlarge / The first step to improved security is making sure it stays improved.
Installing and configuring OpenVPN server
OK, now it's time for the chewy part. The packages you'll need are openvpn and easy-rsa.
root@ars-vpn-test:~$ apt install openvpn easy-rsa
Seriously, that was all there was to the installation, but now it's time to start configuring. First of all, we need to enable ipv4 packet forwarding:
root@ars-vpn-test:~$ nano /etc/sysctl.conf
All you need to do in here is find the line that says #net.ipv4.ip_forward = 1 and remove the leading pound sign ("hashtag", for you young'uns). This uncomments the line, enabling it to take effect. Press ctrl-X to exit and Y to say Yes, you'd like to save it, and you're back at the command prompt again.
root@ars-vpn-test:~$ sysctl -p
The system will inform you that you've set the value net.ipv4.ip_forward = 1. Congratulations, you're ready to route. Next step is getting the helpful scripts from the easy-rsa package in place and using them to generate your own private Certificate Authority.
root@ars-vpn-test:~$ cp -a /usr/share/easy-rsa/* /etc/openvpn/ root@ars-vpn-test:~$ cd /etc/openvpn root@ars-vpn-test:/etc/openvpn$ nano vars
The /etc/openvpn/vars file contains three really important settings - KEY_SIZE, which controls just what it sounds like and should be set to a minimum of 2048 (I use 4096); and CA_EXPIRE and KEY_EXPIRE, which control how long your keys are good for, with a default 10-year expiration date. Expired keys don't work anymore, so this is basically a drop-dead date for your VPN configuration. After these dates come and go, you'll have to regenerate and re-distribute your keys again.
You should generally change the rest of the values—KEY_COUNTRY, KEY_PROVINCE, and so forth—to match what makes sense for you, but these are basically human-readable fluff, and the computer doesn't particularly care what's in there. Anything, including the default values, will work.
Once you've CTRL-X'ed and Y'ed your way out of vars and saved it, it's time to get back to work at the shell.
root@ars-vpn-test:/etc/openvpn$ source ./vars root@ars-vpn-test:/etc/openvpn$ ./clean-all
You'll get some dire warnings about deleting all your keys here—ignore it. Running a preparatory ./clean-all is a mandatory step on modern OpenVPN installations. Just don't run it again unless you want to lose all your keys and certificates.
root@ars-vpn-test:/etc/openvpn$ ./build-ca root@ars-vpn-test:/etc/openvpn$ ./build-key-server server
There will be quite a lot of pressing [enter] through these steps to confirm the default values you set in vars earlier. You can just enter your way through, but be sure to actually press Y twice at the end to first sign the certificate, then commit it. Our next step will be building the Diffie-Hellman key, with the ./build-dh command. You need to specify a keysize argument on the command line for this one. More is generally better, so I went with a 4096 bit key... which took quite a while to generate; 26 minutes and 35 seconds, to be exact. Once you get this process started, you might want to go watch a TV show or something. It will be a while.
root@ars-vpn-test:/etc/openvpn$ ./build-dh 4096
Now you're ready to create your actual certificates and keys. Remember how many times you had to press [enter] when you created your CA certificate and your server key a couple of steps above? If you found that annoying, you might want to do some purely optional prep work here. The build-key and build-key-pass tools are both human-readable scripts that invoke pkitool. Both of them can be edited to remove the --interact argument that they pass it by default, which results in that obnoxious ten-in-a-row [enter] sequence. Instead of editing that line directly (and maybe screwing it up and not knowing how to get it back to the original), copy the line, paste it into a new one, then comment out the first line with a pound sign. Once that's done, remove the --interact argument in the second line you pasted in. For build-key, you should wind up with this:
#!/bin/sh # Make a certificate/private key pair using a locally generated # root certificate. export EASY_RSA="${EASY_RSA:-.}" #"$EASY_RSA/pkitool" --interact $* "$EASY_RSA/pkitool" $* ... and for build-key-pass, you'll wind up with this:
#!/bin/sh # Similar to build-key, but protect the private key # with a password. export EASY_RSA="${EASY_RSA:-.}" #"$EASY_RSA/pkitool" --interact --pass $* "$EASY_RSA/pkitool" --pass $* Once you've edited and saved both of these (or ignored this step, if you don't mind wearing the paint off your Enter key), you're ready to actually generate some keys and certificates to authenticate with. I generated three keypairs—client-no-pass, client-with-pass, and R8000—the latter being intended for use with my handy-dandy Netgear router with DD-WRT firmware.
root@ars-vpn-test:/etc/openvpn$ ./build-key R8000 root@ars-vpn-test:/etc/openvpn$ ./build-key client-no-pass root@ars-vpn-test:/etc/openvpn$ ./build-key-pass client-with-pass
Much like when we generated an SSH keypair earlier, the difference between keys generated with build-key and build-key-pass is that the first work "naked," but the second will require a challenge phrase to be entered in when the OpenVPN tunnel is started each time. In general, keypairs with a challenge are more appropriate for credentials you'll use directly at your computer or phone and start and stop manually, while keypairs without a challenge phrase are more appropriate for unattended use in which devices might automatically start and stop tunnels without user intervention. (DD-WRT can actually use keypairs with challenge phrases, but in doing so it subverts most of the point: you have to save the challenge phrase in the configs; so presumably an attacker that got hold of the keypair would be able to get hold of the challenge phrase just as easily.)
Now that you've got your credentials generated, it's time to configure the server itself. First, let's grab a reference copy of a typical-ish OpenVPN server config from where the packages left it:
root@ars-vpn-test:/etc/openvpn$ cp /usr/share/doc/openvpn/examples/sample-config-files/server.conf.gz /etc/openvpn/ root@ars-vpn-test:/etc/openvpn$ gunzip ./server.conf.gz root@ars-vpn-test:/etc/openvpn$ mv server.conf server.conf.dist
It can be pretty overwhelming wading through the mass of comments in that default config file, so we're going to rename it something safe—server.conf.dist , so that the system won't try to execute it—and just start over with a clean file. That will look like this:
# /etc/openvpn/server.conf - Ars Technica Edition port 1194 proto udp dev tun ca /etc/openvpn/keys/ca.crt cert /etc/openvpn/keys/server.crt key /etc/openvpn/keys/server.key # This file should be kept secret dh /etc/openvpn/keys/dh4096.pem cipher AES-256-CBC auth SHA512 server 10.8.0.0 255.255.255.0 push "redirect-gateway def1 bypass-dhcp" push "dhcp-option DNS 8.8.8.8" push "dhcp-option DNS 8.8.4.4" ifconfig-pool-persist ipp.txt keepalive 10 120 comp-lzo persist-key persist-tun status openvpn-status.log verb 3
The settings port 1194, proto udp, and dev tun set us on the IANA reserved port for OpenVPN, using the UDP protocol (highly recommended; OpenVPN can use TCP, but your performance will suffer significantly for it if you do) and the tun style of virtual network adapter rather than tap. The differences between tun and tap are fairly arcane, but at the end of the day tun both provides more security for individual client devices from other client devices and, in my experience, it's also less likely to crash for no apparent reason, so tun it is.
The next block of four settings should be pretty self-explanatory, pointing OpenVPN to the location of the credentials it needs to run. It gets more interesting with cipher and auth. These are the cipher used to encrypt your data and the digest used to handle authentication, respectively. The options I've chosen here are err on the paranoid side, which won't hurt your performance any on your own computer or at the VM you're running the server on (even my Celeron J1900 Homebrew can push >200 Mbps with these settings), but it may be a bit much for a consumer router if you're setting up a router-based network-wide VPN tunnel like we will be.
If you're interested in twiddling the performance-vs-security slider, I've got your back: my Netgear R8000 test router managed about 25 Mbps throughput configured with AES-256-CBC/SHA512 as shown here. AES-256-CBC/SHA1, which is still reasonably secure, got a more respectable 37.24 Mbps. That's about as far down as you can go and still call the result "a VPN" with a straight face, though. If you want better performance than that, you should probably consider either running the VPN client directly on your computer itself or on a more powerful router.
-
This is pretty representative of the Netgear R8000's throughput on my most paranoid OpenVPN settings. Technically, this is *double* VPN'ed—the Nighthawk built its tunnel *through* the tunnel the Homebrew is already running upstream of it. However, the real constraint here (on the download side, at least) is the R8000's own performance—it can't hit anywhere near the nominal 100 Mbps provided by Spectrum or even whatever's left of that after the Netflix streaming and whatever else my wife, kids, and my other computers were doing while the tests ran.
-
This is a speedtest.net run on the Homebrew, powered by a Celeron J1900, using the nice-and-paranoid combination of AES-256-CBC/SHA512. The results you're seeing—80 Mbps down and 5-8 Mbps up—are the limits of my Internet connection and/or the stuff my wife, kids, and various computers were doing while I ran the test. When not constrained by the actual network connection, the Homebrew will push > 200 Mbps of OpenVPN traffic.
Moving on, server 10.8.0.0 255.255.255.0 defines the IP address range used by the server and its clients. As configured, the server itself will occupy 10.8.0.1 (and several more addresses), and each client will have its own address. Actually, since we're using the tun adapter, each client will use four IP addresses in its own /30 subnet—up to 10.8.0.255. This means we'll be limited to about 60 total clients, so if you're setting this VPN up for your friends and your friends' friends and maybe some people you don't even really like all that much, you may need to consider a bigger subnet.
The next line, push "redirect-gateway def1 bypass-dhcp", is optional but recommended for our purposes. It instructs any connecting client to route all of its traffic across the VPN, ignoring any settings it might have to the contrary from its local DHCP server. It's also possible to set this directly in the client configuration, which we'll cover next. The push "dhcp-option DNS" lines tell OpenVPN to force the client to use Google's multicast DNS servers instead of whatever it was using previously, which might have been an ISP-controlled DNS server or servers. If you don't like Google either, you can choose Level 3's DNS servers at 4.2.2.4 and 4.2.2.2, or OpenDNS at 208.67.222.222 and 208.67.220.220. (Warning: although they do it "for good reasons," OpenDNS edits the results returned from DNS lookups done against their servers. Caveat Emptor.)
The ifconfig-pool-persist directive has OpenVPN keep track of what tunnel IP addresses it has handed out to which clients in the past and try to maintain some consistency as it hands out new ones in the future. The keepalive directive sends pings down the tunnel and restarts it if they don't get back within a certain amount of time. The comp-lzo directive uses LZO compression on the tunnel's contents, which is typically a win. Much of what you send won't be further compressible, but LZO is so cheap as to be nearly free in terms of CPU time, so I prefer to use it when possible. The persist-key and persist-tun directives try to reuse existing pieces of the setup wherever possible when restarting the tunnel, status keeps a log file, and verb sets how verbose the logging is.
If you change any of these settings from what they're shown here, make a note of it. You'll need to make the same changes on your client configs later. Aside from that, you're ready to start your OpenVPN server for the first time!
root@ars-vpn-test:/etc/openvpn$ systemctl enable openvpn root@ars-vpn-test:/etc/openvpn$ systemctl start openvpn
Now check to make sure it's actually running:
root@ars-vpn-test:/etc/openvpn$ ps wwaux | grep vpn | grep -v grep
This should return a process ID and a command mutex for OpenVPN, like this:
root@ars-vpn-test:/etc/openvpn# ps wwaux | grep vpn | grep -v grep root 5493 0.0 1.1 35792 5576 ? Ss 18:01 0:01 /usr/sbin/openvpn --daemon ovpn-server --status /run/openvpn/server.status 10 --cd /etc/openvpn --script-security 2 --config /etc/openvpn/server.conf --writepid /run/openvpn/server.pid
If you get no output at all from this command, you might try starting the openvpn server in interactive mode to see if its output helps you troubleshoot. If you never get to "Initialization Sequence Completed," you've got a problem you'll need to resolve before moving on.
Now that you've got your OpenVPN server running, you'll need to configure NAT from the tunnel to the outside world. For that, you'll need to place a simple script in/etc/network/if-pre-up.d/masquerade:
#!/bin/sh /sbin/iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADE
Once you've created/etc/network/if-pre-up.d/masquerade, you'll need tochmod 755 /etc/network/if-pre-up.d/masquerade, and then run it directly to bring it up for the first time.
root@ars-vpn-test:/etc/openvpn$ /etc/network/if-pre-up.d/masquerade
That's it - you'll NAT all traffic coming from the tunnel now before it's passed on to the internet at large; and the NAT config will come up again automatically any time a network interface is raised in the future, since it's in /etc/network/if-pre-up.d.
Source: https://arstechnica.com/gadgets/2017/05/how-to-build-your-own-vpn-if-youre-rightfully-wary-of-commercial-options/3/
0 Response to "Easy Rsa Command to Build Sha Signed Keys"
Post a Comment