While it looks hackish, I don't think there's a better way (in Bash) to open
the /dev/net/tun character device.
Checking for presence of /dev/net/tun like were doing is not good enough.
nf_tables is not available in old OpenVZ kernels, so we need to use
iptables-legacy instead.
This issue only affects Debian 10 as it is the only distribution using iptables
with a nf_tables backend by default.
This is supposedly resolved in the newest kernels: https://bit.ly/3fgNZCh
Additionally, a bugfix for the ip6tables path is also included.
The new systemd service at `/usr/lib/systemd/system/openvpn-server@.service` that comes with openvpn 2.4 includes the status option in `ExecStart=/usr/sbin/openvpn --status %t/openvpn-server/status-%i.log --status-version 2 --suppress-timestamps --config %i.conf`
Using this default allows to have multiple servers with their own status files and all in the same log directory. Example `/run/openvpn-server/status-server.log` `/run/openvpn-server/status-server2.log`
New logic makes way more sense:
- If either firewalld or iptables are present, use whatever we have
- If not, install firewalld in CentOS/Fedora and iptables in Debian/Ubuntu
- Use a checkip service which works fine over HTTP to avoid issues in systems
where ca-certificates is not available
- Increase timeout to 10 seconds, because the new service is a bit slower from
some locations
- Improve grep sanitization
- Fix#694: added sanitization during the public IP address configuration and
switch to AWS checkip since the Akamai service doesn't support HTTPS.
- Add validation to cover an unlikely case where: server is behind NAT,
checkip service is unreachable and user doesn't provide input when asked for
the public IP address or hostname.
- Other small improvements not worth describing in detail.
LowEndSpirit fixed the issue on their end, so this is longer needed.
Additionally, the check causes unneeded trouble for users whose system doesn't
have the iptables package installed.