veth 장치를 사용하여 두 개의 네임스페이스를 직접 연결하려면 어떤 네트워크 접두사를 사용해야 합니까?

veth 장치를 사용하여 두 개의 네임스페이스를 직접 연결하려면 어떤 네트워크 접두사를 사용해야 합니까?

저는 방금 네트워크 네임스페이스를 조사하기 시작했고 매우 일반적인 예를 연구하고 있습니다. 이는 단지 두 개의 veth를 통해 두 개의 네임스페이스를 연결합니다(브릿지가 포함되지 않음).

ip netns add net1
ip netns add net2
ip netns exec net1 ifconfig lo up
ip netns exec net2 ifconfig lo up
ip link add veth1 type veth peer name veth2
ip link set veth1 netns net1
ip link set veth2 netns net2
ip netns exec net1 ifconfig veth1 10.0.15.1/24 up
ip netns exec net2 ifconfig veth2 10.0.15.2/24 up
ip netns exec net1 ping 10.0.15.2

출력은 다음과 같습니다

PING 10.0.15.2 (10.0.15.2) 56(84) bytes of data.
64 bytes from 10.0.15.2: icmp_seq=1 ttl=64 time=0.355 ms
64 bytes from 10.0.15.2: icmp_seq=2 ttl=64 time=0.189 ms
64 bytes from 10.0.15.2: icmp_seq=3 ttl=64 time=0.187 ms
64 bytes from 10.0.15.2: icmp_seq=4 ttl=64 time=0.184 ms
64 bytes from 10.0.15.2: icmp_seq=5 ttl=64 time=0.158 ms
64 bytes from 10.0.15.2: icmp_seq=6 ttl=64 time=0.300 ms
64 bytes from 10.0.15.2: icmp_seq=7 ttl=64 time=0.189 ms
64 bytes from 10.0.15.2: icmp_seq=8 ttl=64 time=0.186 ms
64 bytes from 10.0.15.2: icmp_seq=9 ttl=64 time=0.186 ms

내가 이해할 수 없는 것은 내가 보는 모든 예에서 veth에 IP를 제공할 때 항상 /24 클래스 IP를 제공하는 이유입니다. IP를 부여하려고 하면:

ip netns exec net2 ifconfig veth2 10.0.15.2/32 up

내가 얻는 결과는 다음과 같습니다.

PING 10.0.15.2 (10.0.15.2) 56(84) bytes of data.
From 10.0.15.1 icmp_seq=9 Destination Host Unreachable
From 10.0.15.1 icmp_seq=10 Destination Host Unreachable
From 10.0.15.1 icmp_seq=11 Destination Host Unreachable
From 10.0.15.1 icmp_seq=12 Destination Host Unreachable
From 10.0.15.1 icmp_seq=13 Destination Host Unreachable
From 10.0.15.1 icmp_seq=14 Destination Host Unreachable
From 10.0.15.1 icmp_seq=15 Destination Host Unreachable

단일 IP 주소를 제공할 수 없는 이유는 무엇입니까?

답변1

긴 이야기 짧게

Linux는 주소를 추가할 때 암시적 경로를 추가합니다. 주소가 /32인 경우 암시적 경로를 추가할 수 없습니다. 그런 다음 다른 IP에 경로를 수동으로 추가해야 합니다. 하나의 대상(LAN 또는 IP)으로만 라우팅되도록 의도되었지만 대칭인 경우 일반적으로 피어의 IP로만 라우팅됩니다.ip addresspeer동일한 샷 내에 경로를 추가하는 매개변수입니다 . 따라서 ifconfig두 명령을 사용하는 대신 이 명령(최신 ip명령 사용)을 사용하면 ping이 작동합니다.

ip -n net1 link set veth1 up
ip -n net2 link set veth2 up
ip -n net1 address add 10.0.15.1 peer 10.0.15.2 dev veth1
ip -n net2 address add 10.0.15.2 peer 10.0.15.1 dev veth2

더 긴 답변:

먼저 몇 가지 사항:

  • 문제는 네트워크 네임스페이스와 관련이 없으며 라우팅 및 Linux 기능과 관련된 모든 것입니다. 그럼에도 불구하고 네트워크 네임스페이스는 전체 설정을 모델링하는 데 매우 편리합니다.
  • Linux에서는 이점을 활용하기 위해 이 ifconfig명령(및 기타 명령) 사용을 중단해야 합니다.routebrctlIP 경로 2. ifconfigLinux의 API(ioctl)는 netlink API를 위해 절반이 포기되었으므로 일부 새로운 기능은 ip ...이러한 명령을 통해서만 사용할 수 있습니다.
  • 최근엔 충분해IP 경로 2대부분의 도구 하위 명령은 네임스페이스를 사용할 때 옵션을 단축키로 사용합니다 . -netns가능 하면 아래에서 이 단축키를 사용하겠습니다. 많은 명령 에는 축약된 버전이 있습니다(예: 또는ip -netns net1 FOOip netns exec net1 ip FOOip addrip aip address) 및 일부 매개변수 키워드는 생략될 수 있습니다. 여기서는 약어를 사용하지 않겠습니다( 제외 -n) -netns.

Linux는 넷마스크를 사용하여 주소를 설정할 때 암시적으로 경로를 추가합니다. 넷마스크가 /32이면 이 방법으로 경로를 추가할 수 없습니다(또는 실제로는 여전히 존재합니다.현지의 범위가 지정된 라우팅이지만 숨겨져 있습니다.현지의ip -n net1 route show table local기본 라우팅 테이블 대신 라우팅 테이블( )을 사용합니다. 암시적 라우팅이 필요하지 않은 특정 설정 ip address add과 함께 플래그를 사용하면 이러한 추가를 방지할 수 있습니다 . 기본(모든 호스트 비트 설정 변형) 브로드캐스트 주소와 noprefixroute같은 ifconfig일부 기본 설정도 추가되었습니다. 를 사용할 때 명시적으로 요청해야 합니다 ip address.

무슨 일이 일어나고 있는지 이해하는 데 도움이 되는 몇 가지 예는 다음과 같습니다.

주소를 추가하기 전에 다음을 실행하십시오.ip monitor네임스페이스 중 하나의 별도 터미널에 있습니다. 네트워크 네임스페이스에서 가능한 많은 네트워크 변경 사항을 표시한 다음 첫 번째 주소 add( ip netns exec net1 ifconfig veth1 10.0.15.1/24 up)를 실행합니다. 일반적으로 얻을 수 있는 것은 다음과 같습니다.

# ip -4 -n net1 monitor route
local 10.0.15.1 dev veth1 table local proto kernel scope host src 10.0.15.1 
broadcast 10.255.255.255 dev veth1 table local proto kernel scope link src 10.0.15.1 linkdown 
10.0.0.0/8 dev veth1 proto kernel scope link src 10.0.15.1 linkdown 
broadcast 10.0.0.0 dev veth1 table local proto kernel scope link src 10.0.15.1 linkdown 
Deleted 10.0.0.0/8 dev veth1 proto kernel scope link src 10.0.15.1 linkdown 
Deleted broadcast 10.255.255.255 dev veth1 table local proto kernel scope link src 10.0.15.1 linkdown 
Deleted broadcast 10.0.0.0 dev veth1 table local proto kernel scope link src 10.0.15.1 linkdown 
Deleted local 10.0.15.1 dev veth1 table local proto kernel scope host src 10.0.15.1 
local 10.0.15.1 dev veth1 table local proto kernel scope host src 10.0.15.1 
broadcast 10.0.15.255 dev veth1 table local proto kernel scope link src 10.0.15.1 linkdown 
10.0.15.0/24 dev veth1 proto kernel scope link src 10.0.15.1 linkdown 
broadcast 10.0.15.0 dev veth1 table local proto kernel scope link src 10.0.15.1 linkdown

여기인 것 같아요ifconfig비효율적: 먼저 /8 경로를 추가한 다음 이를 제거하고 요청된 /24 경로를 넣습니다. 이는 과거에 수정된 적이 없는 레거시 문제일 수 있습니다. 이는 다음과 같습니다 ip -n net1 link set veth1 up; ip -n net1 address add 10.0.15.1/24 broadcast + dev veth1.

local 10.0.15.1 dev veth1 table local proto kernel scope host src 10.0.15.1 
broadcast 10.0.15.255 dev veth1 table local proto kernel scope link src 10.0.15.1 linkdown 
10.0.15.0/24 dev veth1 proto kernel scope link src 10.0.15.1 linkdown 
broadcast 10.0.15.0 dev veth1 table local proto kernel scope link src 10.0.15.1 linkdown 

/24가 필요하지 않으면 어떻게 되나요? /32 IP를 설정하고 다음과 같이 직접 라우팅을 추가할 수 있습니다(전체 설정의 (아마도) 더 짧은 버전을 다시 작성했습니다):

ip netns add net1
ip netns add net2
ip -n net1 link set lo up
ip -n net2 link set lo up
ip -n net1 link add name veth1 type veth peer netns net2 name veth2

인터페이스 설정(이전이나 이후에 수행할 수 있으며 일단 시작된 후에는 최종 결과를 변경하지 않음):

ip -n net1 link set veth1 up
ip -n net2 link set veth2 up

주소:

ip -n net1 address add 10.0.15.1/32 dev veth1
ip -n net2 address add 10.0.15.2/32 dev veth2

여기에는 숨겨진 로컬 경로만 ip -4 -n net1 monitor route표시됩니다 .local 10.0.15.1 dev veth1 table local proto kernel scope host src 10.0.15.1

노선:

ip -n net1 route add 10.0.15.2/32 dev veth1
ip -n net2 route add 10.0.15.1/32 dev veth2

두 주소 값은 전혀 관련이 없을 수 있습니다. 192.0.2.1 및 198.51.100.2를 사용할 수도 있습니다. 일부 호스팅 제공업체는 이 메커니즘을 사용하여 추가 "장애 조치 IP"를 제공합니다. 실제로 이러한 특정 상황에 대한 지름길이 있습니다. 관련 정보를 제공하면 해당 주소를 따라 경로가 즉시 추가됩니다. 따라서 이전 4개의 명령 대신 이것으로 충분합니다.

ip -n net1 address add 10.0.15.1 peer 10.0.15.2 dev veth1
ip -n net2 address add 10.0.15.2 peer 10.0.15.1 dev veth2

모든 경우에 이러한 인터페이스는 여전히 지점 간이 아닌 이더넷 인터페이스이므로 다른 IP를 찾기 위해 링크 계층에서 ARP 요청이 계속 발행됩니다.

최종 참고 사항: 세 개 이상의 네트워크 네임스페이스를 함께 사용하려는 경우 LAN 넷마스크 사용으로 되돌아가야 하며 브리지 인터페이스를 생성해야 할 가능성이 높습니다(원래 네임스페이스에 넣을 수 있음). 네임스페이스를 만들었지만 예상치 못한 상호작용을 방지하기 위해 자체적으로 예약된 네임스페이스에 넣는 것이 좋습니다. 그런 다음 각 veth 인터페이스 쌍에 대해 한 쪽은 브리지의 네트워크 네임스페이스에 배치되고 브리지에 종속되어야 합니다(예: ip -n mybridgens link set vethp1 master bridge0).

관련 정보