[HN Gopher] Understanding modern Linux routing (and wg-quick) ___________________________________________________________________ Understanding modern Linux routing (and wg-quick) Author : EntICOnc Score : 55 points Date : 2022-07-26 17:57 UTC (5 hours ago) (HTM) web link (ro-che.info) (TXT) w3m dump (ro-che.info) | anonymousiam wrote: | "Fun fact: wg-quick uses the same numbers for the table and the | fwmark: 0xca6c is just 51820 in hexadecimal." | | An additional "fun fact" is that 51820 is also the default port | number used by WireGuard servers. | rubatuga wrote: | It's kindly explained on the actual WireGuard page as well: | | https://www.wireguard.com/netns/ | endre wrote: | and it is mentioned on the blogpost as well. :) | VTimofeenko wrote: | I prefer the namespace approach with wg, as it becomes explicit | and easier to use with services through JoinsNamespace. The | routing inside the namespace is just using the main table. | | This also allows to isolate the DNS queries by bind-mounting | nsswitch.conf and resolv.conf as well as manage the isolated | firewall for the namespace. | gxt wrote: | Anybody working on an enterprise bundle and support package for | wireguard? All "enterprise" vpn solutions I've had to touch in | the past 10years are flaky at best. | wswope wrote: | Does tailscale match what you had in mind? | jandrese wrote: | > Older VPN scripts used to override your default route in the | main table when connecting to the VPN and restore it when | disconnecting. Sometimes this wouldn't work, and after | disconnecting from the VPN you would be left without any default | route at all. wg-quick doesn't have this problem, as it never | messes with your main routing table. All it has to do when | disconnecting is delete its two rules, and your default route is | active again, Or you could even do that yourself with ip rule | del. | | Isn't this the same problem the old VPN problems had though? If | it fails to delete its two rules then your routing is still | boned. | | For comparison OpenVPN doesn't use the ip rule infrastructure, | instead it installs two rules directly on your routing table, but | not for 0.0.0.0/0. Instead it installs rules for 0.0.0.0/1 and | 128.0.0.0/1, creating a rule that has slightly higher priority | than the default route so it can leave the default in place and | not get burned with NetworkManager decides to delete and re-add | the default route for whatever reason. | | Not having the routes cleaned up after the VPN exits is usually | not the problem, as they are tied to the TUN interface and get | cleaned up by the kernel when that interface is destroyed anyway. | The bigger issue is clients that forget to install the host route | to the VPN endpoint. I see that error a lot and it always drives | people crazy because their VPN client negotiates and connects | properly, and then everything breaks for no obvious reason. ___________________________________________________________________ (page generated 2022-07-26 23:00 UTC)