Open noctuid opened 9 years ago
Actually, I'm wondering why we're doing it this way in the first place. Is the vpn device always guaranteed to be tun? Does denying out by default and only allowing in on tun not always work? This seems to work for me (e.g. if openvpn is killed):
$ ufw default deny outgoing
# no connection until running following:
$ ufw allow out on tun0
We could save the user's ufws defaults and set them back in the allow (or have a configuration option for the defaults). If there isn't a glaring flaw I've missed, I think this would be a much more reliable way to block non-vpn traffic. It would also remove the need for NETWORK_DEVICES
(unless to reverse the purpose to have a list of devices to also allow?).
EDIT: See the post below first.
With the current default for NETWORK_DEVICES,
--disallow
can only be used before starting vpn. It does not currently fit with the explanation in the manpage since by default it blocks the currently active interface (tun0 if vpn is running, blocking vpn). The same applies to--allow
. Not only must it be run after vpn is off, it must be run with the same interface active (e.g. wifi or ethernet) or it will fail to unblock what was previously blocked.I tried to address this in #25. It's probably not the best default behaviour, but it behaves consistently. When I use vpn, I want everything else to be blocked. I admittedly don't know really anything about docker or libvirt, but I think it's worth noting that the user only needs to change NETWORK_DEVICES to avoid the behaviour. Docker devices seem to be named consistently (docker) and could be easily ignored. Alternatively, we could try to only block the wifi and ethernet device.
If you don't like this idea at all for the default, how about grepping for
state UP
fromip link
and taking the first match? This still may not allow the device that was blocked, but it will never give tun0 and will instead give the wifi or ethernet device. Maybe we could save the blocked device for the--allow
?