Ответы ICMP, видимые tcpdump, но ping 100% не удалось

Question

У меня есть настроенный виртуальный интерфейс (oip1), который имеет действительную конфигурацию IP. Когда я пытаюсь выполнить ping-адрес в Интернете из oip1, я могу видеть ответы/ответы ICMP-echo на tcpdump, но 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) 

Я создал новую таблицу "Г":

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 

ТСРйитр экран:

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 

Как вы можете видеть, все пакеты можно увидеть ТСРйитр.

У кого-нибудь есть идея? С уважением,

Answer 1

Я, наконец, решил это. Это было вызвано активизацией rp_filter на соответствующем интерфейсе и всей системе. Я отключил его с помощью: sysctl -w net.ipv4.conf.all.rp_filter = 0 (также замените все на интерфейс).

Answer 2

Это могло быть вызвано фильтрацией обратного пути, выполняемой ядром. Это может произойти, если вы делаете такие вещи, как proxy-arp, в следующем прыжке. Система считает, что принятый пакет является поддельным (если включена фильтрация по обратному пути) и его удаляет.

Очевидным (но не предлагаемым) способом является отключение фильтрации обратного пути. Другой способ - установить шлюз по умолчанию в хост для pinged IP через предполагаемый интерфейс.