ipfs id show non-exist addresses

[cannium]

Version information:

go-ipfs version: 0.4.18-dev-
Repo version: 7
System version: amd64/darwin
Golang version: go1.11

Type:

bug or intended?

Description:

Say 192.168.x.x is my internal IP, xx.xx.xx.xx is my public IP, QmXXXXXX is my ipfs node ID.

When run ipfs id, I observed addresses like

"/ip4/xx.xx.xx.xx/tcp/4001/ipfs/QmXXXXXX",
"/ip4/xx.xx.xx.xx/tcp/50119/ipfs/QmXXXXXX",
"/ip4/xx.xx.xx.xx/tcp/10328/ipfs/QmXXXXXX",
"/ip4/xx.xx.xx.xx/tcp/51086/ipfs/QmXXXXXX"

Among them, two addresses are generated because of NAT, but the other two, are actually bound to my internal IP, 192.168.x.x:4001 and 192.168.x.x:50119, not the public IP.

I'd like to know if this is the intended behavior. A short explanation would be welcomed.

[leerspace]

I'm pretty sure this is intended behavior so that your node can find peers on the local network. If you want to disable this behavior, you might want to look at the server profile option: using either ipfs init --profile=server for a new repo or ipfs config profile apply server.

[Stebalien]

So, the 192.168.x.x:50119 is likely due to #5387. A fix is in the pipeline, it's just queued up with some other fixes.

Note: the 192.168.x.x:4001 is not a bug.

(closing as a duplicate)

[cannium]

I might miss something important. The network is NATed, the public address is NOT on my computer, so /ip4/xx.xx.xx.xx/tcp/4001/ipfs/QmXXXXXX does not exist.
@Stebalien @leerspace

[Stebalien]

If it's NATed, you may have multiple addresses:

1. You'll always have the internal "private" address: /ip4/192.168.1.12/tcp/4001/ipfs/QmXXX.
2. You may also have an external, "public" address: /ip4/64.12.42.111/tcp/5123/ipfs/QmXXX (where 64.12.42.111 is your router's external IP address and 5123 is the port the router has assigned to IPFS; this may also just be 4001, depending on your router).

You'll see (1) because that's the address your machine knows about (by default). You may see (2) because we use ask the router to open a port for us and forward it to (1). If this succeeds, we'll add this address and port to your known addresses.

[cannium]

As I mentioned in my first post, I see 4 addresses with public IPs. Two of them are created because of NAT, the other two are the so-called "OwnObservedAddrs". They have right port numbers but wrong IP addresses, so I'm wondering if this is intended or a bug.

[Stebalien]

The wrong IPs? I see public xxx.xxx.xxx.xxx and private 192.168.xxx.xxx. Can you the actual output of ipfs id and point out which IPs are real/fake/public/private? (you can mask them out or mung them as long as we can tell private/public etc.)

[Stebalien]

Note: You are correct, we also record addresses other peers see us using. One of those random ports is probably the bug I mentioned but the others are likely ports other peers have recently observed us using.

Basically, we locally pick a consistent source port (using reuseport) for all outbound connections. When this happens, some NATs (I've been told), will map this to a consistent external port (and, depending on the firewall configuration, may allow incoming traffic).

(we do need to get better about when to keep these observed addresses as we're currently pretty liberal)

[cannium]

I should have posted the original logs earlier :)

~ ipfs id
{
	"ID": "QmXU1rmfUPp4fnfLKut6Tk4MzWCEgUn9WjNVK1cnEGXRpe",
	"PublicKey": "CAASpgIwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCk/xsdqqibgxSvp3GTzebBKXEFM7RN5r/3r7BCjCVI4G1Zc2sSjxAJ/fs2Ao9HnpYJ185eLA9u9PoCdXsZeLjgFKa+z4FLc29/DK4UpQBvRtYCPZjip7pPas5nbQZ4cUtp3oueVtqBqw6D4duFV+s5lXXOK8mh9kf9nbS8e8nd4Pr1b/ymf1ZHYVFTmiLNJPM2MoZ/biIXrm7/svUl7Ny11mJACE2/PffdmTRPExER4IXQypp+JFKkucCCUvW4x4dxHYkmKIAZTdIp3sYs/k1Mk/5GOdbEd9YeZv5K6fvpeZCcx4RpIrnXpDIq6yWBj+WUsZLcDI54wuXzB0bQwP6lAgMBAAE=",
	"Addresses": [
		"/ip6/::1/tcp/4001/ipfs/QmXU1rmfUPp4fnfLKut6Tk4MzWCEgUn9WjNVK1cnEGXRpe",
		"/ip4/127.0.0.1/tcp/50664/ipfs/QmXU1rmfUPp4fnfLKut6Tk4MzWCEgUn9WjNVK1cnEGXRpe",
		"/ip4/192.168.6.134/tcp/50664/ipfs/QmXU1rmfUPp4fnfLKut6Tk4MzWCEgUn9WjNVK1cnEGXRpe",
		"/ip6/::1/tcp/50666/ipfs/QmXU1rmfUPp4fnfLKut6Tk4MzWCEgUn9WjNVK1cnEGXRpe",
		"/ip4/127.0.0.1/tcp/4001/ipfs/QmXU1rmfUPp4fnfLKut6Tk4MzWCEgUn9WjNVK1cnEGXRpe",
		"/ip4/192.168.6.134/tcp/4001/ipfs/QmXU1rmfUPp4fnfLKut6Tk4MzWCEgUn9WjNVK1cnEGXRpe",
		"/ip4/123.115.55.171/tcp/50664/ipfs/QmXU1rmfUPp4fnfLKut6Tk4MzWCEgUn9WjNVK1cnEGXRpe",
		"/ip4/123.115.55.171/tcp/4001/ipfs/QmXU1rmfUPp4fnfLKut6Tk4MzWCEgUn9WjNVK1cnEGXRpe",
		"/ip4/123.115.55.171/tcp/23932/ipfs/QmXU1rmfUPp4fnfLKut6Tk4MzWCEgUn9WjNVK1cnEGXRpe",
		"/ip4/123.115.55.171/tcp/38477/ipfs/QmXU1rmfUPp4fnfLKut6Tk4MzWCEgUn9WjNVK1cnEGXRpe"
	],
	"AgentVersion": "go-ipfs/0.4.18-dev/",
	"ProtocolVersion": "ipfs/0.1.0"
}

And ipfs daemon --debug NAT logs:

10:47:27.639 DEBUG        nat: NAT Mapping: /ip4/0.0.0.0/tcp/50664 --> /ip4/123.115.55.171/tcp/23932 nat.go:208
10:47:27.647 DEBUG        nat: NAT Mapping: /ip4/0.0.0.0/tcp/4001 --> /ip4/123.115.55.171/tcp/38477 nat.go:208
10:47:47.640 DEBUG        nat: NAT Mapping: /ip4/0.0.0.0/tcp/4001 --> /ip4/123.115.55.171/tcp/38477 nat.go:208
10:47:47.644 DEBUG        nat: NAT Mapping: /ip4/0.0.0.0/tcp/50664 --> /ip4/123.115.55.171/tcp/23932 nat.go:208
10:48:07.646 DEBUG        nat: NAT Mapping: /ip4/0.0.0.0/tcp/4001 --> /ip4/123.115.55.171/tcp/38477 nat.go:208
10:48:07.651 DEBUG        nat: NAT Mapping: /ip4/0.0.0.0/tcp/50664 --> /ip4/123.115.55.171/tcp/23932 nat.go:208
10:48:27.655 DEBUG        nat: NAT Mapping: /ip4/0.0.0.0/tcp/4001 --> /ip4/123.115.55.171/tcp/38477 nat.go:208
10:48:27.660 DEBUG        nat: NAT Mapping: /ip4/0.0.0.0/tcp/50664 --> /ip4/123.115.55.171/tcp/23932 nat.go:208
10:48:47.663 DEBUG        nat: NAT Mapping: /ip4/0.0.0.0/tcp/4001 --> /ip4/123.115.55.171/tcp/38477 nat.go:208
10:48:47.668 DEBUG        nat: NAT Mapping: /ip4/0.0.0.0/tcp/50664 --> /ip4/123.115.55.171/tcp/23932 nat.go:208
10:49:07.669 DEBUG        nat: NAT Mapping: /ip4/0.0.0.0/tcp/4001 --> /ip4/123.115.55.171/tcp/38477 nat.go:208
10:49:07.674 DEBUG        nat: NAT Mapping: /ip4/0.0.0.0/tcp/50664 --> /ip4/123.115.55.171/tcp/23932 nat.go:208
10:49:27.747 DEBUG        nat: NAT Mapping: /ip4/0.0.0.0/tcp/4001 --> /ip4/123.115.55.171/tcp/38477 nat.go:208
10:49:27.751 DEBUG        nat: NAT Mapping: /ip4/0.0.0.0/tcp/50664 --> /ip4/123.115.55.171/tcp/23932 nat.go:208
10:49:47.752 DEBUG        nat: NAT Mapping: /ip4/0.0.0.0/tcp/4001 --> /ip4/123.115.55.171/tcp/38477 nat.go:208
10:49:47.758 DEBUG        nat: NAT Mapping: /ip4/0.0.0.0/tcp/50664 --> /ip4/123.115.55.171/tcp/23932 nat.go:208
10:50:07.757 DEBUG        nat: NAT Mapping: /ip4/0.0.0.0/tcp/4001 --> /ip4/123.115.55.171/tcp/38477 nat.go:208
10:50:07.765 DEBUG        nat: NAT Mapping: /ip4/0.0.0.0/tcp/50664 --> /ip4/123.115.55.171/tcp/23932 nat.go:208
10:50:27.943 DEBUG        nat: NAT Mapping: /ip4/0.0.0.0/tcp/4001 --> /ip4/123.115.55.171/tcp/38477 nat.go:208
10:50:27.947 DEBUG        nat: NAT Mapping: /ip4/0.0.0.0/tcp/50664 --> /ip4/123.115.55.171/tcp/23932 nat.go:208
10:50:47.953 DEBUG        nat: NAT Mapping: /ip4/0.0.0.0/tcp/4001 --> /ip4/123.115.55.171/tcp/38477 nat.go:208
10:50:47.957 DEBUG        nat: NAT Mapping: /ip4/0.0.0.0/tcp/50664 --> /ip4/123.115.55.171/tcp/23932 nat.go:208
10:51:07.961 DEBUG        nat: NAT Mapping: /ip4/0.0.0.0/tcp/4001 --> /ip4/123.115.55.171/tcp/38477 nat.go:208
10:51:07.964 DEBUG        nat: NAT Mapping: /ip4/0.0.0.0/tcp/50664 --> /ip4/123.115.55.171/tcp/23932 nat.go:208

The question is, where

/ip4/123.115.55.171/tcp/4001/ipfs/QmXU1rmfUPp4fnfLKut6Tk4MzWCEgUn9WjNVK1cnEGXRpe
/ip4/123.115.55.171/tcp/50664/ipfs/QmXU1rmfUPp4fnfLKut6Tk4MzWCEgUn9WjNVK1cnEGXRpe

these two addresses come from.

[Stebalien]

Ah, I see. Yeah, that's interesting.

[cannium]

Turns out the 4001 port mapping is created when my node tried to connect to an outside node, so is observed by peers. I add a patch to handle this situation better: libp2p/go-libp2p#411.