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

ICMP replies seen by tcpdump but ping 100% fails

我配置了一个具有有效 IP 配置的虚拟接口 (oip1)。当我尝试从 oip1 ping 互联网上的地址时,我可以在 tcpdump 上看到 ICMP echo requests/replies,但 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)

我创建了一个新的 table "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

因此,我正在标记数据包 to/from 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

然后,我为 table 添加了默认网关 "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 屏幕:

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看到。

有人对此有想法吗? 最好的问候,

我终于解决了这个问题。这是由相关界面和所有系统上激活的 rp_filter 引起的。我禁用它:sysctl -w net.ipv4.conf.all.rp_filter=0(也用接口替换所有)。

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

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