关于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

第四条路由表示192.168.1.0/24 网段的包需要从enp0s8 网卡的 192.168.1.200 这个接口出去，那么根据路由的双向性：192.168.1.0/24网段的包也只能从上面的接口进来。那么如果192.168.1.0网段的包从别的网络接口进来会被linux 内核直接抛弃，tcpdump抓不到任何信息。

错误重现

物理机ip 192.168.1.217
虚拟机ip 192.168.1.200 （桥接模式和主机同一网段）,桥接网卡enp0s8
虚拟机路由表

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 时间=1ms TTL=64
来自 192.168.1.200 的回复: 字节=32 时间<1ms TTL=64
来自 192.168.1.200 的回复: 字节=32 时间<1ms TTL=64
来自 192.168.1.200 的回复: 字节=32 时间<1ms TTL=64`

在 虚拟机的enp0s8 端口抓包可以看到从物理机过来的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: <LOOPBACK,UP,LOWER_UP> 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: <BROADCAST,MULTICAST,UP,LOWER_UP> 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: <BROADCAST,MULTICAST,UP,LOWER_UP> 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: <BROADCAST,MULTICAST,UP,LOWER_UP> 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.122接口进来，因为路由表示从上往下匹配的。
此时从物理机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% 丢失)

打开ipv4的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
可以看到有从物理机过来的包发到了enp0s8的192.168.1.217这个网络接口，但tcpdump抓不到，原因是被内核丢掉了。至于可以抓到arp包的原因是arp是二层的协议的帧不归路由信息管。