IIRC you reported something to upstream on these lines?
That was ifupdown in wheezy or so that did not fail closed when the pre hook (that we set to Whonix firewall) failed or so, not systemd-networkd.
Is systemd guaranteed air-tight for failing closed and not leaking packets?
Getting a network card up is not a that complex task. Theoretically it could have bugs such as using dhcp even if configured to use static networking.
The conservative approach is to stay with ifupdown since it’s long term stable and - speculation - slower changing target compared to systemd-networkd.
systemd-networkd could have some features we don’t want. Requires research.
As for Predictable Network Interface Names we most likely want to disable them.
With Predictable Network Interface Names on VirtualBox Whonix-Gateway:
- eth0 became enp0s3
- eth1 became enp0s8
With Predictable Network Interface Names on VirtualBox Whonix-Workstation:
- eth0 became enp0s3
I would not be surprised if these have different names in KVM and Qubes.
Currently eth0 and eth1 are hardcoed in various Whonix components.
- whonix-gw-firewall
- whonix-ws-firewall
- whonix-gw-network-conf
- whonix-ws-network-conf
- control-port-filter-python
- whonixcheck
- qubes-whonix
All of these components would have to read these values from some config. With platform specific differences this is absolutely horrible. Would be even more horrible if the same different virtualizers produce different network interface names depending on host operating system and virtuzalizer version.
I am currently searching for a way to disable Predictable Network Interface Names in a clean way:
- without a kernel parameter (may be unreliable, grub dependent)
- without a symlink (cannot be commented) (only one package can own the symlink, what if Qubes also wants to set that symlink)
- using a drop-in