• 0 Posts
  • 8 Comments
Joined 2 years ago
cake
Cake day: June 9th, 2023

help-circle

  • PostUp = ip route add 100.64.0.0/10 dev tailscale0
    

    Looks like you need to stick this line in the tailscale service file, since it’s the only time that the existence of the tailscale0 device is guaranteed. If you don’t want to modify the service file inside the package, could you write your own systemd service file and include the tailscale service as a prerequisite?

    Also make sure that when you start the VPN first and then tailscale, you don’t get a double tunnel situation where tailscale goes out through the VPN (unless that’s what you wanted).


  • 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.






  • IMHO if you don’t have a globally-reachable address or forwarded port, you are not really a participant of the internet, you are just a receptacle xD

    One service I never see mentioned is OVPN. They have a 1-to-1 feature parity with mullvad and were an easy drop-in replacement when mullvad closed their ports:

    • wireguard
    • port forwarding
    • no usernames/emails/registration, only account numbers
    • crypto payments/cash in the mail
    • same price as mullvad
    • multiple device keys
    • multihop
    • no bandwidth limits
    • setup guides
    • status dashboard

    I used mullvad for years, sad to see them go, and all my scripts basically worked without any change other than the server addresses/public keys. Only downside is they don’t have as many users so not as many servers. I wish more people would join up so I get more IPs to choose from :D