Re: Networking in a systemd-nspawn container

[Lennart Poettering <lennart@xxxxxxxxxxxxxx>]

On Fr, 22.10.21 19:54, Tobias Hunger (tobias.hunger@xxxxxxxxx) wrote:

> Hello Systemd Mailing List!
>
> I have a laptop and run a couple of systemd-nspawn containers on that
> machine. This works great, except that name resolution insode the
> containers fails whenever the network on the outside changes.
>
> This is not too surprising: At setup time the resolver information is
> copied into the containers and never updated. That is sup-optimal for
> my laptop that I keep moving between networks.
>
> I have been wondering: Would it be possible to forward the containers
> resolver to the host machine resolver somehow?
>
> Could e.g. systemd-nspawn optionally make the hosts resolver available
> in the containers network namespace? Maybe by setting up some port
> forwarding or by putting a socket into the container somewhere?
>
> Any ideas? I can do some of the work with a bit of guidance.

You could use DNSStubListenerExtra= in resolved.conf to make the stub
listen on some additional container-facing IP address, or multiple of
them. But it's not pretty, as it requires manual configuration.

Two ideas I recently thought about:

1. Maybe resolved's "stub" logic should support listening on yet
   another local IP address: 127.0.0.54 or so, where the same stub
   listens as on 127.0.0.53, but where we unconditionally enable
   "bypass" mode. This mode in resolved means that we'll not process
   the messages ourselves very much, but just look at the domains
   mentioned in it for routing info and then pass the lookup upstream
   and its answer back almost unmodified. (we'd also not consider the
   lookups for mdns/llmnr and such). Right now we only enable that mode
   if we encounter traffic we otherwise don't understand. Thus, if you
   use that other IP address you can use resolved basically as a proxy
   towards whatever the current DNS server is, nothing else. (though
   we'd still translate classic UDP and TCP DNS to DoT if configured)

2. Then, teach nspawn to optionally set up nftables/iptables NAT so
   that port 53 of some veth tunnel IP of the host is automatically
   NAT'ed to 127.0.0.54:53.

That way you then get what you are looking for, as you could then
advertise the host-side IP address of your veth tunnel as DNS server
unconditionally, and the right thing would happen.

(i figure wifi tethering applications could make use of this too?)

Lennart

--
Lennart Poettering, Berlin