This seems like a little change but it was not easy to find.
I want this script to support only OpenVPN 2.4 servers, but also 2.4 and 2.3 clients.
The thing is, the OpenVPN 2.3 client doesn't care at all what cipher the server wants to use. The cipher parameter in the client config is the king here.
But with OpenVPN 2.4, you can specify whatever cipher you want, the clients and the server will negotiate the best cipher possible, which is AES-256-GCM right now. The use of --ncp-ciphers cipher_list is useless because a 2.3 client will still use its cipher and a 2.4 client will still use AES-256-GCM.
I won't detail all my experiments here, but in the end, ncp-disable disable the cipher negotiation for 2.4 clients. But it will only work if the cipher in the server config and the client config are the same, and as they are in the script, it's ok. This is not the best solution because that means if you want to support a 2.3 client, you'll be forced to use one and only one AES-CBC cipher, even with your 2.4 clients, even though you could use a different cipher for each client. But as we're still using AES and OpenVPN 2.4 getting more and more deployed, this is not a too big issue in the end. Also adding menus to to choose what kind of client you want etc would make the script pretty complicated, so this is a good compromise here.
TL;DR: ncp-disable enforces a OpenVPN 2.4 client to use the specified cipher in the server and the client config.
See here for me details regarding the data channel cipher negotiation in OpenVPN 2.4 : https://community.openvpn.net/openvpn/wiki/Openvpn24ManPage#lbAJ
From the OpenVPN wiki:
>Authenticate data channel packets and (if enabled) tls-auth control channel packets with HMAC using message digest algorithm alg. (The default is SHA1 ). HMAC is a commonly used message authentication algorithm (MAC) that uses a data string, a secure hash algorithm, and a key, to produce a digital signature.
>If an AEAD cipher mode (e.g. GCM) is chosen, the specified --auth algorithm is ignored for the data channel, and the authentication method of the AEAD cipher is used instead. Note that alg still specifies the digest used for tls-auth.
Tl;DR: if we're using an AEAD cipher (AES GCM), `auth alg` won't have inpact on the impact channel, but only on the control channel if tls-auth/tls-crypt is enabled.
- Add support for AES-GCM ciphers for the data channel
- Add support for tls-crypt
- Add support for ECDSA certificates
- Add support for ECDHE
- Add choice for HMAC auth algorithm
- Add choice for certificate hash algorithm
- Add choice for the control channel's cipher
All these options have an OpenVPN 2.3-compatible choice (example : RSA cert and DH key)
If you want to run OpenVPN in UDP mode on an secondary IP, UDP routing will fail unless you explicitly bind OpenVPN to the chosen IP address. This change includes the "local" parameter in the config and sets it to the IP address entered at the beginning.
That makes more sense that putting French servers.
What is in /etc/resolv.conf is not always good, but most of the time it's the hoster's or something nearby. Thus it makes more sense for the user to use them by default.
Since OpenVPN 2.4 is out on Arch, the script wasn't working completely because of this : https://www.archlinux.org/news/openvpn-240-update-requires-administrative-interaction/
There is a new path for OpenVPN server config. This is just needed on Arch for now, and you're probably not going to run an OpenVPN client on an OpenVPN server.
Thus I modified the systemd script to use `/etc/openvpn/` and `server.conf` instead of the new `/etc/openvpn/server/` and `openvpn.conf`.
By using the same paths as the other distros, I avoid to rewrite the entire script to change the paths...
It's not 100% clean, but it works pretty well. If you have any objection please leave a comment.
Also, I updated the new service name.
As far as I tested, it's working fine on Arch Linux for now.
Fixes#63 and #61
