Go-ipfs: Bootstrap nodes seems blocked by GFW (China)

[blurHY]

There is no peers connected before executing ipfs swarm connect ...

[hoogw]

GFW, is china government build great firewall, has a white list.
Any IP does not on their white list will be blocked.

Only a few IP on white list is allow access, otherwise NOT on white list, will be blocked.
Your nodes not on china government's white list, so blocked.

[Stebalien]

Last time I checked, GFW was blacklist based. The solution here is probably to try to remember nodes that are reachable between restarts so we can bootstrap off of them. In this case, those would be other nodes in China.

[hoogw]

Check here for how to by pass china's great firewall.

https://github.com/breakwa11/gfw_whitelist

https://github.com/pexcn-legacy/gfw-whitelist

https://github.com/neko-dev/gfw_whitelist

https://github.com/pexcn/daily

[blurHY]

Nope, GFW is blacklist based.
Could IPFS remember nodes like i2p?

[blurHY]

Gov's hackers have already add IPFS's default bootstrap nodes to blacklist. So without ipfs swarm connect to add a non-blocked peer, Chinese users will NOT connect to any peers

[Mikaela]

Could IPFS remember nodes like i2p?

https://github.com/ipfs/go-ipfs/issues/3926 and I think this issue may be a duplicate of https://github.com/ipfs/go-ipfs/issues/3908.

[blurHY]

Duplicate

[hoogw]

Chinese government block chinese user connect to each other. How to work around it?

[Stebalien]

Reopened because this issue is useful to track IPFS use in China.

@hoogw within china? That is, you're having trouble connecting two nodes inside china to each other?

[blurHY]

So far, GFW could only block bootstrap nodes.

[LetItGlow]

When I run my daemon, I get a lot of China nodes, how do they even connect to me?

[blurHY]

Maybe they can't. Because GFW can detect IPFS traffic and block it.
https://github.com/HelloZeroNet/ZeroNet/issues/1914

[LetItGlow]

Any ways to encrypt or 'key' the traffic IPFS side so it isn't obvious for packet sniffers (or whatever they are using) anymore?
Edit: Thinking about it, may increase CPU load per connection.

I created a list of china nodes (At least the Webui told so) and compiled that into a list.
I need to check them against a whois, to see if those are "real" China IP exports. (sorry bad joke)

Edit 2:
Could you try to bootstrap to
/ip4/39.106.19.168/tcp/4001/QmX5KX7nA3PwhCgSswaxavGmNvGKP9un6rU5VzXP8Mduyy
This is a real China node, even online.

[Stebalien]

Any ways to encrypt or 'key' the traffic IPFS side so it isn't obvious for packet sniffers (or whatever they are using) anymore?

We already do.

Our current issues are:

1. We usually run on port 4001 (obvious). We've considered listening on a random port by default, it just makes port forwarding a bit trickier. However, we need to seriously revisit this now.
2. We negotiate our crypto protocol in the clear and, worse, use a custom TLS-like (but not TLS) protocol. We're working on switching to plain TLS which should make IPFS nodes look like normal web traffic.

Unfortunately, even if we fix all this, it's still pretty trivial to connect to a computer and _check_ if it's an IPFS node.

[LetItGlow]

Why don't we just ask nicely, after we exchanged keys?
So we go on with the usual Client and server hello, exchange SSL "business cards" and then just ask encryptedly: "Are you IPFS, gimme your ID"
If the server doesn't understand, just leave the room. But decrypting these may reveal that, I think.. Unless one of the business cards is a envelope..

[Stebalien]

That's effectively how the TLS security transport will work. However, the firewall will still be able to politely ask, discover all computers running IPFS, and block them.

[izern]

@LetItGlow
/ip4/39.106.19.168/tcp/4001/ipfs/QmX5KX7nA3PwhCgSswaxavGmNvGKP9un6rU5VzXP8Mduyy

[blurHY]

Any progress ?

[Stebalien]

No. Unfortunately, the best solution for the moment is to add an alternative bootstrapper by running something like (to use @izern's node):

ipfs bootstrap add   /ip4/39.106.19.168/tcp/4001/ipfs/QmX5KX7nA3PwhCgSswaxavGmNvGKP9un6rU5VzXP8Mduyy