Anyways, VPN war switched to 3 options: set up a container, set up another virtual machine, or set up another dedicated raspberry pi.
There is a supposedly baked protonvpn for docker.
https://github.com/tprasadtp/protonvpn-docker
Sadly, docker still hangs.
LXC is largely accepted as the most popular container tool nowadays. The mane problem users encounter is lxc-create dying with
Unable to fetch GPG key from keyserver.
It seems all the keyservers were shut down at some point. The current recommendation is passing -- --no-validate
lxc-create -t download -n privileged-container -- --no-validate
Then it prints a list & you have to specify an image from the list with 3 prompts:
Distribution: ubuntuRelease: xenial
Architecture: amd64
privileged-container is the name of the container. There is no lxc-rename or lxc-move. The only way to rename it is to copy & delete.
lxc-copy --name privileged-container --newname ubunt
The start command lxc-start -n ubunt throws
failed to attach 'vethEFO7AL' to the bridge 'lxcbr0': Operation not permitted
Then you can get a console with lxc-attach -n ubunt
Now this image has no networking enabled. You have to set eth0 to manual in /etc/network/interfaces
In the image configuration file /var/lib/lxc/ubunt/config you need to add the address lxc.network.ipv4 = 10.0.10.26/24 the gateway lxc.network.ipv4.gateway = 10.0.10.1
Then add a nameserver line to /etc/resolvconf/resolv.conf.d/head
Assign the host address to the bridge: ifconfig lxcbr0 10.0.10.25 netmask 255.255.255.0
The routing table should have the default gateway accessed through the bridge: route add default gw xena
The root filesystem of the container is /var/lib/lxc/ubunt/rootfs. No NFS is required like it was with virtualbox.
The last animal has finally unlocked containers. They're a lot more efficient than the virtual machines lions were using. The mane issues were just getting through the setup bugs & the networking. The next step is just replacing the 125 GB of Linux virtual machines. The windows VM needs to stay.
Of course, containers have improved significantly in the last 3 years. There's a lot more documentation & a lot more images. The images are a lot better. A lot of endemic problems like users getting locked out of their containers have been solved.
There's a hit about using protonvpn with openvpn: https://protonvpn.com/support/linux-openvpn/
You have to download a .ovpn file from https://account.protonvpn.com/downloads
ERROR: Cannot open TUN/TAP dev /dev/net/tun: No such file or directory (errno=2)
Another hit says add --comp-lzo to the openvpn command
openvpn --config ovpn_file --auth-user-pass userpass --comp-lzo
This gets all the way to a connection but corrupts resolv.conf. You have to delete the host DNS from resolv.conf
traceroute shows some subtle differences with the VPN in the container:
root@ubunt:/root% traceroute heroinewarrior.com
1 * * *
2 unn-156-146-54-93.cdn77.com (156.146.54.93) 14.879 ms 14.880 ms unn-156-146-54-92.cdn77.com (156.146.54.92) 14.850 ms
Without the VPN or outside the container:
1 * * *
2 10.0.0.1 (10.0.0.1) 4.714 ms 4.725 ms 4.722 ms
3 10.60.140.2 (10.60.140.2) 75.990 ms 10.60.140.3 (10.60.140.3) 18.855 ms 19.021 ms
After such a great challenge, lions have enough sunk costs to feel better about paying for a VPN.
The next steps are creating a kill switch so a VPN outage doesn't revert to 10.0.0.1, automatically selecting a server based on load, accessing the host filesystem from the container, fixing the DNS issue. It should probably be on a machine which is always on. Xena needs more storage.

Comments
Post a Comment