服务器ping不通，无法远程连接

最新推荐文章于 2024-08-13 13:56:37 发布

weixin_42715413

最新推荐文章于 2024-08-13 13:56:37 发布

阅读量8.7k

点赞数

文章标签： linux arp ping

现象：

[root@lialian-6 ~]# ping -I 172.17.1.6 -c 10 172.17.1.48
PING 172.17.1.48 (172.17.1.48) from 172.17.1.6 : 56(84) bytes of data.

--- 172.17.1.48 ping statistics ---
10 packets transmitted, 0 received, 100% packet loss, time 19000ms

分析：

抓包

[root@gitlab ~]# tcpdump -vv -i eth0 dst host 172.17.1.6
tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
09:50:58.390250 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 172.17.1.6 tell gitlab.lilian.com, length 28
09:50:59.390342 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 172.17.1.6 tell gitlab.lilian.com, length 28
09:51:00.390283 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 172.17.1.6 tell gitlab.lilian.com, length 28
09:51:02.390206 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 172.17.1.6 tell gitlab.lilian.com, length 28
09:51:03.390285 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 172.17.1.6 tell gitlab.lilian.com, length 28
09:51:04.390276 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 172.17.1.6 tell gitlab.lilian.com, length 28
09:51:06.390214 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 172.17.1.6 tell gitlab.lilian.com, length 28
09:51:07.390277 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 172.17.1.6 tell gitlab.lilian.com, length 28
09:51:08.390329 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 172.17.1.6 tell gitlab.lilian.com, length 28
10:13:00.457215 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 172.17.1.6 tell gitlab.lilian.com, length 28

接到icmp request，但是不发送icmp reply

[root@gitlab ~]# arp -n
Address                  HWtype  HWaddress           Flags Mask            Iface
172.17.1.106             ether   18:31:bf:09:1a:e5   C                     eth0
172.17.1.6                       (incomplete)                              eth0

问题所咋arp广播时没有返回网卡mac地址（如果防火墙做了相关ping禁止不影响arp响应）

解决：

如果将网卡配置文件中mac地址注释掉，然后删除70-persistent-net.rules文件重启呢？答案是不行

在网上看到是反向路由检查的问题

Linux内核有反向路由检查的机制。当Linux IP协议栈收到一个IP包时，会找路由。
本机的包会往上层协议送，而非本机的包会根据路由转发。

为了防止非法的包被转发或送给上层协议，查找路由后Linux还会调用fib_validate_source()以
检查其来源的合法性，基本原理是根据包的源地址查找路由的出接口，然后比较包的原始入接口是
否和查到的出接口一致;如果一致则放过，如果不一致查询skb->dev的rp_filter值，为1时将丢弃这
个包，0时放过。

{ 实例
本网络有三台机器，R1, R2 和PC，子网掩码都是255.255.0.0。
R2 (10.1.0.2) ---- (10.1.0.1) R1 (10.3.0.1) ---- (10.3.0.2) PC
R2 (10.2.0.2) ---- (10.2.0.1) R1

注意，设置R2的默认路由为10.1.0.1
现在，从PC上能够ping通10.1.0.2，但是ping不通10.2.0.2。
tcpdump显示，R2接到icmp request，但是不发送icmp reply。

PC
$ ip a
inet 10.3.0.2/16 brd 10.3.255.255 scope global eth0
$ ip r
10.3.0.0/16 dev eth0 proto kernel scope link src 10.3.0.2
default via 10.3.0.1 dev eth0

R1
$ ip a
inet 10.1.0.1/16 brd 10.1.255.255 scope global eth1
inet 10.2.0.1/16 brd 10.2.255.255 scope global eth2
inet 10.3.0.1/16 brd 10.3.255.255 scope global eth3
$ ip r
10.1.0.0/16 dev eth1 proto kernel scope link src 10.1.0.1
10.2.0.0/16 dev eth2 proto kernel scope link src 10.2.0.1
10.3.0.0/16 dev eth3 proto kernel scope link src 10.3.0.1

R2
$ ip a
inet 10.1.0.2/16 brd 10.1.255.255 scope global eth1
inet 10.2.0.2/16 brd 10.2.255.255 scope global eth2

$ ip r
10.1.0.0/16 dev eth1 proto kernel scope link src 10.1.0.2
10.2.0.0/16 dev eth2 proto kernel scope link src 10.2.0.2
default via 10.1.0.1 dev eth1

假设R2的两个接口分别为A(10.1.0.2)、B(10.2.0.2)。
从PC ping 10.2.0.2时，包的路径是PC-->10.3.0.1-->10.2.0.2，
此时包的 ,
以进行反向路径检查, 得到输出设备是A，
因为目的地址是10.3.0.2，只能使用默认路由。A!=B，反向路径检查失败，
丢弃该包！}

每个接口的rp_filter配置在

echo 0 > /proc/sys/net/ipv4/conf/all/rp_filter

echo 0 > /proc/sys/net/ipv4/conf/ethN/rp_filter

其值为1时是使能该接口反向路由检查机制，为0时则关闭该机制，或者
vim /etc/sysctl.conf
net.ipv4.conf.default.rp_filter = 0
禁用反向路径检查。

在实际运用时该机制可能会带来问题。对于一些虚接口上来的包，如gre0,ipsec0来的包，如果没有
IP地址，从该虚接口上来的包可能被认为来源不合法而被内核DROP。
这时需要根据实际情况设置rp_filter为0，并配置IP地址。

以上分析是根据2.6.32内核代码而来。
更高版本的kernel可能已经解决这个问题，如3.6.3内核，对该机制有改进，对IPSEC的接口不做反射路
由检查。