☰

여러 서브넷과의 결합을 통한 KVM 브리지

tag-icon • tag-icon kvm-virtualization centos7 bridge bonding
여러 서브넷과의 결합을 통한 KVM 브리지

213.xxx.xxx.1할당된 호스트를 통해 호스트에 액세스할 수 있지만 (브리지 인터페이스가 있는 ) br0:1VM이 작동하지 않습니다.213.xxx.xxx.2br0:1

두 번째 서브넷에 대해 또 다른 브리지 인터페이스를 생성해야 하는데 bond0이미 에 연결되어 있습니까 br0?!

기본적으로 이 시나리오에서 VM에 두 번째 서브넷을 어떻게 사용할 수 있나요?

서브넷:

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

설정:

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

본드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"

2017년 1월 18일 수요일 16:25:17 GMT 업데이트:

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

2017년 1월 24일 화요일 11:44:21 GMT 업데이트:

VM 네트워크 설정:

# 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?!

호스트의 IPTable:

# 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

VM에서 기본 게이트웨이를 213.xxx.xxx.1(호스트에서 br0:1의 IP)로 설정하면 작동합니다. 호스트(213.xxx.xxx)와 동일한 기본 게이트웨이를 사용할 수 없는 이유를 잘 모르겠습니다. .177).

IPTable도 플러시해야 했기 때문에 어떤 규칙이 필요한지 알아내야 했습니다.

또한 VM에서 핑을 보낼 때 리디렉션이 발생하므로 이 구성이 최적인지 확실하지 않습니다.

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

2017년 1월 24일 화요일 14:49:43 GMT 업데이트:

br_netfilter모듈이 로드되지 않은 경우에도 IPTable이 실제로 브리지를 통과하는 패킷을 필터링하는 이유를 잘 모르겠습니다.

# 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. 1이 아닌 경우 호스트에서 IP 전달이 활성화되어 있는지 확인하십시오 cat /proc/sys/net/ipv4/ip_forward . 변경 방법은 이 사이트를 참조하십시오.
  2. VM 게이트웨이를 vm 서브넷의 호스트 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 구성은 VM에서 외부로의 트래픽을 허용합니다. 외부에서 VM으로의 연결을 허용하려면 다음과 같은 규칙을 넣어야 합니다.iptables -I FORWARD -d 213.xxx.xxx.0/27 -j ACCEPT

권장 해결 방법: 질문하는 방식 때문에 이 모든 것이 엉망일 수도 있다는 점을 명심하세요. 실제로 두 개의 서브넷을 관리하는 라우터/방화벽이 있는 경우 쉬운 방법을 선택해야 합니다. - 라우터/방화벽은 각 서브넷에 IP 주소를 갖습니다. 서브넷의 모든 호스트에 대한 게이트웨이가 됩니다. 각 서브넷에 VLAN을 할당합니다. 호스트에는 2개의 인터페이스와 브리지가 있습니다. vms는 "vms 서브넷"에 브리지되고 방화벽을 게이트웨이로 사용합니다.

이렇게 하면 미친 iptables/별칭/전달 구성이 없습니다. 한 서브넷에 일부 호스트가 있고 다른 서브넷에 다른 호스트가 있으며 방화벽에 라우팅/acls/nats가 구성되어 있습니다. "vm 네트워크"의 IP 주소를 호스트에 할당해서는 안됩니다.

동일한 브로드캐스트 도메인에 있는 두 네트워크를 병합하는 것은 문제의 원인이며, 네트워크 구성에 자신이 없다면 호스트에 여러 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(호스트 서버) 를 통해 서브넷에 액세스할 수 있다는 것을 알고 있습니다 .

VM에 잘못된 게이트웨이 주소가 있습니다. VM에 IP 주소가 있는 경우 213.xxx.xxx.2/27VM에는 동일한 서브넷의 게이트웨이 주소가 있어야 합니다 213.xxx.xxx.0/27. 그렇기 때문에 VM에는 게이트웨이 주소가 있어야 하며 213.xxx.xxx.1, 호스트 서버는 br0인터페이스의 보조 IP 주소를 가지고 있습니다.

서브넷에 VM을 생성하려면 호스트 서버와 213.xxx.xxx.176/28동일한 게이트웨이 IP를 할당해야 합니다 . 213.xxx.xxx.177이 IP가 어딘가에서 사용되지 않는지 확인하세요.

게다가:

다음에 설명된 대로 모든 iptables 규칙을 지웁니다.여기

이 작업을 수행하기 전에 iptables 서비스를 시작해야 합니다. 삭제된 규칙을 디스크에 저장하려면 삭제 후 iptables 서비스를 다시 시작하세요.

관련 정보