☰

Мост KVM через соединение с несколькими подсетями

tag-icon • tag-icon kvm-virtualization centos7 bridge bonding
Мост KVM через соединение с несколькими подсетями

Я могу получить доступ к хосту через 213.xxx.xxx.1назначенный, br0:1но виртуальная машина с 213.xxx.xxx.2(мостовым интерфейсом br0:1) не работает.

Нужно ли мне создавать еще один интерфейс моста для второй подсети, но тогда bond0он уже подключен к br0?!

Как в этом сценарии использовать вторую подсеть для виртуальных машин?

Подсети:

213.xxx.xxx.176/28
213.xxx.xxx.0/27 routed via 213.xxx.xx.180

Настраивать:

эм[1-2]

# cat /etc/sysconfig/network-scripts/ifcfg-em[1-2]
DEVICE="em[1-2]"
NAME="bond0-slave[1-2]"
BOOTPROTO="none"
NM_CONTROLLED="yes"
ONBOOT="yes"
TYPE="Ethernet"
USERCTL=no
IPV6INIT=no
PEERDNS=no
MASTER=bond0
SLAVE=yes

связь0

# cat /etc/sysconfig/network-scripts/ifcfg-bond0 
DEVICE="bond0"
NAME="bond0"
BOOTPROTO="none"
NM_CONTROLLED="yes"
ONBOOT="yes"
TYPE="Bond"
USERCTL="no"
IPV6INIT="no"
PEERDNS="no"
BONDING_OPTS="mode=active-backup miimon=100"
BRIDGE=br0

br0

# cat /etc/sysconfig/network-scripts/ifcfg-br0
DEVICE="br0"
NAME="br0"
BOOTPROTO="none"
IPADDR="213.xxx.xxx.180"
GATEWAY="213.xxx.xxx.177"
NETMASK="255.255.255.240"
BROADCAST="213.xxx.xxx.191"
NM_CONTROLLED="yes"
ONBOOT="yes"
TYPE="Bridge"
USERCTL="no"
IPV6INIT="no"
PEERDNS="no"

br0:1

# cat /etc/sysconfig/network-scripts/ifcfg-br0:1 
DEVICE="br0:1"
NAME="br0:1"
BOOTPROTO="none"
IPADDR="213.xxx.xxx.1"
NETMASK="255.255.255.224"
BROADCAST="213.xxx.xxx.31"
NM_CONTROLLED="yes"
#ONBOOT="yes"
TYPE="Bridge"
USERCTL="no"
IPV6INIT="no"
PEERDNS="no"
ONPARENT="yes"

Обновление Ср 18 Янв 16:25:17 GMT 2017:

<interface type='bridge'>
      <mac address='52:54:00:4c:4f:27'/>
      <source bridge='br0'/>
      <model type='virtio'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/>
</interface>

Обновление Вт 24 Янв 11:44:21 GMT 2017:

Настройка сети ВМ:

# cat /etc/sysconfig/network-scripts/ifcfg-eth0 
TYPE="Ethernet"
BOOTPROTO="none"
DEFROUTE="yes"
IPV4_FAILURE_FATAL="no"
NAME="eth0"
DEVICE="eth0"
ONBOOT="yes"
IPADDR="213.xxx.xxx.2"
PREFIX="27"
GATEWAY="213.xxx.xxx.177" <-- not sure if this should be 213.xxx.xxx.180 instead?!

IPTables на хосте:

# iptables -nL
Chain INPUT (policy ACCEPT)
target     prot opt source               destination         
ACCEPT     udp  --  0.0.0.0/0            0.0.0.0/0            udp dpt:53
ACCEPT     tcp  --  0.0.0.0/0            0.0.0.0/0            tcp dpt:53
ACCEPT     udp  --  0.0.0.0/0            0.0.0.0/0            udp dpt:67
ACCEPT     tcp  --  0.0.0.0/0            0.0.0.0/0            tcp dpt:67
ACCEPT     all  --  0.0.0.0/0            0.0.0.0/0            state RELATED,ESTABLISHED
ACCEPT     icmp --  0.0.0.0/0            0.0.0.0/0           
ACCEPT     all  --  0.0.0.0/0            0.0.0.0/0           
ACCEPT     tcp  --  0.0.0.0/0            0.0.0.0/0            state NEW tcp dpt:22
REJECT     all  --  0.0.0.0/0            0.0.0.0/0            reject-with icmp-host-prohibited

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination         
ACCEPT     all  --  0.0.0.0/0            192.168.122.0/24     ctstate RELATED,ESTABLISHED
ACCEPT     all  --  192.168.122.0/24     0.0.0.0/0           
ACCEPT     all  --  0.0.0.0/0            0.0.0.0/0           
REJECT     all  --  0.0.0.0/0            0.0.0.0/0            reject-with icmp-port-unreachable
REJECT     all  --  0.0.0.0/0            0.0.0.0/0            reject-with icmp-port-unreachable
REJECT     all  --  0.0.0.0/0            0.0.0.0/0            reject-with icmp-host-prohibited

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination         
ACCEPT     udp  --  0.0.0.0/0            0.0.0.0/0            udp dpt:68

# iptables -t nat -nL
Chain PREROUTING (policy ACCEPT)
target     prot opt source               destination         

Chain INPUT (policy ACCEPT)
target     prot opt source               destination         

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination         

Chain POSTROUTING (policy ACCEPT)
target     prot opt source               destination         
RETURN     all  --  192.168.122.0/24     224.0.0.0/24        
RETURN     all  --  192.168.122.0/24     255.255.255.255     
MASQUERADE  tcp  --  192.168.122.0/24    !192.168.122.0/24     masq ports: 1024-65535
MASQUERADE  udp  --  192.168.122.0/24    !192.168.122.0/24     masq ports: 1024-65535
MASQUERADE  all  --  192.168.122.0/24    !192.168.122.0/24

Это работает, когда я устанавливаю шлюз по умолчанию на 213.xxx.xxx.1 на виртуальной машине (IP от br0:1 на хосте) - не знаю, почему я не могу просто использовать тот же шлюз по умолчанию, что и на хосте (213.xxx.xxx.177).

Мне также пришлось очистить IPTables, поэтому мне нужно выяснить, какие правила необходимы.

Я также получаю перенаправление при пинге с виртуальной машины, поэтому не уверен, оптимальна ли эта конфигурация:

# ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
From 213.xxx.xxx.1: icmp_seq=1 Redirect Host(New nexthop: 213.xxx.xxx.177)
From 213.xxx.xxx.1 icmp_seq=1 Redirect Host(New nexthop: 213.xxx.xxx.177)
64 bytes from 8.8.8.8: icmp_seq=1 ttl=47 time=7.26 ms
...

Обновление Вт 24 Янв 14:49:43 GMT 2017:

Я не уверен, почему IPTables на самом деле фильтрует пакеты, проходящие через мост, даже если br_netfilterмодуль не загружен.

# lsmod | grep "br_netfilter"; echo $?
1
# test -d /proc/sys/net/bridge; echo $?
1

Это правило тоже не помогло:

# iptables -I FORWARD -m physdev --physdev-is-bridged -j ACCEPT

решение1

Решение, которое «отвечает на вопрос»:

  1. Убедитесь, что на хосте включена переадресация IP, если cat /proc/sys/net/ipv4/ip_forward она не равна 1, посмотрите на этом сайте, как ее изменить.
  2. Измените шлюз виртуальной машины на IP-адрес хоста в подсети виртуальной машины: 213.xxx.xxx.1
  3. Исправьте вашу сломанную конфигурацию iptable. iptables -I FORWARD -m physdev --physdev-is-bridged -j ACCEPTВыглядит нормально. В конце концов измените ее на что-то связанное iptables -I FORWARD -s 213.xxx.xxx.0/27 -j ACCEPT(это означает: принимать весь трафик из сети vms в другую сеть)

Идея этого решения заключается в использовании вашего хоста в качестве шлюза для сети vm. Очевидно, если у вас уже есть другой шлюз в сети 213.xx0 (213.xxx.xx.180), вы можете использовать его напрямую из ваших vms.

Предложенная конфигурация iptables разрешит трафик от виртуальных машин наружу. Если вы хотите разрешить соединения извне к виртуальным машинам, вам нужно установить правило, выглядящее какiptables -I FORWARD -d 213.xxx.xxx.0/27 -j ACCEPT

Рекомендуемое решение: Имейте в виду, что все это, вероятно, просто беспорядок из-за того, как задан вопрос. В реальном мире, если у вас есть маршрутизатор/брандмауэр, который управляет вашими двумя подсетями, вам следует пойти простым путем: - маршрутизатор/брандмауэр будет иметь IP-адрес в каждой подсети. Он будет шлюзом для всех хостов в подсетях - назначьте vlan для каждой подсети - на вашем хосте у вас будет 2 интерфейса и два моста - ваши vms будут соединены мостом в "vms subnet" и использовать брандмауэр в качестве шлюза

Таким образом, у вас не будет сумасшедшей конфигурации iptables / alias / forwarding. У вас будут некоторые хосты в одной подсети, а другие в другой подсети, и маршрутизация / acls / nats, настроенные на вашем брандмауэре. Вам даже не следует назначать ip-адрес в "сети vm" вашему хосту.

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

решение2

Из Википедии:

Шлюз по умолчанию в компьютерных сетях — это узел, который, как предполагается, знает, как пересылать пакеты в другие сети.

Это означает, что узел шлюза должен быть узлом в сети или подсети. Вы используете две подсети на одном интерфейсе br0 213.xxx.xxx.0/27и 213.xxx.xxx.176/28.

213.xxx.xxx.177В сети есть шлюзовой хост 213.xxx.xxx.176/28. И ваш хост-сервер получает доступ в Интернет через этот шлюз. Я думаю, шлюзовой хост 213.xxx.xxx.177— это маршрутизатор, и этот маршрутизатор не является членом (узлом) подсети 213.xxx.xxx.0/27. Но он знает, что подсеть 213.xxx.xxx.0/27доступна через узел 213.xxx.xxx.180(ваш хост-сервер).

У вашей виртуальной машины неправильный адрес шлюза. Если у виртуальной машины есть IP-адрес, 213.xxx.xxx.2/27то у виртуальной машины должен быть адрес шлюза из той же подсети 213.xxx.xxx.0/27. Вот почему у виртуальной машины должен быть адрес шлюза 213.xxx.xxx.1, который ваш хост-сервер имеет в качестве вторичного IP-адреса на br0интерфейсе.

Если вы создадите VM в подсети, 213.xxx.xxx.176/28вы должны назначить ей тот же шлюзовой IP, 213.xxx.xxx.177что и на вашем хост-сервере. Убедитесь, что этот IP нигде не используется.

Кроме того:

Очистите все правила iptables, как описано вздесь

Перед этим необходимо запустить службу iptables. Перезапустите службу iptables после очистки, чтобы сохранить очищенные правила на диске.

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