@@ -109,23 +109,40 @@ don't, then how can we avoid tor being routed over the VPN?
### 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
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
- _Q_: how can we enforce that *only* VPN software can do that? Is it enough to only allow specific users
(`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?
- Counterintuitively, *forbid*`tor` to send any packets on the physical interface, but allow it to send
packets to VPN interfaces (`tun0` usually)
- spawn the GNOME VPN configuration utility
- _Q_: wouldn't that have too many knobs, leading to the user being more easily able to shoot themselves in the
feet?
I tested OpenVPN. While the GNOME interface clearly puts the focus on the most relevant details, there's
plenty of space for fiddling available.
- _Q_: can we validate the configuration (which also means we only support a subset of the VPN that GNOME would
support)?
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.
- wait for `VPN` to be initialized, then start `tor` with the same configuration we use in easy mode.
In the branch `vpn-before-tor`, I gave a PoC implementation of the firewall. I tested Mullvad like this:
- nmcli connection import type wireguard file cc-loc-wg-001.conf
- nmcli connection up cc-loc-wg-001
... and it works! I tested that:
- tor works.
- Unsafe Browser is routed through the VPN
- the clearnet user goes through the VPN
- if the VPN goes down (ie: nmcli connection down cc-loc-wg-001), tor and unsafe browser fail close. None of
their traffic goes to physical interfaces.
I think we could even only support Mullvad (or everything which has the same working, if there's more). In
fact:
- 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
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.
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.
