Traffic processing methods, devices, and storage media based on virtual network interface cards (NICs)

Abstract

This application discloses a traffic processing method, device, and storage medium based on a virtual network interface card (NIC), relating to the field of network traffic processing technology. The method includes: capturing raw data packets from a traffic source device and transmitting the raw data packets to a traffic processing node via a preset transmission protocol; performing at least one processing operation on the raw data packets at the traffic processing node to obtain processed standardized Layer 2 data packets, including protocol adaptation, data packet decryption, data packet modification, and traffic filtering; determining the target virtual NIC corresponding to the standardized Layer 2 data packets and writing the standardized Layer 2 data packets to the target virtual NIC; connecting the acquisition interface of a preset analysis tool to the target virtual NIC, and performing analysis operations on the standardized Layer 2 data packets through the preset analysis tool to obtain corresponding data analysis results. This solves the technical problem of poor compatibility in existing traffic analysis and processing methods, and improves the flexibility of traffic processing.

Description

Technical Field

[0001] This application relates to the field of network traffic processing technology, and in particular to a traffic processing method, device and storage medium based on a virtual network interface card. Background Technology

[0002] In traditional network traffic analysis systems, the traffic analysis engine and the traffic acquisition module are typically tightly coupled. Specifically, the traffic format output by the traffic acquisition module must strictly match the parsing logic of the traffic analysis engine. If upstream traffic undergoes protocol conversion, decryption, or multi-tenant isolation, the traffic analysis engine must also modify its code to be compatible with the new format; otherwise, it will be unable to correctly parse the data. For example, when a Virtual eXtensible Local Area Network (VXLAN) is added to the network to encapsulate traffic or an encrypted channel is deployed, downstream traffic analysis tools need to redevelop their protocol parsing plugins; otherwise, they will fail because they cannot recognize the new encapsulation structure or decrypt the data. To adapt heterogeneous traffic to existing traffic analysis engines, it is usually necessary to customize the data access layer or parsing logic of the traffic analysis engine, resulting in high development costs, complex maintenance, and compromised versatility and stability.

[0003] The above content is only used to help understand the technical solution of this application and does not represent an admission that the above content is prior art. Summary of the Invention

[0004] The main objective of this application is to provide a traffic processing method, device, and storage medium based on a virtual network interface card (NIC), aiming to solve the technical problems of poor compatibility and scalability of existing traffic analysis and processing methods.

[0005] To achieve the above objectives, this application proposes a traffic processing method based on a virtual network interface card (NIC), the traffic processing method based on a virtual NIC comprising:

[0006] The system captures raw data packets from the traffic source device and transmits them to the traffic processing node using a preset transmission protocol.

[0007] In the traffic processing node, at least one processing operation is performed on the original data packet to obtain a processed standardized Layer 2 data packet. The processing operation includes protocol adaptation, data packet decryption, data packet modification, and traffic filtering.

[0008] Determine the target virtual network interface card (NIC) corresponding to the standardized Layer 2 data packet, and write the standardized Layer 2 data packet into the target virtual NIC;

[0009] The acquisition interface of the preset analysis tool is connected to the target virtual network card, and the preset analysis tool is used to perform analysis operations on the standardized Layer 2 data packets to obtain the corresponding data analysis results.

[0010] In one embodiment, the step of capturing raw data packets from the traffic source device includes:

[0011] Raw data packets are obtained from at least one traffic acquisition source of the traffic source device, wherein the traffic acquisition source includes port mirroring of a physical network switch, a network splitter, a virtual switch, and traffic acquisition probes deployed on the traffic source device;

[0012] The original data packet is an Ethernet frame containing a complete data link layer header.

[0013] In one embodiment, the step of transmitting the raw data packet to the traffic processing node via a preset transmission protocol includes:

[0014] Perform identity authentication and access control verification on the original data packet to obtain the original data packet that passes the verification;

[0015] The original data packet that has passed verification is encrypted based on the Transport Layer Security (TLS) protocol to obtain the encrypted original data packet;

[0016] The encrypted original data packet is transmitted to the traffic processing node through the preset transmission protocol, wherein the preset transmission protocol is at least one of a tunneling protocol and a remote call protocol.

[0017] In one embodiment, when the processing operation includes the protocol adaptation and the data packet decryption, the step of performing at least one processing operation on the original data packet to obtain the processed standardized Layer 2 data packet includes:

[0018] In response to the fact that the original data packet is a heterogeneous protocol data packet encapsulated by the preset transmission protocol, the heterogeneous protocol data packet is decapsulated and converted into an adapted data packet of the target format;

[0019] In response to the original data packet being an encrypted data packet, the session key corresponding to the encrypted original data packet is obtained;

[0020] The adapted data packet is decrypted based on the session key to obtain the decrypted plaintext data packet. The session key is at least one of RSA (Rivest–Shamir–Adleman) private key, Elliptic Curve Diffie–Hellman (ECDH) private key, or TLS ephemeral key.

[0021] The plaintext data packet is encapsulated into the standardized Layer 2 data packet.

[0022] In one embodiment, when the processing operation further includes the traffic filtering, before the step of decapsulating the heterogeneous protocol data packet in response to the original data packet being a heterogeneous protocol data packet encapsulated by the preset transport protocol, the method further includes:

[0023] Obtain traffic filtering rules, which include static rules and dynamic rules. The static rules include fixed filtering conditions based on source Media Access Control (MAC) address range, destination MAC address range, port number, and protocol type. The dynamic rules include dynamic filtering conditions based on packet priority and business scenario.

[0024] Parse the attribute information of the original data packet, the attribute information including at least one of the following: source MAC address, destination MAC address, transmission port, transmission protocol type, data packet priority identifier, and service scenario identifier;

[0025] The attribute information of the original data packet is matched and verified with the static rules and the dynamic rules respectively. If the attribute information meets the filtering conditions that need to be retained in the static rules and the dynamic rules, the original data packet is retained.

[0026] If the attribute information meets the filtering conditions for discarding in the static rules or the dynamic rules, the original data packet is discarded.

[0027] In one embodiment, where the processing operation further includes the data packet modification, the step of encapsulating the plaintext data packet into the standardized Layer 2 data packet includes, before:

[0028] Parse the structural information of the plaintext data packet to determine the target field to be modified. The target field includes the header field and / or payload of the plaintext data packet. The header field includes at least one of the following: source MAC address, destination MAC address, Virtual Local Area Network (VLAN) tag, and protocol type identifier.

[0029] The target field of the plaintext data packet is modified to obtain the corresponding modified data packet. The modification operation includes at least one of adding, deleting, replacing, or recombining.

[0030] If the length of the modified data packet exceeds the preset length, the modified data packet is fragmented to obtain the corresponding fragmented data packet;

[0031] The fragmented data packets are encapsulated into the standardized Layer 2 data packets.

[0032] In one embodiment, the step of determining the target virtual network interface card corresponding to the standardized Layer 2 data packet includes:

[0033] Parse the attribute information of the standardized Layer 2 data packet, including source MAC address, destination MAC address, VLAN tag, and collection point identifier;

[0034] Based on the mapping relationship between the attribute information of the standardized Layer 2 data packet and the preset attribute information - virtual network interface card, the target virtual network interface card corresponding to the attribute information is selected from multiple candidate virtual network interfaces;

[0035] or,

[0036] According to the processing order of the standardized Layer 2 data packets, virtual network interfaces are selected cyclically from multiple candidate virtual network interfaces, and the currently selected virtual network interface is determined as the target virtual network interface.

[0037] or,

[0038] The attribute information of the standardized Layer 2 data packet is hashed to generate a corresponding target hash value. Based on the target hash value and the hash value corresponding to each candidate virtual network interface card (NIC), a virtual NIC is determined from each candidate NIC using a consistent hashing algorithm. The hash value corresponding to the candidate virtual NIC is obtained by mapping the NIC identifier of the candidate virtual NIC using a hashing algorithm.

[0039] In one embodiment, the step of performing analysis on the standardized Layer 2 data packets using the preset analysis tool to obtain the corresponding data analysis results includes:

[0040] Based on the analysis logic corresponding to the preset analysis tool, the standardized Layer 2 data packet is analyzed and processed to generate corresponding data analysis results;

[0041] The target virtual network interface card is configured to support concurrent monitoring and analysis by multiple preset analysis tools, including Snort, Suricata, and Zeek.

[0042] Furthermore, to achieve the above objectives, this application also proposes a traffic processing device based on a virtual network interface card (NIC), the traffic processing device based on a virtual NIC comprising:

[0043] The acquisition module is used to capture raw data packets from the traffic source device and transmit the raw data packets to the traffic processing node through a preset transmission protocol;

[0044] The processing module is used in the traffic processing node to perform at least one processing operation on the original data packet to obtain a processed standardized Layer 2 data packet. The processing operation includes protocol adaptation, data packet decryption, data packet modification, and traffic filtering.

[0045] The writing module is used to determine the target virtual network interface card (NIC) corresponding to the standardized Layer 2 data packet and write the standardized Layer 2 data packet to the target virtual NIC.

[0046] The analysis module is used to connect the acquisition interface of the preset analysis tool to the target virtual network card, and perform analysis operations on the standardized Layer 2 data packets through the preset analysis tool to obtain the corresponding data analysis results.

[0047] In addition, to achieve the above objectives, this application also proposes a traffic processing device based on a virtual network interface card (NIC), the device comprising: a memory, a processor, and a computer program stored in the memory and executable on the processor, the computer program being configured to implement the steps of the traffic processing method based on the virtual NIC as described above.

[0048] In addition, to achieve the above objectives, this application also proposes a storage medium, which is a computer-readable storage medium, on which a computer program is stored, and when the computer program is executed by a processor, it implements the steps of the traffic processing method based on the virtual network card as described above.

[0049] In addition, to achieve the above objectives, this application also provides a computer program product, which includes a computer program that, when executed by a processor, implements the steps of the traffic processing method based on a virtual network interface card as described above.

[0050] The one or more technical solutions proposed in this application have at least the following technical effects: They capture raw data packets from the traffic source device and transmit them to the traffic processing node via a preset transmission protocol, ensuring the integrity and security of the traffic during transmission. At the traffic processing node, at least one processing operation is performed on the raw data packets to obtain processed standardized Layer 2 data packets. These processing operations include protocol adaptation, data packet decryption, data packet modification, and traffic filtering. The target virtual network interface card (NIC) corresponding to the standardized Layer 2 data packets is determined, and the standardized Layer 2 data packets are written to the target NIC. The acquisition interface of a preset analysis tool is connected to the target NIC, and the preset analysis tool performs analysis operations on the standardized Layer 2 data packets to obtain corresponding data analysis results. The analysis tool requires no code modification; it only needs to configure its acquisition interface to the target virtual NIC so that the analysis tool can automatically receive, parse, and generate data analysis results of standardized Layer 2 data packets, just like processing traffic from a local physical NIC. This solves the technical problems of poor compatibility and scalability in existing traffic analysis and processing methods, improves the flexibility of traffic processing, supports on-demand expansion of processing functions, and achieves unified standardization of multiple types of traffic, thereby adapting to traffic analysis and processing tasks in different deployment scenarios. The traffic processing method based on virtual network interface cards (NICs) provided in this application captures raw data packets at the traffic source device and sends them to a dedicated traffic processing node via a preset transmission protocol. The traffic processing node then centrally performs operations such as protocol adaptation, data packet decryption, data packet modification, and traffic filtering, uniformly converting heterogeneous traffic into standard Layer 2 data packets. Next, the standardized Layer 2 data packets are written to the target virtual NIC, allowing any analysis tool supporting standard network interfaces to simply point its acquisition interface to the corresponding virtual NIC to receive and analyze traffic (standardized Layer 2 data packets) "plug and play" without any code modification. The analysis tool connects to the target virtual NIC, which simulates the interaction logic of a physical NIC, enabling the analysis tool to directly process standardized data without modifying the parser or protocol stack, thus solving the adaptation problem between analysis tools and multi-format traffic. Therefore, the format adaptation and preprocessing logic of raw data packets are converged to an intermediate layer, decoupling the analysis tool from traffic acquisition. Different types of raw traffic data do not affect the downstream analysis engine, fundamentally improving the compatibility and scalability of traffic analysis and processing. Attached Figure Description

[0051] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0052] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, for those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0053] Figure 1 This is a flowchart illustrating an embodiment of the traffic processing method based on a virtual network interface card (NIC) in this application.

[0054] Figure 2 A schematic diagram of the topology of the traffic processing system based on virtual network interface card provided in this application;

[0055] Figure 3 A flowchart illustrating another traffic processing method based on a virtual network interface card provided in this application;

[0056] Figure 4 This application provides a schematic diagram of HTTPS protocol traffic decryption and analysis for intranet HyperText Transfer Protocol Secure (HTTPS).

[0057] Figure 5 This application provides a visualization diagram of east-west container traffic in a cloud-native environment.

[0058] Figure 6 This is a schematic diagram of the module structure of the traffic processing device based on a virtual network interface card according to an embodiment of this application;

[0059] Figure 7 This is a schematic diagram of the hardware operating environment involved in the traffic processing method based on a virtual network interface card in the embodiments of this application.

[0060] The purpose, features, and advantages of this application will be further explained in conjunction with the embodiments and with reference to the accompanying drawings. Detailed Implementation

[0061] It should be understood that the specific embodiments described herein are merely illustrative of the technical solutions of this application and are not intended to limit this application.

[0062] To better understand the technical solution of this application, a detailed description will be provided below in conjunction with the accompanying drawings and specific implementation methods.

[0063] The main solution of this application embodiment is as follows: capture raw data packets from the traffic source device and transmit the raw data packets to the traffic processing node through a preset transmission protocol; in the traffic processing node, perform at least one processing operation on the raw data packets to obtain processed standardized Layer 2 data packets, the processing operations including protocol adaptation, data packet decryption, data packet modification, and traffic filtering; determine the target virtual network interface card corresponding to the standardized Layer 2 data packets and write the standardized Layer 2 data packets to the target virtual network interface card; connect the acquisition interface of the preset analysis tool to the target virtual network interface card, and perform analysis operations on the standardized Layer 2 data packets through the preset analysis tool to obtain the corresponding data analysis results.

[0064] In this embodiment, for ease of description, the following description will focus on identifying a traffic processing system based on a virtual network interface card.

[0065] In the field of network security and operations, traffic collection and analysis are fundamental components for realizing various functions such as intrusion detection, abnormal behavior identification, malicious traffic tracing, protocol reverse engineering, and performance diagnostics. Current mainstream implementations typically rely on port mirroring (Switched Port Analyzer, SPAN), test access points (TAP), or dedicated hardware probes on network switching devices. These probes directly copy raw Layer 2 / Layer 3 data packets passing through switches / routers and import them into a traffic analysis engine for deep packet inspection, rule matching, or traffic statistics. Traffic analysis engines are usually implemented in highly optimized C / C++ and tightly coupled to the underlying network stack. These modules are often large and logically complex. When extending these engines to support parsing new protocols such as HTTPS, secondary development and regression testing of the core parsing module, kernel-level data paths, or high-performance collection plugins are often required, leading to long development cycles, wide-ranging impacts, high risks, and high maintenance costs. Meanwhile, switch mirroring and TAP are mainly applicable to wired aggregation points or data center backbone links. They cannot fully cover business system servers or edge terminals (such as laptops and industrial controllers) whose traffic does not pass through the mirrored switch, resulting in an incomplete traffic view and failing to fully analyze the threats within the internal network. They may even miss malicious behavior or lateral movement traces on the terminal side. In cloud environments, virtualization, or containerized deployments, traditional switch mirroring traffic collection methods cannot directly obtain east-west traffic inside containers or on virtual switches on the host machine, creating monitoring blind spots. Existing traffic transmission is mostly "point-to-point" replication, with the collection point directly sending traffic to a single analysis engine or storage device. There is a lack of a pluggable intermediate processing layer for decryption, session reassembly, on-demand packet fragmentation, privacy masking, or policy-based traffic filtering. This makes it impossible to perform controllable modification or enrichment processing on the traffic before it reaches the final analyzer (e.g., decrypting the traffic and distributing it to different analyzers or stripping sensitive loads while retaining metadata), limiting the collaborative work of heterogeneous analysis tools and meeting compliance requirements.

[0066] This application provides a solution that captures raw data packets at the traffic source device and sends them to a dedicated traffic processing node via a preset transmission protocol. The traffic processing node then centrally performs operations such as protocol adaptation, data packet decryption, data packet modification, and traffic filtering, uniformly converting heterogeneous traffic into standard Layer 2 data packets. Next, the standardized Layer 2 data packets are written to the target virtual network interface card (NIC). This allows any analysis tool supporting standard network interfaces to simply point its acquisition interface to the corresponding virtual NIC to receive and analyze traffic (standardized Layer 2 data packets) "plug and play," without any code modification. The analysis tool connects to the target virtual NIC, which simulates the interaction logic of the physical NIC, enabling it to directly process standardized data without modifying the parser or protocol stack. This solves the problem of adapting analysis tools to multi-format traffic. Thus, the format adaptation and preprocessing logic of the raw data packets are converged to an intermediate layer, decoupling the analysis tool from traffic acquisition. Different types of raw traffic data do not affect the downstream analysis engine, fundamentally improving the compatibility and scalability of traffic analysis and processing.

[0067] It should be noted that the executing entity in this embodiment can be a computing service device with data processing, network communication, and program execution functions, such as a tablet computer, personal computer, or mobile phone, or a traffic processing device based on a virtual network interface card (NIC) capable of performing the above functions. The following description uses a traffic processing system based on a virtual NIC as an example to illustrate this embodiment and the subsequent embodiments.

[0068] Based on this, embodiments of this application provide a traffic processing method based on a virtual network interface card (NIC), referring to... Figure 1 , Figure 1 This is a flowchart illustrating the first embodiment of the traffic processing method based on a virtual network interface card (NIC) of this application.

[0069] In this embodiment, the traffic processing method based on the virtual network interface card includes steps 101-104:

[0070] Step 101: Capture raw data packets from the traffic source device and transmit the raw data packets to the traffic processing node using a preset transmission protocol.

[0071] Specifically, the traffic processing method based on a virtual network interface card (NIC) provided in this application is applied to a traffic processing system based on a virtual NIC. (See reference...) Figure 2 , Figure 2This is a topology diagram of a traffic processing system based on virtual network interface cards (NICs). The system includes a traffic acquisition module, a traffic processing module, virtual NICs, a traffic analysis module, and a module management module. The module management module is used for interface standardization and configuration center and policy distribution. Specifically, interface standardization can include defining virtual NIC naming, defining raw data packet capture methods, defining monitoring indicator specifications for the traffic analysis module, and defining the connection between the acquisition interface of preset analysis tools and the target virtual NIC, ensuring interoperability between modules. The configuration center and policy distribution provide configuration management components for distributing processing links (processing operations), traffic filtering rules, and rules for determining key materials and target virtual NICs.

[0072] Specifically, traffic source devices are various entities that generate network traffic, including physical devices, virtual devices, and edge terminals. Physical devices can be PCs, servers, and switches; virtual devices can be virtual machines (VMs), containers, etc.; and edge terminals can be industrial controllers, Internet of Things (IoT) devices, etc. Raw data packets are unprocessed data packets generated by traffic source devices during network interactions, and can contain complete link layer, network layer, transport layer, and application layer payloads. Optionally, raw data packets can be Layer 2 or Layer 3 data packets. Raw data packets also include metadata, such as timestamps, collection point information, original interface information, and VLAN tags, for downstream processing and traceability. Pre-configured transmission protocols are pre-configured network protocols used to transmit raw data packets, requiring reliability or efficiency. The protocol can be selected based on the scenario; for example, Transmission Control Protocol (TCP) can be used for cross-segment transmission, while User Datagram Protocol (UDP) can be used for transmission within a local area network. The default transport protocols can also include Virtual eXtensible Local Area Network (VXLAN), Generic Routing Encapsulation (GRE), Transport Layer Security (TLS), Internet Protocol Security (IPSec), and Google Remote Procedure Call (gRPC). Traffic processing nodes are independent entities with data processing capabilities (such as servers, virtual machines, or dedicated processing devices) used to perform standardized processing on raw data packets. They allow for progressive transformation and filtering of traffic according to policy chains, and their main functions include protocol adaptation, packet decryption, packet modification, and traffic filtering.

[0073] In some embodiments, capture tools can be deployed on traffic source devices (such as physical switches, virtual switches, or container runtimes). For example, physical switches can copy specified link traffic to the physical network interface card of the processing node by configuring mirror ports. Virtual environments (such as Open vSwitch) can export VXLAN traffic between virtual machines / containers through flow table rules. In container scenarios, extended Berkeley Packet Filter (eBPF) probes can be used to directly capture kernel-mode packets, avoiding user-mode performance loss, thereby capturing raw packets. The captured raw packets (including Layer 2 / Layer 3 headers) are encapsulated using a preset transport protocol (such as TLS-encrypted gRPC, VXLAN, or GRE) and transmitted to the traffic processing node through an encrypted channel. After receiving the packets, the traffic processing node first decapsulates and verifies their integrity, and then temporarily stores the raw packets in a buffer queue, completing the collection and transmission of raw traffic. By accurately capturing and standardizing transmission at the source, a data foundation is laid for building a unified, compatible, and scalable analysis system.

[0074] Optionally, the steps of capturing raw data packets from the traffic source device include:

[0075] Raw data packets are obtained from at least one traffic acquisition source on the traffic source device, including port mirroring of physical network switches, network splitters, virtual switches, and traffic acquisition probes deployed on the traffic source device;

[0076] The original data packet is an Ethernet frame containing a complete data link layer header.

[0077] Specifically, traffic acquisition sources are physical or logical devices / components used to acquire raw data packets, and include various types, such as port mirroring (SPAN) of physical network switches, network splitters (TAP), virtual switches, and traffic acquisition probes. Among them, port mirroring (SPAN / Port Mirroring) of physical network switches copies the inflow / outflow traffic of a specified port to the monitoring port by configuring the physical switch, thereby collecting the traffic of wired links; network splitters (TAPs) are hardware devices that can be connected in series in physical network links, and can copy bidirectional traffic flowing through the link, often used for high-bandwidth backbone link collection; virtual switches are logical switches in virtualization environments (such as KVM, VMware), and can be open-source virtual switches (Open Virtual Switch, Open vSwitch), Linux Bridge, VMware vSphere Distributed Switch (VMware vDS), which can collect east-west traffic between virtual machines (VMs) and containers by configuring port mirroring or traffic mirroring rules; traffic collection probes are software modules deployed on traffic source devices (such as servers, terminals), such as packet capture tools based on eBPF and dedicated agents, which can directly capture the traffic sent / received by the device itself. The Ethernet frame with a complete data link layer header is a data packet format conforming to the IEEE 802.3 standard, containing link layer fields such as destination MAC address, source MAC address, frame type / length, and VLAN tag (optional) to ensure that the original data packet retains the original identification information transmitted at the underlying layer.

[0078] For example, the system obtains raw data packets from at least one traffic acquisition source associated with the traffic source device, based on the actual network environment. For physical networks, the port mirroring (SPAN) function of the physical network switch can be used to copy traffic from the service port to the monitoring port, and / or, passive network splitter (TAP) hardware can be used to physically split the network link and divert the copied traffic. In virtualization or cloud environments, the mirroring policy of virtual switches (such as Open vSwitch, Linux Bridge, or VMware vDS) can be configured to capture east-west communication traffic between virtual machines or containers. For scenarios involving terminal devices, edge nodes, or where network devices cannot be configured, a lightweight traffic acquisition probe (Agent) can be deployed locally on the traffic source device. This traffic acquisition probe is based on the underlying operating system mechanism, such as Linux's AF_PACKET socket, eBPF program, or Windows' Npcap driver, to directly capture raw frames on the local network card. Multiple acquisition sources are used to obtain raw data packets, all of which are Ethernet frames containing complete data link layer headers, including destination MAC address, source MAC address, frame type / length, VLAN tag, and frame check sequence. The raw data packets are then aggregated to the acquisition agent, achieving comprehensive and complete acquisition of traffic from multiple scenarios. This provides comprehensive and complete underlying traffic data for subsequent transmission to traffic processing nodes, covering traffic from physical and virtual scenarios, ensuring the integrity of the raw data packets, and providing a foundation for subsequent link layer processing.

[0079] Optionally, the step of transmitting the raw data packets to the traffic processing node via a preset transmission protocol includes:

[0080] Perform authentication and access control checks on the original data packets to obtain the original data packets that pass the checks;

[0081] The original data packets that pass the verification are transmitted to the traffic processing node through a preset transmission protocol, which is at least one of the tunnel protocol and remote call protocol.

[0082] Optionally, the step of transmitting the raw data packets to the traffic processing node via a preset transmission protocol includes:

[0083] Perform authentication and access control checks on the original data packets to obtain the original data packets that pass the checks;

[0084] The original data packet that has passed verification is encrypted based on the TLS protocol to obtain the encrypted original data packet;

[0085] The encrypted raw data packets are transmitted to the traffic processing node using a preset transmission protocol, which is at least one of a tunneling protocol or a remote call protocol.

[0086] Specifically, identity authentication refers to the mechanism for verifying the legitimacy of the sender (collection source) and receiver (traffic processing node) of the original data packet, such as key-based authentication and digital certificate verification, to ensure that both parties are authorized entities. Access control verification is based on preset permission rules, such as role permissions, to check whether the sender has the authority to transmit data to the processing node and to block data packets from illegal sources. The TLS protocol is an encryption protocol used to provide confidentiality and data integrity between two communicating applications. It negotiates encryption algorithms through a handshake process and performs symmetric encryption on the data to prevent eavesdropping during transmission. Preset transmission protocols are pre-configured network protocols used to carry encrypted data packets, including tunneling protocols and remote call protocols. Tunneling protocols are protocols that establish private communication channels in public networks through encapsulation technology, such as GRE, VXLAN, and IPsec, and are suitable for transmission across public networks or heterogeneous networks. Remote call protocols allow different nodes to call services over the network, such as gRPC, HTTP / 2, and WebSocket, which transmit in the form of structured message streams, making it easy to carry metadata, support flow control and retries, and are suitable for efficient data interaction between nodes in a distributed architecture.

[0087] For example, the original data packets are first authenticated and access controlled. The sending end submits its device certificate or pre-shared key to the traffic processing node. The processing node verifies the legitimacy of the sender's identity and checks whether the sender's address is on the authorized whitelist. Only original data packets that pass the double verification proceed to the next step. Subsequently, the verified original data packets are encrypted using the TLS protocol. The sending end and the processing node complete a TLS handshake, negotiating encryption algorithms such as AES (Advanced Encryption Standard) and a session key. The session key is used to symmetrically encrypt the original data packets, and a message authentication code is generated to ensure integrity. Finally, the encrypted data packets are sent to the traffic processing node via a preset transport protocol, which can be a tunneling protocol (such as VXLAN, GRE, or TLS) or a remote procedure call protocol (such as gRPC based on HTTP / 2). Upon receiving the data, the processing node first decrypts it using TLS, then verifies the message authentication code, and stores the data in a buffer after confirming its integrity. In the process of securely and reliably transmitting raw data packets from the collection end to the traffic processing node, identity authentication, access control and encryption mechanisms are introduced, and secure tunneling transmission across the network is achieved through standardized preset transmission protocols to ensure that traffic is not eavesdropped, tampered with or forged during transmission. At the same time, it supports stable delivery in complex network environments, providing a reliable, complete and compliant data source for subsequent analysis.

[0088] Step 102: In the traffic processing node, perform at least one processing operation on the original data packet to obtain a processed standardized Layer 2 data packet. The processing operations include protocol adaptation, data packet decryption, data packet modification, and traffic filtering.

[0089] Specifically, protocol adaptation refers to converting raw data packets into a target protocol format that the traffic analysis module can parse. Data packet decryption refers to decrypting encrypted raw data packets (such as HTTPS and IPsec encrypted traffic) using a preset key or certificate to restore the plaintext payload. Data packet modification refers to adjusting the content of data packets according to business needs, such as correcting checksums, adding metadata (such as collection timestamps), removing sensitive fields (such as user privacy information), and fragmenting data packets as needed to ensure compatibility with the existing equipment architecture. Traffic filtering is based on rules, such as source / destination MAC, VLAN ID, and traffic type, filtering data packets, retaining traffic that meets analysis requirements, and discarding redundant or irrelevant data. Standardized Layer 2 data packets are Ethernet frames in a unified format, containing a complete and standardized link layer header (source MAC, destination MAC, VLAN tag, etc.) and a processed payload, which can be directly recognized by analysis tools.

[0090] In some embodiments, the original data packets are protocol adapted and converted into Ethernet frames containing standardized MAC addresses and VLAN tags; the encrypted data packets are decrypted using the corresponding key to restore the plaintext payload; the data packets are modified as needed, such as correcting checksums, adding metadata, or removing sensitive fields; traffic is filtered based on rules such as source / destination MAC addresses and VLAN IDs, retaining valid data. After one or more of the above operations, standardized Layer 2 data packets are output, which can be subsequently written to virtual network interface cards and directly processed by general analysis tools, thereby achieving unified compatibility and efficient analysis of heterogeneous traffic. By centrally performing protocol adaptation, decryption, modification, and filtering operations at the traffic processing node, raw data packets from heterogeneous sources with different formats are uniformly converted into standardized Layer 2 data packets that conform to the standard Ethernet frame structure and can be directly consumed by general analysis tools. This decouples input diversity from output consistency, thereby significantly improving the compatibility, accuracy, and efficiency of downstream analysis.

[0091] Optionally, the steps of performing at least one processing operation on the original data packet to obtain the processed normalized Layer 2 data packet include:

[0092] Perform traffic filtering on the original data packets to obtain filtered data packets;

[0093] The filtered data packets are encapsulated into standardized Layer 2 data packets.

[0094] Optionally, the steps of performing at least one processing operation on the original data packet to obtain the processed normalized Layer 2 data packet include:

[0095] Perform protocol adaptation on the original data packets, converting heterogeneous protocol data packets into adapted data packets of the target format;

[0096] The adaptation data packet is encapsulated into a standardized Layer 2 data packet.

[0097] Optionally, the steps of performing at least one processing operation on the original data packet to obtain the processed normalized Layer 2 data packet include:

[0098] Decrypt the original data packet to obtain the decrypted plaintext data packet.

[0099] Encapsulate plaintext data packets into standardized Layer 2 data packets.

[0100] Optionally, the steps of performing at least one processing operation on the original data packet to obtain the processed normalized Layer 2 data packet include:

[0101] Modify the original data packet to obtain the corresponding modified data packet;

[0102] The modified data packet is encapsulated into a standardized Layer 2 data packet.

[0103] Optional, see reference Figure 3 The steps to perform at least one processing operation on the original data packet to obtain the processed, standardized Layer 2 data packet include:

[0104] Step 301: Perform traffic filtering on the original data packets to obtain filtered data packets;

[0105] Step 302: Perform protocol adaptation on the filtered data packets, converting the filtered data packets into adapted data packets of the target format;

[0106] Step 303: Decrypt the adapted data packet to obtain the decrypted plaintext data packet;

[0107] Step 304: Modify the plaintext data packet to obtain the corresponding modified data packet;

[0108] Step 305: Encapsulate the modified data packet into a standardized Layer 2 data packet.

[0109] Step 103: Determine the target virtual network interface card (NIC) corresponding to the standardized Layer 2 data packet, and write the standardized Layer 2 data packet to the target virtual NIC.

[0110] Specifically, the virtual network interface card (NIC) type supports common virtual interface types such as TAP (Tap Interface) and TUN (Tunnel Interface). It also supports creating multiple virtual NICs based on tenants, analysis tasks, or policies, enabling multi-tenant isolation through network namespaces, container network isolation, or VLAN tags. Virtual NICs are TAP (or TUN, but TAP is used here for Layer 2) devices created on traffic processing nodes, such as tap0, tap1, and tap2. In Linux, a TAP device is represented as a character device named / dev / net / tun. User-space programs can write Ethernet frames to it via file descriptors. After writing, the system kernel treats it as "traffic received from this virtual NIC," and any packet capture tool bound to this interface can capture it. The target virtual NIC refers to the specific TAP device dynamically selected for writing based on routing policies. Common policies may include tenant isolation, load balancing, function orientation, and session affinity. Tenant isolation refers to writing different customer traffic to different TAPs (e.g., tenantA writes to tap0, tenantB writes to tap1); load balancing can refer to round-robin or hash distribution to multiple TAPs for consumption by multiple analytics instances; function orientation can write data packets of different functions to different virtual network interfaces, such as the rule engine using tap0, the machine learning model using tap1, the auditing system using tap2, etc.; session affinity means that the same TCP session is always written to the same TAP to avoid fragmentation errors.

[0111] In some embodiments, the traffic processing node pre-creates multiple TAP-type virtual network interfaces (such as tap0, tap1, etc.) and registers them as standard network interfaces in the system. When a standardized Layer 2 packet is generated, the system dynamically determines the target virtual network interface to which the standardized Layer 2 packet should be written according to a preset strategy. Subsequently, through the TAP driver interface provided by the system, the standardized Layer 2 packet is written to the file descriptor of the corresponding virtual network interface in the form of a raw Ethernet frame. After writing, the kernel network stack regards it as real traffic received from the virtual interface, so that the analysis tools (such as Snort, Suricata) bound to the interface can capture and process the packet through the standard packet capture mechanism without any modification, achieving multi-path distribution, load balancing and logical isolation, while maintaining full compatibility with existing analysis tools (such as Snort, Suricata, Zeek).

[0112] Step 104: Connect the acquisition interface of the preset analysis tool to the target virtual network card, and perform analysis operations on the standardized Layer 2 data packets through the preset analysis tool to obtain the corresponding data analysis results.

[0113] Specifically, the preset analysis tools are pre-selected and deployed general-purpose traffic analysis software, such as Intrusion Detection Systems (IDS), Intrusion Prevention Systems (IPS) (e.g., Snort, Suricata), network analyzers (Zeek / Bro), forensic tools (e.g., Wireshark / tshark), or self-developed detection engines. The data acquisition interface is the input channel used by the analysis tool to receive network data packets. In Linux / Windows systems, it can be bound to a specific network interface (e.g., tap0, tap1) through libraries such as libpcap, AF_PACKET, and WinPcap / Npcap. Analysis operations refer to the deep inspection performed on data packets by the analysis tool, such as rule matching (intrusion detection), protocol parsing (extracting HTTP headers), and traffic statistics (calculating bandwidth usage). Data analysis results are the conclusive information output by the analysis tool, such as intrusion alarms, protocol field parsing results, and traffic trend reports.

[0114] In some embodiments, one or more TAP-type virtual network interface cards (such as tap0, tap1, etc.) have been created on the traffic processing node, which appear as standard Layer 2 network devices in the system. Acquisition parameters are configured for a preset analysis tool (e.g., Snort, Suricata, Zeek, or a self-developed detection engine), specifying that the tool's acquisition interface is bound to the target virtual network interface card. Using the tool's built-in network interface selection function, the target virtual network interface card is set as the sole data source. The analysis tool registers monitoring permissions for this virtual network interface card through low-level capture libraries such as libpcap, ensuring real-time acquisition of incoming data packets. Subsequently, when standardized Layer 2 data packets are written to the target virtual network interface card, the analysis tool captures these packets in real-time through the acquisition interface and calls its built-in parsing engine to perform analysis operations. For example, IDS / IPS performs pattern matching on packet payloads based on a predefined rule base to detect whether they contain attack characteristics (such as malicious code or abnormal commands); protocol analyzers can parse the link layer, network layer, and transport layer header information of standardized Layer 2 packets layer by layer, extracting key fields such as MAC address, IP address, and port number, and deeply analyze application layer protocols (such as HTTP request headers and response codes); traffic statistics tools can calculate indicators such as bandwidth usage, number of sessions, and packet distribution based on information such as timestamps and lengths of standardized Layer 2 packets. Pre-defined analysis tools summarize key information generated during the analysis process (such as intrusion alarms, protocol field details, and traffic trend charts) into structured data analysis results, outputting them to local logs, management platforms, or related systems. By fully utilizing the capabilities of existing analysis tools and achieving "plug-and-play" integration through standard virtual network cards, custom development of the analysis engine is avoided, significantly reducing system coupling and maintenance costs. Simultaneously, multiple tools can consume the same traffic in parallel, improving overall detection coverage and analysis flexibility, and ensuring the accuracy and efficiency of the analysis results.

[0115] Based on the traffic processing method based on virtual network interface cards (NICs) provided in this application, raw data packets are captured from the traffic source device and transmitted to the traffic processing node via a preset transmission protocol, ensuring the integrity and security of the traffic during transmission. At the traffic processing node, at least one processing operation is performed on the raw data packets to obtain processed standardized Layer 2 data packets. These processing operations include protocol adaptation, data packet decryption, data packet modification, and traffic filtering. The target virtual NIC corresponding to the standardized Layer 2 data packets is determined, and the standardized Layer 2 data packets are written to the target virtual NIC. The acquisition interface of a preset analysis tool is connected to the target virtual NIC, and the preset analysis tool performs analysis operations on the standardized Layer 2 data packets to obtain corresponding data analysis results. The analysis tool requires no code modification; its acquisition interface only needs to be configured to the target virtual NIC so that the analysis tool can automatically receive, parse, and generate data analysis results of standardized Layer 2 data packets, just like processing traffic from a local physical NIC. This solves the technical problems of poor compatibility and scalability in existing traffic analysis and processing methods, improves the flexibility of traffic processing, supports on-demand expansion of processing functions, and achieves unified standardization of multiple types of traffic, thereby adapting to traffic analysis and processing tasks in different deployment scenarios.

[0116] Optional, see reference Figure 4To achieve transparent decryption and security analysis of HTTPS protocol traffic on the internal network, the system can adopt an architecture of edge acquisition + central decryption + virtual interface delivery. Specifically, a lightweight traffic acquisition probe (agent-client) is deployed on the business server running HTTPS services on the intranet. This traffic acquisition probe works in two ways: firstly, it uses the underlying packet capture mechanism of the operating system to capture raw TLS encrypted traffic on a specified network card in real time; secondly, it intercepts key functions of encryption libraries such as OpenSSL and BoringSSL called by the business process through dynamic library injection or function hooking technology, extracting the master key or session ticket used by the TLS session and other key materials required for decryption. Subsequently, the agent-client associates the captured raw encrypted data packets with the corresponding key materials and securely transmits them to the processing server (agent-server) deployed on security products (such as IDS / IPS devices) through a two-way authenticated encrypted gRPC channel. After receiving the data, the agent-server performs a standard RFC 5077-compliant decryption operation on each TLS stream according to the key, restores the complete HTTP plaintext request and response content, and repackages it into a standardized Layer 2 data packet. Finally, the standardized Layer 2 data packet is written to a pre-created virtual TAP interface (such as tap1). At this point, the traffic analysis module of the existing IDS system requires no code modification or configuration reconstruction. It only needs to point its collection interface to tap1 (for example, setting the startup parameter to -i tap1) to process ordinary plaintext traffic, directly receiving and analyzing decrypted HTTP content, thereby achieving effective detection of internal network encryption threats. The entire process is completely non-intrusive to the existing security product architecture, significantly reducing integration complexity and operational risks.

[0117] Optional, see reference Figure 5To achieve comprehensive visualization and security analysis of east-west traffic between containers in a cloud-native environment, the system can adopt a lightweight collection architecture based on node-side probes and virtual network interface card delivery. Specifically, firstly, a traffic acquisition probe (agent-client) is deployed on each worker node of the Kubernetes cluster. This traffic acquisition probe runs as a DaemonSet and directly monitors the virtual network interface cards used for inter-container communication using eBPF or AF_PACKET technology by sharing the host network namespace or mounting a veth pair peer interface, capturing raw Layer 2 packets of Pod-to-Pod communication in real time. Subsequently, the traffic acquisition probe (agent-client) aggregates the captured traffic by flow and uploads it to the processing server (agent-server) on a centrally deployed analysis platform (such as an IDS device) via a pre-defined gRPC protocol. After receiving the data, the agent-server performs standardization processing on the raw packets, including completing missing Ethernet frame headers (such as filling in default MAC addresses), removing redundant encapsulation (such as CNI-specific headers), and writing the processed standardized Layer 2 packets to the corresponding virtual network interface card (TAP) according to a policy (such as by namespace or application tag). Finally, the traffic analysis module binds its acquisition interface to the corresponding virtual network interface card (TAP) device, enabling it to transparently receive and parse short-term, high-frequency east-west communication traffic between containers. This effectively overcomes the limitations of traditional reliance on physical switch port mirroring, directly capturing inter-container interaction data through node-level probes to ensure that short-term, high-frequency east-west traffic is not lost; and achieves seamless integration of traffic and analysis modules with the virtual network interface card (TAP), enabling visualization and analysis of container traffic without modifying analysis tools, clearly presenting the communication relationships, protocol types, and data interaction characteristics between containers, providing complete data support for traffic monitoring and security analysis in cloud-native environments.

[0118] In some embodiments, when the processing operations include protocol adaptation and packet decryption, the step of performing at least one processing operation on the original data packet to obtain a processed standardized Layer 2 data packet includes:

[0119] In response to the fact that the original data packet is a heterogeneous protocol data packet encapsulated by a preset transmission protocol, the heterogeneous protocol data packet is decapsulated and converted into an adapted data packet of the target format.

[0120] In response to the original data packet being an encrypted data packet, obtain the session key corresponding to the encrypted original data packet;

[0121] The adapted data packet is decrypted based on the session key to obtain the decrypted plaintext data packet. The session key is at least one of RSA private key, ECDH private key or TLS temporary key.

[0122] Encapsulate plaintext data packets into standardized Layer 2 data packets.

[0123] Specifically, heterogeneous protocol data packets are data packets encapsulated using non-Ethernet protocols. These non-Ethernet protocols can include Point-to-Point Protocol (PPP), Asynchronous Transfer Mode (ATM), and VXLAN. The link layer format of data packets encapsulated using non-Ethernet protocols differs from that of Ethernet frames. The target format adapted data packets are data packets conforming to the Ethernet protocol specification, containing complete source / destination MAC addresses, frame type, and other link layer fields. The session key is the key material used to decrypt TLS sessions and can include RSA private keys, ECDH private keys, or TLS ephemeral keys.

[0124] When processing operations simultaneously involve protocol adaptation and packet decryption, as an example, the traffic processing node first determines whether the received raw data packet is a heterogeneous protocol data packet encapsulated by a preset transport protocol (such as gRPC, VXLAN, or a custom UDP tunnel). If so, it performs a decapsulation operation, stripping the outer tunnel header, extracting the inner payload, and performing protocol adaptation according to the target format requirements, such as completing the standard Ethernet MAC header for raw IP packets to generate adapted data packets. Subsequently, the system further determines whether the adapted data packet is encrypted traffic such as TLS. If so, it obtains the corresponding session key, which can be a pre-configured RSA private key, ECDH private key, or a TLS temporary key uploaded by the acquisition probe. Based on this session key, a cryptographic library (such as OpenSSL) can be called to perform a standard TLS decryption process on the encrypted data packet, restoring plaintext application layer data such as HTTP and DNS, forming a decrypted plaintext data packet. This plaintext data packet is then re-encapsulated into a standard Ethernet frame containing the complete source / destination MAC address and the correct EtherType field, i.e., a standardized Layer 2 data packet. By converting encrypted traffic from heterogeneous protocols into plaintext Layer 2 data packets in a unified format, end-to-end parsing of tunneled encrypted traffic is achieved. This transforms complex traffic that was originally invisible and unreadable into plaintext standard frames that can be directly processed by general analysis tools without modifying their core engine. This significantly improves the ability to perform deep detection and threat discovery of encrypted east-west traffic in cloud-native and zero-trust scenarios.

[0125] In some embodiments, where the processing operation further includes traffic filtering, before the step of decapsulating the heterogeneous protocol data packet in response to the original data packet being a heterogeneous protocol data packet encapsulated with a preset transport protocol, the method further includes:

[0126] Obtain traffic filtering rules, which include static rules and dynamic rules. Static rules include fixed filtering conditions based on source media access control MAC address range, destination MAC address range, port number, and protocol type. Dynamic rules include dynamic filtering conditions based on packet priority and business scenario.

[0127] Parse the attribute information of the original data packet. The attribute information includes at least one of the following: source MAC address, destination MAC address, transmission port, transmission protocol type, data packet priority identifier, and service scenario identifier.

[0128] The attribute information of the original data packet is matched and verified with the static and dynamic rules respectively. If the attribute information meets the filtering conditions that need to be retained in the static and dynamic rules, the original data packet is retained.

[0129] If the attribute information meets the filtering conditions for discarding in static or dynamic rules, the original data packet is discarded.

[0130] To improve processing efficiency and focus on critical traffic, a refined traffic filtering operation is first performed before decapsulating heterogeneous protocol data packets encapsulated with a preset transmission protocol. As an example, traffic filtering rules are first obtained from the configuration center. Static rules include fixed conditions based on source / destination MAC address ranges, port numbers, and protocol types (e.g., only retaining traffic with MAC prefixes of 00:1A:2B, port 443, and TCP protocol). Dynamic rules include dynamic conditions based on data packet priority and business scenario (e.g., financial transaction identifiers). Next, the attribute information of the original data packets is parsed, extracting features such as source / destination MAC addresses, transmission ports, protocol types, priority identifiers, and business scenario identifiers. Then, the attribute information is matched and verified against the static and dynamic rules respectively: if the retention conditions of both types of rules are met simultaneously (e.g., MAC in a specified range, port 443 with high priority, and belonging to a financial scenario), the data packet is retained and proceeds to the subsequent decapsulation stage; if the discard conditions of either rule are met (e.g., MAC in a blacklist, low priority), it is directly discarded without consuming further computing resources. Before performing protocol decapsulation, the original data packets are subjected to fine-grained traffic filtering to effectively avoid decapsulation and decryption operations on irrelevant traffic (such as heartbeat packets, broadcast packets, and non-target business flows), significantly reducing system load. At the same time, it ensures that security analysis resources are concentrated on high-value, high-risk critical business traffic, improving overall detection accuracy and response efficiency.

[0131] In some embodiments, where the processing operation further includes data packet modification, the step of encapsulating plaintext data packets into standardized Layer 2 data packets includes, prior to:

[0132] Parse the structural information of the plaintext data packet to determine the target field to be modified. The target field includes the header field of the plaintext data packet and / or the payload. The header field includes at least one of the following: source MAC address, destination MAC address, VLAN tag, and protocol type identifier.

[0133] Modify the target field of a plaintext data packet to obtain the corresponding modified data packet. The modification operation includes at least one of adding, deleting, replacing, or reorganizing.

[0134] If the length of the modified data packet exceeds the preset length, the modified data packet is fragmented to obtain the corresponding fragmented data packet;

[0135] Fragmented data packets are encapsulated into standardized Layer 2 data packets.

[0136] Specifically, the modification operation involves adjusting the target fields, such as adding metadata fields, deleting sensitive information, replacing incorrect MAC addresses, and reordering payloads. The preset length is the pre-set Maximum Transmission Unit (MTU), typically 1500 bytes for Ethernet. Fragmentation processing involves splitting excessively long data packets according to the MTU, adding fragment identifiers and sequence numbers, and ensuring that the receiving end can reassemble them.

[0137] When processing involves data packet modification, before encapsulating the plaintext data packet into a standardized Layer 2 data packet, as an example, after receiving the decrypted plaintext data packet, the structural information of the plaintext data packet is parsed, and the link layer header (source / destination MAC address, VLAN tag, protocol type identifier, etc.) and payload are extracted. The target fields to be modified are determined according to preset rules, such as adding VLAN tags for specific traffic or deleting sensitive information from the payload. Then, modification operations are performed on the target fields, such as adding metadata fields (e.g., collection timestamp), deleting user privacy data from the payload, replacing incorrect MAC addresses, or reordering the application layer payload, generating a modified data packet. If the length of the modified data packet exceeds a preset MTU (e.g., 1500 bytes for Ethernet), the data packet is split according to this length, and fragment identifiers and sequence numbers are added to ensure that the receiving end can reassemble it. Finally, fields such as frame check sequence numbers are added to the modified data packet (or fragmented data packet), and it is encapsulated into a standardized Layer 2 data packet conforming to the IEEE 802.3 standard. By making targeted modifications to adapt data packets to the parsing requirements of analysis tools, supplementing key information to enhance the analysis dimensions, fragmenting ultra-long data packets to ensure transmission compliance, and finally outputting standardized data with uniform format and usable content, providing high-quality input for subsequent analysis.

[0138] In some embodiments, the step of determining the target virtual network interface card corresponding to a standardized Layer 2 data packet includes:

[0139] Parse the attribute information of the standardized Layer 2 data packets. The attribute information includes the source MAC address, destination MAC address, VLAN tag, and collection point identifier.

[0140] Based on the mapping relationship between the attribute information of standardized Layer 2 data packets and the preset attribute information of virtual network interface cards (NICs), the target virtual NIC corresponding to the attribute information is selected from multiple candidate virtual NICs.

[0141] or,

[0142] Based on the processing order of standardized Layer 2 data packets, virtual network interfaces are selected sequentially from multiple candidate virtual network interfaces, and the currently selected virtual network interface is determined as the target virtual network interface.

[0143] or,

[0144] The attribute information of the standardized Layer 2 data packets is hashed to generate the corresponding target hash value. Based on the target hash value and the hash value corresponding to each candidate virtual network interface, the virtual network interface is determined from each candidate virtual network interface through a consistent hashing algorithm. The hash value corresponding to the candidate virtual network interface is obtained by mapping the network interface identifier of the candidate virtual network interface through the hash algorithm.

[0145] Specifically, the attribute information-virtual network interface card (NIC) mapping relationship follows preset matching rules, such as "VLAN tag=100 written to tap0" and "collection point A written to tap1," used for statically binding specific attribute traffic to virtual NICs. Candidate virtual NICs are multiple virtual NICs pre-created on the traffic processing node, serving as optional targets for traffic distribution. Hash transformation is the process of converting packet attribute information into a fixed-length hash value using a hash algorithm (such as MD5). The consistent hashing algorithm maps the candidate virtual NIC identifier (such as "tap0") to a [0, 2³²) ring using a hash function (such as SHA-1), hashes the packet attribute information in the same way, and then finds the first virtual NIC node clockwise as the target.

[0146] As an example, the traffic processing node performs attribute parsing on the standardized Layer 2 packets that have been processed, extracting key metadata, including source MAC address, destination MAC address, VLAN tag, and collection point identifier injected by the collection probe (such as "node-prod-01" or "tenant-A"). Subsequently, the system selects one of the following methods to determine the target virtual network interface according to a preset strategy. Specifically, the first is a rule-based mapping mode, where the system loads pre-configured attribute information—a virtual network interface mapping table (e.g., "VLAN tag=100 written to tap0", "collection point A written to tap1")—and filters out the uniquely corresponding target TAP interface by matching the packet's attribute information. The second is a round-robin distribution mode, suitable for stateless load balancing scenarios. The system sequentially selects the next candidate virtual network interface from the list (e.g., tap0, tap1, tap2, etc.) as the target according to the order in which the packets were processed, ensuring that the load is evenly distributed among the analysis instances. The third method is consistent hashing. The system performs a hash operation (such as SHA-1) on the attribute information of the data packets (e.g., source / destination MAC + VLAN combination) to generate a target hash value. Simultaneously, the network interface identifier (e.g., "tap0") of each candidate virtual network interface is mapped to a ring hash space using the same hash algorithm. Then, based on the consistent hashing algorithm, the virtual network interface node closest to the target hash value is searched clockwise as the final target. This method only affects traffic within a small hash range when adding or removing TAP devices, maximizing session affinity and preventing the same TCP flow from being distributed to different analysis engines. Regardless of the mode used, the selected target virtual network interface is used for subsequent write operations, allowing analysis tools (such as IDS and Zeek) bound to that target virtual network interface to transparently receive the corresponding traffic. By employing multiple strategies to achieve precise or balanced traffic distribution, the system meets the specific traffic needs of different analysis tools, balances the load, adapts to dynamic expansion, and ensures efficient integration of standardized data packets with analysis tools.

[0147] In some embodiments, the step of performing analysis operations on standardized Layer 2 data packets using a preset analysis tool to obtain the corresponding data analysis results includes:

[0148] Based on the analysis logic corresponding to the preset analysis tool, the standardized Layer 2 data packets are analyzed and processed to generate corresponding data analysis results.

[0149] The target virtual network interface card is configured to support concurrent monitoring and analysis by multiple preset analysis tools, including Snort, Suricata, and Zeek.

[0150] Specifically, the traffic processing node writes standardized Layer 2 data packets to the target virtual network interface card (e.g., tap0). The target virtual network interface card is configured in the operating system to support multi-process concurrent monitoring. Multiple pre-defined analysis tools (e.g., Snort, Suricata, Zeek) can be bound to the same virtual network interface card simultaneously, each independently receiving complete copies of the data packets through a standard packet capture interface (e.g., libpcap). Each tool, based on its built-in analysis logic—such as Snort's rule matching, Suricata's multi-threaded deep detection, and Zeek's protocol reconstruction and log generation—executes parsing and detection in parallel without interference. The system kernel or TAP driver ensures that each monitoring process can acquire the full traffic volume, achieving one-write-many-read; finally, each tool outputs its corresponding data analysis results (e.g., alarm logs, session records, threat scores). Utilizing the concurrent support capabilities of the virtual network interface card, parallel analysis of the same traffic by multiple tools is achieved, combining the advantages of different tools to improve detection comprehensiveness, without requiring coordination between tools, simplifying deployment while ensuring analysis efficiency and depth.

[0151] As an example, after completing the decapsulation, decryption, filtering, modification, and standardization of the raw data packets, the traffic processing node writes the generated standardized Layer 2 data packets into one or more pre-created virtual network interface cards (NICs). The virtual NIC interface can behave as a standard network device in the system, equivalent to a physical NIC. Various analysis tools require no code modification; they only need to specify the collection interface as the corresponding virtual NIC in their startup configuration or command-line parameters to transparently receive traffic through standard packet capture interfaces such as libpcap and AF_PACKET, just like monitoring a local physical NIC. These analysis tools can include open-source IDS / IPS such as Snort and Suricata, protocol analyzers like Zeek, forensic tools like Wireshark, or self-developed detection engines. To support multi-channel parallel analysis, a traffic replication mechanism can be used to synchronously send data streams from the same virtual NIC to multiple analysis instances, or the same data stream can be directed to different engines based on routing rules. For example, traffic can be simultaneously sent to a rule engine for feature matching, a machine learning detection module for abnormal behavior analysis, and a traffic recording module for storing raw data, achieving multi-engine parallel processing. The traffic analysis process described above achieves seamless integration between the analysis tool and standardized traffic, preserving the original functional logic of the tool while supporting diverse analysis scenarios through a flexible distribution mechanism. This significantly reduces the tool adaptation cost and improves the comprehensiveness and efficiency of traffic analysis.

[0152] It should be noted that the above examples are only for understanding this application and do not constitute a limitation on the traffic processing method based on the virtual network card in this application. Any simple modifications based on this technical concept are within the protection scope of this application.

[0153] This application also provides a traffic processing device based on a virtual network interface card (NIC), please refer to... Figure 6 Traffic processing devices based on virtual network interface cards include:

[0154] The acquisition module 601 is used to capture raw data packets from the traffic source device and transmit the raw data packets to the traffic processing node through a preset transmission protocol;

[0155] Processing module 602 is used to perform at least one processing operation on the raw data packet in the traffic processing node to obtain the processed standardized Layer 2 data packet. The processing operation includes protocol adaptation, data packet decryption, data packet modification and traffic filtering.

[0156] The writing module 603 is used to determine the target virtual network interface card (NIC) corresponding to the standardized Layer 2 data packet and write the standardized Layer 2 data packet to the target virtual NIC.

[0157] The analysis module 604 is used to connect the acquisition interface of the preset analysis tool to the target virtual network card, and perform analysis operations on the standardized Layer 2 data packets through the preset analysis tool to obtain the corresponding data analysis results.

[0158] The traffic processing device based on a virtual network interface card (NIC) provided in this application, employing the traffic processing method based on a virtual NIC in the above embodiments, can solve the technical problems of poor compatibility and scalability of existing traffic analysis and processing methods. Compared with the prior art, the beneficial effects of the traffic processing device based on a virtual NIC provided in this application are the same as those of the traffic processing method based on a virtual NIC provided in the above embodiments, and other technical features in the traffic processing device based on a virtual NIC are the same as those disclosed in the methods of the above embodiments, and will not be repeated here.

[0159] This application provides a traffic processing device based on a virtual network interface card (NIC). The traffic processing device based on a virtual NIC includes: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, and the instructions are executed by the at least one processor to enable the at least one processor to perform the traffic processing method based on the virtual NIC in the first embodiment described above.

[0160] The following is for reference. Figure 7 This document illustrates a schematic diagram of a traffic processing device based on a virtual network interface card (NIC) suitable for implementing embodiments of this application. The traffic processing device based on a virtual NIC in these embodiments may include, but is not limited to, mobile terminals such as laptops, tablets (Portable Application Description, PADs), and in-vehicle terminals (e.g., in-vehicle navigation terminals), as well as fixed terminals such as digital TVs and desktop computers. Figure 7The traffic processing device based on the virtual network interface card shown is merely an example and should not impose any limitations on the functionality and scope of use of the embodiments of this application.

[0161] like Figure 7 As shown, a traffic processing device based on a virtual network interface card (NIC) may include a processing unit 1001 (e.g., a central processing unit, a graphics processing unit, etc.), which can perform various appropriate actions and processes according to a program stored in read-only memory (ROM) 1002 or a program loaded from storage device 1003 into random access memory (RAM) 1004. The RAM 1004 also stores various programs and data required for the operation of the traffic processing device based on the virtual NIC. The processing unit 1001, ROM 1002, and RAM 1004 are interconnected via a bus 1005. An input / output (I / O) interface 1006 is also connected to the bus. Typically, the following systems can be connected to the input / output interface 1006: input devices 1007 including, for example, touchscreens, touchpads, keyboards, mice, image sensors, microphones, accelerometers, gyroscopes, etc.; output devices 1008 including, for example, liquid crystal displays (LCDs), speakers, vibrators, etc.; storage devices 1003 including, for example, magnetic tapes, hard disks, etc.; and communication devices 1009. Communication device 1009 allows the traffic processing device based on a virtual network interface card (NIC) to exchange data wirelessly or via wired communication with other devices. Although a traffic processing device based on a virtual NIC with various systems is shown in the figure, it should be understood that it is not required to implement or possess all of the systems shown. More or fewer systems may be implemented alternatively.

[0162] Specifically, according to the embodiments disclosed in this application, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments disclosed in this application include a computer program product comprising a computer program carried on a computer-readable medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via a communication device, or installed from storage device 1003, or installed from read-only memory 1002. When the computer program is executed by processing device 1001, it performs the functions defined in the methods of the embodiments disclosed in this application.

[0163] The traffic processing device based on a virtual network interface card (NIC) provided in this application, employing the traffic processing method based on a virtual NIC in the above embodiments, can solve the technical problems of poor compatibility and scalability of existing traffic analysis and processing methods. Compared with the prior art, the beneficial effects of the traffic processing device based on a virtual NIC provided in this application are the same as those of the traffic processing method based on a virtual NIC provided in the above embodiments, and other technical features of this traffic processing device based on a virtual NIC are the same as those disclosed in the previous embodiment method, and will not be repeated here.

[0164] It should be understood that the various parts disclosed in this application can be implemented using hardware, software, firmware, or a combination thereof. In the description of the above embodiments, specific features, structures, materials, or characteristics can be combined in any suitable manner in one or more embodiments or examples.

[0165] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the technical scope disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

[0166] This application provides a computer-readable storage medium having computer-readable program instructions (i.e., a computer program) stored thereon, which are used to execute the traffic processing method based on the virtual network interface card in the above embodiments.

[0167] The computer-readable storage medium provided in this application may be, for example, a USB flash drive, but is not limited to, electrical, magnetic, optical, electromagnetic, infrared, or semiconductor systems, devices, or any combination thereof. More specific examples of computer-readable storage media may include, but are not limited to: electrical connections having one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM), optical fibers, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof. In this embodiment, the computer-readable storage medium may be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, system, or device. The program code contained on the computer-readable storage medium may be transmitted using any suitable medium, including but not limited to: wires, optical cables, RF (Radio Frequency), etc., or any suitable combination thereof.

[0168] The aforementioned computer-readable storage medium may be included in a traffic processing device based on a virtual network interface card (NIC); or it may exist independently and not be assembled into a traffic processing device based on a virtual NIC.

[0169] The aforementioned computer-readable storage medium carries one or more programs. When these programs are executed by a traffic processing device based on a virtual network interface card (NIC), the traffic processing device based on the NIC performs the following actions: captures raw data packets from a traffic source device and transmits the raw data packets to a traffic processing node via a preset transmission protocol; at the traffic processing node, performs at least one processing operation on the raw data packets to obtain processed standardized Layer 2 data packets, including protocol adaptation, data packet decryption, data packet modification, and traffic filtering; determines the target NIC corresponding to the standardized Layer 2 data packets and writes the standardized Layer 2 data packets to the target NIC; connects the acquisition interface of a preset analysis tool to the target NIC, performs analysis operations on the standardized Layer 2 data packets through the preset analysis tool, and obtains the corresponding data analysis results.

[0170] Computer program code for performing the operations of this application can be written in one or more programming languages ​​or a combination thereof, including object-oriented programming languages ​​such as Java, Smalltalk, and C++, as well as conventional procedural programming languages ​​such as "C" or similar programming languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer can be connected to the user's computer via any type of network—including a Local Area Network (LAN) or a Wide Area Network (WAN)—or can be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0171] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of this application. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, can be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0172] The modules described in the embodiments of this application can be implemented in software or hardware. The names of the modules do not necessarily limit the functionality of the unit itself.

[0173] The readable storage medium provided in this application is a computer-readable storage medium that stores computer-readable program instructions (i.e., a computer program) for executing the above-described traffic processing method based on a virtual network interface card (NIC). This solves the technical problems of poor compatibility and scalability in existing traffic analysis and processing methods. Compared with the prior art, the beneficial effects of the computer-readable storage medium provided in this application are the same as those of the traffic processing method based on a virtual NIC provided in the above embodiments, and will not be repeated here.

[0174] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the steps of the traffic processing method based on the virtual network interface card described above.

[0175] The computer program product provided in this application can solve the technical problems of poor compatibility and scalability of existing traffic analysis and processing methods. Compared with the prior art, the beneficial effects of the computer program product provided in this application are the same as those of the traffic processing method based on virtual network cards provided in the above embodiments, and will not be repeated here.

[0176] The above description is only a part of the embodiments of this application and does not limit the patent scope of this application. All equivalent structural transformations made under the technical concept of this application and using the contents of the specification and drawings of this application, or direct / indirect applications in other related technical fields, are included in the patent protection scope of this application.

Claims

1. A method for processing traffic based on a virtual network card, characterized in that, The virtual network card-based traffic processing method comprises: Capturing original data packets from a traffic source device and transmitting the original data packets to a traffic processing node through a preset transmission protocol; In the traffic processing node, performing at least one processing operation on the original data packets to obtain processed standardized two-layer data packets, the processing operation including protocol adaptation, data packet decryption, data packet modification and traffic screening; Determining a target virtual network card corresponding to the standardized two-layer data packets and writing the standardized two-layer data packets into the target virtual network card; Connecting a collection interface of a preset analysis tool to the target virtual network card and performing an analysis operation on the standardized two-layer data packets through the preset analysis tool to obtain corresponding data analysis results; In the case where the processing operation includes the traffic screening, the protocol adaptation and the data packet decryption, the step of performing at least one processing operation on the original data packets to obtain processed standardized two-layer data packets comprises: Obtaining traffic screening rules, the traffic screening rules including static rules and dynamic rules, wherein the static rules contain fixed filtering conditions based on source media access control (MAC) address segments, destination MAC address segments, port numbers and protocol types, and the dynamic rules contain dynamic filtering conditions based on data packet priorities and service scenarios; Analyzing attribute information of the original data packets, the attribute information including source MAC addresses, destination MAC addresses, transmission ports, transmission protocol types, data packet priority identifiers and service scenario identifiers of the original data packets; Matching and checking the attribute information of the original data packets with the static rules and the dynamic rules respectively, and retaining the original data packets if the attribute information meets the filtering conditions required to be retained in the static rules and the dynamic rules; Discarding the original data packets if the attribute information meets the filtering conditions required to be discarded in the static rules or the dynamic rules; In response to the original data packets being heterogeneous protocol data packets encapsulated through the preset transmission protocol, performing decapsulation on the heterogeneous protocol data packets, converting the heterogeneous protocol data packets into adapted data packets in a target format; In response to the original data packets being encrypted data packets, obtaining a session key corresponding to the encrypted original data packets; Performing decryption processing on the adapted data packets based on the session key to obtain decrypted plaintext data packets, the session key being at least one of an RSA private key, an elliptic curve Diffie-Hellman (ECDH) private key or a TLS temporary key; Encapsulating the plaintext data packets into the standardized two-layer data packets; The step of determining the target virtual network card corresponding to the standardized two-layer data packets comprises: Hash transforming the attribute information of the standardized two-layer data packet to generate a corresponding target hash value, determining a target virtual network card from each of the candidate virtual network cards based on the target hash value and a hash value corresponding to each of the candidate virtual network cards, the hash value corresponding to each of the candidate virtual network cards being obtained by mapping a network card identifier of the candidate virtual network card through a hash algorithm.

2. The virtual network card based traffic processing method of claim 1, wherein, The step of capturing the original data packet from the traffic source device includes: obtaining the original data packet from at least one traffic collection source of the traffic source device, the traffic collection source including port mirroring of a physical network switch, a network splitter, a virtual switch, and a traffic collection probe deployed on the traffic source device; wherein the original data packet is an Ethernet frame containing a complete data link layer header.

3. The virtual network card based traffic processing method of claim 1, wherein, The step of transmitting the original data packet to the traffic processing node through a preset transmission protocol includes: performing identity authentication and access control verification on the original data packet to obtain the original data packet that passes the verification; encrypting the original data packet that passes the verification based on a transport layer security (TLS) protocol to obtain the original data packet after encryption; transmitting the original data packet after encryption to the traffic processing node through the preset transmission protocol, the preset transmission protocol being at least one of a tunneling protocol and a remote invocation protocol.

4. The virtual network card based traffic processing method of claim 1, wherein, In the case where the processing operation further includes data packet modification, before the step of encapsulating the plaintext data packet as the standardized two-layer data packet, the method further includes: parsing the structure information of the plaintext data packet to determine a target field to be modified, the target field including a header field and / or a payload of the plaintext data packet, the header field including at least one of a source MAC address, a destination MAC address, a virtual local area network (VLAN) tag, and a protocol type identifier; performing a modification operation on the target field of the plaintext data packet to obtain a corresponding modified data packet, the modification operation including at least one of addition, deletion, replacement, or reorganization; if the length of the modified data packet exceeds a preset length, performing fragmentation processing on the modified data packet to obtain a corresponding fragmented data packet; encapsulating the fragmented data packet as the standardized two-layer data packet.

5. The virtual network card based traffic processing method of claim 1, wherein, The step of determining the target virtual network card corresponding to the standardized two-layer data packet includes: parsing attribute information of the standardized two-layer data packet, the attribute information including a source MAC address, a destination MAC address, a VLAN tag, and a collection point identifier; based on a mapping relationship between the attribute information of the standardized two-layer data packet and preset attribute information-virtual network card, screening the target virtual network card corresponding to the attribute information from a plurality of candidate virtual network cards; or, according to the processing order of the standardized two-layer data packet, sequentially selecting a virtual network card from a plurality of the candidate virtual network cards in a loop, and determining the currently selected virtual network card as the target virtual network card.

6. The virtual network card based traffic processing method of claim 1, wherein, The step of performing an analysis operation on the standardized two-layer data packet through the preset analysis tool to obtain a corresponding data analysis result includes: The standardized two-layer data packet is analyzed based on analysis logic corresponding to the preset analysis tool, and a corresponding data analysis result is generated. The target virtual network card is configured to support concurrent monitoring and analysis processing of a plurality of preset analysis tools, and the preset analysis tools include Snort, Suricata, and Zeek.

7. A virtual network card based traffic processing device, comprising: The device includes a memory, a processor, and a computer program stored on the memory and executable on the processor, and the computer program is configured to implement the steps of the virtual network card-based traffic processing method according to any one of claims 1 to 6.

8. A storage medium, characterized by The storage medium is a computer-readable storage medium, and the storage medium stores a computer program. When the computer program is executed by a processor, the steps of the virtual network card-based traffic processing method according to any one of claims 1 to 6 are implemented.

Images