Only bind loopback addresses when binding to local#28029
Merged
Conversation
Today when binding to local (the default) we bind to any address that is a loopback address, or any address on an interface that declares itself as a loopback interface. Yet, not all addresses on loopback interfaces are loopback addresses. This arises on macOS where there is a link-local address assigned to the loopback interface (fe80::1%lo0) and in Docker services where virtual IPs of the service are assigned to the loopback interface (moby/libnetwork#1877). These situations cause problems: - because we do not handle the scope ID of a link-local address, we end up bound to an address for which publishing of that address does not allow that address to be reached (since we drop the scope) - the virtual IPs in the Docker situation are not loopback addresses, they are not link-local addresses, so we end up bound to interfaces that cause the bootstrap checks to be enforced even though the instance is only bound to local We address this by only binding to actual loopback addresses, and skip binding to any address on a loopback interface that is not a loopback address. This lets us simplify some code where in the bootstrap checks we were skipping link-local addresses, and in writing the ports file where we had to skip link-local addresses because again the formatting of them does not allow them to be connected to by another node (to be clear, they could be connected to via the scope-qualified address, but that information is not written out).
jasontedor
added
:Distributed/Network
ywelsch
approved these changes
Jan 2, 2018
| downloading and playing with Elasticsearch as well as everyday development, but | ||
| it's useless for production systems. To join a cluster, an Elasticsearch node | ||
| must be reachable via transport communication. To join a cluster via a | ||
| non-loopback address, a node must bind transport to an non-loopback address and |
jasontedor
added a commit
that referenced
this pull request
Jan 2, 2018
* Only bind loopback addresses when binding to local Today when binding to local (the default) we bind to any address that is a loopback address, or any address on an interface that declares itself as a loopback interface. Yet, not all addresses on loopback interfaces are loopback addresses. This arises on macOS where there is a link-local address assigned to the loopback interface (fe80::1%lo0) and in Docker services where virtual IPs of the service are assigned to the loopback interface (moby/libnetwork#1877). These situations cause problems: - because we do not handle the scope ID of a link-local address, we end up bound to an address for which publishing of that address does not allow that address to be reached (since we drop the scope) - the virtual IPs in the Docker situation are not loopback addresses, they are not link-local addresses, so we end up bound to interfaces that cause the bootstrap checks to be enforced even though the instance is only bound to local We address this by only binding to actual loopback addresses, and skip binding to any address on a loopback interface that is not a loopback address. This lets us simplify some code where in the bootstrap checks we were skipping link-local addresses, and in writing the ports file where we had to skip link-local addresses because again the formatting of them does not allow them to be connected to by another node (to be clear, they could be connected to via the scope-qualified address, but that information is not written out). Relates #28029
jasontedor
added a commit
that referenced
this pull request
Jan 2, 2018
* Only bind loopback addresses when binding to local Today when binding to local (the default) we bind to any address that is a loopback address, or any address on an interface that declares itself as a loopback interface. Yet, not all addresses on loopback interfaces are loopback addresses. This arises on macOS where there is a link-local address assigned to the loopback interface (fe80::1%lo0) and in Docker services where virtual IPs of the service are assigned to the loopback interface (moby/libnetwork#1877). These situations cause problems: - because we do not handle the scope ID of a link-local address, we end up bound to an address for which publishing of that address does not allow that address to be reached (since we drop the scope) - the virtual IPs in the Docker situation are not loopback addresses, they are not link-local addresses, so we end up bound to interfaces that cause the bootstrap checks to be enforced even though the instance is only bound to local We address this by only binding to actual loopback addresses, and skip binding to any address on a loopback interface that is not a loopback address. This lets us simplify some code where in the bootstrap checks we were skipping link-local addresses, and in writing the ports file where we had to skip link-local addresses because again the formatting of them does not allow them to be connected to by another node (to be clear, they could be connected to via the scope-qualified address, but that information is not written out). Relates #28029
jasontedor
added a commit
that referenced
this pull request
Jan 2, 2018
* Only bind loopback addresses when binding to local Today when binding to local (the default) we bind to any address that is a loopback address, or any address on an interface that declares itself as a loopback interface. Yet, not all addresses on loopback interfaces are loopback addresses. This arises on macOS where there is a link-local address assigned to the loopback interface (fe80::1%lo0) and in Docker services where virtual IPs of the service are assigned to the loopback interface (moby/libnetwork#1877). These situations cause problems: - because we do not handle the scope ID of a link-local address, we end up bound to an address for which publishing of that address does not allow that address to be reached (since we drop the scope) - the virtual IPs in the Docker situation are not loopback addresses, they are not link-local addresses, so we end up bound to interfaces that cause the bootstrap checks to be enforced even though the instance is only bound to local We address this by only binding to actual loopback addresses, and skip binding to any address on a loopback interface that is not a loopback address. This lets us simplify some code where in the bootstrap checks we were skipping link-local addresses, and in writing the ports file where we had to skip link-local addresses because again the formatting of them does not allow them to be connected to by another node (to be clear, they could be connected to via the scope-qualified address, but that information is not written out). Relates #28029
jasontedor
added a commit
that referenced
this pull request
Jan 2, 2018
* Only bind loopback addresses when binding to local Today when binding to local (the default) we bind to any address that is a loopback address, or any address on an interface that declares itself as a loopback interface. Yet, not all addresses on loopback interfaces are loopback addresses. This arises on macOS where there is a link-local address assigned to the loopback interface (fe80::1%lo0) and in Docker services where virtual IPs of the service are assigned to the loopback interface (moby/libnetwork#1877). These situations cause problems: - because we do not handle the scope ID of a link-local address, we end up bound to an address for which publishing of that address does not allow that address to be reached (since we drop the scope) - the virtual IPs in the Docker situation are not loopback addresses, they are not link-local addresses, so we end up bound to interfaces that cause the bootstrap checks to be enforced even though the instance is only bound to local We address this by only binding to actual loopback addresses, and skip binding to any address on a loopback interface that is not a loopback address. This lets us simplify some code where in the bootstrap checks we were skipping link-local addresses, and in writing the ports file where we had to skip link-local addresses because again the formatting of them does not allow them to be connected to by another node (to be clear, they could be connected to via the scope-qualified address, but that information is not written out). Relates #28029
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Today when binding to local (the default) we bind to any address that is a loopback address, or any address on an interface that declares itself as a loopback interface. Yet, not all addresses on loopback interfaces are loopback addresses. This arises on macOS where there is a link-local address assigned to the loopback interface (fe80::1%lo0) and in Docker services where virtual IPs of the service are assigned to the loopback interface (moby/libnetwork#1877). These situations cause problems:
We address this by only binding to actual loopback addresses, and skip binding to any address on a loopback interface that is not a loopback address. This lets us simplify some code where in the bootstrap checks we were skipping link-local addresses, and in writing the ports file where we had to skip link-local addresses because again the formatting of them does not allow them to be connected to by another node (to be clear, they could be connected to via the scope-qualified address, but that information is not written out).