The exact script would depend on the use case; you’d use commands something like this:
mkdir -p /etc/netns/VPN
sh -c 'echo nameserver 1.1.1.1 > /etc/netns/VPN/resolv.conf'
ip netns add VPN
ip link add tun1 type wireguard
ip link set tun1 netns VPN
Because the wireguard device was created in the default namespace, it will “magically” remember its birthplace, even after you move its mouth (the tun1 device) to a separate namespace. The envelope VPN packets will keep going in/out in the default namespace.
ip netns exec VPN wg setconf tun1 /etc/wireguard/vpn.conf
ip netns exec VPN wg set tun1 private-key /etc/wireguard/vpn-key.private
ip -n VPN addr add 192.my.peer.ip/32 dev tun1
Get the wireguard config file from the VPN website, both mullvad and OVPN have a wizard to generate them. Your assigned private network ip is in the config file. Also get and save your device key.
ip -n VPN link set tun1 mtu 1420
ip -n VPN link set tun1 up
ip -n VPN route add default dev tun1
ip netns exec VPN su myuser -c 'firefox --no-remote'
Now all firefox (and only that firefox) traffic will go through the tunnel. Firefox has its own DNS, if you run another app it will use 1.1.1.1.
I actually do the reverse of this - I create a namespace ETH and move my eth0 device in there and attach dhcpcd to it. Then I create the wireguard tun1 device inside ETH namespace, and move tun1 to the default namespace. Then any software I run can only use the tunnel, because the ethernet device doesn’t even exist there. This keeps the routing table simple and avoids a whole class of issues and potential deanonymization exploits with the split routing table used in traditional single-namespace VPN configurations.
windy.com with a VPN in a private browser window. They can’t track you if they don’t know where you are!
I want people to be able to report bugs without any trouble.
Thank you for being aware! I’ve experienced this on github.com. I’ve tried to submit issues several times to open source projects, complete with proposed code to solve a bug, but github shadowbans my account 6 hours after creating it (because I use a VPN? a third-party email provider? do not provide a phone number? who knows). I can see the issue and pull request when logged in, but they only see a 404 on their project page even if I give them a direct link. I ended up sending them a screenshot of the issue page just to convince them this was even possible. Sad to hear gitlab does it even worse now by making phone mandatory.
The list of tor exit ips is publicly viewable. Some IPS block the entire list contrary to Tor Project’s request not to do exactly that.
I assume this “VPN Server” that they can see is the “entry node”, and not the “exit node” (i.e. my IP as seen by the world) - but never got a clear answer to that
Traditionally, the entry node and the exit node have been the same VPN server/ip. In that sense, your ISP does know the IP of your exit server, since they are the ones connecting you to it.
For example, your X ISP’s logs could show “At 15:00, user #123 connects to IP 1.2.3.4, which lookup shows is assigned to “CheapVPNs Ltd”. At 15:01 our email server received 1,000,000 emails from IP 1.2.3.4 all angrily complaining about how “X ISP sucks”. Correlation implies user #123 is responsible for the mail bomb attack against our servers.”
At the moment, Mullvad specifically does use different entry and exit IPs, but they are all still located in the same datacenter and subnet. That is, you could be connecting to a Mullvad VPN server 1.2.3.4, 1.2.3.5, or 1.2.3.6 in London, and they all exit out through 1.2.3.1 in London. This is just something Mullvad does. Other VPN services may not do it and Mullvad hasn’t done it in the past. Someone analyzing ISP logs could correlate these IPs if they really wanted to.
Mullvad also offers “multihop”, but the way they have it implemented currently (changing the destination port number), an ISP could still deduce your exit IP if they bother looking up records of Mullvad network structure (which are publicly available), since they know the IP number and the port number of your entrance node.
The only way to hide your VPN exit IP from your ISP currently is to use multiple VPN services and nest them inside each other (or use one service and nest it inside itself using the “multiple devices” perk). Then only a state-level actor could hope to correlate your traffic by monitoring the ingress/outflow of multiple IPs simultaneously.
The US bans all of it, while Japan has an exception for drawings
Absolutely incorrect. You are thinking of Canada or UK. In US, drawings are fine. Rather it is photorealistic depictions “indistinguishable from that of a minor” that are prohibited, almost presciently pre-empting techniques like deepfake and stablediffusion by 20 years, a rare win by legislators.
Airplane mode on Apple has two sub-toggles: wifi and bluetooth (the main toggle controls the cellular antenna). With all three toggled off, find-my does not work. The device just shows up as “offline, location unknown, last seen at…” on the map. Something to watch out for though: for some reason Apple will turn bluetooth back on after a couple days without asking, even with airplane still on. Also, an app running in background could in theory record the GPS coordinates and transmit them to home server once connection is reestablished.