Проблемы с маршрутизацией между интерфейсами на KVM-хосте

Резюме: ВМ на хосте в разных подсетях могут связываться друг с другом, но виртуальные машины в подсети B не могут связаться с интерфейсом хоста в подсети A. Я не уверен, является ли это продуктом моей лабораторной настройки и правил брандмауэра или что-то в сети libvirt / KVM.

Отказ от ответственности: этот хост виртуальной машины на самом деле является самой виртуальной машиной, а ее внешние интерфейсы представляют собой интерфейсы virbrX с прямым режимом = маршрут, но я не думаю , что это проблема, поскольку большинство виртуальных машин могут нормально взаимодействовать . Тем не менее ...

Хост виртуальной машины имеет два интерфейса. Подсеть A: 192.168.122.10 и 192.168.130.10. маршрутизация выглядит так:

Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
192.168.130.0   0.0.0.0         255.255.255.0   U     0      0        0 br1
192.168.122.0   0.0.0.0         255.255.255.0   U     0      0        0 br0
0.0.0.0         192.168.122.1   0.0.0.0         UG    0      0        0 br0

ВМ (все на этом хосте) на 122 могут подключаться к виртуальным машинам (все на этом хосте) на 130, и наоборот. Однако, когда виртуальная машина на 122 пытается подключиться к ХОСТУ на 130.10, или когда виртуальная машина на 130 пытается подключиться к 122.10, эхо-запросы не работают, и время ожидания соединения истекает.

Выполнение дампа TCP на хосте показывает что пакеты попадают на хост, но никакие пакеты не возвращаются на виртуальную машину. Я вижу это, например:

23:18:24.111043 IP mailserver-a.kugler.localdomain.34642 > 
vmserver-a.kugler.localdomain.ssh <packet information here>

Я, конечно, не вижу ни возвратных пакетов, ни даже попыток возврата пакетов. Нет правил iptables, которые могли бы блокировать (нет правил, все принимаются по умолчанию). Что мне не хватает? Почему все соединения между подсетями работают, кроме , когда я пытаюсь подключиться к хосту виртуальной машины?

Спасибо за любую информацию.

0
задан 10 April 2016 в 10:39
1 ответ

Поразмыслив еще над этим, я понял, что это, вероятно, связано с попыткой ответа пройти через интерфейс 130.10. Я установил этот интерфейс на другую частную подсеть RFC 172.16.x.x, которую я не использовал, и перезапустил сеть. Точно так же хосты 130.x могут подключаться к адресу 122.10.

Это нормально, потому что в производстве второй интерфейс даже не будет иметь действительного IP-адреса, он будет просто служить мостом для виртуальных машин, которые должны быть в этой физической сети.

0
ответ дан 5 December 2019 в 10:35

Теги

Похожие вопросы