关于Linux 下的错误路由产生火星包的问题

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

大家好,我是讯享网,很高兴认识大家。

关于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–MGW>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. ARP, Request who-has 192.168.1.200 tell 192.168.1.217, length 46
03:34:39. IP 192.168.1.217 > 192.168.1.200: ICMP echo request, id 1, seq 11, length 40
03:34:40. IP 192.168.1.217 > 192.168.1.200: ICMP echo request, id 1, seq 12, length 40
03:34:41. IP 192.168.1.217 > 192.168.1.200: ICMP echo request, id 1, seq 13, length 40
03:34:42. 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. ARP, Request who-has 192.168.1.200 tell 192.168.1.217, length 46
03:48:42. ARP, Request who-has 192.168.1.200 tell 192.168.1.217, length 46
03:48:43. ARP, Request who-has 192.168.1.200 tell 192.168.1.217, length 46
03:48:44. ARP, Request who-has 192.168.1.200 tell 192.168.1.217, length 46
03:48:45. ARP, Request who-has 192.168.1.200 tell 192.168.1.217, length 46
03:48:46. ARP, Request who-has 192.168.1.200 tell 192.168.1.217, length 46
03:48:47. ARP, Request who-has 192.168.1.200 tell 192.168.1.217, length 46
03:48:48. ARP, Request who-has 192.168.1.200 tell 192.168.1.217, length 46
03:48:49. ARP, Request who-has 192.168.1.200 tell 192.168.1.217, length 46
03:48:50. ARP, Request who-has 192.168.1.200 tell 192.168.1.217, length 46
03:48:51. ARP, Request who-has 192.168.1.200 tell 192.168.1.217, length 46

物理机ping不通虚拟机

C:\Users\Administrator.PC--MGW>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是二层的协议的帧不归路由信息管。

小讯
上一篇 2025-03-10 22:01
下一篇 2025-01-11 12:48

相关推荐

版权声明:本文内容由互联网用户自发贡献,该文观点仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容,请联系我们,一经查实,本站将立刻删除。
如需转载请保留出处:https://51itzy.com/kjqy/18345.html