You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Oct 20, 2023. It is now read-only.
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.
The text was updated successfully, but these errors were encountered:
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:
IP
address forexample.com
from within a Codespace10.0.1.100
through user's local machine10.0.1.0/24
namedeth10
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 usThe same issue would happen if, instead of having the
eth10
, a10.0.1.0/24
route is defined inside the Codespace.This is, of course, an expected issue, but we can improve user experience by:
The text was updated successfully, but these errors were encountered: