@@ -109,23 +109,40 @@ don't, then how can we avoid tor being routed over the VPN?
...
@@ -109,23 +109,40 @@ don't, then how can we avoid tor being routed over the VPN?
### VPN before Tor
### VPN before Tor
To make VPN work, we need to change lot of firewall rules. This could mean that the user has "VPN" as an
In the branch `vpn-before-tor`, I gave a PoC implementation of the firewall. I tested Mullvad like this:
option in Tor Connection (so it becomes easy mode / hide mode / vpn mode). Selecting that option would:
- change firewall rules so that VPN can actually send packets wherever they need to
- nmcli connection import type wireguard file cc-loc-wg-001.conf
- _Q_: how can we enforce that *only* VPN software can do that? Is it enough to only allow specific users
- nmcli connection up cc-loc-wg-001
(`root`, or some `vpn-specific` user maybe) to send packets? Can we have specific iptables rules that
allow only the vpn software to send packets?
... and it works! I tested that:
- Counterintuitively, *forbid*`tor` to send any packets on the physical interface, but allow it to send
- tor works.
packets to VPN interfaces (`tun0` usually)
- Unsafe Browser is routed through the VPN
- spawn the GNOME VPN configuration utility
- the clearnet user goes through the VPN
- _Q_: wouldn't that have too many knobs, leading to the user being more easily able to shoot themselves in the
- if the VPN goes down (ie: nmcli connection down cc-loc-wg-001), tor and unsafe browser fail close. None of
feet?
their traffic goes to physical interfaces.
I tested OpenVPN. While the GNOME interface clearly puts the focus on the most relevant details, there's
I think we could even only support Mullvad (or everything which has the same working, if there's more). In
plenty of space for fiddling available.
fact:
- _Q_: can we validate the configuration (which also means we only support a subset of the VPN that GNOME would
support)?
- Mullvad is very popular and has a good reputation
- Adding a connection is *so* easy: they just give you a file and you can directly import that. I cheated and
kinda: we can get [an event](https://developer-old.gnome.org/NetworkManager/stable/gdbus-org.freedesktop.NetworkManager.Settings.html#gdbus-signal-org-freedesktop-NetworkManager-Settings.NewConnection) very early, but NetworkManager won't wait for us to handle it. So we need to quickly validate and, if everything works, do the appropriate firewall changes that will allow connections to be performed. If there is something we don't like, we can't provide information context. Sure, we can open a window, or a notification, but that will be a bit out of place.
used `nmcli connection import type wireguard file my-mullvad-file.conf`. I guess it could have been easy
from the UI, but I haven't tried.
- wait for `VPN` to be initialized, then start `tor` with the same configuration we use in easy mode.
To implement VPN-before-Tor, we need to distinguish if VPN is enabled or not. I propose we make it something
that cannot be changed during the session. We could even add it to the greeter. Whatever method we use, let's
assume that during a single session, this information never changes.
If the VPN is off, everything works like Tails' does currently.
When the VPN is on, then the firewall rules need to be changed:
- only wireguard can use the network
- everything else that used to be able to use the network directly (clearnet and debian-tor) can now only use
the VPN interface
Subtleties:
- what if the user somehow imports/enables multiple VPNs? shall we try to forbid them to do so?
- how can the user import a VPN without being able to use the internet? should they keep it in a separate usb
stick, then move it to Persistent Storage?
- How can we wait for the `VPN` to be ready, so that `tor` is started when it makes sense?
We could just ignore this, start tor anyway, and hope this is good enough.
