☰

KVM-Bridge über Bonding mit mehreren Subnetzen

tag-icon • tag-icon kvm-virtualization centos7 bridge bonding
KVM-Bridge über Bonding mit mehreren Subnetzen

Ich kann über 213.xxx.xxx.1die Zuweisung auf den Host zugreifen br0:1, aber die VM mit 213.xxx.xxx.2(Bridge-Schnittstelle ein br0:1) funktioniert nicht.

Muss ich für das zweite Subnetz noch ein weiteres Bridgeinterface anlegen, bond0mit dem dann aber schon eine Verbindung hergestellt ist br0?!

Wie kann ich in diesem Szenario grundsätzlich das zweite Subnetz für VMs verwenden?

Subnetze:

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

Aufstellen:

em[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

Bindung0

# 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"

Update Mi 18 Jan 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>

Update Dienstag, 24. Januar 2017, 11:44:21 GMT:

VM-Netzwerk-Setup:

# 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 auf dem Host:

# 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

Es funktioniert, wenn ich auf der VM ein Standard-Gateway auf 213.xxx.xxx.1 einstelle (IP von br0:1 auf dem Host) – ich bin nicht sicher, warum ich nicht einfach dasselbe Standard-Gateway wie beim Host (213.xxx.xxx.177) verwenden kann.

Ich musste auch IPTables leeren, also muss ich herausfinden, welche Regeln erforderlich sind.

Ich bekomme auch eine Umleitung, wenn ich von einer VM aus pinge, daher bin ich nicht sicher, ob diese Konfiguration optimal ist:

# 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
...

Update Dienstag, 24. Januar 2017, 14:49:43 GMT:

Ich bin nicht sicher, warum IPTables tatsächlich Pakete filtert, die die Brücke passieren, auch wenn br_netfilterdas Modul nicht geladen ist

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

Auch diese Regel hat nicht geholfen:

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

Antwort1

Lösung, die „die Frage beantwortet“:

  1. Stellen Sie sicher, dass die IP-Weiterleitung auf dem Host aktiviert ist. Wenn cat /proc/sys/net/ipv4/ip_forward sie nicht 1 ist, sehen Sie auf dieser Site nach, wie Sie sie ändern können.
  2. Ändern Sie das VM-Gateway zur Host-IP im VM-Subnetz: 213.xxx.xxx.1
  3. Reparieren Sie Ihre defekte iptable-Konfiguration. iptables -I FORWARD -m physdev --physdev-is-bridged -j ACCEPTSieht gut aus. Ändern Sie sie eventuell in etwas Link iptables -I FORWARD -s 213.xxx.xxx.0/27 -j ACCEPT(das heißt: akzeptieren Sie den gesamten Datenverkehr vom VMS-Netzwerk zu einem anderen Netzwerk).

Die Idee dieser Lösung besteht darin, Ihren Host als Gateway für das VM-Netzwerk zu verwenden. Wenn Sie bereits ein anderes Gateway im Netzwerk 213.xx0 ( 213.xxx.xx.180 ) haben, können Sie es natürlich direkt von Ihren VMs aus verwenden.

Die vorgeschlagene iptables-Konfiguration erlaubt Datenverkehr von den VMs nach außen. Wenn Sie Verbindungen von außen zu den VMs zulassen möchten, müssen Sie eine Regel wie folgt festlegen:iptables -I FORWARD -d 213.xxx.xxx.0/27 -j ACCEPT

Empfohlene Lösung: Bedenken Sie, dass das alles wahrscheinlich nur ein Durcheinander ist, weil die Frage so gestellt wird. In der Praxis sollten Sie den einfachen Weg wählen, wenn Sie einen Router/eine Firewall haben, der/die Ihre beiden Subnetze verwaltet: - Der Router/die Firewall hat in jedem Subnetz eine IP-Adresse. Er/sie ist das Gateway für alle Hosts in den Subnetzen. - Weisen Sie jedem Subnetz ein VLAN zu. - Auf Ihrem Host haben Sie zwei Schnittstellen und zwei Bridges. - Ihre VMs werden im „VMs-Subnetz“ überbrückt und verwenden die Firewall als Gateway.

Auf diese Weise haben Sie keine verrückte iptables-/Alias-/Weiterleitungskonfiguration. Sie haben einige Hosts in einem Subnetz und andere in dem anderen Subnetz und das Routing/die ACLs/die NATs sind in Ihrer Firewall konfiguriert. Sie sollten Ihrem Host nicht einmal eine IP-Adresse im „VM-Netzwerk“ zuweisen.

Das Zusammenführen zweier Netzwerke in derselben Broadcast-Domäne kann Probleme verursachen. Wenn Sie sich bei der Netzwerkkonfiguration nicht besonders gut auskennen, sollten Sie die Konfiguration mehrerer IP-Adressen auf einem Host vermeiden.

Antwort2

Aus Wikipedia:

Ein Standard-Gateway in einem Computernetzwerk ist der Knoten, von dem angenommen wird, dass er weiß, wie Pakete an andere Netzwerke weitergeleitet werden.

Das bedeutet, dass der Gateway-Knoten ein Knoten im Netzwerk oder Subnetz sein muss. Sie verwenden zwei Subnetze auf einer Schnittstelle br0 213.xxx.xxx.0/27und 213.xxx.xxx.176/28.

Es gibt einen Gateway-Host 213.xxx.xxx.177im Netzwerk 213.xxx.xxx.176/28. Und Ihr Host-Server erhält über dieses Gateway Internetzugriff. Ich denke, der Gateway-Host 213.xxx.xxx.177ist ein Router und dieser Router ist kein Mitglied (Knoten) des Subnetzes 213.xxx.xxx.0/27. Aber er weiß, dass das Subnetz 213.xxx.xxx.0/27über den Knoten (Ihren Host-Server) zugänglich ist 213.xxx.xxx.180.

Ihre VM hat die falsche Gateway-Adresse. Wenn die VM eine IP-Adresse hat, 213.xxx.xxx.2/27muss die VM eine Gateway-Adresse aus demselben Subnetz haben 213.xxx.xxx.0/27. Aus diesem Grund muss die VM eine Gateway-Adresse haben 213.xxx.xxx.1, die Ihr Hostserver als sekundäre IP-Adresse auf br0der Schnittstelle hat.

Wenn Sie eine VM im Subnetz erstellen, 213.xxx.xxx.176/28müssen Sie ihr dieselbe Gateway-IP zuweisen 213.xxx.xxx.177wie Ihrem Hostserver. Stellen Sie sicher, dass diese IP nicht bereits irgendwo verwendet wird.

Zusätzlich:

Löschen Sie alle iptables-Regeln wie unterHier

Zuvor muss der iptables-Dienst gestartet werden. Starten Sie den iptables-Dienst nach dem Löschen neu, um gelöschte Regeln auf der Festplatte zu speichern.

verwandte Informationen