* 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.
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.
Since AppVMs will have their own NetVM-facing neighbor entries, a user
might (correctly) conclude that NetVMs do not need ARP or NDP enabled.
For this to work with NAT namespaces, they need their own neighbor
entries.
