traffic might be routed to non-default network interface

[legomushroom]

When we resolve a DNS name, the resolved IP address might be routed to a non-default network interface inside a Codespace and hence cannot be routed to the local machine. For example, this happens if a Codespace has a defined route or a network interface that handles a subnet that the resolved IP address is part of.

Example:

• we try to resolve IP address for example.com from within a Codespace
• it is resolved to 10.0.1.100 through user's local machine
• the Codespace also has a network interface for 10.0.1.0/24 named eth10
• we try to do TCP connection to the example.com(10.0.1.100), which is routed by kernel to eth10, and the default network gateway never gets the packet; hence the network traffic is never routed to the local machine by us

The same issue would happen if, instead of having the eth10, a 10.0.1.0/24 route is defined inside the Codespace.

This is, of course, an expected issue, but we can improve user experience by:

• detecting such cases and hinting users with steps to resolve the issue
• listen to all network interfaces on the remote side (currently, we listen on the default gateway only) and hence be able to capture packets for previously resolved DNS names. While this approach allows resolving the issue for users automatically, it is not straightforward. It may create another source of confusion because we would fight against the existing Codespace network config.
• akin to the previous, but we could create an explicit route thru the default gateway for each resolved IP address. As with the previous approach, this one has the potential to generate a source of confusion for the same reason.