Spi*_*der -1 virtual ping tcpdump
我配置了一个虚拟接口(oip1),该接口具有有效的IP配置。当我尝试从oip1 ping Internet上的地址时,可以在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)
Run Code Online (Sandbox Code Playgroud)
我创建了一个新表“ 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
Run Code Online (Sandbox Code Playgroud)
因此,我正在标记往返于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
Run Code Online (Sandbox Code Playgroud)
然后,我为表“ lte”添加了默认网关:
root@openair-PC:~/openair4G# ip route show table lte
default dev oip1 scope link
Run Code Online (Sandbox Code Playgroud)
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
Run Code Online (Sandbox Code Playgroud)
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
Run Code Online (Sandbox Code Playgroud)
如您所见,tcpdump可以看到所有数据包。
有人对此有想法吗?最好的祝福,
我终于解决了这个问题。这是由于在相关接口以及所有系统上激活了rp_filter引起的。我使用以下命令禁用了它:sysctl -w net.ipv4.conf.all.rp_filter = 0(也将所有内容替换为该接口)。
这可能是由内核执行的反向路径过滤引起的。如果您在下一跳中执行诸如proxy-arp之类的操作,则可能会发生这种情况。系统认为接收到的数据包是伪造的(如果启用了反向路径过滤),则将其丢弃。
显而易见(但不建议使用)的方法是禁用反向路径过滤。另一种方法是通过预期的接口在主机中为ping IP设置默认网关。