루트 네임스페이스를 통해 연결된 두 네트워크 네임스페이스 간 통신을 위해 다이어그램에 표시된 veth 쌍을 사용하려고 합니다. netns A에서 netns B로 ping을 수행할 수 없습니다. 또한 루트 네임스페이스에서 netns A(VA IP) 및 B(VB IP)를 ping할 수 있습니다.
+-------+ +-------+
| A | | B |
+-------+ +-------+
| VA | VB
| |
| RA | RB
+-------------------------+
| |
| Root namespace |
| |
+-------------------------+
ip netns add A
ip netns add B
ip link add VA type veth peer name RA
ip link add VB type veth peer name RB
ip link set VA netns A
ip link set VB netns B
ip addr add 192.168.101.1/24 dev RA
ip addr add 192.168.102.1/24 dev RB
ip link set RA up
ip link set RB up
ip netns exec A ip addr add 192.168.101.2/24 dev VA
ip netns exec B ip addr add 192.168.102.2/24 dev VB
ip netns exec A ip link set VA up
ip netns exec B ip link set VB up
ip netns exec A ip route add default via 192.168.101.1
ip netns exec B ip route add default via 192.168.102.1
IP 전달을 활성화하려고 시도했지만 트래픽을 차단하는 IP 테이블 규칙이 없습니다. 루트 네임스페이스를 사용하지 않고 "transit"이라는 다른 네임스페이스를 사용하여 아래와 같이 연결해도 효과는 동일합니다.
+-------+ VA RA +-------+ RB VB +-------+
| A |--------|transit|---------| B |
+-------+ +-------+ +-------+
+-------------------------+
| |
| Root namespace |
| |
+-------------------------+
여기서는 네임스페이스 A와 B 사이를 성공적으로 ping했습니다.
루트 네임스페이스에서는 트래픽이 삭제되지만 세 번째 전송 네임스페이스를 사용할 때는 삭제되지 않는 이유는 무엇입니까?
docker에는 몇 가지 iptable 규칙이 설치되어 있지만 충돌이 발생하지 않습니다.
rahul@inception:~$ sudo iptables -L -n -v
Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
Chain FORWARD (policy DROP 2 packets, 168 bytes)
pkts bytes target prot opt in out source destination
2 168 DOCKER-USER all -- * * 0.0.0.0/0 0.0.0.0/0
2 168 DOCKER-ISOLATION-STAGE-1 all -- * * 0.0.0.0/0 0.0.0.0/0
0 0 ACCEPT all -- * docker0 0.0.0.0/0 0.0.0.0/0 ctstate RELATED,ESTABLISHED
0 0 DOCKER all -- * docker0 0.0.0.0/0 0.0.0.0/0
0 0 ACCEPT all -- docker0 !docker0 0.0.0.0/0 0.0.0.0/0
0 0 ACCEPT all -- docker0 docker0 0.0.0.0/0 0.0.0.0/0
Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
Chain DOCKER (1 references)
pkts bytes target prot opt in out source destination
Chain DOCKER-ISOLATION-STAGE-1 (1 references)
pkts bytes target prot opt in out source destination
0 0 DOCKER-ISOLATION-STAGE-2 all -- docker0 !docker0 0.0.0.0/0 0.0.0.0/0
2 168 RETURN all -- * * 0.0.0.0/0 0.0.0.0/0
Chain DOCKER-ISOLATION-STAGE-2 (1 references)
pkts bytes target prot opt in out source destination
0 0 DROP all -- * docker0 0.0.0.0/0 0.0.0.0/0
0 0 RETURN all -- * * 0.0.0.0/0 0.0.0.0/0
Chain DOCKER-USER (1 references)
pkts bytes target prot opt in out source destination
2 168 RETURN all -- * * 0.0.0.0/0 0.0.0.0/0
nft 목록 형식
rahul@inception:~$ sudo nft list ruleset
table ip nat {
chain DOCKER {
iifname "docker0" counter packets 0 bytes 0 return
}
chain POSTROUTING {
type nat hook postrouting priority srcnat; policy accept;
oifname != "docker0" ip saddr 172.17.0.0/16 counter packets 1 bytes 90 masquerade
}
chain PREROUTING {
type nat hook prerouting priority dstnat; policy accept;
fib daddr type local counter packets 148 bytes 11544 jump DOCKER
}
chain OUTPUT {
type nat hook output priority -100; policy accept;
ip daddr != 127.0.0.0/8 fib daddr type local counter packets 3 bytes 258 jump DOCKER
}
}
table ip filter {
chain DOCKER {
}
chain DOCKER-ISOLATION-STAGE-1 {
iifname "docker0" oifname != "docker0" counter packets 0 bytes 0 jump DOCKER-ISOLATION-STAGE-2
counter packets 2 bytes 168 return
}
chain DOCKER-ISOLATION-STAGE-2 {
oifname "docker0" counter packets 0 bytes 0 drop
counter packets 0 bytes 0 return
}
chain FORWARD {
type filter hook forward priority filter; policy drop;
counter packets 2 bytes 168 jump DOCKER-USER
counter packets 2 bytes 168 jump DOCKER-ISOLATION-STAGE-1
oifname "docker0" ct state related,established counter packets 0 bytes 0 accept
oifname "docker0" counter packets 0 bytes 0 jump DOCKER
iifname "docker0" oifname != "docker0" counter packets 0 bytes 0 accept
iifname "docker0" oifname "docker0" counter packets 0 bytes 0 accept
}
chain DOCKER-USER {
counter packets 2 bytes 168 return
}
}
IP 라우팅
rahul@inception:~$ ip route
default via 192.168.0.1 dev wlo1 proto dhcp metric 600
169.254.0.0/16 dev wlo1 scope link metric 1000
172.17.0.0/16 dev docker0 proto kernel scope link src 172.17.0.1 linkdown
192.168.0.0/24 dev wlo1 proto kernel scope link src 192.168.0.101 metric 600
192.168.101.0/24 dev RA proto kernel scope link src 192.168.101.1
192.168.102.0/24 dev RB proto kernel scope link src 192.168.102.1
TCPDUMP를 사용하여 패킷이 루트 네임스페이스에 도달하고 있음을 발견했습니다. 네임스페이스 내에서 패킷이 통과하는 위치를 확인하기 위해 배우고 사용할 수 있는 디버깅 도구(예: strace 또는 ftrace)가 있습니까?
답변1
도커가 변경되었습니다기본 전달 정책은 DROP입니다.:
Docker는 또한 FORWARD 체인의 정책을 DROP으로 설정합니다. Docker 호스트가 라우터 역할도 하는 경우 라우터가 더 이상 트래픽을 전달하지 않게 됩니다.
OP의 경우와 마찬가지로 :
Chain FORWARD (policy DROP 2 packets, 168 bytes)
문서에는 다음 사항도 나와 있습니다.
시스템이 계속해서 라우터 역할을 하도록 하려면
ACCEPT체인에 명시적인 규칙을 추가하여DOCKER-USER이를 허용할 수 있습니다.
해결책은 체인에서 이러한 트래픽을 활성화하는 것입니다 DOCKER-USER(최종 목표가 있으므로 추가하는 대신 체인에 삽입함으로써 RETURN).
따라서 더 많은 실험을 허용하지 않고 방해 없이 실험할 수 있는 최소한의 솔루션은 다음과 같습니다.
iptables -I DOCKER-USER 1 -i RA -o RB -j ACCEPT
iptables -I DOCKER-USER 2 -i RB -o RA -j ACCEPT