Feature request: Show a warning if peer is not publicly dialable

[andrasfuchs]

I use ipfs-desktop 0.8.0.0 (and go-ipfs 0.4.21) on Windows 10.

IPFS ports are open on my Windows Firewall and my router by default. If I run IPFS normally I can connect to 250+ peers and my shared files can be accessed without too much extra delay.

I use a VPN service frequently. This service doesn't support port forwarding, so if I'm on VPN my ports appear to be closed. In this case I can connect to fewer peers (~40) and the access to my files are significantly slower.

I think it would be beneficial to have a small indication somewhere (maybe on the peers page) if the ports on the computer seem to be closed.
A brief explanation of the drawbacks of this would be motivating, and we could even offer some helpful links to configure the firewall and/or the router.

[hacdias]

Thanks for the suggestion @andrasfuchs. I need to see if there's an easy way in Node.js to detect if ports are open on the firewall on all OSes. Do you happen to know if such tool exists?

[andrasfuchs]

I don't know Node.js that much, but I'll look into it. Since the checking must be initiated from outside the network of the node in question, it's very likely that we would need to use an external service to do the check. I suppose we would need both ipv4 and ipv6.

As a long term solution it would be great if any node could ask any other node to check its port, and report it back if it found it open or closed ;)

Update: after checking some port checker websites, I would recommend not to use them, but rather implement a simple ipv4/ipv6/tor port check request option in the node implementation. This way as soon as we connect to at least one peer, we could ask it if our port looks open from their side. If not, we could display the warning message in ipfs-desktop.

I suppose that should be part of go-ipfs first and not ipfs-desktop, right?

[hacdias]

Yes, it should go into the implementation go-ipfs and js-ipfs. Perhaps you should open an issue there 😃

[hacdias]

Just leaving a ref to #1001.

[hacdias]

From @andrasfuchs on ipfs/kubo#6593

So, if we wanted to show a warning message to ipfs-desktop users when they are in passive mode (their port looks closed from the outside), we should:
1, check if AutoReplay is enabled in their config file (because it's needed for the port checking)
2, check if ipfs id returns any addresses with the "p2p-circuit" substring (because this means that our port looks closed)

[jessicaschilling]

@lidel @rafaelramalho19 This sounds like it could be a pretty valid unboarding unblocker - thinking specifically about new users who assume their relevant ports are open, but they're actually not. Is it worth prioritizing?

[lidel]

Hm.. dial check would improve onboarding of new users, but we should avoid using centralized services for the check.

AFAIK go-ipfs ships with AutoNAT enabled to determine if node should be DHT server or only a DHT client:

an ambient NAT autodiscovery service. It allows peers to figure out their NAT dialability situation by using test dial backs through peers providing the AutoNAT service.

In simpler words, go-ipfs asks publicly dialable peers to check if it is publicly dialable too.

So in theory, decentralized solution is in place already, but it is internal to go-ipfs and ipfs-desktop can't leverage it to warn user they are not publicly dialabe, because AutoNAT service is not exposed via HTTP API.

@jacobheun @aschmahmann are you familiar with AutoNAT design/implementation?
Got some questions, and would appreciate sanity check on the idea of using it in IPFS Desktop:

• How reliable it is? Is AutoNAT test happening only once, periodically, or on listening address change?
  • Main use case here would be user moving their laptop between different networks: some having UPnP, some blocking IPFS, some being VPNs.
• thoughts on exposing the result of AutoNAT test via HTTP API somehow?
  • for MVP it does not need to be part of official /api/v0, it could be under /debug like http://127.0.0.1:5001/debug/metrics/prometheus