У меня есть новый тестовый случай дляhttps://github.com/xdp-project/bpf-examplesздесь https://github.com/tjcw/bpf-examples/tree/tjcw-integration-0.3/AF_XDP-filter . Он предназначен для фильтрации потоков; идея состоит в том, чтобы отправить первый пакет потока в пространство пользователя, чтобы пространство пользователя определило (просматривая пятиэлементный пакет), приемлем ли поток или нет, и соответственно установило запись в карте eBPF. Второй и последующие пакеты потока обрабатываются в ядре кодом eBPF. Тестовый случай работает, за исключением того, что первый пакет (который повторно вводится в ядро через интерфейс tun/tap) затем отбрасывается ядром как «марсианин». Эффект заключается в том, что если вы попробуете «ping» к этому коду, то увидите все пакеты, на которые был дан ответ, кроме первого, а если вы попробуете «ssh», то в начале будет небольшая пауза, пока протокол TCP на клиенте не выполнит тайм-аут и повторно отправит пакет SYN.
Я прилагаю вывод 'pwru' (cilium packet-where-are-you) при запуске
tjcw@tjcw-Standard-PC-Q35-ICH9-2009:~$ ping -c 2 192.168.122.48
PING 192.168.122.48 (192.168.122.48) 56(84) bytes of data.
64 bytes from 192.168.122.48: icmp_seq=2 ttl=64 time=2.28 ms
--- 192.168.122.48 ping statistics ---
2 packets transmitted, 1 received, 50% packet loss, time 1028ms
rtt min/avg/max/mdev = 2.282/2.282/2.282/0.000 ms
tjcw@tjcw-Standard-PC-Q35-ICH9-2009:~$
Кто-нибудь из читающих это знает, почему ядро считает пакет марсианским, и есть ли способ обойти это? Я использую Ubuntu 22.04 с uname -a, показывающим
tjcw@tjcw-Standard-PC-Q35-ICH9-2009:~$ uname -a
Linux tjcw-Standard-PC-Q35-ICH9-2009 5.15.0-53-generic #59-Ubuntu SMP
Mon Oct 17 18:53:30 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux
tjcw@tjcw-Standard-PC-Q35-ICH9-2009:~$
2022/11/25 11:37:02 Listening for events..
SKB CPU PROCESS FUNC
0xffff9478f5038300 1 [<empty>] pskb_expand_head
0xffff9478f5038300 1 [<empty>] skb_free_head
0xffff9478f5038300 1 [<empty>] bpf_prog_run_generic_xdp
0xffff9478f5038300 1 [<empty>] xdp_do_generic_redirect
0xffff9478f5038300 1 [<empty>] consume_skb
0xffff9478f5038300 1 [<empty>] skb_release_head_state
0xffff9478f5038300 1 [<empty>] skb_release_data
0xffff9478f5038300 1 [<empty>] skb_free_head
0xffff9478f5038300 1 [<empty>] kfree_skbmem
0xffff9478f5038300 1 [af_xdp_user] netif_receive_skb
0xffff9478f5038300 1 [af_xdp_user] skb_defer_rx_timestamp
0xffff9478f5038300 1 [af_xdp_user] __netif_receive_skb
0xffff9478f5038300 1 [af_xdp_user] __netif_receive_skb_one_core
0xffff9478f5038300 1 [af_xdp_user] ip_rcv
0xffff9478f5038300 1 [af_xdp_user] ip_rcv_core
0xffff9478f5038300 1 [af_xdp_user] sock_wfree
0xffff9478f5038300 1 [af_xdp_user] ip_route_input_noref
0xffff9478f5038300 1 [af_xdp_user] ip_route_input_rcu
0xffff9478f5038300 1 [af_xdp_user] ip_route_input_slow
0xffff9478f5038300 1 [af_xdp_user] fib_validate_source
0xffff9478f5038300 1 [af_xdp_user] __fib_validate_source
0xffff9478f5038300 1 [af_xdp_user] ip_handle_martian_source
0xffff9478f5038300 1 [af_xdp_user] kfree_skb_reason
0xffff9478f5038300 1 [af_xdp_user] skb_release_head_state
0xffff9478f5038300 1 [af_xdp_user] skb_release_data
0xffff9478f5038300 1 [af_xdp_user] skb_free_head
0xffff9478f5038300 1 [af_xdp_user] kfree_skbmem
0xffff9478c75d3000 1 [<empty>] pskb_expand_head
0xffff9478c75d3000 1 [<empty>] skb_free_head
0xffff9478c75d3000 1 [<empty>] bpf_prog_run_generic_xdp
0xffff9478c75d3000 1 [<empty>] ip_rcv
0xffff9478c75d3000 1 [<empty>] ip_rcv_core
0xffff9478c75d3000 1 [<empty>] skb_clone
0xffff9478c75d3000 1 [<empty>] consume_skb
0xffff9478f5038c00 1 [<empty>] ip_route_input_noref
0xffff9478f5038c00 1 [<empty>] ip_route_input_rcu
0xffff9478f5038c00 1 [<empty>] ip_route_input_slow
0xffff9478f5038c00 1 [<empty>] fib_validate_source
0xffff9478f5038c00 1 [<empty>] __fib_validate_source
0xffff9478f5038c00 1 [<empty>] ip_local_deliver
0xffff9478f5038c00 1 [<empty>] ip_local_deliver_finish
0xffff9478f5038c00 1 [<empty>] ip_protocol_deliver_rcu
0xffff9478f5038c00 1 [<empty>] raw_local_deliver
0xffff9478f5038c00 1 [<empty>] icmp_rcv
0xffff9478f5038c00 1 [<empty>] __skb_checksum_complete
0xffff9478f5038c00 1 [<empty>] icmp_echo
0xffff9478f5038c00 1 [<empty>] icmp_reply
0xffff9478f5038c00 1 [<empty>] __ip_options_echo
0xffff9478f5038c00 1 [<empty>] fib_compute_spec_dst
0xffff9478f5038c00 1 [<empty>] security_skb_classify_flow
0xffff9478f5038c00 1 [<empty>] consume_skb
0xffff9478f5038c00 1 [<empty>] skb_release_head_state
0xffff9478f5038c00 1 [<empty>] skb_release_data
0xffff9478f5038c00 1 [<empty>] kfree_skbmem
0xffff9478c75d3000 1 [<empty>] packet_rcv
0xffff9478c75d3000 1 [<empty>] consume_skb
0xffff9478c75d3000 1 [<empty>] skb_release_head_state
0xffff9478c75d3000 1 [<empty>] skb_release_data
0xffff9478c75d3000 1 [<empty>] skb_free_head
Первый (отброшенный) пакет — это участок от первого pskb_expand_head до kfree_skbmem, а второй (пропущенный) пакет — это участок от второго pskb_expand_head до конца.
решение1
Такое поведение обусловлено фильтрацией обратного пути, попыткой избежать обработки пакетов, которые приходят на «неправильный» интерфейс. Это можно отключить с помощью
for device in /proc/sys/net/ipv4/conf/*
do
echo 0 >${device}/rp_filter
done
в скрипте, который выполняется на сервере. После этого на все ping-пакеты отправляются ответы.