6ixfalls
commented
6 months ago Possibly fixed through a lot of configuration, but will do deeper testing to confirm
Open 6ixfalls opened 6 months ago
6ixfalls
commented
6 months ago Possibly fixed through a lot of configuration, but will do deeper testing to confirm
I have two nodes, one node has a public address, and another that does not (behind NAT). The node behind NAT can communicate with the node with a public address, but the node with a public address can't dial back. From testing, it appears edgevpn doesn't handle this, but there are specs documented in libp2p that fix this.
Notably, the libp2p Circuit Relay v2 protocol solves this issue by allowing a node to act as a relay. In addition, the Direct Connection Upgrade through Relay protocol allows this to be upgraded into a direct connection, which has the same benefits as direct node-node communication. Ideally, the node with a public address could also act as a relay, which would allow for the other node behind NAT to negotiate with it to connect. This solution would also allow for more nodes of either type to be added without compromising the performance of the network.
I notice that edgevpn has options to add node addresses, but I'm not sure if this works with the Circuit Relay protocol or DCUtR. Edgevpn should automatically negotiate and run these relays so that nodes can connect indirectly.
To summarize, currently, edgevpn doesn't work at all if one of the nodes is behind NAT, only one node can negotiate with the other, manifesting as the node showing up on the public node's blockchain while the private node is empty. Introducing automatic negotiation using the Circuit Relay protocol and the DCUtR protocols would allow edgevpn to traverse these NAT conditions, and allows it to be used in more use cases, such as bridging personal devices into a Kairos cluster for development and management.