A flow acquisition method and apparatus

Abstract

The application provides a flow collection method and device. In the method, a first eBPF program collects first flow, after mirroring the first flow, the first flow is redirected to a third eBPF program, a second eBPF program collects second flow, after mirroring the second flow, the second flow is redirected to the third eBPF program, the third eBPF program encapsulates the first flow and the second flow, and then sends them to the traffic control TC out direction of a physical out interface, and then sends them to a target storage device through the physical out interface. The application collects the out direction flow and all the in direction flow of the kernel of a virtual machine, instead of only collecting the in direction flow, so that the flow of the virtual machine is comprehensively acquired, and comprehensive information is provided for the analysis of the flow of the virtual machine.

Description

Technical Field

[0001] This application relates to the field of network technology, and in particular to a traffic collection method and apparatus, which can be deployed on physical machines and virtual machines. Background Technology

[0002] With the rapid development of information technology and the increasing popularity of network applications, network traffic monitoring has become an important means of network management, security protection, and performance optimization.

[0003] Existing traffic acquisition solutions mainly fall into two categories: The first is based on physical port mirroring, a traditional traffic acquisition technique that relies heavily on physical network devices such as switch port mirroring or dedicated network splitters. However, in virtualized environments, a large amount of network traffic flows entirely at the virtual layer, sometimes without even touching physical network devices. This change makes it difficult for traditional acquisition methods to comprehensively capture network communication, especially traffic between virtual machines. The second is a distributed acquisition solution based on front-end computation, which primarily involves deploying a lightweight acquisition agent near the data source (such as a virtual machine or host machine). The agent is responsible for local traffic and result data reporting. While this solution solves the traffic visibility problem in cloud environments, it introduces additional resource overhead, potentially impacting business performance, and faces challenges related to the complexity of agent deployment, maintenance, and versioning conventions.

[0004] Therefore, new methods are needed to ensure comprehensive monitoring of both virtual and physical network traffic. Furthermore, traffic monitoring itself may impact network performance, and how to conduct efficient traffic monitoring without affecting normal business operations is a technical challenge. Summary of the Invention

[0005] This application provides a traffic collection method and apparatus that can directly forward traffic in the kernel without copying it to user space for encapsulation and forwarding. This greatly improves collection performance, significantly reduces CPU consumption caused by copying the original traffic, and minimizes the impact on the original business.

[0006] Firstly, a traffic collection method is provided, the method including:

[0007] The eBPF user space obtains configuration information, converts the configuration information into an eBPF mapping table, and then sends the eBPF mapping table to the eBPF kernel space. The eBPF mapping table includes the interface to be collected, the physical forwarding interface, and the relay interface.

[0008] According to the eBPF mapping table, in the eBPF kernel mode, the first eBPF program is attached to the first tracking point, the second eBPF program is attached to the second tracking point, and the third eBPF program is attached to the third tracking point. The first tracking point is the inbound direction of the flow control TC of the interface to be collected, the second tracking point is the outbound direction of the flow control TC of the interface to be collected, and the third tracking point is the outbound direction of the flow control TC of the relay interface.

[0009] The first eBPF program collects the first traffic, mirrors it, and then redirects it to the third eBPF program. The second eBPF program collects the second traffic, mirrors it, and then redirects it to the third eBPF program. The first traffic is a data packet sent from an external device to the physical interface, and the second traffic is a data packet that has already passed through the kernel protocol stack and routing decisions and is about to be sent to the external device.

[0010] The third eBFP program receives the first and second traffic flows, encapsulates them, and sends them to the outgoing direction of the flow control TC of the physical forwarding interface, which then sends them to the target storage device through the physical forwarding interface.

[0011] This method attaches the kernel-mode eBPF to a suitable TC tracking point, redirecting the mirrored traffic to the corresponding eBPF program, thus completing customized collection of outbound and inbound traffic, not just inbound traffic. After kernel collection, the traffic is directly cloned in the kernel and then encapsulated and forwarded. The original traffic continues its original process, and the cloned and encapsulated packets are forwarded without copying to user space, greatly improving forwarding performance without affecting existing network services. Full virtual machine traffic is stored, and the stored virtual machine traffic can be quickly extracted and output as a pcap file for secondary analysis by third parties. In this embodiment, all outbound and inbound traffic of the virtual machine is collected in the kernel, not just inbound traffic. Comprehensive acquisition of virtual machine traffic provides comprehensive information for virtual machine traffic analysis. Direct kernel forwarding, without copying to user space for encapsulation and forwarding, greatly improves collection performance and significantly reduces the CPU consumption increased by copying the original traffic, minimizing the impact on original services. It can obtain preliminary analysis and statistical information of virtual machine traffic, as well as historical virtual machine traffic for secondary analysis.

[0012] In one possible implementation, the interface to be collected includes a physical interface and a virtual interface, wherein the physical forwarding interface is the physical interface that forwards the collected traffic to the target storage device; it also includes:

[0013] eBPF user space instructs eBPF kernel space to create a new relay interface, which is a virtual interface.

[0014] In one possible implementation, the second eBPF program collects the second traffic, mirrors the second traffic, and then redirects the second traffic to the third eBPF program, specifically including:

[0015] The second eBPF program collected the second traffic flow;

[0016] Determine whether the interface to be collected and the physical forwarding interface are the same;

[0017] If they are different, the second traffic that meets the preset conditions will be copied and redirected to the third eBPF program;

[0018] If they are the same, determine whether the second traffic is a self-encapsulated traffic;

[0019] If not, the second traffic that meets the preset conditions will be copied and redirected to the third eBPF program.

[0020] In one possible implementation, traffic is sent to the target storage device via a physical traffic forwarding interface, specifically including:

[0021] Determine whether the physical forwarding interface and the interface to be collected are the same;

[0022] If so, the encapsulated traffic is forwarded out using the TC outgoing direction processing flow of the interface to be collected;

[0023] Otherwise, the encapsulated traffic is forwarded out using the physical forwarding interface.

[0024] In one possible implementation, the configuration information also includes an EIP mapping table, which includes the IP to be converted and the converted IP.

[0025] The first eBPF program mirrors the first traffic, specifically including:

[0026] The first eBPF program converts the IP to be converted for the first traffic after mirroring into a converted IP based on the EIP mapping table;

[0027] The second eBPF program mirrors the second traffic, specifically including:

[0028] The second eBPF program, based on the EIP mapping table, converts the IP to be converted in the mirrored second traffic to the converted IP.

[0029] In one possible implementation, the configuration information also includes encapsulation methods, such as GRE tunnel encapsulation and Vxlan tunnel encapsulation.

[0030] Encapsulating the first traffic and the second traffic specifically includes:

[0031] The third eBFP program encapsulates the first and second traffic flows using an encapsulation method.

[0032] One possible implementation also includes: the target storage device decapsulating the encapsulated traffic.

[0033] Secondly, a flow acquisition device is provided, the device comprising:

[0034] The first module is used to instruct the eBPF user space to obtain configuration information, convert the configuration information into an eBPF mapping table, and send the eBPF mapping table to the eBPF kernel space. The eBPF mapping table includes the interface to be collected, the physical forwarding interface, and the relay interface.

[0035] The second module is used to instruct, according to the eBPF mapping table, to attach the first eBPF program to the first tracking point, the second eBPF program to the second tracking point, and the third eBPF program to the third tracking point in the eBPF kernel mode. The first tracking point is the inbound direction of the flow control TC of the interface to be collected, the second tracking point is the outbound direction of the flow control TC of the interface to be collected, and the third tracking point is the outbound direction of the flow control TC of the relay interface.

[0036] The third module is used to instruct the first eBPF program to collect the first traffic, mirror the first traffic, and redirect the first traffic to the third eBPF program. The second eBPF program collects the second traffic, mirrors the second traffic, and redirects the second traffic to the third eBPF program. The first traffic is a data packet sent from an external device to the physical interface, and the second traffic is a data packet that has passed through the kernel protocol stack and routing decisions and is about to be sent to an external device.

[0037] The fourth module is used to instruct the third eBFP program to receive the first and second traffic, encapsulate the first and second traffic, and send them to the outgoing direction of the traffic control TC of the physical forwarding interface, and then send them to the target storage device through the traffic physical forwarding interface.

[0038] In one possible implementation, the interface to be collected includes a physical interface and a virtual interface. The physical forwarding interface is the physical interface that forwards the collected traffic to the target storage device.

[0039] The first module is used by the eBPF user space to instruct the eBPF kernel space to create a new relay interface based on the configuration information. The relay interface is a virtual interface.

[0040] In one possible implementation, a third module is used for the second eBPF program to collect the second traffic.

[0041] Determine whether the interface to be collected and the physical forwarding interface are the same.

[0042] If they are different, the second traffic that meets the preset conditions will be copied and redirected to the third eBPF program.

[0043] If they are the same, determine whether the second traffic is a self-encapsulated traffic.

[0044] If not, the second traffic that meets the preset conditions will be copied and redirected to the third eBPF program.

[0045] In one possible implementation, the third module is used to determine whether the physical forwarding interface and the interface to be collected are the same;

[0046] If so, the encapsulated traffic is forwarded out using the TC outgoing direction processing flow of the interface to be collected;

[0047] Otherwise, the encapsulated traffic is forwarded out using the physical forwarding interface.

[0048] In one possible implementation, the configuration information also includes an EIP mapping table, which includes the IP to be converted and the converted IP.

[0049] The third module is used by the first eBPF program to convert the IP to be converted of the first traffic after mirroring to the converted IP according to the EIP mapping table;

[0050] The second eBPF program converts the IP to be converted in the mirrored second traffic to the converted IP according to the EIP mapping table.

[0051] In one possible implementation, the configuration information also includes encapsulation methods, including GRE tunnel encapsulation and Vxlan tunnel encapsulation;

[0052] The fourth module is used by the third eBFP program to encapsulate the first and second traffic through an encapsulation method.

[0053] Thirdly, a computing device cluster is provided, including at least one computing device, each computing device including a processor and a memory; the processor of the at least one computing device is used to execute instructions stored in the memory of the at least one computing device, so that the computing device cluster performs the method provided in the second aspect.

[0054] Fourthly, a computer-readable storage medium is provided, including computer program instructions that, when executed by a cluster of computing devices, cause the cluster of computing devices to perform the method provided in the second aspect.

[0055] Fifthly, a computer program product containing instructions is provided, which, when executed by a cluster of computer devices, causes the cluster of computer devices to perform the method provided in the sixth aspect.

[0056] The beneficial effects of the second to fifth aspects can be referred to the introduction of the beneficial effects of the first aspect above, and will not be repeated here. Attached Figure Description

[0057] Figure 1 A schematic diagram of a flow rate acquisition device is shown;

[0058] Figure 2 A flowchart illustrating a traffic acquisition method is shown.

[0059] Figure 3 A flowchart illustrating a traffic acquisition method is shown.

[0060] Figure 4 A flowchart illustrating a traffic acquisition method is shown.

[0061] Figure 5 A flowchart illustrating a traffic acquisition method is shown.

[0062] Figure 6 A schematic diagram of a traffic acquisition method is shown.

[0063] Figure 7 A schematic diagram of a flow rate acquisition device is shown. Detailed Implementation

[0064] The solutions provided in the embodiments of this application will now be described with reference to the accompanying drawings. In the embodiments of this application, "multiple" refers to two or more objects, and "various types" refers to two or more types. Terms such as "first," "second," etc., are only used to distinguish similar objects and are not necessarily used to describe a specific order or number of objects.

[0065] In the embodiments of this application, the words "exemplary" or "for example" are used to indicate examples, illustrations, or descriptions. Any embodiment or design that is described as "exemplary" or "for example" in the embodiments of this application should not be construed as being more preferred or advantageous than other embodiments or design options. Specifically, the use of the words "exemplary" or "for example" is intended to present the relevant concepts in a specific manner.

[0066] In modern virtualized / cloud-based data centers, network traffic is primarily east-west oriented. The traditional north-south approach of mirroring traffic on core switches, routers, and firewalls is no longer effective at capturing internal server traffic. The industry typically categorizes feasible data collection methods into two main types: "virtual network device mirroring" and "host-level data collection (proxy-based)." The latter can be further subdivided into four specific implementations: system call interception, kernel network stack integration, user space sniffing, and eBPF / XDP.

[0067] Virtual network device mirroring involves port mirroring of vSwitch or vNIC at the hypervisor level. It copies the inbound / outbound traffic of a specified virtual machine port and forwards it to a dedicated collector virtual machine deployed on the same host. The advantages of this method are that it does not intrude on the business virtual machine, requires no agent installation within the VM, and does not affect the guest operating system; it directly copies the original Ethernet frames, retaining all L2-L7 information, enabling DPI and PCAP replay; the mirroring link is completed at the virtual switching layer, with microsecond-level latency, allowing for second-level alarms. However, it has high resource consumption; copying 1 Gbps of traffic consumes approximately 1 Gbps of host CPU + network I / O; in high-concurrency scenarios, host CPU usage spikes, potentially slowing down business traffic. It also carries a high risk of packet loss, as vSwitch will prioritize discarding mirrored traffic during congestion, resulting in the collector not seeing 100% accurate packets. High management costs: each host machine requires independent configuration of mirroring rules; with thousands of nodes, any policy change needs to be distributed to each machine individually, and maintenance scripts, configuration migration, and rollback are all hidden costs. Large horizontal scaling bottlenecks: the collector VM is usually placed locally, and the local disk, CPU, and memory of the host machine become single points of bottleneck; if remote aggregation is required, the "east-west" traffic will be changed back to "north-south", which deviates from the original intention of low latency.

[0068] Host-based data collection includes four methods: system call interception, kernel network stack integration, user-space sniffing, and eBPF. System call interception, through methods such as LD_PRELOAD, ptrace, or kernel modules, hooks network-related system calls such as socket, bind, connect, send, and recv. It can collect not only the network 5-tuple but also directly correlate it with process ID, thread ID, user ID, and even call stack information. However, it incurs significant performance overhead; each network call triggers a tracing process, resulting in frequent context switching and severe performance degradation in high-throughput scenarios. It is also highly dependent on the kernel version; system upgrades or applications using non-standard libraries (such as static compilation) may cause tracing failures or program crashes. Currently, it is rarely used for core data collection in production environments, but rather for specific scenarios with lower performance requirements, such as security analysis (e.g., HIDS) or deep debugging.

[0069] The network stack integration method requires registering a hook function directly in the kernel network protocol stack or handling it at the virtual network interface card (NIC) driver level. It processes data packets directly in the kernel path, avoiding the overhead of system calls and context switching. It can collect data at various stages of packet processing (such as NF_INET_PRE_ROUTING and NF_INET_LOCAL_OUT) to obtain the most raw and complete data. However, it is highly complex to develop and requires extensive kernel development experience. Code defects can cause the entire system kernel to malfunction, leading to serious stability issues. Each kernel version may require re-adaptation and compilation, resulting in enormous maintenance costs. This approach is typically adopted by large network equipment manufacturers or operating system vendors, and is difficult for ordinary users or projects to adopt.

[0070] User-space sniffing uses the libpcap library to capture packets from the kernel in user space via AF_PACKET sockets or BSD's BPF. Leveraging a mature library, it eliminates the need for in-depth kernel development. Even if the proxy crashes, it almost never causes a system crash. libpcap is implemented on Linux, Windows, BSD, and other systems. However, packets need to be completely copied from kernel space to user space, which incurs significant CPU overhead on high-speed networks, easily becoming a bottleneck and causing packet loss.

[0071] eBPF (Extended Berkeley Packet Filter) is mounted and runs very early in the network interface card (NIC) driver layer, typically handling only inbound traffic. This is because XDP's design and its very early mounting position in the kernel network stack dictate that it primarily handles inbound traffic. At this stage, the kernel has not yet allocated an sk_buff (the core data structure representing a data packet in the kernel), parsed any header information, or performed a route lookup; it can only process packets arriving from the outside, i.e., inbound traffic. Outbound traffic follows a completely different path, originating from the application's socket, undergoing layers of encapsulation in the kernel protocol stack, and finally being sent out by the NIC driver. By this time, the packet has completed all kernel processing and is about to be sent to the physical interface.

[0072] Elastic IP (EIP) is a type of NAT IP that actually resides on the public network gateway of the public cloud and is mapped to the bound cloud resource via NAT. Once an EIP is bound to a cloud resource, the cloud resource can communicate with the public network through the EIP. However, agent-based data collection deployed within a VPC does not have an EIP. Without modification, data sent to the analysis system will not show any EIP-related analysis, even though users are more interested in EIP-related analysis. Traditional data collection solutions deployed within virtual machines cannot directly see the Elastic IP (EIP) assigned to that virtual machine because they capture traffic at the virtual machine's operating system kernel network stack level. At this point, the EIP's NAT translation has not yet occurred or has already been completed. The agent runs inside the virtual machine's operating system and collects traffic at the kernel network stack level, such as the TCP / UDP 5-tuple: source IP, source port, destination IP, destination port, and protocol. For inbound traffic, when external traffic accesses the virtual machine through an EIP, the DNAT translation from EIP to private IP occurs at the virtualization layer or gateway device. When the data packet arrives at the virtual machine, the destination IP has been restored to a private IP, and the agent still sees the private IP. For outbound traffic, when a process inside the virtual machine initiates a connection, the source IP of the data packet remains a private IP address, such as 10.xxx, when leaving the virtual machine. EIP NAT translation occurs at the virtualization layer or gateway device, such as the NAT gateway of a VPC or the mapping table of elastic public IPs, which the agent is still unaware of. Therefore, the agent's perspective is limited to inside the virtual machine, while the EIP mapping relationship exists in the virtualization layer or the SDN controller of the cloud platform; the two are not at the same level.

[0073] In summary, the above method, which attaches to the XDP tracking point via eBPF, can only collect inbound traffic and cannot perform EIP replacement on the addresses in the traffic, so users cannot see EIP-related analysis.

[0074] In view of this, this application provides a traffic collection method. This method uses kernel-level eBPF attached to the TC tracking point to collect outbound and inbound traffic in a customized manner, not just inbound traffic. After the kernel completes the collection, it directly encapsulates and forwards the raw traffic in the kernel, without copying it to user space, which greatly improves forwarding performance without affecting the original network services. It stores all virtual machine traffic and can quickly extract the stored virtual machine traffic, outputting it as a pcap file for third-party secondary analysis. In this application embodiment, all outbound and inbound traffic of the virtual machine is collected in the kernel, instead of just inbound traffic. Comprehensive acquisition of virtual machine traffic provides comprehensive information for virtual machine traffic analysis. Direct forwarding by the kernel, without copying to user space for encapsulation and forwarding, greatly improves collection performance and significantly reduces the CPU consumption increased by copying the raw traffic, minimizing the impact on the original services in the VPC. It can obtain preliminary analysis and statistical information of virtual machine traffic, as well as historical traffic of the virtual machine for secondary analysis.

[0075] It should be noted that the embodiments of this application can be deployed inside a physical machine, inside a virtual machine, or on the physical node of a container. The specific deployment method is similar to the traffic collection and storage method in the embodiments of this application.

[0076] Next, the virtualized traffic collection and storage method provided in the embodiments of this application will be described in detail. Figure 1 A schematic diagram of a traffic acquisition device is shown. In this embodiment, the traffic acquisition device includes a control system, an acquisition system, and a storage and analysis system. The control system provides a user configuration interface and collects acquisition and forwarding configurations. The acquisition system is deployed in a VPC and performs acquisition and forwarding based on the configuration information. The storage and analysis system stores and analyzes the received traffic.

[0077] The control system receives the user's forwarding configuration, including the encapsulation method and storage analysis system information. Encapsulation methods support GRE tunnels, Vxlan tunnels, and pcap-over-ip. Storage analysis system information refers to the IP address of the storage analysis system. The storage analysis system and the data acquisition system are deployed on different devices, minimizing the impact on the original virtual machine service operation. Users do not need to configure mirror ports on the VPC.

[0078] Figure 2 A flowchart illustrating a traffic acquisition method is shown. The virtualized traffic acquisition and storage method includes the following steps:

[0079] Step 110: The control system receives the user's configuration information.

[0080] In this embodiment, the configuration information needs to specify the interface and direction of traffic collection, allowing collection of only outbound or inbound traffic, or traffic from both directions. Filtering methods support BPF format or a custom 5-tuple key-value format. Furthermore, the configuration information can also configure the truncation length, saving only a certain length of raw traffic; truncation is not configured by default. The configuration information can also configure EIP replacement, replacing the virtual machine's internal IP address in the traffic with an EIP, facilitating service observation by EIP unit in the analysis system. Different EIPs typically carry different services.

[0081] Step 120: The user-space eBPF receives the configuration information, creates a new virtual interface, and converts the configuration information and the virtual interface into the information required for collection and forwarding, which is then passed to the kernel-space eBPF in the form of maps.

[0082] Step 130: The kernel-mode eBPF module is attached to three TC tracking points, namely the TC inbound direction of the interface to be acquired, the TC outbound direction of the interface to be acquired, and the TC outbound direction of the virtual interface.

[0083] In this embodiment of the application, according to the eBPF mapping table, a first eBPF program is attached to a first tracking point, a second eBPF program is attached to a second tracking point, and a third eBPF program is attached to a third tracking point in the eBPF kernel mode. The first tracking point is the inbound direction of the flow control TC of the interface to be collected, the second tracking point is the outbound direction of the flow control TC of the interface to be collected, and the third tracking point is the outbound direction of the flow control TC of the relay interface.

[0084] In this embodiment, the kernel mode includes physical interfaces, virtual interfaces, and acquisition interfaces. The physical interface corresponds to a real hardware network card, while the virtual interface is a network interface entirely created and managed by the operating system software. It does not have a direct, proprietary physical hardware device (such as a network card chip) corresponding to it. Its existence, state, and packet sending and receiving behavior are all defined by software drivers and algorithms in the kernel. It can be understood as a logical abstraction layer in the network stack. Forwarding is possible between the virtual interface and the physical interface. Suppose a virtual machine needs to access a server in the physical network (e.g., 192.168.1.100). For the outbound direction, the process of sending a data packet from the virtual interface vnet0 to the server through the physical interface eth0 is as follows: The virtual machine application inside the virtual machine generates a data packet (destination IP: 192.168.1.100). This packet is encapsulated into a data frame by the TCP / IP protocol stack inside the virtual machine, with the destination MAC address being the gateway's MAC address or (if in the same network segment) the MAC address of 192.168.1.100. The data frame is then sent to the virtual network card. TAP device reception: Data is written to the virtual interface vnet0 in the kernel. Since virtual interface vnet0 is a port of bridge br0, the data frame enters bridge br0 from port vnet0. Bridge br0 checks the source MAC address of the data frame and records MAC_A (the virtual machine's MAC address) on virtual interface vnet0. It updates its MAC address table and checks the destination MAC address of the data frame (e.g., MAC_B). It looks up which port MAC_B corresponds to in its own MAC address table. If MAC_B corresponds to physical interface eth0, the data frame is forwarded only from port eth0. The data frame is sent from bridge eth0 to physical interface eth0. Physical interface eth0 converts the data frame into an electrical signal and sends it to the physical switch via the network cable, ultimately reaching the target server 192.168.1.100.

[0085] The response packet returned by the external server 192.168.1.100 arrives at the host's physical interface eth0 via the physical network. Physical interface eth0 converts the electrical signals of this packet back into data frames and sends them into the kernel. Since physical interface eth0 is bound to bridge br0, all its data frames are processed through bridge br0. Bridge br0 checks the source MAC address of the data frame and records MAC_B (the external server's MAC address) on physical interface eth0. Bridge br0 checks the destination MAC address of the data frame (MAC_A, i.e., the virtual machine's MAC address). Bridge br0 queries the MAC address table and finds that MAC_A corresponds to virtual interface vnet0. It forwards the data frame only from the virtual interface vnet0 port. The data frame is sent to the device on virtual interface vnet0. The virtual device where virtual interface vnet0 resides stores the data frame in its kernel buffer. The data frame is then sent to the network protocol stack inside the virtual machine and finally delivered to the application within the virtual machine.

[0086] Step 140: The first eBPF program collects the first traffic, mirrors the first traffic, and redirects the first traffic to the third eBPF program. The second eBPF program collects the second traffic, mirrors the second traffic, and redirects the second traffic to the third eBPF program. The first traffic is a data packet sent from an external device to the physical interface, and the second traffic is a data packet that has passed through the kernel protocol stack and routing decisions and is about to be sent to the external device.

[0087] Figure 3 and Figure 4 A flowchart of a traffic acquisition method is shown. In this embodiment, a second eBPF program acquires the second traffic; determines whether the interface to be acquired and the physical forwarding interface are the same; if they are different, the second traffic that meets the preset conditions is copied and redirected to a third eBPF program; if they are the same, determines whether the second traffic is self-encapsulated traffic; if not, the second traffic that meets the preset conditions is copied and redirected to the third eBPF program.

[0088] Figure 5 A flowchart of a traffic acquisition method is shown. In this embodiment, it is determined whether the physical forwarding interface and the interface to be acquired are the same; if so, the encapsulated traffic is forwarded out using the TC outgoing direction processing flow of the interface to be acquired; otherwise, the encapsulated traffic is forwarded out using the physical forwarding interface.

[0089] In this embodiment, the configuration information further includes an EIP mapping table, which includes the IP to be converted and the converted IP. The first eBPF program converts the IP to be converted for the mirrored first traffic to the converted IP according to the EIP mapping table; the second eBPF program converts the IP to be converted for the mirrored second traffic to the converted IP according to the EIP mapping table.

[0090] Step 150: The third eBFP program receives the first traffic and the second traffic, encapsulates the first traffic and the second traffic, and sends them to the outgoing direction of the flow control TC of the physical forwarding interface, and sends them to the target storage device through the physical forwarding interface.

[0091] In this embodiment, it is determined whether the physical forwarding interface and the interface to be collected are the same; if so, the encapsulated traffic is forwarded out using the TC outgoing direction processing flow of the interface to be collected; otherwise, the encapsulated traffic is forwarded out using the physical forwarding interface.

[0092] In this embodiment, the configuration information also includes encapsulation methods, including GRE tunnel encapsulation, Vxlan tunnel encapsulation, and pcap-over-ip. A third eBFP program encapsulates the first and second traffic using the appropriate encapsulation methods. The target storage device decapsulates the encapsulated traffic. The target storage device performs preliminary analysis on the received traffic and stores the analysis results and the original traffic.

[0093] In this embodiment, the capture points (hook points) are the appropriate eBPF mount points to select. To achieve bidirectional traffic capture, it is not sufficient to rely solely on XDP (since it is primarily in the inbound direction); more suitable eBPF mount points need to be selected. The TC (Traffic Control) ingress and egress hooks serve as eBPF mount points. `ingress` processes packets entering the virtual machine's internal network protocol stack (corresponding to the "inbound direction" in the physical world). `egress` processes packets exiting the virtual machine's protocol stack (corresponding to the "outbound direction" in the physical world). By attaching the TC eBPF program to the virtual network interface card (veth pair, virtio-net, etc.) of the virtual machine, all bidirectional traffic passing through that network interface card can be captured.

[0094] In this embodiment, when the eBPF program matches the traffic to be collected (e.g., through 5-tuple filtering), it does not affect the path of the original data packet. It calls `bpf_clone_redirection` or a similar helper function. This function efficiently creates a copy of the data packet. eBPF performs this operation in kernel space, avoiding the overhead of copying the entire data packet from kernel space to user space.

[0095] The cloned packet copy needs to be sent to a specified destination. eBPF provides several redirection methods, including redirecting to another network device: this is the most efficient method. For example, the cloned packet can be sent directly to another physical or virtual network interface card (NIC) on the host machine, specifically connected to a data capture virtual machine or physical packet capture machine. This uses helper functions such as `bpf_redirect` or `bpf_redirect_peer`. Alternatively, it can be redirected to a user-space program: through eBPF mappings, particularly AF_XDP sockets. The cloned packet can be directly fed into a user-space process (such as a professional packet capture program like Wireshark, Suricata IDS, or a custom analyzer). Alternatively, it can be redirected to a queue on another CPU for complex load balancing.

[0096] In this embodiment, at the moment the eBPF program clones the network data packet, it no longer simply copies it. Instead, based on a pre-set "EIP-Private Network EIP Mapping Table," it replaces the source private network IP (or destination private network IP) in the packet's IP header with the corresponding EIP (or vice versa), and then sends the modified cloned packet to the collector. Thus, the collector receives a copy of the traffic after NAT translation.

[0097] Establishing and maintaining the mapping table is the cornerstone of the entire solution. The mapping table must be extremely efficient and accessible to eBPF programs. Using an eBPF hash map or LRU mapping is the best choice. The key is the virtual machine's private IP address, and the value is the elastic public IP address bound to it. A separate agent (control plane process) running on the host machine can periodically call the cloud vendor's metadata service or OpenAPI to query the binding relationships of all virtual machines and their EIPs on the local host machine. Alternatively, the agent can listen for event notifications from the cloud platform and update the mapping table in real time when EIP binding / unbinding occurs.

[0098] After obtaining the mapping relationship, the user-space agent synchronizes this mapping table to the eBPF Map in the kernel via the eBPF file system or system calls. eBPF programs can then directly query this Map at runtime.

[0099] In this embodiment, to implement atomic replacement in the eBPF program, the following logic needs to be implemented in eBPF hook points such as tcingress / egress: For cloned packets of outbound traffic (virtual machine -> external network): create a packet copy using bpf_clone_redirection() or other methods. In the eBPF Map, use the saddr (source IP, i.e., private network IP) in the packet IP header as the key to find the corresponding EIP. If found, use auxiliary functions such as bpf_skb_store_bytes or directly modifying the packet pointer to replace the saddr in the IP header of the cloned packet from the private network IP to the EIP. After modifying the IP header, the IP checksum will inevitably become invalid and must be recalculated. In addition, if TCP or UDP protocols are involved, their checksums (L4 checksums) also pseudo-include the source IP and destination IP in the IP header, so the L4 checksum must also be recalculated. The modified and verified cloned packet is sent to the collector.

[0100] For inbound traffic (external network -> virtual machine) cloned packets: the logic is similar, but the process is reversed. Identify that the destination IP is a specific EIP. Query the mapping table to find the private network IP corresponding to that EIP. Replace the `daddr` (destination IP, i.e., EIP) in the cloned packet's IP header with the private network IP. Recalculate the IP and L4 checksum, update the packet, and send it to the collector.

[0101] In this embodiment, for a complete TCP connection, the inbound and outbound IPs are different after NAT. Simply replacing the IP might cause the collector to see two unrelated unidirectional flows. This can be addressed by maintaining a connection tracking table to record the mapping relationship (private IP:port, EIP:assigned port, peer IP:port). This ensures that when processing inbound packets, the destination EIP and port are correctly restored to the private IP and port. Alternatively, by associating flow logs with the five-tuple and timestamp, the eBPF program can only modify the IP address without handling port translation.

[0102] In this embodiment, after the EIP replacement is completed in kernel space, the original packets are immediately encapsulated into tunnels (VxLAN / GRE / PCAP-over-IP) and sent losslessly to a storage and analysis cluster completely isolated from the service VPC via the virtual encapsulation interface, achieving full traffic collection with zero mirrored ports and zero service intrusion. a) Virtual encapsulation interface: Host internal veth-pair (virt0 / virt0p) or macvtap; virt0 is responsible for "receiving mirrors", and virt0p is responsible for "sending tunnels". b) Encapsulation action: Completed in the TC-egress eBPF program of virt0; packets do not need to pass through user space again. c) Isolation: The tunnel destination address is located in an independent VPC / subnet, and the ACL only allows ports 4789 / 47 / 6653, achieving physical separation between the traffic plane and the management plane.

[0103] Figure 6 A schematic diagram of a traffic acquisition method is shown. This example uses traffic acquisition and storage of virtual machine A as an example. The implementation plan involves three systems: a control system, a acquisition system, and a storage and analysis system.

[0104] The control system provides a web interface for user configuration, which is then synchronized to the eBPF user space. Data acquisition is configured with the acquisition interface ens3, acquisition port 22, and TCP protocol. The BPF statement is "tcp port 22", and the packet truncation length is set to 128 bytes, indicating that only the first 128 bytes of each packet are acquired. The IP address 10.0.0.133 in the packet is replaced with the EIP address 172.168.10.133 corresponding to this virtual machine. This way, during observation, only the EIP needs to be monitored, as the EIP indicates the service it carries. Forwarding is configured with Vxlan tunneling as the encapsulation method, and the IP address of the storage and analysis system is 10.0.0.182. The acquisition system performs acquisition and tunnel encapsulation forwarding operations. A new virtual interface, virt0, is created in eBPF user space. The eBPF user space receives the system configuration, and the destination IP for forwarding is 10.0.0.182. Route lookup reveals the forwarding interface to be ens3. eBPF synchronizes information such as the virtual interface, acquisition interface, and forwarding interface to the kernel space via BPF Maps. The eBPF kernel space attaches to three tracking points: ens3 TC inbound, ens3 TC outbound, and virt0 outbound. The eBPF kernel space handles the ens3 TC inbound traffic as follows: traffic using the TCP protocol and port 22 is cloned and redirected to the virt0 TC outbound direction, then returns OK, allowing the original traffic to continue its processing flow within the protocol stack.

[0105] In eBPF kernel mode, the outbound traffic of ens3 TC is processed as follows: Since the outbound interface and the acquisition interface are the same, it is necessary to determine whether the traffic at this tracking point is self-encapsulated. If it is not self-encapsulated traffic, it is determined whether the traffic protocol is TCP and the port is 22. If so, a copy is cloned and redirected to the outbound direction of virt0 TC. If not, OK is returned, allowing the original traffic to continue its processing in the protocol stack. If it is self-encapsulated traffic, OK is also returned, and the traffic continues to be processed in the protocol stack.

[0106] In eBPF kernel mode, the outbound traffic from virt0 TC is processed as follows: the first 128 bytes of the traffic are encapsulated into a Vxlan tunnel, and then the encapsulated traffic is cloned and redirected to the outbound traffic from ens3 TC. Then, the process returns to the previous shot, cutting off subsequent protocol stack processing.

[0107] The storage analysis system stores and analyzes received virtual machine traffic. Upon receiving encapsulated VXLAN packets, the system strips the outer VXLAN header, extracts the 128-byte virtual machine traffic, stores the raw 128-byte traffic, and creates an index to search for traffic with EIP 172.168.10.133. This traffic is then exported as a pcap file, which is analyzed using tools such as Wireshark.

[0108] Figure 7 A schematic diagram of a flow rate acquisition device is shown. The flow rate acquisition device includes:

[0109] The first module is used to instruct the eBPF user space to obtain configuration information, convert the configuration information into an eBPF mapping table, and send the eBPF mapping table to the eBPF kernel space. The eBPF mapping table includes the interface to be collected, the physical forwarding interface, and the relay interface.

[0110] The second module is used to instruct, according to the eBPF mapping table, to attach a first eBPF program to a first tracking point, a second eBPF program to a second tracking point, and a third eBPF program to a third tracking point in the eBPF kernel mode, wherein the first tracking point is the flow control TC inbound direction of the interface to be collected, the second tracking point is the flow control TC outbound direction of the interface to be collected, and the third tracking point is the flow control TC outbound direction of the relay interface.

[0111] The third module is used to instruct the first eBPF program to collect the first traffic, mirror the first traffic, and redirect the first traffic to the third eBPF program. The second eBPF program collects the second traffic, mirrors the second traffic, and redirects the second traffic to the third eBPF program. The first traffic is a data packet sent from an external device to the physical interface, and the second traffic is a data packet that has passed through the kernel protocol stack and routing decisions and is about to be sent to the external device.

[0112] The fourth module is used to instruct the third eBFP program to receive the first traffic and the second traffic, encapsulate the first traffic and the second traffic, and send them to the outgoing direction of the traffic control TC of the physical forwarding interface, and send them to the target storage device through the traffic physical forwarding interface.

[0113] In one possible implementation, the interface to be collected includes a physical interface and a virtual interface, wherein the physical forwarding interface is the physical interface that forwards the collected traffic to the target storage device.

[0114] The first module is used by the eBPF user space to instruct the eBPF kernel space to create the relay interface according to the configuration information, wherein the relay interface is a virtual interface.

[0115] In one possible implementation, a third module is used by the second eBPF program to collect the second traffic.

[0116] Determine whether the interface to be collected and the physical forwarding interface are the same.

[0117] If they are different, the second traffic that meets the preset conditions will be copied and redirected to the third eBPF program.

[0118] If they are the same, determine whether the second traffic is a self-encapsulated traffic.

[0119] If not, the second traffic that meets the preset conditions will be copied and redirected to the third eBPF program.

[0120] In one possible implementation, the third module is used to determine whether the physical forwarding interface and the interface to be collected are the same.

[0121] If so, the encapsulated traffic is forwarded out using the processing flow of the TC outgoing direction of the interface to be collected.

[0122] Otherwise, the encapsulated traffic is forwarded out using the physical forwarding interface.

[0123] In one possible implementation, the configuration information further includes an EIP mapping table, which includes the IP to be converted and the converted IP.

[0124] The third module is used by the first eBPF program to convert the IP to be converted of the mirrored first traffic to the converted IP according to the EIP mapping table.

[0125] The second eBPF program converts the IP to be converted of the mirrored second traffic into the converted IP according to the EIP mapping table.

[0126] In one possible implementation, the configuration information further includes an encapsulation method, which includes GRE tunnel encapsulation and Vxlan tunnel encapsulation;

[0127] The fourth module is used by the third eBFP program to encapsulate the first traffic and the second traffic using the encapsulation method.

[0128] It should be understood that each step of the above method embodiments can be accomplished by hardware logic circuits or software instructions in a processor.

[0129] Based on the methods in the above embodiments, this application provides a computer-readable storage medium including computer program instructions. When executed by a cluster of computing devices including at least one computing device, the computer program instructions cause the cluster of computing devices to perform the methods in the above embodiments. Exemplarily, the computer-readable storage medium can be any available medium that the computing device can store, or a data storage device such as a data center containing one or more available media. The available medium can be a magnetic medium (e.g., floppy disk, hard disk, magnetic tape), an optical medium (e.g., DVD), or a semiconductor medium (e.g., solid-state drive).

[0130] Based on the methods in the above embodiments, this application provides a computer program product containing instructions that, when executed by a cluster of computing devices containing at least one computing device, cause the cluster of computing devices to perform the methods in the above embodiments.

[0131] It is understood that the processor in the embodiments of this application may be a central processing unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, transistor logic devices, hardware components, or any combination thereof. A general-purpose processor may be a microprocessor or any conventional processor.

[0132] The method steps in the embodiments of this application can be implemented in hardware or by a processor executing software instructions. The software instructions can consist of corresponding software modules, which can be stored in random access memory (RAM), flash memory, read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), registers, hard disks, portable hard disks, CD-ROMs, or any other form of storage medium known in the art. An exemplary storage medium is coupled to the processor, enabling the processor to read information from and write information to the storage medium. Of course, the storage medium can also be a component of the processor. The processor and the storage medium can reside in an ASIC.

[0133] In the above embodiments, implementation can be achieved entirely or partially through software, hardware, firmware, or any combination thereof. When implemented using software, it can be implemented entirely or partially in the form of a computer program product. The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, all or part of the processes or functions described in the embodiments of this application are generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transmitted through the computer-readable storage medium. The computer instructions can be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via wired (e.g., coaxial cable, fiber optic, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium can be any available medium that a computer can access or a data storage device such as a server or data center that integrates one or more available media. The available medium can be a magnetic medium (e.g., floppy disk, hard disk, magnetic tape), an optical medium (e.g., DVD), or a semiconductor medium (e.g., solid-state disk (SSD)).

[0134] It is understood that the various numerical designations used in the embodiments of this application are merely for descriptive convenience and are not intended to limit the scope of the embodiments of this application.

[0135] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the protection scope of the technical solutions of the embodiments of this application.

Claims

1. A method for collecting traffic flow, characterized in that, The method includes: The eBPF user space obtains configuration information, converts the configuration information into an eBPF mapping table, and sends the eBPF mapping table to the eBPF kernel space. The eBPF mapping table includes the interface to be collected, the physical forwarding interface, and the relay interface. According to the eBPF mapping table, in the eBPF kernel mode, the first eBPF program is attached to the first tracking point, the second eBPF program is attached to the second tracking point, and the third eBPF program is attached to the third tracking point. The first tracking point is the inbound direction of the flow control TC of the interface to be collected, the second tracking point is the outbound direction of the flow control TC of the interface to be collected, and the third tracking point is the outbound direction of the flow control TC of the relay interface. The first eBPF program collects the first traffic, mirrors the first traffic, and redirects the first traffic to the third eBPF program. The second eBPF program collects the second traffic, mirrors the second traffic, and redirects the second traffic to the third eBPF program. The first traffic is a data packet sent from an external device to the physical interface, and the second traffic is a data packet that has passed through the kernel protocol stack and routing decisions and is about to be sent to the external device. The third eBPF program receives the first traffic and the second traffic, encapsulates the first traffic and the second traffic, and sends them to the outgoing direction of the flow control TC of the physical forwarding interface, and sends them to the target storage device through the physical forwarding interface. The process of sending data to the target storage device via the physical forwarding interface specifically includes: Determine whether the physical forwarding interface and the interface to be collected are the same; If so, the encapsulated traffic is forwarded out using the processing flow of the TC outgoing direction of the interface to be collected; Otherwise, the encapsulated traffic is forwarded out using the physical forwarding interface.

2. The method according to claim 1, characterized in that, in, The interface to be collected includes a physical interface and a virtual interface. The physical forwarding interface is the physical interface that forwards the collected traffic to the target storage device. The method further includes: The eBPF user space, based on the configuration information, instructs the eBPF kernel space to create the relay interface, which is a virtual interface.

3. The method according to claim 1, characterized in that, The second eBPF program collects the second traffic, mirrors the second traffic, and then redirects the second traffic to the third eBPF program, specifically including: The second eBPF program collects the second traffic; Determine whether the interface to be collected and the physical forwarding interface are the same; If they are not the same, the second traffic that meets the preset conditions will be copied and redirected to the third eBPF program; If they are the same, determine whether the second traffic is a self-encapsulated traffic; If not, the second traffic that meets the preset conditions will be copied and redirected to the third eBPF program.

4. The method according to claim 1, characterized in that, The configuration information also includes an EIP mapping table, which includes the IP to be converted and the converted IP; The first eBPF program mirrors the first traffic, specifically including: The first eBPF program converts the IP to be converted of the mirrored first traffic to the converted IP according to the EIP mapping table; The second eBPF program mirrors the second traffic, specifically including: The second eBPF program converts the IP to be converted of the mirrored second traffic into the converted IP according to the EIP mapping table.

5. The method according to claim 4, characterized in that, The configuration information also includes encapsulation methods, which include GRE tunnel encapsulation and Vxlan tunnel encapsulation. The encapsulation of the first traffic and the second traffic specifically includes: The third eBFP program encapsulates the first traffic and the second traffic using the encapsulation method.

6. The method according to claim 5, characterized in that, The method further includes: The target storage device decapsulates the encapsulated traffic.

7. A flow rate acquisition device, characterized in that, The device includes: The first module is used to instruct the eBPF user space to obtain configuration information, convert the configuration information into an eBPF mapping table, and send the eBPF mapping table to the eBPF kernel space. The eBPF mapping table includes an interface to be collected, a physical forwarding interface, and a relay interface. The second module is used to instruct, according to the eBPF mapping table, to attach a first eBPF program to a first tracking point, a second eBPF program to a second tracking point, and a third eBPF program to a third tracking point in the eBPF kernel mode, wherein the first tracking point is the flow control TC inbound direction of the interface to be collected, the second tracking point is the flow control TC outbound direction of the interface to be collected, and the third tracking point is the flow control TC outbound direction of the relay interface. The third module is used to instruct the first eBPF program to collect the first traffic, mirror the first traffic, and redirect the first traffic to the third eBPF program. The second eBPF program collects the second traffic, mirrors the second traffic, and redirects the second traffic to the third eBPF program. The first traffic is a data packet sent from an external device to the physical interface, and the second traffic is a data packet that has passed through the kernel protocol stack and routing decision and is about to be sent to the external device. The fourth module is used to instruct the third eBPF program to receive the first traffic and the second traffic, encapsulate the first traffic and the second traffic, and send them to the outgoing direction of the flow control TC of the physical forwarding interface, and send them to the target storage device through the physical forwarding interface. The fourth module is specifically used to determine whether the physical forwarding interface and the interface to be collected are the same; If so, the encapsulated traffic is forwarded out using the processing flow of the TC outgoing direction of the interface to be collected; Otherwise, the encapsulated traffic is forwarded out using the physical forwarding interface.

8. A non-transitory computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by the processor, it implements the traffic acquisition method as described in any one of claims 1 to 6.

9. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by the processor, it implements the traffic acquisition method as described in any one of claims 1 to 6.

Images