Resolve route bug for MacOS

[happyharryh]

Starting from MacOS Tahoe, running ZeroTierOne may corrupt the operating system’s routing table and DNS configuration (#2520 ). The occurrence of this problem depends on the network environment (not happen in all environments). In certain network setups, when Allow Managed Addresses is enabled, either immediately or after running for a period of time, the OS routing table and DNS become unusable. In the past three months (after updating to MacOS Tahoe), I have to disable Allow Managed Addresses and manually add the virtual IP by sudo ifconfig feth537 inet xx.xx.xx.xx/24 up.

These days, by debugging, I found that this issue is related to the code in MacDNSHelper.mm. As shown in the code, skipping the configuration of State:/Network/Service/%.16llx/IPv4:Router in SystemConfiguration can prevent this problem from occurring.

The logic of the setting was introduced in commit #1d095e8, seemingly to fix network DNS on macOS. However, starting with MacOS Tahoe, Apple appears to have changed certain behaviors related to SystemConfiguration, causing the breaking.

Here is my environment:

MacOS 26.2
ZeroTierOne 1.16.0
allowManaged = 1
allowGlobal = 0
allowDefault = 0
allowDNS = 0

In my network environment, applying the modification of this PR restores normal behavior. However, I am not sure whether this change could introduce other issues, for example when the settings of allowGlobal/allowDefault/allowDNS changes.

I would appreciate if maintainers or others who can build and test ZeroTier could help verify this PR.

[CLAassistant]

All committers have signed the CLA.

[ihexon]

In macOS 26.2 (Build 25C56), ZeroTier One built from the latest main branch commit
8d4cb1e no longer appears to exhibit the previously observed routing issues.

➜  ~ sw_vers
ProductName:		macOS
ProductVersion:		26.2
BuildVersion:		25C56

➜  ~ route -n get default

route to: default
destination: default
mask: default
gateway: 192.168.1.1
interface: en0
flags: <UP,GATEWAY,DONE,STATIC,PRCLONING,GLOBAL>
recvpipe  sendpipe  ssthresh  rtt,msec    rttvar  hopcount      mtu     expire
0         0         0         0         0         0      1500         0

Based on this limited testing, it appears that Apple may have addressed the underlying issue at the OS level.

However, this is purely anecdotal, and confirmation from other users and environments would be helpful to determine whether the problem has been fully resolved.