☰

如何讓核心不將透過 tun/tap 注入的資料包視為“火星人”

tag-icon • tag-icon ubuntu linux-networking linux-kernel
如何讓核心不將透過 tun/tap 注入的資料包視為“火星人”

我有一個新的測試案例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 封包都會得到回應。

相關內容