Make IPFS in VMs available for p2p connections from the outside #229

New Issue

raucao · 2020-10-25T09:57:03Z

raucao commented

2020-10-25 09:57:03 +00:00

go-ipfs doesn't currently know about its external IP, and thus doesn't accept requests from it. There should be some kind of config variable for this.

It can still connect to other peers itself. But e.g. people running the kredits pinner can't connect to the main gateway node now.

go-ipfs doesn't currently know about its external IP, and thus doesn't accept requests from it. There should be some kind of config variable for this. It can still connect to other peers itself. But e.g. people running the [kredits pinner](https://gitea.kosmos.org/kosmos/kredits-ipfs-pinner/) can't connect to the main gateway node now.

raucao commented

2020-10-26 08:56:13 +00:00

Status update: I worked on this for a while just now, and it appears that Addresses.Announce would be the correct config to use. I added some DNS-based multiaddrs to the config on ipfs-1.

Instead of an error, I now get connection success announced when connecting to the draco node. However, the connection never seems to persist, as I can never see it among ipfs swarm peers.

Status update: I worked on this for a while just now, and it appears that `Addresses.Announce` would be the correct config to use. I added some DNS-based multiaddrs to the config on `ipfs-1`. Instead of an error, I now get connection success announced when connecting to the draco node. However, the connection never seems to persist, as I can never see it among `ipfs swarm peers`.

raucao added the

service

ipfs

label 2020-12-09 13:06:21 +00:00

raucao commented

2021-01-20 12:12:54 +00:00

I have a feeling that we may need #290 for solving this properly. We can, of course, also connect our own nodes internally via the private network, too.

raucao commented

2022-10-24 12:29:48 +00:00

Update: The source of the problem described above is likely that we filter 10.0.0.0/8 addresses via config, so as not to trigger netscan reports in the data center.

Update: The source of the problem described above is likely that we filter `10.0.0.0/8` addresses via config, so as not to trigger netscan reports in the data center.

raucao commented

2023-01-05 10:27:11 +00:00

This has been solved recently.

raucao closed this issue

2023-01-05 10:27:11 +00:00

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: kosmos/chef#229