Allow passing auth file to OpenVPN & move proxy startup script to `--up` options

[Toanzzz]

Summary

This will allow usage with private VPN that required authentication by setting OPENVPN_AUTH_FILE environment variable (default is /data/auth.txt)

From official OpenVPN Manual:

--auth-user-pass [up]

Authenticate with server using username/password. upis a file containing username/password on 2 lines (Note: OpenVPN will only read passwords from a file if it has been built with the --enable-password-save configure option, or on Windows by defining ENABLE_PASSWORD_SAVE in config-win32.h).If up is omitted, username/password will be prompted from the console.

While enabling this options, I encountered an error from dante-server about cannot bind to tun0 interface. Turn out that when your vpn server require authenticate, openvpn service will need more time after startup to establish the tunnel, and the technique that wait for 1.1.1.1 does not work. So I converted it to up.sh script and make it run after the socket is open by pass it to --up option.

--up

Executed after TCP/UDP socket bind and TUN/TAP open.

Example Usage

services:
  vpn:
    image: ghcr.io/wfg/openvpn-client
    cap_add: [NET_ADMIN]
    devices: [/dev/net/tun]
    restart: unless-stopped
    ports: ["11080:1080/udp", "11080:1080/tcp"]
    volumes: [./config:/data/vpn]
    secrets: [ovpn_auth]
    environment:
      KILL_SWITCH: "off"
      SOCKS_PROXY: "on"
      OPENVPN_AUTH_FILE: /run/secrets/ovpn_auth

secrets:
  ovpn_auth: { file: ./secrets/auth.txt }

TODO

• Update docs

[wfg]

Thanks for the well-written PR!

How will this affect the up.sh provided by Alpine? https://github.com/wfg/docker-openvpn-client/blob/20b27d71b661e6faa4c89ec0c810469e8b6ad4ab/data/scripts/entry.sh#L57-L59

[Toanzzz]

How will this affect the up.sh provided by Alpine?

https://github.com/wfg/docker-openvpn-client/blob/20b27d71b661e6faa4c89ec0c810469e8b6ad4ab/data/scripts/entry.sh#L57-L59

Sorry but I'm not really sure about that. I tried looking it up a bit but still have no clue why you need to do that for Alpine, would you please give me some references (links) about it? I'm a bit curious too.

Anyway, I tested and using this the whole day without any warning or error pop up, so perhaps it totally unrelated? 😅

[wfg]

The up.sh script included in the openvpn package is here (and is at least 10 years old): https://git.alpinelinux.org/aports/tree/main/openvpn/openvpn.up

It may not be a problem. I'm honestly not sure when/why $PEER_DNS would be set.

[wfg]

@Toanzzz Let's split this up into the two distinct parts.

I've went a different route to fix the sockd starting before tun0 issue. It's been pushed to master, but I haven't rebuilt the image to use it yet. You'll have to build the image yourself if you want to test.

---

Passing the auth file as an environment variable would be fine, but we need to support not passing it as well. As it stands, a user does not need to make any changes to use the auth file specified in the config. With this, they would have to manually rename their file to auth.txt or pass in the filename.

I think a better option would be to conditionally add the flag to the openvpn command if the user specifies an auth file.

[Toanzzz]

@wfg Sorry I messed up and make this PR closed. But I create another one, following your suggestion, please take a look here #28 😀

I've went a different route to fix the sockd starting before tun0 issue.

Personally, I still prefer using the --up option provided by OpenVPN, it seem a little bit less "hacky" IMO. And there also --down option that allow us to do some cleanup when vpn connect got interrupted too (network issue, PC go to sleep, etc...). Not sure, but possibly :)

Please let me know what you think.

[wfg]

Personally, I still prefer using the --up option provided by OpenVPN, it seem a little bit less "hacky" IMO. And there also --down option that allow us to do some cleanup when vpn connect got interrupted too (network issue, PC go to sleep, etc...). Not sure, but possibly :)

I understand where you're coming from. My concern is that in my testing, the up.sh that is packaged with Alpine's openvpn was used. It changed the nameservers in /etc/resolv.conf to whatever was pushed from the VPN server.

If we change to use a different up.sh script (which would be cleaner), we would have to 1) add our custom bits to the end of Alpine's and 2) hope we notice when/if the up.sh script is changed upstream so we could update our up.sh.