The network-uplink-wait.sh script may be called before xen-netfront
module is even loaded (by udev). In that case, `get_qubes_managed_iface`
will fail to get the interface name and the wait will be skipped.
Fix this by loading xen-netfront module explicitly (do not try to
synchronize with udev, which is tricky not knowing the device
name).
* origin/pr/268:
Don’t rely on an arbitrary length limit
Don’t assume dom0 will never have a network connection
Add conntrack-tools dependency to qubes-core-agent-networking
Keep shellcheck from complaining
Stop disabling checksum offload
Remove spurious line continuation; add quotes.
vif-route-qubes: Check that the -e flag is set
Purge stale connection tracking entries
Otherwise, if “user” has the SELinux user “staff_u”, the user will
typically need to write “sudo -r unconfined_r -t unconfined_t”, which is
annoying. If SELinux is disabled, these fields are ignored.
Newer versions of qubes-dom0-update will spawn
qubes-download-dom0-updates.sh in an xterm if GUI mode is enabled.
Therefore, we don’t need to spawn our own progress bar.
Make sure NM config for uplink interface (eth0) is created before
starting NetworkManager itself. Otherwise NM helpfully will try to use
automatic DHCP configuration, which will fail and cause delays on
network start.
... if it doesn't exist.
The /qubes-mac qubesdb entry is present on Qubes 4.1, but not 4.0. It is
ok to depend on it here, but keep safer fallback if this code would need
to be backported.
Previously, network uplink (eth0) was configured in two places:
- udev (asynchronously)
- qubes-misc-post.service - at the very end of the boot process
This caused multiple issues:
1. Depending on udev event processing (non-deterministic), network
uplink could be enabled too early, for example before setting up
firewall.
2. Again depending on udev processing, it can be enabled quite late in
the boot process, after network.target is up and services assume
network already configured. This for example causes qubes-firewall to
fail DNS queries.
3. If udev happen try to enable enable networking even earlier, it may
happend before qubesdb-daemon is started, in which case network setup
fill fail. For this case, there was network re-setup in
qubes-misc-post service - much later in the boot.
Fix the above by placing network uplink setup in a dedicated
qubes-network-uplink@${INTERFACE}.service unit ordered after
network-pre.target and pulled in by udev based on vif device existence,
to handle also dynamic network attach/detach.
Then, create qubes-network-uplink.service unit waiting for appropriate
interface-specific unit (if one is expected!) and order it before
network.target.
QubesOS/qubes-issues#5576
Stop IP forwarding when stopping qubes-network service (which initially
enables it). This makes ordering against qubes-firewall safe - firewall
is applied before allowing IP forward and then is removed when IP
forward is already disabled.
FixesQubesOS/qubes-issues#5599
* origin/pr/232:
Use netvm_gw_ip instead of netvm_ip
Remove commented-out code
Add NetVM-facing neighbor entry in NAT namespace
Optimization: use `ip -n` over `ip netns exec`
NAT network namespaces need neighbor entries
vif-route-qubes: better input validation
Don’t use onlink flag for nexthop
Fix running under -euo pipefail
Don’t hardcode MAC addresses
Add gateway IP+MAC, not VM’s own
Add permanent neighbor entries
network: prevent IP spoofing on upstream (eth0) interface
network: setup anti-spoofing firewall rules before enabling the interface
The socket path will be included in a shell command and then as a socat
argument, so only allow a small subset of known-safe characters. In
practice, this has not been a problem because mktemp doesn’t include
these characters in its output.
