☰

동일한 네임스페이스에 있는 veth 장치로부터 ICMP 응답이 없습니다.

tag-icon • tag-icon networking veth
동일한 네임스페이스에 있는 veth 장치로부터 ICMP 응답이 없습니다.

Ubuntu 16.04에서 다음과 같이 veth 장치 쌍을 만들었습니다.

$ sudo ip link add veth1 type veth peer name veth2
$ sudo ip link set dev veth1 up
$ sudo ip link set dev veth2 up
$ sudo ip address add 10.0.10.50/24 dev veth1
$ sudo ip address add 10.0.10.51/24 dev veth2

veth 장치 쌍은 동일한 네임스페이스에 있습니다. 한 veth 장치에서 다른 장치로의 ping을 테스트하려고 합니다. 그래서 다음과 같이 ping을 시도했습니다.

$ ping -I veth1 10.0.10.51
PING 10.0.10.51 (10.0.10.51) from 10.0.10.50 veth1: 56(84) bytes of data.
From 10.0.10.50 icmp_seq=1 Destination Host Unreachable
From 10.0.10.50 icmp_seq=2 Destination Host Unreachable
From 10.0.10.50 icmp_seq=3 Destination Host Unreachable

veth2에 대한 wireshark 추적을 확인할 때 ARP 요청에 대한 응답을 받지 못합니다(veth1에 대해서도 유사한 추적이 관찰됩니다).

 Broadcast  ARP 42  Who has 10.0.10.51? Tell 10.0.10.50

veth1과 동일한 네임스페이스에 있는 ICMP 요청에 veth2가 응답할 수 없는 이유는 무엇입니까?

고쳐 쓰다: 다음과 같이 ping을 시도하면 ICMP 응답을 받지만 Wireshark는 veth1 및 veth2 장치에 대한 추적 정보를 표시하지 않습니다.

 $ ping -I 10.0.10.50 10.0.10.51
 PING 10.0.10.51 (10.0.10.51) from 10.0.10.50 : 56(84) bytes of data.
 64 bytes from 10.0.10.51: icmp_seq=1 ttl=64 time=0.016 ms
 64 bytes from 10.0.10.51: icmp_seq=2 ttl=64 time=0.022 ms

두 ping 테스트 결과의 차이점을 설명할 수 있는 사람이 있습니까?

답변1

부분 답변:

두 번째 변형의 경우 다음을 수행 tcpdump -ni lo하거나 Wireshark를 사용하면 루프백 인터페이스에서 통신이 이루어지는 것을 볼 수 있습니다. 이는 커널이 두 주소가 모두 로컬이라는 것을 인식하고 이러한 주소가 할당된 인터페이스에 관계없이 루프백 인터페이스를 사용하기 때문입니다.

첫 번째 변형의 경우 왜 브로드캐스트에 응답이 없는지 잘 모르겠지만 일반적으로 커널은 한 인터페이스에서 나오고 다른 인터페이스에 나타나는 트래픽을 라우팅 오류로 처리하고 억제합니다. 방송이기 때문에 방송은 아마 통할 것 같습니다.

상당한 노력을 기울이면 이를 조정할 수 있습니다.부메랑 플랫, 그러나 이것은 일반적으로 특별히 유용하지 않습니다.

가상 eth 쌍은 서로 다른 네트워크 네임스페이스를 연결하는 데 사용할 경우에만 의미가 있습니다. 설정 방법은 동일한 LAN 세그먼트에 두 개의 서로 다른 물리적 이더넷 카드를 갖는 것만큼 쓸모가 없습니다.

관련 정보