-
Notifications
You must be signed in to change notification settings - Fork 205
Description
- In 1.7.0 we added a port overriding feature that allows users to skip specifying the IP part of the override endpoint (Support override-endpoint with an unspecified IP address #315).
- It's not a slam dunk though, because specifying the IP can still be useful in rare cases where the client cannot reach the server for whatever reason but the other direction (when using the full override endpoint) still works.
- It would be optimal if we supported both full overriding and port overriding at the same time: and thanks to the candidate list we can!
Specifically, we can conceptually add three candidates to the list.
<WIREGUARD_IP>:<WIREGUARD_PORT>,<WIREGUARD_IP>:<OVERRIDE_PORT>,<OVERRIDE_IP>:<OVERRIDE_PORT>.
In more detail: the above endpoints should be checked for validity, duplicates should be removed, the first one should go into the endpoint field rather than candidates, etc. But skipping over these implementation details, this should uniformly handle all existing as well as new overriding use cases.
Additionally, #315 only touched the API part of resolving unspecified IPs, which had an unfortunate by-product of having the server pass the 0.0.0.0 IPs directly through to wireguard. This is not strictly a regression (there's not much else we can do in this case anyway) but it would be good if the fix for the current issue double checked this other part of the server processing and improved it if possible (this is super vague as I have never seen that code).