Re: three privacy questions

[Chuck Anderson <cra WPI EDU>]

On Sat, Dec 20, 2008 at 09:21:50AM +0800, Etienne Zind wrote:
> >> As iproute is already heavily used in NM, the blocking might be done
> >> with `ip rule` or `ip route` ath can do `reject`,`unreachable` and
> >> `prohibits` simulation.
> >>
> >> $ ip rule from all unreachable
> >>
> >> or
> >>
> >> $ ip route add unreachable default
> >>
> >> Should do the trick
> >
> > Interesting.  But it just occurred to me that we'd of course have to
> > punch through so the VPN itself could re-connect, which might well be
> > VPN-method specific.  OpenVPN can do both UDP or TCP, and the port # is
> > specific to the server.  Thus, we'd have to know quite a bit about the
> > VPN implementation to lock down the TCP/IP stack to only allow
> > connections to the VPN server...
> 
> Ok, you got me here, I don't know a lot about VPN's but here's my guess :
> 
> As soon as we want to block the trafic remove all our default route(s)
> and replace them with some "unreachable" or "reject" route according
> to what kind of error we want to generate on outgoing trafic.
> 
> Then we add a route to the VPN server, or all the IPs needed to setup the VPN:
> $ route add $VPN_IP1 dev $VPN_DEV
> $ route add $VPN_IP2 dev $VPN_DEV
> ...
> 
> And when the VPN is up and running, we add our default route(s) again

Yes, VPN clients typically install a host-route to the VPN server.  It 
is definately worth implmenting the above, even if it is only a 
partial solution.  Many VPN servers have a unique IP address used just 
for VPN services--for those setups the above would effectively prevent 
non-encrypted traffic, since the VPN server wouldn't allow any traffic 
through until the VPN tunnel was set up.  

The rules could be locked down more for the cases where the VPN server 
IP is shared with other services, but I'm not sure how much sense it 
makes to put VPN-specific intelligence into NM.