Network

Interfaces, host name, DNS, IPv4/IPv6 and LAN bridge with automatic rollback.

Network shows every interface with state, addresses, MAC address, speed and MTU, plus the host name, default gateway and the DNS servers in use. Interfaces of Docker, Incus and other services (docker0, br-…, veth…, incusbr0, virbr…, tap…, wg…) are only shown (switch Show virtual) and never changed.

Editing the configuration

Edit configuration opens the editor:

Section	Settings
General	Host name (one DNS label, without domain), DNS servers (one address per line, at most 6; empty = from DHCP), search domains
LAN bridge	Switch for br0 and the Ethernet ports that belong to the bridge
per interface	IPv4: DHCP, static (addresses with prefix, gateway) or off; IPv6: automatic (SLAAC), DHCPv6, static or off; MTU (empty = 1500)

Preview shows the generated files and hints without changing anything. Among other things it checks: valid addresses with prefix, no network or broadcast address, the gateway lies in the network of the interface, no address used twice, MTU 576–9216 (at least 1280 with IPv6), at least one interface with IPv4 or IPv6. Hints appear for example when the address you are connected through goes away, when no gateway or DNS server is left, or when DNS servers are expected from DHCP without systemd-resolved.

LAN bridge for VMs and containers

With the LAN bridge switched on, Bunkerbox creates br0 and adds the selected ports (e.g. enp3s0) without addresses of their own; the address configuration of the port moves to the bridge. Virtual machines and LXC containers under Virtualization then sit directly in the LAN and get addresses from the router. br0 takes over the MAC address of the first port, so the DHCP server usually hands out the same address as before and reservations keep working. STP is off.

Applying with automatic rollback

A wrong network setting can make Bunkerbox unreachable. That is why every change is provisional at first:

1. Apply … shows the future addresses and hints. After confirming, Bunkerbox stages the new files in /var/lib/bunkerbox-network/staged/, backs up every affected file to …/network/backup/ and starts a systemd timer (bunkerbox-network-rollback.timer, 90 seconds).
2. About 1.5 seconds later the unit bunkerbox-network-apply.service activates the new configuration (install the files, set the host name, restart systemd-networkd). The connection may drop for a moment.
3. The page shows a countdown. If it still reaches Bunkerbox, Keep configuration is enough. If the address changes, the page probes the new addresses and offers Open there and confirm for each. The link points to /network-confirm on the new address and carries a one-time code in the fragment (#…, never sent to a server). No login is needed for it, because the session cookie belongs to the old address.
4. Without confirmation within 90 seconds the timer starts bunkerbox-network-rollback.service: it restores the backed-up files, removes new files, deletes a newly created bridge, sets the old host name and activates the previous configuration (ifupdown or systemd-networkd). Roll back now starts the same unit immediately.

The rollback runs entirely in systemd and does not depend on the Bunkerbox service: it also takes effect when the service crashes or restarts. The timer is enabled (timers.target); if the machine reboots before the confirmation, the rollback happens 90 seconds after boot. While a change waits for confirmation, further changes and updates are blocked. If the activation fails, the rollback starts at once (details in the system log, unit bunkerbox-network-apply).

Takeover from ifupdown

A freshly installed Debian configures the network with ifupdown (/etc/network/interfaces). Until the first apply Bunkerbox only reads this file (and the current addresses). On the first apply the apply unit

• takes the ifupdown interfaces down (ifdown -a --exclude=lo),
• replaces /etc/network/interfaces with a version that only contains lo and keeps the original as /etc/network/interfaces.bunkerbox-migrated,
• enables systemd-networkd.

The rollback undoes this (original back, systemd-networkd off again, ifup -a). Files included with source (/etc/network/interfaces.d/) are not taken over; the preview points this out.

Generated files

File	Content
/etc/systemd/network/10-bunkerbox-br0.netdev	Bridge br0 (MACAddress= of the first port, STP=no)
/etc/systemd/network/10-bunkerbox-<port>.network	Bridge member (Bridge=br0) or addresses, DHCP=, Gateway=, DNS=, Domains=, IPv6AcceptRA=, MTUBytes=; DHCPv4 with ClientIdentifier=mac as ifupdown did before
/etc/systemd/network/10-bunkerbox-br0.network	Addresses of the bridge
/etc/systemd/networkd.conf.d/10-bunkerbox.conf	ManageForeignRoutes=no, ManageForeignRoutingPolicyRules=no, so routes and rules of Docker and Incus survive a restart of networkd
/etc/resolv.conf	only without systemd-resolved and with DNS servers entered (at most three are used); a symlink is never overwritten
/etc/hosts	line 127.0.1.1 <hostname>

With systemd-resolved active, DNS servers and search domains reach resolved through networkd. Without resolved, DNS servers sent by DHCP are not used – then enter DNS servers or install systemd-resolved. Every value is validated before it is written; the units only contain fixed programs (install, rm, ip, ifup/ifdown, hostnamectl, systemctl, networkctl) with validated arguments, never a shell.

Resetting by hand

If Bunkerbox is unreachable after a confirmed change, as root on the console:

rm /etc/systemd/network/10-bunkerbox-*
mv /etc/network/interfaces.bunkerbox-migrated /etc/network/interfaces   # if present
systemctl disable --now systemd-networkd.socket systemd-networkd.service
ip link delete br0 2>/dev/null; ifup -a

Mock mode

In mock mode there are enp3s0 (2.5 GbE, 192.168.1.20 and fd00::20 via DHCP), enp4s0 without cable, plus docker0, a veth… and incusbr0; ifupdown manages enp3s0 at first. After applying, the simulation switches after about 2 seconds; without confirmation it rolls back after 90 seconds.