Bug: Advertised Audio Endpoints Not Correct

[nyaaaaaaatalie]

Describe the bug
The audio endpoints advertised by the daemon need to be double-checked. I attempted to connect over a VPN which utilizes a different network interface/IP address than the main Ethernet on the Raspberry Pi I have running my radios. The websocket connection succeeds, but the audio connection bails out after it's not able to be established. I see this in my packet capture sent from the daemon:

a=candidate:211358957 1 udp 2113940223 fd16:[redacted] 34854 typ host generation 0\r\n
a=candidate:1901922428 1 udp 2113937663 10.[redacted] 34854 typ host generation 0\r\n

Both the v4/v6 addresses sent by the daemon correspond to the LAN IP address, not the VPN IP address. As a result the console attempts to connect to an impossible address.

[W3AXL]

I have not seen this when connecting to a daemon over Wireguard, but that's the only VPN I've tested. There's currently not much in the way of network configuration in the WebRTC negotiation since it's historically "just worked" so this might be annoying to burn down.