두 개의 브리지된 veth가 서로 핑을 보낼 수 없는 이유는 무엇입니까?

라우팅은 각각 자체 네트워크 스택이 있는 여러 시스템 간에, 즉 여러 네트워크 스택 간에 이루어져야 합니다.

이것을 테스트하는 데 관심이 없습니다하나의네트워크 스택. 이와 같이 작동하려면 많은 조정이 필요하며 최종 결과는 의도한 대상과 유사한 구성을 반영하지 않으며 이와 같은 프로젝트를 개발하는 데 유용하지 않습니다.

Linux에서 이를 수행하는 가장 간단하고 올바른 방법은 네트워크 네임스페이스(또는 컨테이너)를 사용하는 것입니다.

OP의 설정을 사용하여 인터페이스는 두 네임스페이스(다음을 사용하여 생성됨)로 이동되었습니다.ip netns add). 인터페이스에서 구성 손실이 발생하므로 누락된 콘텐츠를 다시 추가하세요. 그래서뿌리사용자, OP 설정 후(어쨌든 손실되었을 주소 할당 제외):

ip netns add system1
ip netns add system2

ip link set dev veth0 netns system1
ip link set dev veth1 netns system2

ip -n system1 link set lo up # this is optional for this problem
ip -n system2 link set lo up # this is optional for this problem
ip -n system1 address add 10.0.0.1/24 dev veth0
ip -n system2 address add 10.0.0.2/24 dev veth1
ip -n system1 link set dev veth0 up
ip -n system2 link set dev veth1 up

이제 모든 것이 간단합니다.시스템 1그리고시스템 2실제 최종 설정에 사용될 시스템을 시뮬레이션합니다. 다음 명령은 스위치를 통해 실제 시스템에서 예상한 대로 성공하고 정상적인 라우팅 동작을 따릅니다.

ip netns exec system1 ping 10.0.0.2

참고: 처음에 다음과 같은 인터페이스를 생성하여 연결 없이 전체 특정 설정(2개의 피어만 포함)을 단축할 수 있습니다 ip link add name veth0 type veth peer name veth1. 브리지는 문제의 일부가 아니지만 제3의 피어 시스템을 시뮬레이션해야 한다면 반드시 브리지가 필요할 것입니다.

---

호기심에 대한 보상: 질문에 엄격하게 답하세요

목표: 호스트가 (인터페이스를 통하지 않고) 유선을 통해 lo자체적으로 ping 하도록 합니다. 다시 한 번 경고합니다. 이것이 작동하더라도 결과는 여러 시스템 시뮬레이션을 포함하여 유용한 용도로 사용될 수 없습니다.

따라서 이는 네트워크 네임스페이스 없이 OP의 초기 설정을 통해 수행되었습니다.

와하나의네트워크 스택은 일부 조정을 거쳐야 합니다. 아래에는 제대로 작동하지 못하게 하는 세부 사항이 많이 있습니다.

• 시스템은 다음과 같아야 합니다.Accept는 소스 IP 주소가 자신에게 속한 데이터 패킷을 수신합니다.버리는 대신

  sysctl -w net.ipv4.conf.veth0.accept_local=1
  sysctl -w net.ipv4.conf.veth1.accept_local=1
  

• 동일한 패킷이 전송될 때 한 번, 수신될 때 한 번, 두 번 표시되며, 이를 위해서는 다른(정책 기반) 라우팅이 필요합니다.

  시스템은 패킷이 생성되어 로컬로 전송되는 경우 veth0와 이후에 패킷이 외부에서 수신되는 경우를 구별해야 합니다. veth1패스라인으로. 두 개의 서로 다른 라우팅 테이블을 선택하려면 두 개의 서로 다른 정책 라우팅 규칙이 필요합니다. 방향을 반대로 하면 총 4개의 룰과 4개의 테이블이 형성됩니다. 실제로현지의라우팅 테이블에는 이미 이 중 절반(수신된 패킷용: 호스트용)이 포함되어 있으므로 로컬로 나가는 패킷에만 특수 라우팅 규칙과 테이블이 필요합니다.

  정책 규칙:

  ip rule add priority 11 iif lo from 10.0.0.1 lookup 1001
  ip rule add priority 21 iif lo from 10.0.0.2 lookup 2001
  

  특수는 iif lo트래픽이 로컬에서 발생했음을 의미합니다(실제로 인터페이스에서 수신되지 않음 lo).

  연결된 라우팅 테이블에는 각각 고유한 단일 경로가 있습니다.

  ip route add 10.0.0.2 dev veth0 table 1001
  ip route add 10.0.0.1 dev veth1 table 2001
  

• 이것현지의라우팅 테이블이 방해가 됨

  지금까지 우리는:

  # ip rule
  0:      from all lookup local
  11:     from 10.0.0.1 iif lo lookup 1001
  21:     from 10.0.0.2 iif lo lookup 2001
  32766:  from all lookup main
  32767:  from all lookup default
  
  # ip route show table local to root 10.0.0.0/24
  local 10.0.0.1 dev veth0 proto kernel scope host src 10.0.0.1 
  local 10.0.0.2 dev veth1 proto kernel scope host src 10.0.0.2 
  broadcast 10.0.0.255 dev veth0 proto kernel scope link src 10.0.0.1 
  broadcast 10.0.0.255 dev veth1 proto kernel scope link src 10.0.0.2 
  

  이것현지의테이블은 가장 낮은 우선순위 값 규칙을 가지며 먼저 사용됩니다. 처음 두 항목이 먼저 일치하고 추가 규칙(우선순위 11 및 21)과 라우팅을 재정의하여 패킷을 로컬로 유지합니다(예: 인터페이스 사용 lo).

  이러한 항목을 삭제할 수 있지만 위에서 설명한 것처럼 실제로는 필요하지만 정책 규칙을 추가한 후에만 필요합니다. 게다가 인터페이스의 주소를 변경하면 조만간 커널이 해당 주소를 다시 추가하게 됩니다.

  따라서 from all lookup local규칙을 더 높은 우선 순위 값으로 이동하고 우선 순위가 11과 21인 추가 규칙을 먼저 통과하여 특수 경로를 먼저 얻을 수 있습니다.

  ip rule add priority 50 lookup local 
  ip rule del priority 0
  

단일 핑과 그에 대한 응답이 뒤따르는 경로를 확인할 수 있습니다.

초기 패킷은

• veth0다음을 사용할 때 강제 통과 ping -I veth0 10.0.0.2:

  # ip route get oif veth0 to 10.0.0.2
  10.0.0.2 dev veth0 src 10.0.0.1 uid 0 
      cache 
  

• 또는 다음을 사용할 때 소스 IP 주소를 10.0.0.1에 바인딩합니다 ping -I 10.0.0.1 10.0.0.2.

  # ip route get from 10.0.0.1 to 10.0.0.2
  10.0.0.2 from 10.0.0.1 dev veth0 table 1001 uid 0 
      cache 
  

두 경우 모두 라우팅은 동일합니다(다른 라우팅 테이블이 사용됨).

패킷은 브리지를 건너고(나중에 ARP에 대한 경고 참조) 이제 다른 쪽 끝에서 수신됩니다 veth1.

# ip route get from 10.0.0.1 iif veth1 to 10.0.0.2
local 10.0.0.2 from 10.0.0.1 dev lo table local 
    cache <local> iif veth1 

응답은 소스 주소 10.0.0.2를 사용하여 대상 10.0.0.1로 다시 전송됩니다.

# ip route get from 10.0.0.2 to 10.0.0.1
10.0.0.1 from 10.0.0.2 dev veth1 table 2001 uid 0 
    cache 

다음 주소에서 답장을 받았습니다(다리를 건너서) veth0.

# ip route get from 10.0.0.2 iif veth0 to 10.0.0.1
local 10.0.0.1 from 10.0.0.2 dev lo table local 
    cache <local> iif veth0 

플랫 휠이 성공적으로 완료될 것으로 예상됩니다.

ARP 요청 발행 및 해결:

# ip neigh
10.0.0.1 dev veth1 lladdr f2:2a:75:82:17:d3 DELAY
10.0.0.2 dev veth0 lladdr 42:91:a1:a6:64:45 REACHABLE
10.0.0.1 dev br0 lladdr f2:2a:75:82:17:d3 STALE

br0브리지 자체 인터페이스에는 주소가 구성되어 있지 않지만 Linux의 Weak 구현으로 인해 동일한 네트워크 스택에만 존재하고 ARP 및 라우팅에도 참여하는 것을 볼 수 있습니다 .호스트 모델. 위의 내용은 (에서 상속됨 ) 42:91:a1:a6:64:45에서 비롯됩니다 . 따라서 처음 몇 개의 핑은 처음에 -> ( + -> ) 대신 -> (+는 - > 에 응답 )로 라우팅될 수 있으며 잠정적으로 학습된 ARP 항목이 만료되면 몇 초 후에 올바른 흐름으로 되돌릴 수 있습니다.br0veth1pveth0br0veth1veth0veth0veth1veth1veth0

br0라우팅 참여는 다음과 같은 여러 가지 방법으로 차단될 수 있습니다.

• 그리고arp_ignore:

  sysctl -w net.ipv4.conf.br0.arp_ignore=1
  

• 또는 활성화하여rp_filter(을 위한엄격한 역방향 경로 전달) ARP에 응답하지 않도록 다음을 수행합니다.

  sysctl -w net.ipv4.conf.br0.rp_filter=1
  

• 또는 Linux 시스템이 브리지 VLAN 필터링을 지원하는 경우 브리지 포트에서 브리지 자체 인터페이스를 격리합니다.

  ip link set dev br0 type bridge vlan_filtering 1
  bridge vlan del vid 1 dev br0 self
  

  이는 기본 구성에서 브리지 자체 인터페이스의 트래픽을 자체 브리지 포트로 분리하여 로컬 네트워크 스택에서 이를 통한 "누출"을 차단합니다. (이 경우 tcpdump -i br0 -p무차별 모드로 설정하지 않은 옵션으로 캡처해도 -p더 이상 트래픽이 수신되지 않습니다.)

다시 말하지만, 브리지가 다른 곳에 위치할 수 있으므로(예: 실제 스위치, 다른 VM 또는 기타 네트워크 네임스페이스/컨테이너) 실제 시나리오에서는 이 결함이 발생하지 않습니다.