Support for persistent docker container

[TheBv]

I'd be nice if there was a simple way to just create a container with the script that could just be started without needing to run e.g openconnect NAME. Given that anyconnect profiles are supported I think this would be a nice feature to add.

Main issue with this idea would be how to forward the password. I personally bodged it by modifying the docker-entrypoint.sh and adding a similar line to the one found in the vpn.sh script.

I know one could just run the script e.g on startup but since I'm on windows and I'm creating the container via WSL it is a bit cumbersome and ideally I'd like the container to just spin up on startup.

Feel free to close this if it's not a feature you want to support :)

[ethack]

I don't really interact with AnyConnect VPN servers much anymore so it's not something I'd spend a lot of time to develop or get a test environment set up.

But I'd be open to merging a pull request. Or if you can explain exactly how you got it working with your setup, I might have an idea on how it could be put in.

[TheBv]

Basically I replaced the last entrypoint line with cat vpn.secret - | exec "$@" and added the vpn.secret file to the dockercontainer. Which is not very dynamic. I had two solutions in mind and I couldn't get either of them to work.

One of them was to modify the vpnCmd in the vpn.sh file, to also include a line like echo PASSWORD | openconnect ... But due to how the entrypoint script executes things I couldn't get that to work directly. I think this would be quite a clean approach although it would leave the password in the CMD string as plain text.

Other approach, similar to the one I have currently, would be to copy the secret file to the container (through scp maybe), and then if a secret file exists change the entrypoint command from exec "$@" to cat vpn.secret - | exec "$@"

Issue with that approach being that we could only copy the file after the docker container has started; so that would be after the entrypoint script has run for the first time. Ideally we'd do it before that.

We could also pass the password as an env variable, but that does have the same issue as the first idea. (Although the secret is already stored in a plain-text file...)

So I couldn't really get option 1 and 2 to work. Right now 3 would be the best idea I have. If you have any better ideas let me know. I'd be willing to create a PR with it :)

[cwilby]

For future reference, here's a working setup using restart policies in docker-compose:

This container stops when the host shuts down, and automatically starts up again when the host starts.

I have other containers that can then depend on this container.

./docker-compose.yml

services:
  anyconnect-vpn:
    image: ethack/vpn:latest
    restart: always
    container_name: anyconnect-vpn
    hostname: anyconnect-vpn
    stdin_open: true
    tty: true
    cap_add:
      - NET_ADMIN
    devices:
      - /dev/net/tun
    ports:
      - 2222:22
    env_file: .env
    command: openconnect $VPN_URL \
        --authgroup=$VPN_AUTHGROUP \
        --servercert $VPN_SERVERCERT \
        --user=$VPN_USERNAME \
        --form-entry main:password=$VPN_PASSWORD
    volumes:
      - ./authorized_keys:/root/.ssh/authorized_keys

./.env

VPN_URL=https://vpn.acme.com
VPN_AUTHGROUP=ACME-ANYCONNECT-SSL-PROFILE
VPN_SERVERCERT=pin-sha256:2fae6aSEEtco0bbFSEDrT0XLIV+kVQDjbyCHVgi5D9=
VPN_USERNAME=cwilby
VPN_PASSWORD=password123
BIND_INTERFACE: 127.0.0.1
SSH_PORT: 2222
SOCKS_PORT: 1080

./authorized_keys (run wget https://github.com/{username}.keys && mv {username}.keys authorized_keys)