2:57 p.m.
Hello all,
I did some more investigation.
TL;DR: Internal networks should work for my purposes as Keith said
(while still being able to resolve container names via DNS), but
apparently that doesn't work on my host due to either a bug or
unsupported configuration.
> For each container that needs to talk to another container,
define a
> network in the `networks:` top-level element with `internal: true` set
> for it. In each container's entry in the `services:` top-level
> element, include that network in `networks:`.
When I do that, DNS name resolution stops working: I cannot nslookup
<other container> e.g. a database from within a web server container,
which is useful for avoiding having to hardcode IPs. Any way to help
with that?
The following rules (I copied part of what's present when internal:
false) are enough to get DNS working in containers with internal: true:
iptables -I INPUT 1 -s 10.89.0.0/24 -d 10.89.0.0/24 -p udp --dport
20053 -j ACCEPT
iptables -t nat -I PREROUTING 1 -m addrtype --dst-type LOCAL -p udp
-d 10.89.0.0/24 --dport 53 -j DNAT --to-destination 10.89.0.1:20053
iptables -t nat -I OUTPUT 1 -m addrtype --dst-type LOCAL -p udp -d
10.89.0.0/24 --dport 53 -j DNAT --to-destination 10.89.0.1:20053
Container-to-container networking (directly via their IP) was already
working even without these rules - they only affect DNS resolution.
On my machine I set the dns_bind_port to 20053 in
/etc/containers/containers.conf (because a DNS resolver is already
listening on port 53 on the host and prevents aardvark-dns from running
on the default port), but it turns out that:
* My default policy for the INPUT and FORWARD iptables chains is DROP,
managed by ufw, which blocks access to the resolver. The first rule lets
containers contact the resolver at the non-standard 20053 port, but not
53 (because it's not actually listening at that port).
* The last 2 rules redirect regular port 53 DNS requests from inside
containers to the resolver listening at port 20053, making DNS finally work.
I don't know why they're missing with internal: true. I looked at [0] in
detail and it does not mention anything to explain these two gotchas. Is
there any chance they could be added in the documentation/FAQ, and is
[0] the best place for it?
Or is it something that could be fixed/improved in Podman itself? In the
second bullet point in particular a non-default DNS port is simply not
working at all in an internal network because the DNAT rule is missing.
In the first point I feel that Podman/netavark should cooperate with (or
at least warn about connectivity issues potentially caused by) existing
firewall rules and default chain policies, but I would understand that
supporting all possible (mis-)configurations would be a daunting task!
Thanks a lot for your insights,
François-Xavier
---
[0]
https://github.com/containers/podman/blob/main/docs/tutorials/basic_netwo...