Open VPN via docker

[atakacs]

Hi

for various reasons (one being 2FA support) I want to bypass the built in OpenVPN and run it via a container. I have started with this guide which refers to this Github hosted container. Unfortunately It would not start in my environment:

iptables: No chain/target/match by that name.
iptables: No chain/target/match by that name.
Enabling IPv6 Forwarding
sysctl: error setting key 'net.ipv6.conf.all.disable_ipv6': Read-only file system
Failed to enable IPv6 support
sysctl: error setting key 'net.ipv6.conf.default.forwarding': Read-only file system
Failed to enable IPv6 Forwarding default
sysctl: error setting key 'net.ipv6.conf.all.forwarding': Read-only file system
Failed to enable IPv6 Forwarding
Running 'openvpn --config /etc/openvpn/openvpn.conf --client-config-dir /etc/openvpn/ccd --crl-verify /etc/openvpn/crl.pem '
Thu Sep  3 04:27:02 2020 WARNING: file '/etc/openvpn/pki/private/xx.xx.xx.xx.key' is group or others accessible
Thu Sep  3 04:27:02 2020 WARNING: file '/etc/openvpn/pki/ta.key' is group or others accessible
Thu Sep  3 04:27:02 2020 OpenVPN 2.4.9 x86_64-alpine-linux-musl [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [MH/PKTINFO] [AEAD] built on Apr 20 2020
Thu Sep  3 04:27:02 2020 library versions: OpenSSL 1.1.1g  21 Apr 2020, LZO 2.10
Thu Sep  3 04:27:02 2020 Diffie-Hellman initialized with 2048 bit key
Thu Sep  3 04:27:02 2020 CRL: loaded 1 CRLs from file /etc/openvpn/crl.pem
Thu Sep  3 04:27:02 2020 Outgoing Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
Thu Sep  3 04:27:02 2020 Incoming Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
Thu Sep  3 04:27:02 2020 ROUTE_GATEWAY 172.17.0.1/255.255.0.0 IFACE=eth0 HWADDR=02:42:ac:11:00:02
Thu Sep  3 04:27:02 2020 ERROR: Cannot open TUN/TAP dev /dev/net/tun: No such device (errno=19)
Thu Sep  3 04:27:02 2020 Exiting due to fatal error

I guess I can live with some of the IPv6 issues but clearly the is issue with referencing /dev/net/tun

What would be the correct interface in the Synology world ?

 

[Rusty]

Check if you have the tun module installed:

lsmod | grep tun

If the result comes out empty, try installing it:

insmod /lib/modules/tun.ko

If everything went fine, move on to the next test.

Test if the tun.ko module works
make sure the tun.komodule works as expected:

mkdir /dev/net
mknod /dev/net/tun c 10 200
chmod 600 /dev/net/tun
cat /dev/net/tun

If the result of the catcommand was File descriptor in bad state, it means the module has been correctly installed.

Make tun.ko module persistent
The module installation needs to be made persistent otherwise on every Synology restart, you’ll have to repeat the insmodcommand.

Create the following file to run on every system boot:

cat /usr/local/etc/rc.d/tun.sh

Enter this as the content of the file and save it.

#!/bin/sh -e

insmod /lib/modules/tun.ko

Make the script executable:
chmod a+x /usr/local/etc/rc.d/tun.sh

Reboot your Synology NAS or execute the script manually once

 

[one-eyed-king]

Create the following file to run on every system boot:

cat <<EOF > /usr/local/etc/rc.d/tun.sh

Enter this as the content of the file and save it.

#!/bin/sh -e


insmod /lib/modules/tun.ko

EOF

Make the script executable:
chmod a+x /usr/local/etc/rc.d/tun.sh

Can you take another look on this, Rusty? The first code block starts a here-doc with <<EOF , while its terminating EOF is in the second script.

 

[fredbert]

It looks as though the two code blocks should have been one, without splitting the here-doc.

Not that I've used the feature but why not create a Scheduled Task? There's the Triggered Task type and the event could be Boot Up. Then enter the user-defined script:

#!/bin/bash
insmod /lib/modules/tun.ko

Would that be soon enough in the NAS startup?

 

[one-eyed-king]

Would that be soon enough in the NAS startup?

If the image is done right, it should exit with an error code if the tun device is missing. If the container is configured to restart it will catch up eventually in one of its restart cycles ^^ This would remedy a race condition pretty quick.

On the other hand, it appears that files in /usr/local/etc/rc.d seem to be executed during system initialization.

Fun fact: with Kubernetes, one could add a a priviliged initContainer to the pod, which would take care of whatever is needed for the main container(s). The pod concept bundles 1 to n containers with 0 to n initContainers (used to prepare and/or wait for preconditions). It's a pitty plain docker doesn't have anything similar.

 

[atakacs]

I was indeed missing the tun module. The container now works after installing per your instructions - thanks !
Now I can start playing with OpenVPN setting