search

ipfs / ipfs-desktop

An unobtrusive and user-friendly desktop application for IPFS on Windows, Mac and Linux.
https://docs.ipfs.tech/install/ipfs-desktop/
MIT License
5.94k stars 857 forks source link

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

Open andrasfuchs opened 5 years ago

andrasfuchs commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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

hacdias commented 5 years ago

Just leaving a ref to #1001.

hacdias commented 5 years ago

From @andrasfuchs on https://github.com/ipfs/go-ipfs/issues/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 commented 4 years ago

@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 commented 4 years ago

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: