Detect if IPv6 is disabled in the kernel (like it is in Whonix Gateway)
and skip setting IPv6 in that case. Otherwise 'ip' call would fail and
since the script is with 'set -e', it would interrupt setting IPv4 too.
Log error message in that case anyway.
FixesQubesOS/qubes-issues#5110
Example:
/rw/config/network-hooks.d/test.sh
\#!/bin/bash
command="$1"
vif="$2"
ip="$3"
if [ "$ip" == '10.137.0.100' ]; then
case "$command" in
online)
ip route add 192.168.0.100 via 10.137.0.100
;;
offline)
ip route del 192.168.0.100
;;
esac
fi
In rare cases when vif-route-qubes is called simultaneously with some
other iptables-restore instance, it fails because of missing --wait (and
recent iptables-restore defaults to aborting instead of waiting
for lock). That other call may be from qubes-firewall or user script.
Related to QubesOS/qubes-issues#3665
If IPv6 gateway address provided by dom0 isn't a link local address, add
a /128 route to it. Also, add this address on backend interfaces (vif*).
This is to allow proper ICMP host unreachable packets forwarding - if
gateway (address on vif* interface) have only fe80: address, it will be
used as a source for ICMP reply. It will be properly delivered to the VM
directly connected there (for example from sys-net to sys-firewall), but
because of being link-local address, it will not be forwarded any
further.
This results timeouts if host doesn't have IPv6 connectivity.
If dom0 expose IPv6 address settings, configure it on the interface.
Both backend and frontend side. If no IPv6 configuration is provided,
block IPv6 as it was before.
FixesQubesOS/qubes-issues#718
Core3 no longer reuse netvm own IP for primary DNS. At the same time,
disable dropping traffic to netvm itself because it breaks DNS (as one
of blocked things). This allows VM to learn real netvm IP, but:
- this mechanism is not intended to avoid detection from already
compromised VM, only about unintentional leaks
- this can be prevented using vif-qubes-nat.sh on the netvm itself (so
it will also have hidden its own IP)
QubesOS/qubes-issues#1143
Since 'script' xenstore entry no longer allows passing arguments
(actually this always was a side effect, not intended behaviour), we
need to pass additional parameters some other way. Natural choice for
Qubes-specific script is to use QubesDB.
And since those parameters are passed some other way, it is no longer
necessary to keep it as separate script.
FixesQubesOS/qubes-issues#1143
Apparently even iptables-restore does not handle concurrent firewall
updates. This is especially a problem in case of HVM, which have two
network interfaces (one through stubom and the other direct) added at
the same time.
The later one is present only in latest iptables version - especially
debian does not have it. But we need to handle "Device or resources
busy" problem somehow.
vif-route-qubes can be called simultaneously, for example in case of:
- multiple domains startup
- HVM startup (two interfaces: one to the target domain, second one to
stubdom)
If that happens, one of calls can fail because of iptables lock.
