tcpdump看到的ICMP回复但ping 100%失败

时间:2015-08-19 16:01:33

标签: virtual ping tcpdump

我配置了一个具有有效IP配置的虚拟接口(oip1)。当我尝试从oip1 ping互联网上的地址时,我可以在tcpdump上看到ICMP回应请求/回复,但ping仍然报告100%失败。

root@openair-PC:~/openair4G# ifconfig oip1
      oip1      Link encap:AMPR NET/ROM  HWaddr   
      inet addr:192.188.0.2  Bcast:192.188.0.255  Mask:255.255.255.0
      UP BROADCAST RUNNING NOARP MULTICAST  MTU:1500  Metric:1
      RX packets:10 errors:0 dropped:0 overruns:0 frame:0
      TX packets:10 errors:0 dropped:0 overruns:0 carrier:0
      collisions:0 txqueuelen:100 
      RX bytes:840 (840.0 B)  TX bytes:840 (840.0 B)

我创建了一个新表“lte”:

root@openair-PC:~/openair4G# ip rule show
0:  from all lookup local 
32743:  from all fwmark 0x1 lookup lte 
32766:  from all lookup main 
32767:  from all lookup default

因此,我正在向/从oip1地址标记数据包:

root@openair-PC:~/openair4G# iptables -t mangle -L
Chain PREROUTING (policy ACCEPT)
target     prot opt source               destination         
MARK       all  --  anywhere             192.188.0.0/24       MARK set 0x1

Chain INPUT (policy ACCEPT)
target     prot opt source               destination         

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination         

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination         
MARK       all  --  192.188.0.0/24       anywhere             MARK set 0x1

Chain POSTROUTING (policy ACCEPT)
target     prot opt source               destination

然后,我为表“lte”添加了一个默认网关:

root@openair-PC:~/openair4G# ip route show table lte
default dev oip1  scope link

ping结果:

openair@openair-PC:~/openair4G/cmake_targets$ ping -c 5 -I oip1 8.8.8.8
PING 8.8.8.8 (8.8.8.8) from 192.188.0.2 oip1: 56(84) bytes of data.
^C
--- 8.8.8.8 ping statistics ---
5 packets transmitted, 0 received, 100% packet loss, time 3999ms

tcpdump screen:

openair@openair-PC:~/openair4G$ sudo tcpdump -p -i oip1
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on oip1, link-type LINUX_SLL (Linux cooked), capture size 65535 bytes
17:19:10.576680 IP 192.188.0.2 > google-public-dns-a.google.com: ICMP echo request, id 20987, seq 1, length 64
17:19:11.021851 IP google-public-dns-a.google.com > 192.188.0.2: ICMP echo reply, id 20987, seq 1, length 64
17:19:11.576617 IP 192.188.0.2 > google-public-dns-a.google.com: ICMP echo request, id 20987, seq 2, length 64
17:19:11.752243 IP google-public-dns-a.google.com > 192.188.0.2: ICMP echo reply, id 20987, seq 2, length 64
17:19:12.576583 IP 192.188.0.2 > google-public-dns-a.google.com: ICMP echo request, id 20987, seq 3, length 64
17:19:12.676980 IP google-public-dns-a.google.com > 192.188.0.2: ICMP echo reply, id 20987, seq 3, length 64
17:19:13.576559 IP 192.188.0.2 > google-public-dns-a.google.com: ICMP echo request, id 20987, seq 4, length 64
17:19:13.767922 IP google-public-dns-a.google.com > 192.188.0.2: ICMP echo reply, id 20987, seq 4, length 64
17:19:14.576561 IP 192.188.0.2 > google-public-dns-a.google.com: ICMP echo request, id 20987, seq 5, length 64
17:19:15.097164 IP google-public-dns-a.google.com > 192.188.0.2: ICMP echo reply, id 20987, seq 5, length 64
^C
10 packets captured
10 packets received by filter
0 packets dropped by kernel

如您所见,tcpdump可以看到所有数据包。

有没有人对此有所了解? 最好的问候,

2 个答案:

答案 0 :(得分:5)

这可能是由内核完成的反向路径过滤引起的。如果您在下一跳中执行proxy-arp之类的操作,则可能会发生这种情况。系统认为收到的数据包是欺骗性的(如果启用了反向路径过滤)并丢弃它。

明显(但不建议)的方法是禁用反向路径过滤。另一种方法是通过预期的接口在主机中为ping的IP设置默认网关。

答案 1 :(得分:4)

我终于解决了这个问题。这是由相关接口和所有系统上激活的rp_filter引起的。我使用以下命令禁用它:sysctl -w net.ipv4.conf.all.rp_filter = 0(同样用接口替换所有内容)。