
Я настраиваю хост виртуализации KVM с маршрутизацией на основе политик (сеть управления 192.168.1.0/24 для трафика, связанного с хостом, такого как обновления, ssh и т. д., сеть DMZ 192.168.2.0/24, маршрутизируемая на виртуальные машины)
Настройка выглядит так (под ^^^ я имею в видукак вышедля представления древовидной структуры)
#external connectivity
eth0 -> vlan110 -> brhost (192.168.1.9)
^^^ -> vlan120 -> brguest (192.168.2.4)
#internal connectivity
brguestA (10.0.1.1) -> tapA0
^^^ -> tapA1
^^^ -> tapA2
brguestB (10.0.2.1) -> tapB0
^^^ -> tapB1
# ... and so on for each VM group subnet
Машины An находятся в одном "коммутаторе", Bn во втором и т. д. Хост ведет себя как маршрутизатор и имеет установленные iptables. Исходный ip проверяется для каждого моста на уровне iptables.
В целом все "нормально" работает, но когда я выполняю некоторые пограничные операции, все равно ведет себя так, как и должно, но логи говорят о том, что это скорее совпадение, чем действительно правильное функционирование. Например:
подключение к 192.168.1.3 с виртуальной машины (другой хост в сети управления), которая заблокирована на уровне iptables (tcp-reset), дает
(iptables reject log) IN=brguestA OUT=brguest SRC=10.0.1.2 DST=192.168.1.3 ... IPv4: martian source 10.0.1.2 from 192.168.1.3 on dev brhost
обратите внимание, что OUT
интерфейс на самом деле правильный, согласно тому, что он должен делать, учитывая логику разделения хоста/гостя в сети, и даже если такие пакеты будут пересылаться хостом, они все равно будут отброшены на брандмауэре. Тем не менее, хост iptables не может правильно отклонить с помощью tcp-reset, поэтому такие соединения просто висят на виртуальной машине и не получают сброс
подключение к 192.168.1.9 из виртуальной машины дает
IPv4: martian source 192.168.1.9 from 10.0.1.2 on dev brguestA
и ничего больше. Перестановка мест 10.0.1.x и 192.168.1.x в этих журналах меня действительно сбивает с толку, и я не совсем понимаю, что они означают (какой из них src ip, а какой dst ip). Я не совсем понимаю, что пытается сделать хост и почему это не получается. Вот вывод моего ip rule
и ip route
:
ip rule
0: from all lookup local
32763: from 10.0.0.0/16 lookup guest
32764: from 192.168.2.0/24 lookup guest
32765: from all iif lo lookup host
32766: from all lookup main
32767: from all lookup default
ip route show table host
default via 192.168.1.1 dev brhost proto static
192.168.1.0/24 dev brhost proto static
ip route show table guest
default via 192.168.2.1 dev brguest proto static
10.0.0.0/24 dev brguestA proto static
10.0.1.0/24 dev brguestB proto static
# ... so on for other networks
ip route show table main
192.168.1.0/24 dev brhost proto static
10.0.0.0/24 dev brguestA proto static
10.0.1.0/24 dev brguestB proto static
# ...
Я использую systemd-networkd
для управления сетью. Ямысльэто происходит, потому что хост всегда пытается ответить, используя brhost
устройство как OUTPUT
тип пакета, который он iif
установил, lo
поэтому это ловится from iif lookup host
правилом. Однако это, похоже, не тот случай, поскольку подключение к 192.168.2.4
отклоняется должным образом, поэтому он не всегда выбирает brhost
в качестве источника вывода.