search

ipfs / kubo

An IPFS implementation in Go
https://docs.ipfs.tech/how-to/command-line-quick-start/
Other
16.12k stars 3.01k forks source link

Support QUIC in private networks #8006

Open akowalsk opened 3 years ago

akowalsk commented 3 years ago

Version information:

go-ipfs version: 0.8.0-ce693d7e8 Repo version: 11 System version: amd64/linux Golang version: go1.14.15

Description:

When using a private swarm (by placing a properly formatted swarm.key file in the repo), the daemon won't listen for the QUIC protocol even when configured in Addresses. If you increase the logging level, the relevant message that appears is:

WARN swarm2 listen on /ip4/0.0.0.0/udp/4001/quic failed: no transport for protocol WARN swarm2 listen on /ip6/::/udp/4001/quic failed: no transport for protocol

I found some reference to this being a problem in earlier releases (pre-0.6 when QUIC was redone) here. The release notes imply that QUIC is GA now and should be preferred for all connections.

Steps to replicate:

  1. Create a new repo with ipfs init
  2. Start the daemon The output will include "Swarm listening on /ip4/127.0.0.1/udp/4001/quic"
  3. Add a properly formatted swarm.key file to the repo.
  4. Start the daemon The output will not include "Swarm listening on /ip4/127.0.0.1/udp/4001/quic"
Stebalien commented 3 years ago

Support for private connections on QUIC was never finished. Work was started in https://github.com/libp2p/go-libp2p-quic-transport/pull/119 but was never finished because it was never really a high priority. QUIC is important when you have a large network (no per-connection file descriptor, fast connection establishment times, etc.). Private networks are usually small enough that you can remain connected to all peers on the network without running out of file descriptors.

However, you're right. We should finish this eventually.

akowalsk commented 3 years ago

Understood. Just to add another use case to the list for this, I actually need it for NAT traversal (where nodes of the private network are behind different and independent NAT devices that do not support UPnP). Specifically, I need a UDP-based protocol (QUIC itself doesn't matter to me) so that I can use a STUN/ICE server to communicate peer connections back to each node after doing a UDP hole punch. I realize IPFS itself doesn't support STUN/ICE right now, but I can handle this out of band as long as the communication protocol uses UDP.

Stebalien commented 3 years ago

Ah, I see. Yeah, that makes sense. FYI: https://github.com/libp2p/go-libp2p/issues/1039.

ldhios commented 1 year ago

@akowalsk Hi, I am having the same NAT problem as you while using ipfs private network. Do you have any good solutions?

Tommi04 commented 4 months ago

@Stebalien Hi, excuse me, what about this issue? Nowaday I have the error "quic-transport quic/transport.go:75 QUIC doesn't support private networks yet.". I am in the same situation of @akowalsk, behind a NAT in a private company's network and I am not able to connect each peer with TCP protocol, I can't see them by the dht