influence RPC public address detection #811

Open
opened 2024-04-18 08:37:31 +00:00 by flokli · 2 comments
Contributor

I have the same config file on each of my garage nodes, and I'd like to keep it that way if possible.

In this network, there's an IPv6 ULA prefix (stable), some private IPv4, as well as one public prefix (not guaranteed to be stable).

I'd like to have each node use the IPv6 ULA, and that's why I configured these addresses in bootstrap_peers.

Looking at the output of garage status, it seems however sometimes nodes find (?) or announce their IPv4 address:

==== HEALTHY NODES ====
ID                Hostname  Address                                     Tags  Zone      Capacity  DataAvail
bd94fdc709ea3f87  n3-rk1    [fd42:172:2042:0:e89a:61ff:fe07:8440]:3901  []    kadriorg  3.5 TB    1.8 TB (44.3%)
afd7e76fa5bb4e20  n4-rk1    [fd42:172:2042:0:438:80ff:fef9:6720]:3901   []    kadriorg  3.5 TB    1.2 TB (29.7%)
cf8ae7c345e3efbb  n2-rk1    [fd42:172:2042:0:dcc6:b6ff:fe53:502b]:3901  []    kadriorg  3.5 TB    1.8 TB (44.2%)
7febdd18a6e81380  n1-rk1    172.20.42.41:3901                           []    kadriorg  3.5 TB    2.2 TB (55.2%)

As you can see, there's an IPv4 address here, and initially I didn't even open up the IPv4 firewall.

I assume these are IPs coming from get_rpc_public_addr(), which in my case uses get_default_ip(), which is defined as such:

fn get_default_ip() -> Option<IpAddr> {
	pnet_datalink::interfaces()
		.iter()
		.find(|e| e.is_up() && !e.is_loopback() && !e.ips.is_empty())
		.and_then(|e| e.ips.first())
		.map(|a| a.ip())
}

I assume the order of elements returned in pnet_datalink::interfaces() is not stable.

Would you be open to accept a PR that makes the rpc_public_addr config option accept a CIDR to specify a range, and in that case, have Garage's get_rpc_public_addr filter out IPs in that range?

I have the same config file on each of my garage nodes, and I'd like to keep it that way if possible. In this network, there's an IPv6 ULA prefix (stable), some private IPv4, as well as one public prefix (not guaranteed to be stable). I'd like to have each node use the IPv6 ULA, and that's why I configured these addresses in `bootstrap_peers`. Looking at the output of `garage status`, it seems however sometimes nodes find (?) or announce their IPv4 address: ``` ==== HEALTHY NODES ==== ID Hostname Address Tags Zone Capacity DataAvail bd94fdc709ea3f87 n3-rk1 [fd42:172:2042:0:e89a:61ff:fe07:8440]:3901 [] kadriorg 3.5 TB 1.8 TB (44.3%) afd7e76fa5bb4e20 n4-rk1 [fd42:172:2042:0:438:80ff:fef9:6720]:3901 [] kadriorg 3.5 TB 1.2 TB (29.7%) cf8ae7c345e3efbb n2-rk1 [fd42:172:2042:0:dcc6:b6ff:fe53:502b]:3901 [] kadriorg 3.5 TB 1.8 TB (44.2%) 7febdd18a6e81380 n1-rk1 172.20.42.41:3901 [] kadriorg 3.5 TB 2.2 TB (55.2%) ``` As you can see, there's an IPv4 address here, and initially I didn't even open up the IPv4 firewall. I assume these are IPs coming from `get_rpc_public_addr()`, which in my case uses `get_default_ip()`, which is defined as such: ``` fn get_default_ip() -> Option<IpAddr> { pnet_datalink::interfaces() .iter() .find(|e| e.is_up() && !e.is_loopback() && !e.ips.is_empty()) .and_then(|e| e.ips.first()) .map(|a| a.ip()) } ``` I assume the order of elements returned in `pnet_datalink::interfaces()` is not stable. Would you be open to accept a PR that makes the `rpc_public_addr` config option accept a CIDR to specify a range, and in that case, have Garage's `get_rpc_public_addr` filter out IPs in that range?
Owner

Yes, PRs are welcome. Make sure that the new behavior is well documented in the config file reference page.

Yes, PRs are welcome. Make sure that the new behavior is well documented in the config file reference page.
Author
Contributor

I opened #817, PTAL.

I opened https://git.deuxfleurs.fr/Deuxfleurs/garage/pulls/817, PTAL.
Sign in to join this conversation.
No Milestone
No Assignees
2 Participants
Notifications
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: Deuxfleurs/garage#811
No description provided.