Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

util.privateBlocks contains loopback address range #102

Closed
woodsaj opened this issue Jan 9, 2017 · 6 comments
Closed

util.privateBlocks contains loopback address range #102

woodsaj opened this issue Jan 9, 2017 · 6 comments
Assignees

Comments

@woodsaj
Copy link

woodsaj commented Jan 9, 2017

When determining the advertiseAddr the IP of each network interface is examined to see if it is a privateIP.

The set of privateIp ranges that the addresses are evaluated against include the loopback address range (127.0.0.0/8).

When iterating over the interface addresses, the loopback address (127.0.0.1) is always returned first on my system (Ubuntu 14.04- 3.13.0-100-generic #147-Ubuntu).

As a result, 127.0.0.1 is always selected as the privateIP address to advertise to peers, which results in the peers being unable to communicate with each other.

I really think that the loopback range should be removed from the privateBlocks or at the very least moved to the end of the slice so that all other private Ip ranges are checked first.

woodsaj pushed a commit to woodsaj/memberlist that referenced this issue Jan 9, 2017
- prefer private networks over link-local and loopback addresses.
- fixes hashicorp#102
woodsaj pushed a commit to woodsaj/memberlist that referenced this issue Jan 9, 2017
- prefer private networks over link-local and loopback addresses.
- fixes hashicorp#102
woodsaj pushed a commit to woodsaj/memberlist that referenced this issue Jan 10, 2017
- when automatically determining the advertiseAddr use a private
IP address if available over a loopback adddress
- fixes hashicorp#102
@slackpad
Copy link
Contributor

slackpad commented Feb 8, 2017

@sean- any thoughts on this one?

@sean-
Copy link
Contributor

sean- commented Feb 8, 2017

This is the express reason why hashicorp/go-sockaddr sorts its addresses before making an address selection. Jiggling the sort order of utils.go's privateBlocks is suboptimal, but pragmatic in a pinch (

memberlist/util.go

Lines 25 to 34 in 9800c50

/*
* Contains an entry for each private block:
* 10.0.0.0/8
* 100.64.0.0/10
* 127.0.0.0/8
* 169.254.0.0/16
* 172.16.0.0/12
* 192.168.0.0/16
*/
var privateBlocks []*net.IPNet
).

From a correctness perspective, there are a few possible solutions, some more correct than others, but all solutions involve the use of hashicorp/go-sockaddr (mostly because that's the bestest hammer available, imnsho! 😁 ).

@woodsaj , can you run the following few commands and see if they're correct for your environment:

$ go get -u github.com/hashicorp/go-sockaddr/cmd/sockaddr
$ sockaddr eval GetPrivateIP

@woodsaj
Copy link
Author

woodsaj commented Feb 8, 2017

$ sockaddr eval GetPrivateIP
192.168.0.102

looks to work correctly. :)

@sean-
Copy link
Contributor

sean- commented Feb 8, 2017

Ha!, excellent. Thank you for that point of validation.

@slackpad, your call now. :) I'm game for PRing this at some point unless you beat me to it. As far as impact, Consul already has a vendor dependency on go-sockaddr so that's a no op there. As far as other public projects, Serf and Nomad will need love because there will be a new library dependency. It's not that high on my list to tackle atm, but I can squeeze it in if needed.... or I'll do it on the train this morning (#108).

@sean- sean- self-assigned this Feb 8, 2017
@slackpad
Copy link
Contributor

slackpad commented Feb 8, 2017

Yep I'll pull this through Serf and Consul - /cc @dadgar for Nomad.

@slackpad
Copy link
Contributor

slackpad commented Feb 8, 2017

Should be fixed at this level by #108.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants