Linuxでの誤ったルーティングによる火星パケットの発生に関する問題

linuxでの誤ったルーティングによる火星パケットの問題について
誤った原理.
linuxの下のrouteテーブルは、パケットの転送経路の選択だけでなく、パケットのソースの合理性を検証する責任を負います.例えば、# ip r default via 10.0.2.2 dev enp0s3 proto static metric 100
default via 192.168.1.1 dev enp0s8 proto static metric 101
10.0.2.0/24 dev enp0s3 proto kernel scope link src 10.0.2.15 metric 100
192.168.1.0/24 dev enp0s8 proto kernel scope link src 192.168.1.200 metric 100第4のルーティングは192.168.1.0/24セグメントを表すパケットがenp 0 s 8ネットワークカードの192.168.1.200というインタフェースから出る必要がある場合、ルーティングの双方向性によって:192.168.1.0/24セグメントのパケットも上のインタフェースから入るしかない.では、192.168.1.0セグメントのパケットが他のネットワークインタフェースから入ってくるとlinuxカーネルに直接捨てられ、tcpdumpには情報がつかめません.
エラーの再現
物理マシンip 192.168.1.1217仮想マシンip 192.168.1.200(ブリッジモードとホストの同じセグメント)、ブリッジNIC enp 0 s 8仮想マシンルーティングテーブル
default via 10.0.2.2 dev enp0s3 proto static metric 100 default via 192.168.1.1 dev enp0s8 proto static metric 101 10.0.2.0/24 dev enp0s3 proto kernel scope link src 10.0.2.15 metric 100 192.168.1.0/24 dev enp0s8 proto kernel scope link src 192.168.1.200 metric 100
この場合、物理マシンは仮想マシンにpingできます.
` C:\Users\Administrator.PC–20130915MGW>ping 192.168.1.200
Ping 192.168.1.200で32バイトのデータを持つ:192.168.1.200からの返信:バイト=32時間=1 ms TTL=64 192.168.1.200からの返信:バイト=32時間<1 ms TTL=64 192.168.1.200からの返信:バイト=32時間<1 ms TTL=64 192.168.1.200からの返信:ワード=32時間<1 ms TTL=64
仮想マシンのenp 0 s 8ポートでパケットをつかむと、物理マシンからのICMPメッセージtcpdump -i enp0s8 src host 192.168.1.200 03:34:39.649050 ARP, Request who-has 192.168.1.200 tell 192.168.1.217, length 46
03:34:39.650075 IP 192.168.1.217 > 192.168.1.200: ICMP echo request, id 1, seq 11, length 40
03:34:40.653015 IP 192.168.1.217 > 192.168.1.200: ICMP echo request, id 1, seq 12, length 40
03:34:41.661146 IP 192.168.1.217 > 192.168.1.200: ICMP echo request, id 1, seq 13, length 40
03:34:42.669583 IP 192.168.1.217 > 192.168.1.200: ICMP echo request, id 1, seq 14, length 40が表示されます.
現在、仮想マシンに新しいブリッジ
[root@localhost ~]# brctl addbr newbr
[root@localhost ~]# ip addr add dev newbr 192.168.1.122/24
[root@localhost ~]# ip link set dev newbr up
[root@localhost ~]# ip a
1: lo: mtu 65536 qdisc noqueue state UNKNOWN
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: enp0s3: mtu 1500 qdisc pfifo_fast state UP qlen 1000
link/ether 08:00:27:de:0e:0e brd ff:ff:ff:ff:ff:ff
inet 10.0.2.15/24 brd 10.0.2.255 scope global dynamic enp0s3
valid_lft 84942sec preferred_lft 84942sec
inet6 fe80::a00:27ff:fede:e0e/64 scope link
valid_lft forever preferred_lft forever
3: enp0s8: mtu 1500 qdisc pfifo_fast state UP qlen 1000
link/ether 08:00:27:d9:8b:cf brd ff:ff:ff:ff:ff:ff
inet 192.168.1.200/24 brd 192.168.1.255 scope global dynamic enp0s8
valid_lft 84954sec preferred_lft 84954sec
inet6 fe80::a00:27ff:fed9:8bcf/64 scope link
valid_lft forever preferred_lft forever
5: newbr: mtu 1500 qdisc noqueue state UNKNOWN
link/ether c2:40:fe:38:8b:83 brd ff:ff:ff:ff:ff:ff
inet 192.168.1.122/24 scope global newbr
valid_lft forever preferred_lft forever
inet6 fe80::c040:feff:fe38:8b83/64 scope link
valid_lft forever preferred_lft forever
linuxが追加されると、新しいルーティング情報[root@localhost ~]# ip r
default via 10.0.2.2 dev enp0s3 proto static metric 100
default via 192.168.1.1 dev enp0s8 proto static metric 101
10.0.2.0/24 dev enp0s3 proto kernel scope link src 10.0.2.15 metric 100
192.168.1.0/24 dev newbr proto kernel scope link src 192.168.1.122
192.168.1.0/24 dev enp0s8 proto kernel scope link src 192.168.1.200 metric 100
が自動的に追加されます.このとき、ルーティングパケット情報は192.168.1.0/24セグメントを表すパケットがnewbrの192.168.1.212インタフェースから入ります.ルーティングは上から下へ一致するためです.このとき、物理マシンping仮想マシンのtcpdump情報から、ICMPメッセージが捉えられず、arpメッセージ[root@localhost ~]# tcpdump -i enp0s8 src host 192.168.1.217
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on enp0s8, link-type EN10MB (Ethernet), capture size 65535 bytes
03:48:41.059625 ARP, Request who-has 192.168.1.200 tell 192.168.1.217, length 46
03:48:41.834576 ARP, Request who-has 192.168.1.200 tell 192.168.1.217, length 46
03:48:42.834913 ARP, Request who-has 192.168.1.200 tell 192.168.1.217, length 46
03:48:43.843778 ARP, Request who-has 192.168.1.200 tell 192.168.1.217, length 46
03:48:44.835582 ARP, Request who-has 192.168.1.200 tell 192.168.1.217, length 46
03:48:45.836889 ARP, Request who-has 192.168.1.200 tell 192.168.1.217, length 46
03:48:46.843927 ARP, Request who-has 192.168.1.200 tell 192.168.1.217, length 46
03:48:47.837329 ARP, Request who-has 192.168.1.200 tell 192.168.1.217, length 46
03:48:48.838204 ARP, Request who-has 192.168.1.200 tell 192.168.1.217, length 46
03:48:49.845249 ARP, Request who-has 192.168.1.200 tell 192.168.1.217, length 46
03:48:50.839235 ARP, Request who-has 192.168.1.200 tell 192.168.1.217, length 46
03:48:51.838971 ARP, Request who-has 192.168.1.200 tell 192.168.1.217, length 46
のみ物理マシンping不通仮想マシン
C:\Users\Administrator.PC--20130915MGW>ping 192.168.1.200
Ping 192.168.1.200 32 :
192.168.1.217 : 。
192.168.1.217 : 。
192.168.1.217 : 。
192.168.1.217 : 。
192.168.1.200 Ping :
: = 4， = 4， = 0 (0% )ipv 4のlog echo 1 >> /proc/sys/net/ipv4/conf/all/log_martiansを開いてdmesg情報[ 2348.008659] IPv4: martian source 192.168.1.200 from 192.168.1.217, on dev enp0s8を見ると、物理機からのパケットがenp 0 s 8の192.168.1.1217というネットワークインタフェースに送られているのが見えますが、tcpdumpがつかめません.カーネルが失われたためです.arpパケットをキャプチャできるのは、arpが2層のプロトコルであるフレームがルーティング情報管に帰属しないためである.