[Bug] - Unclean disconnect leaves the tunnel running on MacOS clients

[danixtech]

I recently ran into this issue while setting up the Defguard infrastructure and testing the Mac client. If the client does not disconnect from the tunnel cleanly, then it will sometimes leave the tunnel running in wireguard, while the client says that it disconnected. When you attempt to connect again, it will create a new tunnel, which is a duplicate of the original and cause an IP conflict. I have run into this issue multiple times when doing the following:

• Use the MacOS client to connect to the Defguard Instance
• While the tunnel is up and running, login to the Defguard proxy and make a significant change to the tunnel config. I have experienced this when changing DNS servers, adding new allowed IPs, but most commonly when enabling "Require MFA for this Location".
• The client will seize up and you can "sometimes" hit the disconnect button. However, it never actually completes and usually returns a network error message.
• If you force-quit the client and check Wireguard, it will still show as connected when you run wg show.
• Relaunch the client and then reconnect to the Defguard Instance. It will succeed, but network connectivity starts to act flaky.
• Check Wireguard from CLI again using wg show and you will see two identical tunnels setup and connected. They will usually be labeled as separate tunnels, such as utun4 and utun5
• Since there is an IP conflict happening, network traffic might sporadically work. It just depends on the last one to handshake.
• If you disconnect the Instance in the client, it will remove the most recent tunnel, but not the older one. Ironically, in this state the VPN tunnel still seems to function and network traffic gets cleared up since the IP conflict was resolved.
• The only way I have been able to remove the tunnel is by running launchctl unload net.defguard or launchctl stop net.defguard.
• After that, most things are cleaned up

This is related to #264, since the DNS servers do not get restored to their non-VPN values and I have to change them back manually in their network configs.