ルートネームスペースを介して接続された2つのネットワークネームスペース間の通信に、図に示されている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しました。
ルートネームスペースではトラフィックが破棄されますが、3番目のトランスポートネームスペースを使用しても削除されないのはなぜですか？
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