We have the following situation: one node is established in the cloud which is a full node, always accessible, the other nodes are under NAT (e.g. mobile network), lets call them node A and node B. Full node has a relay mode turned on and if A calls B through relay like
/addr/QmRelay/p2p-circuit/p2p/QmNode then everything works.
But the problem is that neither node A or node B knows that they must use relay to contact each other. Yes, they announce their addresses (which indicate that connecting node should use a relay), but it is not possible to query their addresses via DHT. When I looked at the logs of the Full node I saw the
peer stopped dht logs, which means that neither node A nor node B are included in the routing table of the Full node.
That means when node A tries to query Full node’s dht for node B’s address it doesn’t get any results, because it is not in the routing table of Full node even if Full node has a connection to node B.
- So the question is how can a Full node tell node A of an address of node B if node A and node B both under NAT and never heard of each other?
- Is our understanding correct that it is impossible to query DHT for such nodes’ addresses (see above how it worked for us in practice)?
- I remember that when I typed
ipfs dht query …I got ids of closest peers (not addresses), maybe it is possible to somehow utilise that?
- I see that at some point such discovery functionality was removed from DHT (Don’t join DHT when behind a NAT · Issue #778 · libp2p/go-libp2p · GitHub), is there any other mechanism in place for that?
- I guess this should be a very important issue for hole punching, because some of the devices will only have NAT’d addresses and wouldn’t be able therefore to be queried in the DHT, how do you solve this problem there?