☰

브리지 네트워킹을 사용하여 두 네트워크 네임스페이스 간에 통신을 설정할 수 없습니다.

tag-icon • tag-icon networking network-interface network-namespaces
브리지 네트워킹을 사용하여 두 네트워크 네임스페이스 간에 통신을 설정할 수 없습니다.

나는 후속 조치를 취하고 있다이 비디오Linux의 네트워크 네임스페이스에 대해 직접 연습해 보았지만 어떤 이유로 작동하지 않았습니다. 내가 한 일은 다음과 같습니다.

"blue" 및 "red"라는 2개의 네트워크 네임스페이스를 만든 후:

sudo ip link add bridge type bridge
sudo ip link set dev bridge up
sudo ip link add veth-red type veth peer name veth-red-br
sudo ip link add veth-blue type veth peer name veth-blue-br
sudo ip link set veth-red netns red
sudo ip link set veth-red-br master bridge
sudo ip link set veth-blue netns blue
sudo ip link set veth-blue-br master bridge
sudo ip netns exec red ip addr add 192.168.15.1/24 dev veth-red
sudo ip netns exec blue ip addr add 192.168.15.2/24 dev veth-blue
sudo ip netns exec red ip link set veth-red up
sudo ip link set veth-red-br up
sudo ip netns exec blue ip link set veth-blue up
sudo ip link set veth-blue-br up

이제 빨간색에서 파란색으로 또는 그 반대로 ping을 시도하면 작동하지 않습니다. 이상하게도 ARP가 작동하므로 인터페이스 간에 연결이 있습니다. arp네임스페이스에서 실행하면 올바른 값을 볼 수 있기 때문에 이를 알고 있습니다 .

$ sudo ip netns exec red arp
Address                  HWtype  HWaddress           Flags Mask            Iface
192.168.15.2             ether   ca:4f:b6:65:a0:f8   C                     veth-red

$ sudo ip netns exec blue ifconfig
veth-blue: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 192.168.15.2  netmask 255.255.255.0  broadcast 0.0.0.0
        inet6 fe80::c84f:b6ff:fe65:a0f8  prefixlen 64  scopeid 0x20<link>
        ether ca:4f:b6:65:a0:f8  txqueuelen 1000  (Ethernet)
        RX packets 85  bytes 8946 (8.9 KB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 27  bytes 1986 (1.9 KB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

그러면 빨간색 네임스페이스에는 ARP 테이블에 있는 파란색 네임스페이스의 MAC 주소가 있는 것을 알 수 있는데 왜 ping이 작동하지 않습니까?

답변1

IPv4가 필터링되었기 때문입니다.iptables또는nftables. 당신은 이렇게 생각할 수도 있습니다: 말도 안돼, 이더넷 브리지는 레이어 2에서 작동하므로iptables레이어 3에서 IPv4를 사용합니다.

하지만 방법이 있습니다:br_netfilter(다음을 통해 표시됨백트래커인증서가 만료되도록 허용했기 때문입니다.)

bridge-netfilter 코드는 다음 기능을 활성화합니다.

{Ip,Ip6,Arp} 테이블은 802.1Q VLAN 또는 PPPoE 헤더에 캡슐화된 경우에도 브리지된 IPv4/IPv6/ARP 패킷을 필터링할 수 있습니다. 이를 통해 상태 저장형 투명 방화벽 기능이 가능해집니다.

따라서 이 세 가지 도구의 모든 필터링, 로깅 및 NAT 기능은 브리지된 프레임에서 사용할 수 있습니다.

당신은 또한 볼 수 있습니다Linux 기반 브리지의 ebtables/iptables 상호 작용더 알아보기.

따라서 누군가가 이렇게 하면:

iptables -I FORWARD -j DROP
modprobe br_netfilter

(또는 패킷을 허용하는 규칙 없이 FORWARD 정책을 DROP으로 설정) 기본적으로 브리지는 레이어 2에서 수신된 모든 IPv4 트래픽을 삭제합니다.iptables: IPv4 프레임의 경우 br_netfilter레이어 2 이더넷 프레임은 일시적으로 IPv4 패킷으로 "업그레이드"되어iptables, 아직 Bridge Road에 있습니다. 삭제된 패킷iptables다리에서 나가지 않을 것입니다. 폐기되지 않은 항목(위 예에서는 없음)은 브리지 처리를 계속하기 위해 이더넷 프레임으로 브리지에 다시 공급됩니다.

가능한 원인: Docker. Docker가 실제로 활성화되었습니다 br_netfilter(컨테이너 간 격리를 위해). 명시적으로 문서화되어 있지는 않지만 이는 다음과 같습니다.Docker 부분 소스:

  if config.EnableIPTables || config.EnableIP6Tables {
      if _, err := os.Stat("/proc/sys/net/bridge"); err != nil {
          if out, err := exec.Command("modprobe", "-va", "bridge", "br_netfilter").CombinedOutput(); err != nil {
              logrus.Warnf("Running modprobe bridge br_netfilter failed with message: %s, error: %v", out, err)
          }
      }
  }

bridge커널 모듈을 로드할 때 br_netfilter.

Docker가 설정합니다.iptables' 정책을 DROP으로 전달:

라우터의 도커

Docker는 또한 체인의 정책을 [...] FORWARD로 설정합니다 DROP.

Docker 때문이 아니더라도 분명히 Docker br_netfilter를 통해 로드한 것입니다.physdev그런 다음) 방화벽 규칙이 패킷을 삭제합니다.iptables' (또는nftables') 전달 규칙. 그렇지 않으면 실제로 브리지 규칙이 있습니다.ebtables또는nftables그리고다리패밀리는 전달된 프레임을 차단합니다.

커널 5.3 이전에는 이것이 브리지 수준에서 상태 저장 방화벽을 수행하는 유일한 방법이었을 것입니다.

존재하다이 다이어그램파란색 필드(이더넷)의 녹색(IPv4) 상자는 다음을 나타냅니다.iptables(또는nftablesbr_netfilter)는 활성화할 때 이더넷 브리지 경로에서 실행됩니다.

일반 네트워크의 Netfilter 및 패킷 흐름

시스템 전체 세분성 대신 브리지 세분성을 사용하여 이를 수행하는 방법이 있습니다(새 네임스페이스에도 상속되도록 시작 초기에 이 작업을 수행하는 것이 가장 좋습니다).

  • 해당 효과를 로드 br_netfilter하지만 비활성화합니다.

    modprobe br_netfilter
sysctl -w net.bridge.bridge-nf-call-arptables=0
sysctl -w net.bridge.bridge-nf-call-ip6tables=0
sysctl -w net.bridge.bridge-nf-call-iptables=0

    이 지점에서빨간색그리고파란색통신이 가능하지만 Docker(아마도 손상의 원래 원인)가 임의로 자체적으로 손상됩니다.

  • 선택한 브리지에서 다시 활성화합니다.

    ip link set bridge type bridge nf_call_iptables 1

    사이의 통신빨간색그리고파란색.

커널 5.3부터 시스템 전반에 걸쳐각 네트워크 네임스페이스를 가져오도록 설정, 초기가 아닌 네트워크 네임스페이스에서 이 기능을 비활성화(또는 다시 활성화)해야 하는 경우 해당 기능 내의 모든 브리지에 영향을 미칩니다.

ip netns FOO sysctl -w net.bridge.bridge-nf-call-iptables=X

Docker는 이러한 모드를 지원하지 않습니다. 생성하는 모든 브리지에서(및 브리지 생성 설정이 있는 경우 생성하는 네트워크 네임스페이스에서) sysctl을 활성화해야 하지만 이는 현재 알려져 있지 않습니다.

물론 커널 모듈을 제거하면 상호 작용도 방지되고 트래픽이 반환될 수 있습니다.

rmmod br_netfilter

여전히 커널 5.3으로 시작 중,nftables브리지 시리즈에서 직접 상태 저장 방화벽 지원을 받으므로 br_netfilter더 이상 이 기능을 사용할 필요가 없습니다. br_netfilterPPPoE 관련 방화벽 net.bridge.bridge-nf-filter-pppoe-tagged(기본적으로 활성화되지 않음)과 함께 sysctl을 사용하는 것이 오늘날에도 여전히 유용할 수 있지만, 내가 아는 한 간단한 대체 방법은 없습니다.

여기와 SF에 대한 다음 Q/A에서 관련 답변도 참조하세요.

관련 정보