Leaderboard

It's more than necessary, maybe not for regular users but for those who are building networks for users to use. Whoever told you that v6 is unnecceary is probably such an user him/herself. Those leaks you mentioned are nothing but VPN configuration errors and don't appear outside the VPN context – why should they, after all. Every IP host needs a globally unique IP. When the internet was an infant, designed as a research network, 255^4 - 2 IP addresses were probably enough for a second lifetime of the earth, they said. But the core belief was still that every participant in this network needed a unique IP to be directly addressable. Nothing changed with IPv6, every participant still needs a unique IP. And thus NAT was born: The idea that multiple devices of the same network/house/company/whatever can use the internet through a machine in the middle which will forward their requests and return the answers. Pro: 100+ hosts need just one public IP. Con: You get to deal with port forwarding and other stuff. That's what AirVPN's "privacy" is all about: You use the internet as if you were the AirVPN server. It's pseudonymous, not anonymous. The IPv6 challenge for VPN providers is that IPv6 does not need NAT anymore as it was explicitly made to tackle this IPv4 address space exhaustion. There's no such thing as a v6 address exhaustion (yet), so we can again afford to assign public IPs to all hosts out there. The engineers wanted it to be as easy as possible, so they used the MAC address of the interfaces to automatically build part of that IPv6 address. The problem: This MAC address is supposed to be globally unique as well (it's not exactly, but still). Another problem is that by the time v6 started to be more or less widely adopted, the online ad train was already speeding and looking for more data points to use in the targeting algorithms. A unique IP which is not changed even after a reconnect is almost equivalent to finding the Holy Grail in targeted advertising. That's what gets people around communities like this spooked. And thus the v6 Privacy Extensions were born which are now the default on all platforms: The hosts themselves simply randomize this address, and no one really needs to know how they do it as long as the address is in fact addressable. Makes them less of a target for those ads, and in my humble opinion that should be enough, but people are still spooked by the addressing possibility by MAC so they avoid it in a privacy context. Not to mention the loudest argument of them all: "I can't memorize those long addresses!" Now, IPv6 can be configured to be NATed, just like v4. AirVPN did just that: v6 is NATed like v4 so your exit IPv6 address is that of the AirVPN server, not an address calculated by your own machine. It works and is what happens if you don't disable IPv6.

I connect to AirVPN from one of my VPSes. I only wanted to route particular apps through the VPN though (so eg. SSH connections and system updates still go to the internet directly) and ended up doing that via Docker. I was already using Docker for deployment of most apps on this particular server, so it worked out well. If you're okay with using Docker, and the apps you want to route through the VPN are available as Docker containers (or you're okay learning how to create your own Docker containers), one approach is to use the openvpn-client Docker container (https://hub.docker.com/r/dperson/openvpn-client). This lets you selectively route only particular Docker containers through the VPN tunnel. If you go this route, I'd recommend using docker-compose to configure the containers.

@frpergflf Hello! SELinux correctly prevents systemd to delete the lock file. That's an illegal operation that systemd wants to perform and that tells something on how systemd is designed. Bleutit crash is caused by the fact that systemd bombards with SIGTERM Bluetit (and in general any real daemon). Under specific circumstances, i.e. when 2 or more SIGTERM signals are sent to Blueit almost simultaneously, Bluetit crashes, because the promise object has been already depleted when the 2nd or nth SIGTERM is received. Again, this incomprehensible behavior tells something about how systemd is designed, but at least it made us find a bug which might cause crashes in any other similar circumstance (imagine if you manage to send SIGTERM from two "kill" commands synced to be executed almost simultaneously). Fix will be of course implemented in the next, imminent version. Kind regards

AFAIK, VPN over Tor is an Eddie feature.