[PATCH v3 0/3] Fixes and workarounds for pasta with Podman in Google Cloud
These patches work around or fix some issues found while testing the Podman integration for pasta in Google Compute Engine environments. v3: Fix up botched rebase, especially in 2/3, further reword 2/3, fix up 1/3 to match the recent patch from David that stores IPv4 netmasks as prefix lengths instead of masks v2: Rephrase commit messages of 1/3 and 2/3 adding examples with addresses. In 2/3, set host addresses (dns4 and dns6) and increase the pointer regardless of what we're doing with dns4_send and dns6_send. Stefano Brivio (3): conf: Adjust netmask on mismatch between IPv4 address/netmask and gateway conf: Split the notions of read DNS addresses and offered ones udp: Check for answers to forwarded DNS queries before handling local redirects conf.c | 74 ++++++++++++++++++++++++++++++++++++++++++++------------ dhcp.c | 4 +-- dhcpv6.c | 5 ++-- ndp.c | 6 ++--- passt.h | 8 ++++-- udp.c | 22 ++++++++--------- 6 files changed, 84 insertions(+), 35 deletions(-) -- 2.35.1
Seen in a Google Compute Engine environment with a machine configured
via cloud-init-dhcp, while testing Podman integration for pasta: the
assigned address has a /32 netmask, and there's a default route,
which can be added on the host because there's another route, also
/32, pointing to the default gateway. For example, on the host:
ip -4 address add 10.156.0.2/32 dev eth0
ip -4 route add 10.156.0.1/32 dev eth0
ip -4 route add default via 10.156.0.1
This is not a valid configuration as far as I can tell: if the
address is configured as /32, it shouldn't be used to reach a gateway
outside its derived netmask. However, Linux allows that, and
everything works.
The problem comes when pasta --config-net sources address and default
route from the host, and it can't configure the route in the target
namespace because the gateway is invalid. That is, we would skip
configuring the first route in the example, which results in the
equivalent of doing:
ip -4 address add 10.156.0.2/32 dev eth0
ip -4 route add default via 10.156.0.1
where, at this point, 10.156.0.1 is unreachable, and hence invalid
as a gateway.
Sourcing more routes than just the default is doable, but probably
undesirable: pasta users want to provide connectivity to a container,
not reflect exactly whatever trickery is configured on the host.
Add a consistency check and an adjustment: if the configured default
gateway is not reachable, shrink the given netmask until we can reach
it.
Signed-off-by: Stefano Brivio
With --dns-forward, if the host has a loopback address configured as
DNS server, we should actually use it to forward queries, but, if
--no-map-gw is passed, we shouldn't offer the same address via DHCP,
NDP and DHCPv6, because it's not going to be reachable.
Problematic configuration:
* systemd-resolved configuring the usual 127.0.0.53 on the host: we
read that from /etc/resolv.conf
* --dns-forward specified with an unrelated address, for example
198.51.100.1
We still want to forward queries to 127.0.0.53, if we receive one
directed to 198.51.100.1, so we can't drop 127.0.0.53 from our list:
we want to use it for forwarding. At the same time, we shouldn't
offer 127.0.0.53 to the guest or container either.
With this change, I'm only covering the case of automatically
configured DNS servers from /etc/resolv.conf. We could extend this to
addresses configured with command-line options, but I don't really
see a likely use case at this point.
Signed-off-by: Stefano Brivio
Now that we allow loopback DNS addresses to be used as targets for
forwarding, we need to check if DNS answers come from those targets,
before deciding to eventually remap traffic for local redirects.
Otherwise, the source address won't match the one configured as
forwarder, which means that the guest or the container will refuse
those responses.
Signed-off-by: Stefano Brivio
participants (1)
-
Stefano Brivio