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: ubuntu
Release: 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
lxc-destroy --name privileged-container

The start command lxc-start -n ubunt throws

 failed to attach 'vethEFO7AL' to the bridge 'lxcbr0': Operation not permitted

The kernel needs to have CONFIG_BRIDGE enabled.  Networking support → Networking options -> 802.1d Ethernet Bridging

modprobe bridge
Then the bridge needs to be created: brctl addbr lxcbr0

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

The bridge has to be manually enabled in the host: ip link set lxcbr0 up

The object of the game is for the container to appear as another confuser on the LAN.  Unassign the host address from the host: ifconfig enp6s0 0.0.0.0

Then attach the host to the bridge: brctl addif lxcbr0 enp6s0

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

Copy the username & password to a new userpass file, then fire away: openvpn --config ovpn_file --auth-user-pass userpass

ERROR: Cannot open TUN/TAP dev /dev/net/tun: No such file or directory (errno=2)

The kernel needs IP tunneling enabled. Device Drivers → Network device support -> Universal TUN/TAP device driver support

modprobe tun
mkdir /dev/net
mknod /dev/net/tun c 10 200

Then you get 
write to TUN/TAP : Invalid argument (code=22)

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
3 vl203.sjc-eq10-core-1.cdn77.com (138.199.0.194) 14.872 ms 14.877 ms vl201.sjc-eq10-core-1.cdn77.com (138.199.0.192) 14.864 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

Popular posts from this blog

snow white