Allow traffic towards private internal endpoints via WireGuard

[qdrop17]

VpnRoutes.EXCLUDED_RANGES hardcodes 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16 as excluded from the tun. Setting AllowedIPs = 0.0.0.0/0 in WireGuard doesn't help — it only feeds wireguard-go's UAPI, never VpnService.Builder.addRoute(), which reads exclusively from VpnRoutes.getRoutes().

I run a split-DNS setup: my VPN's resolver hands back RFC1918 addresses for some hostnames (services I host at home, behind the WireGuard endpoint). Those hosts are only reachable through the tunnel, but they land in the excluded gap and get pushed out over the underlying network, where they're unreachable. Lookup succeeds (the DNS host gets re-injected as a /32), connection times out — confusing.

This isn't an edge case. Plenty of privacy-conscious users self-host things at home and want to reach them while TC is running. On Android you can't run a second VPN alongside TC, so there's no workaround.

I built the app from master with the three RFC1918 entries removed and it works flawlessly for me.

diff --git a/app/src/main/java/eu/faircode/netguard/VpnRoutes.java b/app/src/main/java/eu/faircode/netguard/VpnRoutes.java
index 29430d6..846bfb8 100644
--- a/app/src/main/java/eu/faircode/netguard/VpnRoutes.java
+++ b/app/src/main/java/eu/faircode/netguard/VpnRoutes.java
@@ -43,12 +43,9 @@ public class VpnRoutes {
     private static final String[][] EXCLUDED_RANGES = {
             // Reserved and private ranges
             {"0.0.0.0", "8"},       // Current network (RFC 1122)
-            {"10.0.0.0", "8"},      // Private (RFC 1918)
             {"100.64.0.0", "10"},   // CGNAT (RFC 6598)
             {"127.0.0.0", "8"},     // Loopback (RFC 1122)
             {"169.254.0.0", "16"},  // Link-local (RFC 3927)
-            {"172.16.0.0", "12"},   // Private (RFC 1918)
-            {"192.168.0.0", "16"},  // Private (RFC 1918)
             {"224.0.0.0", "3"},     // Multicast (224/4) + reserved (240/4)
 
             // T-Mobile Wi-Fi calling

Trade-off: a host on the local LAN (the Wi-Fi router the phone is currently on) would also get pulled into the tunnel — arguably what the user asked for with AllowedIPs = 0.0.0.0/0, and VpnService.protect() still handles Wi-Fi calling.

Would this be acceptable, or would a toggle be preferable?