This is a follow up to this issue: "routed" LXC containers with public IP in Vagrant . I realized that I was using “Ubuntu” image accidentally. My intention was to use Debian 10 though, and after changing image to “Debian 10 (cloud)” one, my setup broke.
Specifically: there is something different in Debian when it comes to routing and domain resolution.
Debian 10 container doesn’t connect to the internet by default, but we can make it work by setting up NAT on the host with:
iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
Do anyone know why for Ubuntu container it wasn’t required? I could learn something new.
What still doesn’t work is domain resolution. As you can see below, I have 18.104.22.168 defined as a nameserver in my cloud-init configuration but it doesn’t work:
root@mail-server:~# ping google.com ping: google.com: Temporary failure in name resolution
There is nothing suspicious in the /var/log/cloud-init-output.log .
/etc/network/interfaces.d/50-cloud-init I have:
auto lo iface lo inet loopback auto eth0 iface eth0 inet static address 192.168.7.201/32 dns-nameservers 22.214.171.124 post-up route add default gw 169.254.0.1 || true pre-down route del default gw 169.254.0.1 || true
/etc/resolv.conf contains only comments.
Host runs on Ubuntu 20.04 . Container is Debian 10.
LXC version: 4.0.4
config: core.https_address: '[::]:8443' core.trust_password: true networks:  storage_pools: - config: source: /home/luken/lxd-storage-pools description: "" name: default driver: dir profiles: - config: user.user-data: | #cloud-config users: - name: luken gecos: '' primary_group: luken groups: "sudo" shell: /bin/bash sudo: ALL=(ALL) NOPASSWD:ALL ssh_authorized_keys: - <REDACTED> description: Default LXD profile devices: root: path: / pool: default type: disk name: default - config: user.network-config: | #cloud-config version: 2 ethernets: eth0: addresses: - 192.168.7.201/32 nameservers: addresses: - 126.96.36.199 routes: - to: 0.0.0.0/0 via: 169.254.0.1 on-link: true description: Mail Server LXD profile devices: eth0: ipv4.address: 192.168.7.201 nictype: routed parent: eth1 type: nic name: mail-server
I mean, I KNOW how to make it work, I could add
nameserver 188.8.131.52 to
/etc/resolv.conf or something, but there is something wrong that cloud-init cannot handle it, so instead of hacking some workaround, I (and probably other lxc users) would rather like to know how to make cloud-init work correctly, or understand why it fails at that.
Any help would be appreciated
I also noticed a weird thing on the guest:
root@mail-server:/etc/resolvconf/resolv.conf.d# systemctl --failed UNIT LOAD ACTIVE SUB DESCRIPTION ● networking.service loaded failed failed Raise network interfaces ● systemd-journald-audit.socket loaded failed fail ed Journal Audit Socket LOAD = Reflects whether the unit definition was properly loaded. ACTIVE = The high-level unit activation state, i.e. generalization of SUB. SUB = The low-level unit activation state, values depend on unit type. 2 loaded units listed. Pass --all to see loaded but inactive units, t oo. To show all installed unit files use 'systemctl list-unit-files'. root@mail-server:/etc/resolvconf/resolv.conf.d# systemctl status networking ● networking.service - Raise network interfaces Loaded: loaded (/lib/systemd/system/networking.service; enabled; vendor preset: enabled) Active: failed (Result: exit-code) since Sun 2021-01-24 12:07:03 UTC; 7min ago Docs: man:interfaces(5) Process: 89 ExecStart=/sbin/ifup -a --read-environment (code=exited, status=1/FAILURE) Main PID: 89 (code=exited, status=1/FAILURE) Jan 24 12:07:03 mail-server systemd: Starting Raise network interfaces... Jan 24 12:07:03 mail-server ifup: RTNETLINK answers: File exists Jan 24 12:07:03 mail-server ifup: ifup: failed to bring up eth0 Jan 24 12:07:03 mail-server systemd: networking.service: Main process exited, code=exite d, status=1/FAILURE Jan 24 12:07:03 mail-server systemd: networking.service: Failed with result 'exit-code'. Jan 24 12:07:03 mail-server systemd: Failed to start Raise network interfaces.
This is on barebones testing configuration, so I think it’s worth figuring out what’s going on here, as it may blocking a lot of people from enjoing lxc, because it looks like even Debian 10 doesn’t work without issues out of the box here.