☰

ICMP가 Linux 브리지를 통과한 후 IP 소스가 변경되는 이유는 무엇입니까?

tag-icon • tag-icon linux docker internet
ICMP가 Linux 브리지를 통과한 후 IP 소스가 변경되는 이유는 무엇입니까?

br0 및 veth(v0 및 v1) 브리지를 만들었지만 상호 운용되지 않습니다. tcpdump는 ICMP의 IP 소스가 변경되었음을 보여줍니다. Mask가 /24이면 상호 운용이 가능합니다. 당신의 도움을 주셔서 감사합니다.

[root@VM-12-6-centos ~]# ip netns exec n1 ip addr
1: lo: <LOOPBACK> mtu 65536 qdisc noop state DOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
1147: v0@if1146: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether 46:39:b5:cf:bd:b6 brd ff:ff:ff:ff:ff:ff link-netnsid 0
    inet 192.168.0.2/16 scope global v0
       valid_lft forever preferred_lft forever
    inet6 fe80::4439:b5ff:fecf:bdb6/64 scope link 
       valid_lft forever preferred_lft forever

[root@VM-12-6-centos ~]# ip netns exec n2 ip addr 
1: lo: <LOOPBACK> mtu 65536 qdisc noop state DOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 
1149: v1@if1148: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether 56:c0:82:05:6f:7d brd ff:ff:ff:ff:ff:ff link-netnsid 0
    inet 192.168.0.3/16 scope global v1
       valid_lft forever preferred_lft forever
    inet6 fe80::54c0:82ff:fe05:6f7d/64 scope link 
       valid_lft forever preferred_lft forever 

[root@VM-12-6-centos ~]# ip netns exec n2 ping 192.168.0.2 
PING 192.168.0.2 (192.168.0.2) 56(84) bytes of data. ^C
--- 192.168.0.2 ping statistics --- 
3 packets transmitted, 0 received, 100% packet loss, time 81ms

[root@VM-12-6-centos ~]# ip netns exec n1 tcpdump -ni v0 
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on v0, link-type EN10MB (Ethernet), capture size 262144 bytes 
23:49:35.395270 IP 10.0.12.6 > 192.168.0.2: ICMP echo request, id 7989, seq 1, length 64 23:49:40.562143 ARP, Request who-has
192.168.0.2 tell 192.168.0.3, length 28 23:49:40.562154 ARP, Reply 192.168.0.2 is-at 46:39:b5:cf:bd:b6, length 28

[root@VM-12-6-centos ~]# route -n Kernel IP routing table Destination  Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         10.0.12.1       0.0.0.0         UG    100    0        0 eth0
10.0.12.0       0.0.0.0         255.255.252.0   U     100    0        0 eth0
10.42.0.0       0.0.0.0         255.255.255.0   U     0      0        0 cni0
172.17.0.0      0.0.0.0         255.255.0.0     U     0      0        0 docker0
172.20.0.0      0.0.0.0         255.255.0.0     U     0      0        0 docker_gwbridge
172.31.0.0      0.0.0.0         255.255.0.0     U     0      0        0 br-3f74298c82df
192.168.0.0     0.0.0.0         255.255.240.0   U     0      0        0 br-447c96a995be

[root@VM-12-6-centos ~]# brctl show bridge name     bridge id          STP enabled     interfaces br-3f74298c82df         8000.0242cacea67f   no              vethf4618dd br-447c96a995be         8000.024273831baf  no              vethbf5d89d br0             8000.7ae1f3216832       no br-v0
                                                        br-v1 cni0            8000.52bc6b3b510e       no              veth0f9960a8
                                                        veth1cd3811c
                                                        veth2a89c6ed
                                                        veth3aeb1ce7
                                                        vethca9494e3 docker0         8000.0242fcf19461       no docker_gwbridge        
8000.02420fc41a90       no              veth85a243e
                                                        vethd1cfb42

답변1

모든 것이 제대로 작동하려면 두 쌍의 veth파이프를 만들어야 합니다. 한편으로는 브리지에 포함되어야 합니다. 브리지 및 veth 인터페이스는 루트 네트워크 네임스페이스에서 끝납니다. 파이프 v1과 v2의 다른 쪽 끝은 각각 네임스페이스 n1과 네임스페이스 n2에 있습니다. 예:

ip netns add n1
ip netns add n2

브리지에 포함된 두 끝을 bv1 및 bv2라고 합니다.

ip link add v1 netns n1 type veth peer name bv1
ip link add v2 netns n2 type veth peer name bv2
ip link add br0 type bridge
ip link set br0 up
ip link set bv1 master br0
ip link set bv2 master br0
ip link set bv1 up
ip link set bv2 up

brctl show
bridge name bridge id       STP enabled interfaces
br0     8000.d2dba1636571   no          bv1
                                        bv2

n1로 이동:

nsenter --net=/var/run/netns/n1
ip addr add 192.168.0.2/16 dev v1
ip link set v1 up
ip link set lo up
exit

n2로 이동:

nsenter --net=/var/run/netns/n2
ip addr add 192.168.0.3/16 dev v2
ip link set v2 up
ip link set lo up
exit

결과:

ip netns exec n1 ping -c2 -I v1 192.168.0.3
PING 192.168.0.3 (192.168.0.3) 56(84) bytes of data.
64 bytes from 192.168.0.3: icmp_seq=1 ttl=64 time=0.265 ms
64 bytes from 192.168.0.3: icmp_seq=2 ttl=64 time=0.220 ms

ip netns exec n2 ping -c2 -I v2 192.168.0.2
PING 192.168.0.2 (192.168.0.2) 56(84) bytes of data.
64 bytes from 192.168.0.2: icmp_seq=1 ttl=64 time=0.195 ms
64 bytes from 192.168.0.2: icmp_seq=2 ttl=64 time=0.227 ms

답변2

질문에 명확한 답변을 드릴 만큼 정보가 충분하지 않습니다. 하지만 다음과 같습니다.

브리지에는 수많은 다른 인터페이스가 있는데 Docker를 언급하셨습니다. 여러분이 보고 있는 핑 패킷은 여러분이 발행하는 핑이 아니라 Docker 내의 무언가에서 나올 가능성이 높습니다. 이것이 "소스 IP가 변경된" 이유입니다(그렇지 않았고 완전히 다른 핑이었습니다).

Docker 없이 시스템에 브리지와 veth를 생성하여 이를 확인합니다. 또한 ping을 실행할 때 실행되어야 하는 두 번째 터미널에서 tcpdump를 실행해야 합니다.

또 다른 옵션은 Docker의 많은 iptables 규칙 중 하나가 실제로 핑에 영향을 미치는 것입니다.하다어떤 이유로든 소스 주소를 변경하세요.

핵심요약: Docker를 실행 중인 경우,아니요네트워크를 방해해 보세요. 작업을 수행하는 데 어려움을 겪을 것이며 작업을 수행하더라도 다음에 Docker가 iptables 규칙을 업데이트할 때 다시 충돌이 발생할 수 있습니다.

두 컨테이너 간에 직접 네트워킹이 필요한 경우 다음을 사용하세요.오버레이 네트워크, 완료하는 데 5분 정도 소요됩니다.도커 작업자.

~에서https://docs.docker.com/network/iptables/, 의견을 바탕으로 내 강조점:

Linux에서 Docker는 iptables 규칙을 조작하여 네트워크 격리를 제공합니다. 이는 구현 세부 사항이지만Docker가 삽입한 규칙을 수정하면 안 됩니다.iptables 정책에 포함하면 원하는 경우 수행해야 할 작업에 어느 정도 영향을 미칩니다.또한 자신의 정책Docker가 관리하는 것.

즉, 특히 Docker에서 사용하는 브리지에 연결된 모든 항목에는 Docker iptables 규칙이 적용됩니다.수정하면 안 된다.

Docker 네트워킹과 완전히 독립적인 모든 항목에 대해 자체 정책을 가질 수 있지만 Docker의 네트워킹 접근 방식을 방해하지 않는 것이 좋습니다.

즉, Docker 컨테이너 간에 네트워크를 구축하려면 어려운 방법이 아닌 쉬운 방법으로 수행해야 합니다.

답변3

패킷이 통과하기 때문에 IP 소스가 변경됩니다.네트워크 주소 변환로 설정iptables도커로.

이는 네트워크(및 인터넷)의 다른 머신이 Docker 네트워크 내에서 IP 주소를 찾을 수 있는 위치를 모르기 때문에 수행됩니다. 따라서 나가는 모든 패킷은 호스트의 IP를 포함하도록 변경됩니다.

관련 정보