UDP: Bind a separate service to each interface #109
Conversation
As discussed in #106, a UDP socket bound to 0.0.0.0 results in pathological behavior when there are multiple interfaces of the same address family. This change binds a separate instance of the UDP service to each interface IP, ensuring that outbound Shadowsocks packets have the expected source IP.
|
Network interfaces can change after the server started. It's difficult and a bit unrealistic to keep track of future changes. |
|
Are you aware of a situation where it would be important to serve Outline on an interface that did not exist when the Outline daemon started? Note that SIGHUP, which causes Outline to reload the config file (e.g. when a new key is added), also would cause it to re-scan the system's interfaces, so it is possible for the management layer to expand coverage to additional interfaces if it knows that they have been added. |
Some of my deployments are on home networks where the interface IPs change irregularly. Some user-space VPN services like OpenVPN may also finish starting after Outline. |
|
OK, dynamic IPs are an interesting case. This approach would fail in that case, because it binds directly to the IPs, rather than to the interfaces. Outline generally assumes static IPs, but Shadowsocks could be deployed using dynamic IPs and a rendezvous mechanism (e.g. dynamic DNS). |
|
This is another thing we need to fix |
As discussed in #106, a UDP socket bound to 0.0.0.0 results in
pathological behavior when there are multiple interfaces of the same
address family. This change binds a separate instance of the UDP
service to each interface IP, ensuring that outbound Shadowsocks packets
have the expected source IP.