Have you tried setting a VPN inside a container? Any tips?
Have you tried setting a VPN inside a container? Any tips?
Not yet. I haven't even gotten around to trying things out on that old laptop with the nVidia GPU yet. I promised that first, but the craziness of life has rather sidetracked me (it's scary out there).
It's a worthwhile project, I'm curious too, so will try an implementation and report back. Full disclosure: networking is not my strength. I may have to lean on forum members for help.
At least I managed to install resolvconf and direct the DNS to adguard.com's servers, so browsers no longer show ads. If that's any indication, then VPN shouldn't be too hard, but with the NAT layers and other network complexities, I'm not holding my breath either.
A system upgrade is a heart, lung and brain transplant. !!BACKUP FIRST!!
Linux is Not Windows | A Great CLI Guide | Resources for Newcomers
The Best 'buntu Flavour | Remapping Keys | Sandboxing Apps with LXD
I've now set up a VPN that mostly works. But though it works, it throws an irritating error that I haven't been able to solve. Note that my VPN needs are less demanding than yours—I only need to connect to my provider whereas you've mentioned in the past that you connect to your own server. At any rate, my steps:
- Install vpn client:
Code:sudo apt install openvpn- Download .ovpn stack from provider:
Code:sudo wget https://www.privateinternetaccess.com/openvpn/openvpn.zip- Unzip to /etc/openvpn/
So far, so good. These simple steps were all that was necessary for complete success on my host machine. But invoking openvpn within the container only completed partially:
*Personally identifiable info has been redacted.Code:ubuntu@xubuntu:~$ sudo openvpn /etc/openvpn/'US California.ovpn' Sat Apr 4 00:00:34 2020 OpenVPN 2.4.7 x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [PKCS11] [MH/PKTINFO] [AEAD] built on Sep 5 2019 Sat Apr 4 00:00:34 2020 library versions: OpenSSL 1.1.1c 28 May 2019, LZO 2.10 Enter Auth Username: ********** Enter Auth Password: ********** Sat Apr 4 00:01:25 2020 TCP/UDP: Preserving recently used remote address: [AF_INET]xxx.xxx.xxx.xxx:1198 Sat Apr 4 00:01:25 2020 UDP link local: (not bound) Sat Apr 4 00:01:25 2020 UDP link remote: [AF_INET]xxx.xxx.xxx.xxx:1198 Sat Apr 4 00:01:25 2020 WARNING: this configuration may cache passwords in memory -- use the auth-nocache option to prevent this Sat Apr 4 00:01:26 2020 [xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx] Peer Connection Initiated with [AF_INET]xxx.xxx.xxx.xxx:1198 Sat Apr 4 00:01:27 2020 TUN/TAP device tun0 opened Sat Apr 4 00:01:27 2020 Note: Cannot set tx queue length on tun0: Operation not permitted (errno=1) Sat Apr 4 00:01:27 2020 /sbin/ip link set dev tun0 up mtu 1500 Sat Apr 4 00:01:27 2020 /sbin/ip addr add dev tun0 local 10.30.10.6 peer 10.30.10.5 Sat Apr 4 00:01:27 2020 Initialization Sequence Completed
I have bolded the error.
The process then stalls after "Initialization Sequence Completed". Fortunately, because the stall occurs only after initialization has completed, the VPN tunnel actually gets created. An IP address query confirms that it's the VPN provider's. The problem is that I must <Ctrl> + <c> to get back to the shell and this collapses the tunnel:Moreover, because the VPN setup process never completes, the credentials are not recorded and systemd never registers the service, so the tunnel does not survive a reboot. My workaround is to create the tunnel in screen and then detach it. This gives me back my shell and allows me to logout of the session, but it's an ugly, incomplete kludge and there surely has to be a better way.Code:^C Sat Apr 4 00:10:38 2020 event_wait : Interrupted system call (code=4) Sat Apr 4 00:10:38 2020 /sbin/ip addr del dev tun0 local 10.30.10.6 peer 10.30.10.5 Sat Apr 4 00:10:38 2020 SIGINT[hard,] received, process exiting
You asked for hints and I found this link with a possible solution:
https://forum.proxmox.com/threads/op...0/#post-262140
…but I'm barely technically proficient enough to play with it, so I haven't experimented with it—much less implemented it.
A system upgrade is a heart, lung and brain transplant. !!BACKUP FIRST!!
Linux is Not Windows | A Great CLI Guide | Resources for Newcomers
The Best 'buntu Flavour | Remapping Keys | Sandboxing Apps with LXD
VPN clients are pretty easy.
It is the VPN server that needs some funky networking, kernel modules, and internal routing that would be the challenges with any container deployment.
A system upgrade is a heart, lung and brain transplant. !!BACKUP FIRST!!
Linux is Not Windows | A Great CLI Guide | Resources for Newcomers
The Best 'buntu Flavour | Remapping Keys | Sandboxing Apps with LXD
I just finished reading your new tutorial. I have not used it, but I hope to get time to do it. Thanks for sharing the result of your great effort
This is high praise coming from you, who have been doing it for years.
Sharing our discoveries is what belonging to this forum is all about. I hope you find it useful and I'd love to hear your results.
FWIW, since implementing it, I've been on a really satisfying mission: hiving off dozens of apps into containers. I've been able to compartmentalize WINE and Steam, and as a result, have successfully done:…from my base install. I've also removed all but one PPA from sources.list. It so happens that the only remaining one is… yours! mkusb can't be run from a container. Well, technically, it can, but I decided that the contortions needed to map USB to a container are not worth the effort. Accessing the USB bus defeats the purpose of sandboxing anyway so there's little point in compartmentalizing it.Code:sudo dpkg --remove-architecture i386
I've basically cleaned up my system to an almost pristine install state. The upcoming network upgrade to Focal should now be trouble free.
I haven't felt this unburdened in years. It's liberating to try out as many new apps as I want without touching my base install. And I just got some old Windows games running again by simply creating a WINE instance based on Trusty. Talk about versatility!
Sorry to sound so giddy, but it's been an amazing series of discoveries. I'm going to keep expanding the tutorial (judiciously), hopefully without making it too unwieldy.
A system upgrade is a heart, lung and brain transplant. !!BACKUP FIRST!!
Linux is Not Windows | A Great CLI Guide | Resources for Newcomers
The Best 'buntu Flavour | Remapping Keys | Sandboxing Apps with LXD
Been struggling with LXD. Often, usually, problems like I'm having are due to ignorance, so let's assume that for now. My ignorance needs to be assumed.
Got my first play attempt with LXD working last week. It was easy, but with less than great storage. ZFS on a file system, on an LVM setup, wasn't gonna work. Too many disconnected layers and complexity. Performance was poor, as would be expected
For any VM solution, the storage architecture is the foundation. ZFS and LVM storage back-ends haven't worked for me. Have a few more to try, next will be thin-provisioned LVM. I'm crossing my fingers.
I just tried the whole sandboxing process with a fresh Eoan install on an old(ish) laptop. Uneven results. As per TheFu's last post, I partitioned the SSD to install the OS on a traditional ext4 file system. The rest of the SSD was left empty for a zfs file structure. This has worked out well. Everything installs, zfs pool created without complaints, LXD containers all map to the pool nicely.
Creating Bionic containers also went smoothly. However, Eoan containers don't work with the x11.profile that is in my tutorial. I'm trying to debug/troubleshoot it now. This is not a deal-breaker because I'm okay with Bionic containers for now, but it would be nice to have Eoan containers working. And as time goes on and Bionic approaches EoL, then working current versions will become increasingly important. Perhaps I will reach out to Simos or S Graber for guidance.
A system upgrade is a heart, lung and brain transplant. !!BACKUP FIRST!!
Linux is Not Windows | A Great CLI Guide | Resources for Newcomers
The Best 'buntu Flavour | Remapping Keys | Sandboxing Apps with LXD
Bookmarks