fix(network): prevent tunnel route from stealing local LAN on subnet overlap

[paul-kinexon]

Community Contribution License Agreement

By creating this pull request, I grant the project maintainers an unlimited,
perpetual license to use, modify, and redistribute these contributions under any terms they
choose, including both the AGPLv3 and the Fossorial Commercial license terms. I
represent that I have the right to grant this license for all contributed content.

Description

Problem

On Linux, when a client is on a local subnet that overlaps a remote Pangolin subnet (for example, both 10.200.4.0/23), the tunnel route added by OLM/newt can steal local LAN traffic. The tunnel route is added with implicit metric 0, which beats the connected route on the physical interface (often metric 100). Traffic to the local default gateway (for example 10.200.4.1) is then sent via the tunnel interface instead of the LAN interface, breaking default routing.

Root cause

LinuxAddRoute() added routes via netlink without setting Priority (metric). LinuxRemoveRoute() deleted routes by destination only, which is insufficient once multiple routes share the same prefix.

Fix

• Set explicit Linux tunnel route metrics: 50 by default (NetworkManager VPN-style priority), 1025 when overlap with a local IPv4 subnet is detected
• Detect overlap using local interface addresses (stdlib), excluding the tunnel interface
• On overlap-detection failure, fail safe to the higher metric
• Improve Linux route removal: match Dst + LinkIndex + Priority, support IPv4/IPv6 route families, and accept an optional tunnel interface name to avoid deleting unrelated routes
• Pass the tunnel interface name from newt callers when removing routes

macOS and Windows behavior is unchanged.

Notes / follow-ups

• Overlap detection is IPv4-only today
• Overlapping subnets remain inherently ambiguous for non-gateway addresses in the same prefix
• Routes created before this change at implicit metric 0 are not removed by the new logic
• RemoveRoutes() now accepts an optional interface name; olm callers can pass their tunnel interface in a follow-up for safer removal

How to test?

• make test
• Linux manual scenario:
  • Host on 10.200.4.0/23, gateway 10.200.4.1, remote subnet 10.200.4.0/23
  • After tunnel up: ip route get 10.200.4.1 must use the local LAN interface, not the tunnel
  • Default route still works (ping 10.200.4.1, general internet access OK)
  • Non-overlapping remote subnet still routes via tunnel
  • Tunnel teardown removes the correct tunnel route

[oschwartz10612]

Hey @paul-kinexon thanks so much for the PR! We are actually going to move forward with the changes on 2bad244 and 6610655 but I appreciate the submission. We will be in touch about the updates.