By default, VPN interfaces are showing up as default routes on the main table because they can be set as the default destination for traffic, while the actual, physical device (e.g. eth0) sits back as a sort of "shadow" default device (which is still necessary, otherwise you wouldn't be able to talk to your router/the Internet anymore). Unfortunately, this can cause the command ip route show default (which queries the main table) to return multiple entries, including the VPN-bound default routes. Previously we tried to work around this by just cutting the output to a single line and taking whatever was returned. Unfortunately, that's not reliable enough (see the ip mocks I added for both, tun0 and ppp0 default routes) as the output slightly differs and makes parsing the results cumbersome.
I've decided to fix this by hard-filtering the output for any known VPN prefixes ((ppp|tun|tap)) which should then return only a single line, which is also the "true" default route. Traffic measurements should still work correctly, as any traffic passing through VPN tunnels is also aggregated into the device statistics of the relevant underlying network interface.
Fixes #109
PS: Yes, there can be multiple distinct default routes, but not in the same table and usually only on servers. We'll address that edge case once it hits us :wink:
By default, VPN interfaces are showing up as default routes on the
maintable because they can be set as the default destination for traffic, while the actual, physical device (e.g.eth0) sits back as a sort of "shadow" default device (which is still necessary, otherwise you wouldn't be able to talk to your router/the Internet anymore). Unfortunately, this can cause the commandip route show default(which queries themaintable) to return multiple entries, including the VPN-bound default routes. Previously we tried to work around this by just cutting the output to a single line and taking whatever was returned. Unfortunately, that's not reliable enough (see theipmocks I added for both,tun0andppp0default routes) as the output slightly differs and makes parsing the results cumbersome.I've decided to fix this by hard-filtering the output for any known VPN prefixes (
(ppp|tun|tap)) which should then return only a single line, which is also the "true" default route. Traffic measurements should still work correctly, as any traffic passing through VPN tunnels is also aggregated into the device statistics of the relevant underlying network interface.Fixes #109
PS: Yes, there can be multiple distinct default routes, but not in the same table and usually only on servers. We'll address that edge case once it hits us :wink: