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
Nodes that need to connect to the nexodus network (VPC) require direct connectivity to the nexodus control plane for onboarding and receiving all the required configuration. Scenarios where the endpoint node can not directly connect to a public ip address but would like to connect to the nexodus network, Nexodus does not have any out of the box solution to support this scenario.
The higher level goal is to ensure that we have architectural components in place that makes sure that the nexodus control plane can be reachable to devices that are behind restricted networking walls.
Describe the Enhancement
We can leverage the current DERP relay to act as a relay for the control plane as well. It can be deployed at the network boundaries so all the devices can relay the connections to nexodus control plane through the relay. This minimizes the network prerequisite to allow a single (multiple instances - in case of scaled deployed) to connect to the nexodus control plane compared to all the devices making direct connections. The same relay instance can also be used to route data plane traffic between the nodes that are behind hard NAT. This provides an overall better user experience and adds no additional tasks for day zero.
Alternate Solutions
We can design a different proxy component to relay connection between clients and nexodus control plane. It's one more binary to manage and one more component to maintain in the deployment. Currently we don't see much value in this approach, but happy to see thoughts in this failure.
Additional context
No response
The text was updated successfully, but these errors were encountered:
Describe the Problem Statement
Nodes that need to connect to the nexodus network (VPC) require direct connectivity to the nexodus control plane for onboarding and receiving all the required configuration. Scenarios where the endpoint node can not directly connect to a public ip address but would like to connect to the nexodus network, Nexodus does not have any out of the box solution to support this scenario.
The higher level goal is to ensure that we have architectural components in place that makes sure that the nexodus control plane can be reachable to devices that are behind restricted networking walls.
Describe the Enhancement
We can leverage the current DERP relay to act as a relay for the control plane as well. It can be deployed at the network boundaries so all the devices can relay the connections to nexodus control plane through the relay. This minimizes the network prerequisite to allow a single (multiple instances - in case of scaled deployed) to connect to the nexodus control plane compared to all the devices making direct connections. The same relay instance can also be used to route data plane traffic between the nodes that are behind hard NAT. This provides an overall better user experience and adds no additional tasks for day zero.
Alternate Solutions
We can design a different proxy component to relay connection between clients and nexodus control plane. It's one more binary to manage and one more component to maintain in the deployment. Currently we don't see much value in this approach, but happy to see thoughts in this failure.
Additional context
No response
The text was updated successfully, but these errors were encountered: