Как читать логи Linux «marsian source»?

Как читать логи Linux «marsian source»?

Я настраиваю хост виртуализации 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в качестве источника вывода.

Связанный контент