gh-net
gh-net copied to clipboard
traffic might be routed to non-default network interface
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 forexample.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
namedeth10
- we try to do TCP connection to the
example.com
(10.0.1.100
), which is routed by kernel toeth10
, 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.