Distributed cross-domain plc encrypted traffic fast processing method, device and equipment

Abstract

The application discloses a kind of distributed cross-domain PLC encrypted traffic fast processing method, device and equipment, it is related to PLC controller technical field;Encrypted data frame in data packet is extracted using the first filter of physical network card driver layer and is redirected to user state processing program, using the first detection mechanism of kernel state Key negotiation process of WireGuard protocol stack is detected, and key parameter is obtained;Key parameter is sent to user state processing program using asynchronous transmission mechanism;Encrypted data frame is decrypted and checked using user state processing program and key parameter, and according to the check result, the original IP message is shunted as follows;The application can improve encryption processing efficiency, reduce system resource overhead, improve system stability.

Description

Technical Field

[0001] This invention belongs to the field of PLC controller technology, and specifically relates to a method, apparatus and device for rapid processing of encrypted traffic in distributed cross-domain PLCs. Background Technology

[0002] Traditional PLC controllers do not encrypt the transmission of control protocols, making them particularly vulnerable to attacks in large-scale, cross-domain distributed PLC deployment scenarios, such as oil pipeline transmission, multi-workshop production coordination, and cloud deployment and integration.

[0003] Encrypting information transmitted between controllers can improve security, but it inevitably increases processing overhead. Due to the complexity of encryption operations, especially key negotiation, it significantly impacts computing power, storage, and timeliness. Maximizing encryption processing efficiency is a major challenge for distributed controller deployments. Traditional TLS encryption code is complex, supports many algorithms, and has strong compatibility, resulting in relatively low performance, high security vulnerability risks, complex configuration, reliance on certificate management, and difficulty in implementing automated control in off-grid environments. It is not entirely suitable for controller devices and cannot guarantee PLC controller control latency, system load, and other parameters. It is mainly used for northbound (i.e., communication with upper-level systems) communication with programming platforms or interoperability with other IT systems. Private encryption protocols lack formal security proof and professional algorithm review, resulting in algorithm vulnerabilities, insufficient encryption strength, key leakage, replay attacks, DoS attacks, forward security issues, and many other problems, making it difficult to guarantee security between controllers. Summary of the Invention

[0004] To address the aforementioned issues, this invention proposes a method, apparatus, and device for rapid processing of encrypted traffic in a distributed cross-domain PLC, which can improve encryption processing efficiency, reduce system resource consumption, and enhance system stability.

[0005] In a first aspect, the present invention provides a method for fast processing of encrypted traffic in a distributed cross-domain PLC, comprising:

[0006] Use the physical network card to acquire data packets;

[0007] The data packets are filtered using the first filter of the physical network card driver layer to identify and extract encrypted data frames of the WireGuard protocol.

[0008] The encrypted data frame is redirected to the user-space processing program;

[0009] The key negotiation process of the WireGuard protocol stack is detected using the first probing mechanism in kernel mode to obtain key parameters; the key parameters are then sent to the user-mode processing program using an asynchronous transmission mechanism.

[0010] The encrypted data frame is decrypted using the user-space processing program and the key parameters to obtain the decrypted original IP packet;

[0011] The decrypted original IP packet is verified by checking the destination IP address to obtain the verification result.

[0012] Based on the verification result, the original IP packet is processed as follows: if the destination IP address of the original IP packet is the local virtual IP address and conforms to the whitelist protocol, then the local control protocol is processed through the user-space processing program; if the destination IP address of the original IP packet is not the local virtual IP address or does not conform to the whitelist protocol, then the original IP packet is returned to the kernel protocol stack through the return interface and encrypted and forwarded through the WireGuard virtual network card.

[0013] In an optional implementation, the first filter is an XDP program, the user-space processing program is a DPDK program, and the return interface is a DPDK KNI network card.

[0014] In an optional implementation, the first probing mechanism is a Kprobe mechanism, and the key parameters include a session key and an initialization vector. The step of using the kernel-mode first probing mechanism to probe the key negotiation process of the WireGuard protocol stack, obtaining the key parameters, and then using an asynchronous transmission mechanism to send the key parameters to the user-mode processing program includes:

[0015] Hook functions used for key negotiation in the WireGuard protocol stack are extracted based on the Kprobe mechanism;

[0016] In response to the completion of key negotiation, the hook function is triggered to capture the session key and the initialization vector;

[0017] Store the session key and the initialization vector in the enhanced Berkeley packet filter mapping structure;

[0018] The session key and the initialization vector are asynchronously transmitted to the DPDK program based on an asynchronous input / output mechanism.

[0019] In an optional implementation, the step of verifying the destination IP address of the decrypted original IP packet to obtain the verification result includes:

[0020] The enhanced Berkeley packet filter mapping structure is used to obtain a predetermined filtering strategy;

[0021] Based on the filtering strategy, and using the DPDK program to perform destination IP address matching verification on the decrypted original IP packets, if the destination IP address of the decrypted original IP packet belongs to the local virtual IP address and passes the IP address whitelist, it is determined that the decrypted original IP packet conforms to the whitelist protocol.

[0022] In an optional implementation, the method further includes:

[0023] The user-mode processing program is used to establish a socket interface to generate the original IP packet to be sent.

[0024] The first filter is used to receive the original IP packet and verify the original IP packet. When the verification is successful, the original IP packet is attached to the packet sending queue of the WireGuard virtual network card.

[0025] The original IP packet is encrypted and encapsulated using the WireGuard protocol stack to obtain an encrypted packet.

[0026] The corresponding physical network interface card (NIC) is determined based on the routing information in the original IP packet, and the encrypted packet is sent using the physical NIC.

[0027] In an optional implementation, the step of decrypting the encrypted data frame using the user-space processing program and the key parameters to obtain the decrypted original IP packet includes:

[0028] The DPDK program runs through the rte_eth_AF_XDP driver; wherein, the rte_eth_AF_XDP monitors the status of the XDP program forwarding the receive queue packets; when it detects that the receive queue packets are empty, it switches to a sleep state; when it detects that the receive queue packets are not empty, it triggers the PMD thread through the interrupt mechanism; when the encrypted data frame is decrypted and the receive queue packets are empty again, it enables the interrupt and switches to a sleep state.

[0029] In an optional implementation, redirecting the encrypted data frame to a user-space handler includes:

[0030] Use the PMD driver in the DPDK program to create independent AF_XDP sockets for multiple receive queues of packets from the physical network card;

[0031] Allocate a corresponding message processing thread for each AF_XDP socket to perform multi-queue parallel processing of received queue messages.

[0032] In an optional implementation, the filtering strategy includes one or more of the following: IP address whitelist, WireGuard protocol port number, WireGuard protocol message type identifier, and negotiation frequency.

[0033] Secondly, the present invention provides a distributed cross-domain PLC encrypted traffic fast processing device, comprising:

[0034] The acquisition module is used to acquire data packets using the physical network card;

[0035] The filtering module is used to filter the data packets using the first filter of the physical network card driver layer, and to identify and extract encrypted data frames of the WireGuard protocol.

[0036] A redirection module is used to redirect the encrypted data frame to a user-space processing program;

[0037] The key negotiation module is used to probe the key negotiation process of the WireGuard protocol stack using the kernel-mode first probing mechanism to obtain key parameters; and to send the key parameters to the user-mode processing program using an asynchronous transmission mechanism.

[0038] The decryption module is used to decrypt the encrypted data frame using the user-mode processing program and the key parameters to obtain the decrypted original IP packet;

[0039] The verification module is used to verify the destination IP address of the decrypted original IP packet and obtain the verification result.

[0040] The traffic splitting module is used to process the original IP packet according to the verification result as follows: if the destination IP address of the original IP packet is the local virtual IP address and conforms to the whitelist protocol, then the local control protocol is processed through the user-space processing program; if the destination IP address of the original IP packet is not the local virtual IP address or does not conform to the whitelist protocol, then the original IP packet is sent back to the kernel protocol stack through the backhaul interface and encrypted and forwarded through the WireGuard virtual network card.

[0041] Thirdly, the present invention provides an electronic device including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the steps of the method described in any of the foregoing embodiments.

[0042] Fourthly, the present invention provides a computer-readable medium having processor-executable non-volatile program code, the program code causing the processor to perform the method described in any of the foregoing embodiments.

[0043] The beneficial effects of the technical solution provided by the embodiments of the present invention are as follows: The distributed cross-domain PLC encrypted traffic fast processing method, apparatus, and device of the present invention firstly acquire data packets using a physical network card; then, the data packets are filtered for the first time using a first filter of the physical network card driver layer, identifying and extracting encrypted data frames of the WireGuard protocol, and directly redirecting the encrypted data frames to the user-mode processing program, thereby bypassing the traditional kernel protocol stack, effectively improving processing efficiency, and ensuring real-time transmission of PLC controller data; then, the first probing mechanism in kernel mode is used to probe the key negotiation process of the WireGuard protocol stack to obtain key parameters; the key parameters are sent to the user-mode processing program using an asynchronous transmission mechanism; and the user-mode processing program and the key parameters are used to... Encrypted data frames are decrypted, reducing unnecessary context switching and memory copying, effectively lowering CPU usage, and ensuring stable system operation. Finally, the destination IP address of the decrypted original IP packet is verified. Based on the verification result, the original IP packet is processed as follows: if the destination IP address of the original IP packet is the local virtual IP address and conforms to the whitelist protocol, it is processed by the local control protocol through the user-space handler; if the destination IP address of the original IP packet is not the local virtual IP address or does not conform to the whitelist protocol, the original IP packet is returned to the kernel protocol stack for processing through the return interface. This invention can improve encryption processing efficiency and packet filtering accuracy, reduce system resource overhead, and make full use of the original kernel protocol stack to improve system stability. Attached Figure Description

[0044] Figure 1 A flowchart illustrating the distributed cross-domain PLC encrypted traffic fast processing method provided in an embodiment of the present invention;

[0045] Figure 2 This is a schematic diagram of the WireGuard protocol principle provided in an embodiment of the present invention;

[0046] Figure 3 This is a schematic diagram of four message transmission timing streams provided in embodiments of the present invention;

[0047] Figure 4 This is a schematic diagram of the PLC receiving process provided in an embodiment of the present invention;

[0048] Figure 5 This is a block diagram of the WireGuard data packet receiving architecture provided in an embodiment of the present invention;

[0049] Figure 6 This is a schematic diagram of the PLC receiving process data flow provided in an embodiment of the present invention;

[0050] Figure 7This is a schematic diagram illustrating the XDP and DPDK user programs receiving and sending message data streams via UMEM, provided in an embodiment of the present invention.

[0051] Figure 8 This is a schematic diagram of the PLC sending data stream provided in an embodiment of the present invention;

[0052] Figure 9 This is a block diagram of the WireGuard data packet transmission architecture provided in an embodiment of the present invention;

[0053] Figure 10 This is a schematic diagram illustrating the working principle of Kprobe and io_uring provided in an embodiment of the present invention;

[0054] Figure 11 This is a schematic diagram of the XDP program filtering process provided in an embodiment of the present invention;

[0055] Figure 12 A flowchart illustrating the io_uring asynchronous transmission mechanism provided in this embodiment of the invention;

[0056] Figure 13 A schematic diagram of the system principle of the distributed cross-domain PLC encrypted traffic fast processing device provided in an embodiment of the present invention;

[0057] Figure 14 A schematic diagram of the system principle of an electronic device provided in an embodiment of the present invention.

[0058] In the diagram: 100 - Acquisition module; 200 - Filtering module; 300 - Redirection module; 400 - Key negotiation module; 500 - Decryption module; 600 - Verification module; 700 - Stream splitting module; 1000 - Electronic device; 1001 - Communication interface; 1002 - Processor; 1003 - Memory; 1004 - Bus. Detailed Implementation

[0059] The present invention will now be described in detail with reference to the accompanying drawings and embodiments.

[0060] Reference Figure 1 A distributed cross-domain PLC encrypted traffic fast processing method is applied to cross-domain distributed communication scenarios between controllers (PLC controllers) and controllers (PLC controllers or other controllers), including the following steps S101 to S700.

[0061] Step S100: Obtain data packets using the physical network card.

[0062] The PLC controller's physical network card receives data packets and stores them in shared memory. Figure 5 (UMEM receiver block in the middle).

[0063] Step S200: The data packets are filtered using the first filter of the physical network card driver layer to identify and extract encrypted data frames of the WireGuard protocol.

[0064] Here, the first filter uses the XDP program. XDP (eXpress Data Path) is a network packet processing solution that fully utilizes eBPF (Berkeley Packet Filter) technology to implement packet processing logic, such as filtering, mapping, and routing, in kernel space. XDP's advantage lies in its ability to hook into the eBPF program early in the network reception path, thus achieving high-speed packet filtering. XDP is suitable for various network functions, and its designed interface supports flexible packet operations, making it suitable for applications such as traffic monitoring, load balancing, and data sampling.

[0065] This embodiment uses XDP technology to filter WireGuard data transmission packets (type ID 4) and send them to the DPDK program in the application space. The DPDK program (Data Plane Development Kit) is used to quickly process data packets in the network. Its core idea is to bypass the operating system's kernel protocol stack, allowing the application (i.e., the DPDK program) to interact directly with the network card in the application space. Through polling instead of interrupts, large page memory, zero-copy, and other technologies, it greatly improves the processing speed and throughput of data packets, making it particularly suitable for scenarios with extremely high performance requirements. In this embodiment, the DPDK program is used to efficiently decrypt and filter encrypted data frames redirected from the kernel.

[0066] WireGuard, as a next-generation peer-to-peer virtual private network (VPN) technology, deeply integrates encrypted tunneling technology with modern encryption algorithms. Unlike traditional VPN encryption technologies, its session key generation mechanism is based on the Noise protocol framework. It combines the peer's static public key with a local ephemeral key and utilizes the Curve25519 elliptic curve algorithm to achieve efficient and secure key negotiation. The specific framework is as follows: Figure 2As shown, the application space is configured with management tools, the wg command-line tool (wg is short for WireGuard), and the kernel WireGuard module. Users generate keys and configurations through the management tool, and then distribute the configurations to the kernel WireGuard module via the wg command-line tool. The kernel WireGuard module is associated with the virtual network interface wg0 in the kernel space. In addition to the virtual network interface wg0, the kernel space also configures a Cryptokey routing table, an encryption engine, UDP tunnel encapsulation, and a Noise protocol framework. The Cryptokey routing table, encryption engine, and UDP tunnel encapsulation are connected to the virtual network interface wg0. The UDP tunnel encapsulation receives and sends data to the physical network interface eth0. The Noise protocol framework is used to implement Curve25519 key exchange, ChaCha20 encryption, and Poly1305 authentication. The virtual network interface wg0 receives configuration data from the kernel WireGuard module. After processing by the kernel space, the configuration data is sent to the physical network interface eth0 via UDP (User Datagram Protocol) tunnel encapsulation.

[0067] The four message transmission timings involved in WireGuard are as follows: Figure 3 As shown, it includes the following steps (1) to (5).

[0068] Step (1): The client sends a "handshake request" message (message=0x01), and the server receives the handshake request.

[0069] Step (2), the server replies with a "handshake response" (message=0x02), thus completing the key negotiation between the client and the server.

[0070] Step (3): The client sends “transfer data” (message=0x04) to the server, and the server decrypts the data message.

[0071] In step (4), the server replies with "transmit data" (message=0x04) to the client, thus realizing bidirectional data transmission between the client and the server.

[0072] Step (5): After the bidirectional data transmission is completed, the client sends a "keep-alive message" (message = 0x04, data length = 0) to the server after a 25-second interval. The server updates the network address translation table entries (i.e., updates the NAT mapping) to prevent the connection from being disconnected due to timeout.

[0073] Wireguard's protocol messages are divided into four types: "Handshake Request," "Handshake Response," "Handshake Cookie," and "Transmit Data Message." The ports and categories of these four messages are unencrypted. The "Handshake Request" type value is "1," used to initiate a connection and exchange initial keys. The "Handshake Response" type value is "2," used to respond to the handshake and complete key negotiation. The "Handshake Cookie" type value is "3," used to defend against DoS flood attacks. The "Transmit Data Message" type value is "4," used to encapsulate and transmit real IP data packets. In this embodiment, the XDP virtual network card filters "Transmit Data," msg=0x04. The compiled eBPF is loaded into the target physical network card and set to XDP mode, bypassing the kernel's mode judgment. The device's corresponding AF_XDP socket (XSK) is based on the target UDP port (default 51820).

[0074] like Figure 11 As shown, after the encrypted message (i.e., the aforementioned data packet) arrives at the physical network card, the XDP program is triggered and begins processing, starting to parse the header information of the data packet. The message structure during filtering is as described in the following program.

[0075] struct message_data {

[0076] struct message_header header; / / Message header, containing the type (4 here);

[0077] __le32 key_idx; / / The receiver's index, used for quickly finding the decryption key;

[0078] __le64 counter; / / A monotonically increasing counter to prevent replay attacks;

[0079] u8 encrypted_data[]; / / This is the location where the encrypted "real IP data packets" are stored;

[0080] }

[0081] Then, the XDP program in this embodiment performs custom filtering / statistics on the encrypted packets. In optional embodiments, the following filtering conditions can be executed: ① parsing the local physical network card IP header; ② parsing the WireGuard packet port number; ③ parsing the WireGuard packet message ID. Finally, the packet destination is decided: ① discard the packet (discard path); ② pass it to the kernel protocol stack (allow path); ③ redirect it to the TUN virtual network card (redirect path).

[0082] Step S300: Redirect the encrypted data frame to the user-space handler.

[0083] In this embodiment, the user-space processing program is the DPDK program. Redirection means changing the original default transmission path of network data packets and guiding them to a different destination or processing unit. In this embodiment, XDP technology is used to redirect encrypted data frames to the DPDK program in the application space for processing in the early stage when the encrypted data frame enters the kernel protocol stack, according to preset rules. This skips the complex kernel network protocol stack and greatly improves processing efficiency.

[0084] Step S400: Use the kernel-mode first probing mechanism to probe the key negotiation process of the WireGuard protocol stack and obtain the key parameters; use the asynchronous transmission mechanism to send the key parameters to the user-mode processing program.

[0085] In an optional embodiment, the first detection mechanism is the Kprobe mechanism (kernel probe mechanism), and the key parameters include the session key and the initialization vector; step S400 specifically includes the following steps S410 to S440.

[0086] Step S410: Hook the hook function used for key negotiation in the WireGuard protocol stack based on the Kprobe mechanism.

[0087] In step S420, in response to the completion of key negotiation, a hook function is triggered to capture the session key and initialization vector.

[0088] Step S430: Store the session key and initialization vector into the enhanced Berkeley packet filter map structure (i.e., eBPF Map).

[0089] Step S440: The session key and initialization vector are asynchronously transmitted to the DPDK program based on the asynchronous input / output mechanism (io_uring).

[0090] Specifically, the principles of steps S410 to S440 are as follows: Figure 10 As shown, on one hand, the Kprobe hook function is triggered, the eBPF program processes the data, and the data is written to the eBPF Ring Buffer; on the other hand, the user-space application submits an asynchronous read request (io_uring SQE). Then, the user-space application asynchronously reads the data written to the eBPF Ring Buffer through io_uring, the io_uring subsystem pulls data from the Ring Buffer, and the user-space application obtains the complete data from the io_uring CQ queue. Finally, data processing and analysis are performed.

[0091] io_uring is an input / output circular queue, often simply referred to as an I / O circular queue, which is a high-performance asynchronous I / O framework provided by the Linux kernel. io_uring includes a commit queue (io_uring SQE) and a completion queue (io_uring CQ). In this embodiment, io_uring is the core mechanism for efficient I / O operations between user space and kernel space. eBPFRing Buffer refers to the eBPF circular buffer.

[0092] In this embodiment, the first detection mechanism employs the Kprobe mechanism, a powerful debugging and tracing mechanism provided by the Linux kernel. It allows developers to dynamically insert "probes" at any instruction (or function entry point) in the kernel without system downtime or recompiling the kernel. When the kernel executes the instruction, it is trapped and redirected to a predefined processing function, allowing for the collection of debugging information, tracing of execution paths, or capture of critical data. In this embodiment, the Kprobe mechanism is used to hook into the WireGuard protocol stack key negotiation function to obtain parameters such as the session key and initialization vector in real time.

[0093] Key parameters include the session key and the initialization vector. The initialization vector refers to the IV parameter, which is a random or pseudo-random value used in cryptography for encryption algorithms. In block ciphers (such as the algorithm used by WireGuard), if the same plaintext block is encrypted with the same key, it will produce the same ciphertext block, which poses a security risk. The introduction of IVs ensures that even if the plaintext is the same, the ciphertext produced each time is different, thus enhancing security. IVs usually do not need to be kept secret, but they must be unpredictable.

[0094] In this embodiment, the asynchronous transmission mechanism refers to the io_uring asynchronous transmission mechanism. io_uring is an asynchronous input / output ring queue or asynchronous I / O ring, a high-performance asynchronous I / O interface provided by the Linux kernel. Its core mechanism manages I / O operations through two shared ring buffer queues—a commit queue and a completion queue. User space places the description of the I / O request into the commit queue. The kernel asynchronously retrieves the I / O request from the commit queue for processing, and the processing result is placed into the completion queue. The application retrieves the processing result from the completion queue. This mechanism eliminates the overhead of system calls required during commit and completion in traditional asynchronous I / O, and supports batch request processing, achieving truly efficient zero-system-call asynchronous I / O. In this embodiment, the io_uring asynchronous transmission mechanism is used to efficiently transmit key parameters captured in kernel space to the DPDK program in user space.

[0095] Furthermore, the io_uring asynchronous transmission mechanism, such as Figure 12 As shown, this embodiment adopts the first polling method, SQ polling mode. This polling method pursues extremely low latency and low system overhead, and io_uring natively supports kernel polling mode. After setting the IORING_SETUP_SQPOLL flag, a kernel thread is created to continuously check the commit queue. The DPDK program only needs to put the request into the SQ and update the queue tail pointer, and the kernel thread will automatically process the commit, thus potentially achieving I / O operations with zero system calls. For completion events, DPDK actively and frequently checks the completion queue without relying on kernel interrupts. This "busy wait" method trades CPU time for the lowest latency. This embodiment directly adopts this polling mechanism, eliminating the event file descriptor (eventfd).

[0096] This embodiment detects the WireGuard protocol key negotiation hook function based on the Kprobe mechanism, stores the key and IV value in eBPFMap (Kprobe underlying dependency), and asynchronously transmits them to the DPDK program through the io_uring mechanism.

[0097] Step S500: Decrypt the encrypted data frame using the user-mode processing program and key parameters to obtain the decrypted original IP packet.

[0098] In an optional embodiment, step S500 includes: the DPDK program running through the rte_eth_AF_XDP driver; wherein, rte_eth_AF_XDP monitors the status of the XDP program forwarding the receive queue packets; when the receive queue packets are detected to be empty, it switches to a sleep state; when the receive queue packets are detected to be non-empty, it triggers the PMD thread through an interrupt mechanism; when the encrypted data frame is decrypted and the receive queue packets are empty again, it enables an interrupt and switches to a sleep state.

[0099] Step S600: Verify the destination IP address of the decrypted original IP packet to obtain the verification result.

[0100] In an optional embodiment, step S600 includes the following steps S610 to S620.

[0101] Step S610: Obtain a predetermined filtering policy using the eBPF Map; in an optional embodiment, the filtering policy includes one or more of the following: IP address whitelist, WireGuard protocol port number, WireGuard protocol message type identifier, and negotiation frequency.

[0102] Step S620: Based on the filtering strategy, and using the DPDK program to perform packet destination IP address matching verification on the decrypted original IP packet, if the destination IP address of the decrypted original IP packet belongs to the local virtual IP address and passes the IP address whitelist, it is determined that the decrypted original IP packet conforms to the whitelist protocol.

[0103] Step S700: Based on the verification result, the original IP packet is processed as follows: If the destination IP address of the original IP packet is the local virtual IP address and conforms to the whitelist protocol, the local control protocol is processed through the user-space processing program; if the destination IP address of the original IP packet is not the local virtual IP address or does not conform to the whitelist protocol, the original IP packet is returned to the kernel protocol stack through the return interface and encrypted and forwarded through the WireGuard virtual network card.

[0104] Specifically, the return interface is a DPDK KNI network card. KNI (Kernel Network Interface) is a virtual device driver provided by DPDK. It creates a bridge connecting user-space DPDK applications and the Linux kernel protocol stack. Normally, packets processed by DPDK applications bypass the kernel, but for packets that require kernel protocol stack functions (such as routing, firewall, or, in this embodiment, encrypted forwarding via the WireGuard virtual network card), KNI provides an efficient mechanism: DPDK applications can send packets back to the kernel through the KNI interface, and the kernel will process them as if they were received from a regular physical network card.

[0105] In steps S500-S600, the DPDK program receives encrypted data packets via XSK using the AF_XDP PMD driver, and asynchronously receives the key and IV parameter cache through the uring mechanism. It quickly matches the key based on the peer's public key configuration information and decrypts the WireGuard packets at the user layer. The decrypted packets are filtered based on the peer's IP information: if the virtual IP is the wg0 IP address and is a protocol within the local control protocol whitelist, the application layer directly performs local processing.

[0106] The routing principle of step S700 is as follows: if the destination IP address of the virtual IP is not a local virtual IP network segment address, or if it is a local virtual IP network segment address but does not meet the local control protocol whitelist, the original packet is sent based on the DPDK KNI network card. The kernel protocol stack routes the KNI network card to the wg0 network card.

[0107] If the destination IP address of the virtual IP is within the local virtual IP network segment, the original data packets are transmitted to the WG network card (i.e., the WireGuard network card) send queue through the AF_XDP interface by constructing an XDP transmission queue in the WG. This accelerates the packet processing speed of the local control network.

[0108] The XDP program and the DPDK program receive and send messages through shared memory (UMEM) and four circular queues (Fill Ring, RXRing, TXRing, and Completion Ring). The specific process is as follows: Figure 7 As shown. In the receive path, the user-space DPDK program first fills the fill ring with the idle frame address. After the XDP program obtains the packet data from the network card, it directly stores it in the UMEM shared memory and pushes the data descriptor pointing to the packet into the receive ring (RXRing). The DPDK program then reads the packet from the receive ring, completing the receive process. In the transmit path, the DPDK program writes the data to be transmitted into the UMEM and fills the transmit ring (TX Ring) with its data descriptor; the XDP program reads the descriptor from the transmit ring and transmits it to the UMEM; the XDP program also sends the descriptor to the DPDK program through the completion ring.

[0109] The descriptions of each ring in the diagram are shown in Table 1.

[0110] Table 1 Ring Description

[0111]

[0112] In specific implementation, before step S100, the DPDK application layer pre-establishes an AF_XDP socket, allocates and maps UMEM as shared memory, and the driver layer maps the DMA (Direct Memory Access) cache to a UMEM block. The DPDK KNI network card is configured with an IP address in the same network segment as the WG network card, and the default gateway is set to the WG network card.

[0113] In an optional embodiment, refer to Figure 8 and Figure 9 It also includes message sending steps, such as steps S810 to S840 below.

[0114] Step S810: Generate the raw IP packet to be sent using the socket interface established by the user-mode processor.

[0115] Specifically, the DPDK program creates a new socket interface (AF_XDP socket) and sends messages directly through this socket.

[0116] Step S820: Receive the original IP packet using the first filter and verify the original IP packet. When the verification passes, attach the original IP packet to the packet sending queue of the WireGuard virtual network card.

[0117] Specifically, when the kernel XDP program receives an application packet, it filters whether the target IP address is the IP of the wg0 network card and attaches it to the virtual network card's send queue.

[0118] Step S830: The original IP packet is encrypted and encapsulated using the WireGuard protocol stack to obtain the encrypted packet.

[0119] Specifically, the WireGuard protocol stack checks if the target IP is in the AllowedIP list. If a match is found, the encryption process is triggered; otherwise, the IP is discarded. The WireGuard kernel module performs key negotiation and encryption, followed by UPD encapsulation to obtain the encrypted message.

[0120] Step S840: Determine the corresponding physical network interface card (NIC) based on the routing information in the original IP packet, and send the encrypted packet using the physical NIC.

[0121] Specifically, the WireGuard kernel module selects the physical network card to send packets based on the packet frame routing information.

[0122] In the transmission process of this embodiment, the WireGuard kernel protocol stack is still used. The raw data needs to be transmitted to the kernel layer wg0 network card. The kernel performs key negotiation. The scheme uses the XDP socket interface, which supports zero-copy and batch transmission, thus improving processing efficiency.

[0123] In an optional embodiment, step S300 includes the following steps S310 to S320.

[0124] Step S310: Use the PMD driver in the DPDK program to create independent AF_XDP sockets for the multiple receive queue packets of the physical network card.

[0125] Step S320: Allocate a corresponding message processing thread for each AF_XDP socket to perform multi-queue parallel processing on the received queue messages.

[0126] Specifically, such as Figure 9As shown, in the message sending process, the application in the application space generates the raw data to be sent. This data is first stored in the receive block of the shared memory UMEM and organized in memory by the UMEM management module. Then, the data enters the kernel space through the AF_XDP socket and its associated send ring. In the kernel space, the XDP program obtains the data and processes it. The processed data is encapsulated into a network packet, which includes handshake frames, data frames, keep-alive frames, etc., and sent to the TCP / IP protocol stack for regular network layer and transport layer processing. The TCP / IP protocol stack interacts with the virtual network interface wg0 through the Netlink interface for configuration and data exchange. After the packet enters the wg0 virtual device, the encryption strategy is determined through the Cryptokey routing table, and the encryption engine performs encryption and authentication encapsulation based on the Noise lightweight protocol framework. The encrypted packet is encapsulated through a UDP tunnel, becoming a UDP datagram that can be transmitted over the Internet. Finally, the encapsulated packet is processed by the driver receive module and sent to the physical network interface eth0, where the physical network interface eth0 completes the final physical signal transmission and enters the external network.

[0127] In optional embodiments, such as Figure 8 As shown, the sending process can be as follows: The DPDK application sends the raw IP data packet through the XDP interface. After the XDP program successfully joins the sending queue, it searches for and matches the peer (based on the allowed IP address), encrypts the data packet (ChaCha20-Poly1305), and encapsulates it into a UDP packet (including timestamp and sequence number). Finally, the XDP program sends the UDP packet to the external network through the physical network card.

[0128] Currently, WireGuard is developed based on kernel mode. After integrating WireGuard components, PLC controllers can complete peer-to-peer encrypted communication with controller nodes. However, the following problems still exist: First, encrypted data must first be processed in kernel mode before being transmitted to user mode. Synchronous data is processed and then transmitted from user mode to kernel mode, resulting in significant switching overhead. If the encrypted data belongs to control protocol data, the control action processing delay will inevitably increase, exceeding the control latency index. Second, the interaction data between controllers contains a large amount of unencrypted data, such as general protocols for the local physical IP, such as ARP and ICMP, as well as general non-critical data. To reduce system overhead, encryption is not required. However, since message processing shares kernel protocol stack resources, including hardware interrupts, kernel storage areas, locks, and processing threads, and unencrypted data interrupts and soft interrupts will interfere with the processing efficiency of encrypted frames in the WireGuard protocol stack, resulting in significant jitter and latency.

[0129] To address the above issues, this embodiment, based on the virtual network interface communication process (handshake, response, data transmission, keep-alive) of WireGuard peer nodes, proposes using an AF_BPF interface at the physical network port entry point to filter WireGuard encrypted data frames. The application layer employs a DPDK mode supporting AF_XDP for filtering and rapid processing of encrypted data packets. Encrypted data transmission frames can utilize the XDP / BPF fast filtering mechanism from the moment they enter the network interface, achieving real-time separation of encrypted transmission frames from other frames. After separation, they quickly enter the DPDK application layer for decryption processing, filtering the source and destination IPs. Packets from the local machine are further processed by the industrial control protocol stack (such as Modbus packets), while packets from non-local machines are directly sent to the KNI network interface in the same network segment, where the kernel protocol stack routes them to the WG network interface for encrypted forwarding.

[0130] Compared to the traditional DPDK model for processing WireGuard application packets, which requires developing a WireGuard application layer protocol stack under the DPDK framework and handling complex key interactions, and also requires the use of complete application layer protocols such as BSD protocol to accommodate general network protocols, resulting in extremely high complexity and difficulty, this embodiment utilizes the efficient processing mechanism of DPDK's dedicated kernel polling combined with the completeness of the kernel's WireGuard protocol stack to reduce the execution latency and jitter of the control protocol for encrypted frames, increase the flexibility and efficiency of packet filtering, and avoid the development difficulty of implementing a complete protocol stack at the application layer.

[0131] In this embodiment, the effective encrypted payload is processed at the application layer, avoiding the overhead of switching between the kernel and application layers. The virtual network interface card (NIC) between the XDP program and the DPDK program communicates through the XSK socket, which is essentially based on UMEM shared memory, achieving zero-copy throughout the entire process. The DPDK's AF_XDP PMD, acting as the virtual NIC driver, is responsible for mapping the RX / TX queues of the AF_XDP socket to the DPDK data plane. It directly references the XSK socket (i.e., the AF_XDP socket), using the XSK socket as the channel for receiving or sending data packets. The DPDK module handles the interaction with the XSK socket internally; users only need to configure the DPDK's PMD, reducing implementation complexity.

[0132] like Figure 4 , Figure 5 and Figure 6As shown, for received data, the XDP program filters WireGuard encrypted data frames at the physical network card driver layer / kernel layer and redirects them to the DPDK user-space XSK. DPDK manages queue mapping based on the AF_XDP PMD driver to achieve zero-copy data transfer. When the protocol stack reaches the key negotiation process, the real key and IV parameters are detected in real time through the Kprobe mechanism and then passed to the DPDK user layer through the io_uring mechanism, also achieving zero-copy and avoiding switching overhead. Finally, the encrypted packets are decrypted at the user layer, and the source IP and destination IP are filtered. If the packet is not from the local IP, it is sent back to the kernel for further processing through the constructed virtual KNI network card.

[0133] In one possible embodiment, such as Figure 4 As shown, this illustrates the complete and core process from receiving a packet from the ETH physical network interface card (NIC) to the final processing of the packet. After receiving a data packet, the ETH physical NIC first determines whether the data packet Msg is a WireGuard data transmission message of type 0x4.

[0134] If so, the WireGuard protocol stack is entered to process the handshake response, and the Kprobe hook is used to capture parameters such as the session key and initialization vector (IV) generated by key negotiation. These parameters are then sent to user space through the io_uring asynchronous transmission mechanism.

[0135] If not, the message is sent to user space via the AF_XDP interface (Linux High Performance Network Packet Interface); the key and parameters sent in the previous process are queried based on the data message, and the original frame is decrypted.

[0136] The following judgment is made on the original frame: Is the source IP allowed?

[0137] If not, discard the original frame.

[0138] If so, then further determine whether the destination IP is a WG virtual IP?

[0139] If the packet uses a WG virtual IP, it is considered a local data payload and sent to the packet processing module. If it does not use a WG virtual IP, the packet is directed to the KNI network card for processing.

[0140] like Figure 5As shown, the system architecture of this embodiment includes kernel space and application space. In the packet receiving process, the physical network card eth0 receives packets and performs the first filtering by the XDP program. The filtered packets are then sent via the rx / tx ring (rx = receive, tx = send, ring is a circular buffer) to the AF_XDP socket (XSK) in the AF_XDP polling mode driver (PMD). Subsequently, the packets enter the application space via the AF_XDP socket and are stored in the shared memory UMEM receive block. The kernel and user space communicate and synchronize completion status through the completion ring, achieving efficient collaboration. Afterward, the application space retrieves packet data from the UMEM and performs subsequent protocol parsing and other processing.

[0141] DPDK, as a data packet acceleration technology that allocates resources at the user layer and polls the physical network interface, maps the rtbuffer to UMEM, directly supporting further decryption and processing of encrypted packets processed by XDP at the user layer. It fully utilizes existing architectures such as dedicated CPU cores, polling to reduce switching overhead, multi-queue processing, and zero-copy memory sharing.

[0142] like Figure 6 As shown, the network end sends data packets to the WireGuard kernel. After being filtered by the XDP program, the packets are sent to the DPDK application. The DPDK program reads the packets from AF_XDP RX_RING, extracts the receive scheme, and queries its local key cache. WireGuard calculates the transmission key and writes the calculated key to shared memory. WireGuard sends an event file descriptor (eventfd) notification to the DPDK program, which retrieves the key from shared memory and updates its key cache. The DPDK program sends the IP public key pair configuration information to the XP program, and the XDP program passes the cached IP public key pair information to the WireGuard kernel.

[0143] This embodiment utilizes the kernel WireGuard protocol stack and general network protocol processing stack. Through XDP and DPDK technologies, it performs an initial rapid filtering of valid data frames, acquiring valid data immediately and accelerating the processing speed of the local control protocol. During key negotiation in the WireGuard protocol stack, the valid key and its corresponding IV value are filtered out using the kprobe mechanism. Essentially, this utilizes the underlying eBPF of Kprobe to collect key-related information, which is then asynchronously transmitted to the user layer for decryption via io_uring. This asynchronous notification mechanism reduces processor load and achieves zero-copy between the user layer and the kernel layer, supporting multi-path forwarding and distributed concurrent encryption scenarios. After decryption at the application layer, the DPDK application transmits non-locally processed data packets to the kernel layer via the KNI network card. The kernel protocol stack then routes these packets to the wg network card for processing. The KNI network card fully utilizes the original KNI management queue of DPDK. This method does not require modification of the original processing architecture of the kernel network protocol stack and the WireGuard protocol stack, achieving completely zero-copy data transmission processing.

[0144] DPDK directly references data in UMEM through the `data_off` field of `rte_mbuf`, avoiding memory copying between the kernel and user space. AF_XDP supports multiple RX / TX queues. DPDK's PMD driver (polling mode driver) allocates an independent thread for each PLC controller's physical network interface card (NIC) queue, triggering processing through polling or interrupts. DPDK's memory pool pre-allocates fixed-size memory blocks aligned with the UMEM frame size (e.g., 2KB) to ensure efficient mapping. For NICs supporting DMA mapping, UMEM can be directly mapped to the DMA cache, avoiding copying between the kernel DMA cache and UMEM, further improving file processing efficiency.

[0145] User-level decryption operations require key synchronization and IP / public key pair synchronization. Key information includes a session key handle, a session key, and the corresponding IV value. The session key is negotiated during the kernel negotiation phase. The IP address / public key is configured for the wg0 virtual network interface using the wg configuration tool. The core of WireGuard is binding the communication peer IP address to its public key. During wg tool configuration, a copy of the IP address / public key pair is directly copied and stored in the DPDK application, bypassing kernel communication overhead. When the WireGuard protocol stack reaches the shared key negotiation stage, it obtains this information through the Kprobe mechanism. Since the key information originates from the kernel's key negotiation result and is updated relatively frequently (default validity period 180 seconds), this information is asynchronously passed through to the application layer via the io_uring mechanism for decryption and further processing.

[0146] The DPDK XDP PMD application layer driver, rte_eth_af_xdp, adaptively enables / disables polling based on XDP forwarding traffic. When an empty XDP receive / send queue is detected, it automatically switches to a sleep state (e.g., microsecond-level sleep). When a new data packet arrives and the queue is not empty, an interrupt wakes the sleeping PMD thread, disabling interrupts to avoid continuously consuming CPU resources. After data processing is complete, if the queue is detected to be empty again, interrupts are enabled, and it switches to a sleep state.

[0147] This embodiment integrates local pass-through and real-time control for efficient implementation, and supports mixed encrypted and unencrypted traffic processing.

[0148] This embodiment emphasizes the division of labor in the WireGuard protocol processing flow, specifically the filtering of message information and data using XDP and DPDK respectively. It highlights the use of XDP filtering in the specific WireGuard data packet filtering, with data transmitted to the DPDK application based on AF_XDP. The receiving process in this embodiment involves XDP filtering of specific WireGuard encrypted data packets, redirecting them to the DPDK application, and then returning them to the kernel virtual network interface card for processing based on the decrypted IP address. The first processing step, which involves XDP filtering of WireGuard encrypted data packets and redirection to the user-space DPDK program, is implemented using the DPDK API interface. The final return processing mechanism in this embodiment utilizes the DPDK's KNI network interface card and only filters data packets, fully leveraging the existing kernel protocol stack. This embodiment employs the io_uring asynchronous transmission mechanism for message passing between kernel and user space and uses a user-level key caching mechanism. The received key, IV parameters, and session key index are detected via Kprobe and then transmitted to the application layer via io_uring. This cache table associates the receiver's index value with the specific peer configuration information. This configuration information includes the peer's public key, the currently active session key, and a list of IP addresses allowed for the peer. Data packets can find the corresponding negotiated key based on this index (carried in the data packet) and decrypt it using the IV value.

[0149] This embodiment uses WireGuard's next-generation distributed virtual private network technology to achieve point-to-point encrypted communication between cross-domain distributed PLC controllers. By leveraging the contextual state association feature of WireGuard UDP encapsulation messages, it integrates kernel protocol stack processing with user-level decryption acceleration, supports resistance to DoS attacks, supports forward confidentiality, has a small code size, and high processing efficiency, effectively resolving the contradiction between transmission security and efficiency between PLC controllers.

[0150] This embodiment targets WireGuard data packets and employs the AF_XDP protocol family and the DPDK framework driven by AF_XDP_PMD. It offloads the controller's encrypted traffic from the physical network card driver to the application layer for direct processing. Compared to the traditional WireGuard kernel processing scheme, this improves the processing speed of encrypted traffic. Compared to the traditional DPDK scheme, it fully utilizes the complete functions of the kernel protocol stack, achieving zero copying between the application layer and the kernel layer and reducing CPU utilization.

[0151] This embodiment addresses the key negotiation mechanism of WireGuard by employing the Kprobe mechanism to directly obtain the decryption key and related parameters from the WireGuard protocol stack. Combined with the asynchronous processing mechanism of io_uring, it solves the problem of obtaining the decryption key for DPDK applications and supports distributed multi-channel concurrent encryption processing, achieving complete zero-copy. Compared with traditional socket communication and Netlink, the asynchronous IO mechanism improves the efficiency of asynchronous notification and significantly reduces CPU utilization.

[0152] In this embodiment, when processing packets from non-WG virtual IP network segments, the DPDK application layer utilizes the DPDK KNI network card to achieve zero-copy from the application layer to the kernel layer. By configuring the KNI default gateway to the WG network card, transparent forwarding of decrypted non-local packets is achieved without changing the kernel network protocol stack or its functionality. This embodiment leverages WireGuard's zero-state connection mechanism, which does not store any session state. Using AF_XDP in conjunction with the DPDK framework, it redirects encrypted data frame traffic to the application layer for flexible and efficient packet filtering. Kernel-mode probes filter WireGuard protocol key information and transmit it to the application layer for decryption, combining it with the aforementioned encrypted packets. A second filtering is then performed after decryption. This WireGuard encrypted packet processing flow improves packet processing flexibility and efficiency. In this embodiment, the session encryption key and authentication key generated by WireGuard are obtained based on Kprobe and transmitted asynchronously via the io_uring mechanism, avoiding high-frequency polling and achieving zero-copy between the user layer and the kernel layer, significantly reducing CPU utilization. It also supports distributed multi-path negotiation key filtering.

[0153] In this embodiment, after filtering at the application layer, decrypted messages that are not processed locally are sent back via the DPDK KNI network card. The sent-back messages are then routed to the WG network card for processing. This sent-back message processing mechanism makes full use of the existing network card driver and protocol stack, avoids modifying the WG network card driver, and maintains full protocol compatibility while ensuring efficiency.

[0154] This embodiment implements secondary packet filtering through eBPF Map and DPDK: the first is raw packet filtering, where the kernel, based on the eBPF Map mechanism, supports users to dynamically load eBPF filtering policies (including a whitelist of receiving IPs, WireGuard port numbers, WireGuard packet types, and other traffic rule customizations such as negotiation frequency); the second is filtering based on peer information after decryption by the DPDK application (including the receiving and sending IPs of the raw packets), which improves filtering accuracy and timeliness.

[0155] See Figure 13 The distributed cross-domain PLC encrypted traffic fast processing device provided in this embodiment includes an acquisition module 100, a filtering module 200, a redirection module 300, a key negotiation module 400, a decryption module 500, a verification module 600, and a traffic splitting module 700. The acquisition module 100 is used to acquire data packets using a physical network interface card (NIC). The filtering module 200 is used to filter data packets using a first filter in the physical NIC driver layer, identifying and extracting encrypted data frames of the WireGuard protocol. The redirection module 300 is used to redirect the encrypted data frames to a user-space processing program. The key negotiation module 400 is used to probe the key negotiation process of the WireGuard protocol stack using a first probing mechanism in kernel mode, obtaining key parameters; and sending the key parameters to the user-space processing program using an asynchronous transmission mechanism. The decryption module 500 is used to decrypt the encrypted data frames using the user-space processing program and the key parameters, obtaining the decrypted original IP packets. The verification module 600 is used to verify the destination IP address of the decrypted original IP packets, obtaining the verification result. The traffic splitting module 700 processes the original IP packets according to the verification results as follows: if the destination IP address of the original IP packet is the local virtual IP address and conforms to the whitelist protocol, it is processed by the local control protocol through the user-space processing program; if the destination IP address of the original IP packet is not the local virtual IP address or does not conform to the whitelist protocol, it is sent back to the kernel protocol stack through the backhaul interface and encrypted and forwarded through the WireGuard virtual network card.

[0156] In an optional embodiment, the first filter is an XDP program, the user-space processing program is a DPDK program, and the return interface is a DPDK KNI network card.

[0157] In an optional embodiment, the first probing mechanism is the Kprobe mechanism, and the key parameters include a session key and an initialization vector. The key negotiation module 400 includes a hook function module, a capture module, a storage module, and a transmission module. The hook function module is used to hook the hook function in the WireGuard protocol stack for key negotiation based on the Kprobe mechanism. The capture module is used to trigger the hook function to capture the session key and initialization vector in response to the completion of key negotiation. The storage module is used to store the session key and initialization vector into the enhanced Berkeley packet filter mapping structure. The transmission module is used to asynchronously transmit the session key and initialization vector to the DPDK program based on an asynchronous input / output mechanism.

[0158] In an optional embodiment, the verification module 600 includes a policy determination module and a matching verification module. The policy determination module is used to obtain a predetermined filtering policy using the Enhanced Berkeley Packet Filter Mapping Structure. The matching verification module is used to perform destination IP address matching verification on the decrypted original IP packet based on the filtering policy and using the DPDK program. When the destination IP address of the decrypted original IP packet belongs to the local virtual IP address and passes the IP address whitelist, it is determined that the decrypted original IP packet conforms to the whitelist protocol.

[0159] In optional embodiments, the system further includes a packet generation module, a mounting module, an encryption and encapsulation module, and a packet sending module. The packet generation module generates raw IP packets to be sent using a socket interface established by a user-space handler. The mounting module receives the raw IP packets using a first filter, verifies the raw IP packets, and mounts the raw IP packets to the packet sending queue of the WireGuard virtual network interface card when the verification passes. The encryption and encapsulation module encrypts and encapsulates the raw IP packets using the WireGuard protocol stack to obtain encrypted packets. The packet sending module determines the corresponding physical network interface card based on the routing information in the raw IP packets and sends the encrypted packets using the physical network interface card.

[0160] In an optional embodiment, the decryption module 500 is specifically configured to: have the DPDK program run via the rte_eth_AF_XDP driver; wherein, rte_eth_AF_XDP monitors the status of the XDP program forwarding the receive queue packets; when the receive queue packets are detected to be empty, switch to a sleep state; when the receive queue packets are detected to be non-empty, trigger the PMD thread through an interrupt mechanism; when the encrypted data frame is decrypted and the receive queue packets are empty again, enable the interrupt and switch to a sleep state.

[0161] In an optional embodiment, the redirection module 300 includes a creation module and a parallel processing module. The creation module is used to create independent AF_XDP sockets for multiple receive queue packets of the physical network card using the PMD driver in the DPDK program. The parallel processing module is used to allocate a corresponding packet processing thread for each AF_XDP socket to perform multi-queue parallel processing on the receive queue packets.

[0162] In optional embodiments, the filtering strategy includes one or more of the following: IP address whitelist, WireGuard protocol port number, WireGuard protocol message type identifier, and negotiation frequency.

[0163] The apparatus provided in the embodiments of this application has the same inventive concept as the method provided in the embodiments of this application. As long as the method can solve the technical problem, the apparatus can also solve the technical problem. This will not be elaborated here.

[0164] Reference Figure 14 The present invention also provides an electronic device 1000, including a communication interface 1001, a processor 1002, a memory 1003, and a bus 1004. The processor 1002, the communication interface 1001, and the memory 1003 are connected via the bus 1004. The memory 1003 is used to store a computer program that supports the processor 1002 in executing the distributed cross-domain PLC encrypted traffic fast processing method. The processor 1002 is configured to execute the program stored in the memory 1003.

[0165] Optionally, embodiments of the present invention also provide a computer-readable medium having non-volatile program code executable by a processor 1002, the program code causing the processor 1002 to execute the distributed cross-domain PLC encrypted traffic fast processing method as described in the above embodiments.

[0166] As is known from common technical knowledge, this invention can be implemented through other embodiments that do not depart from its spirit or essential characteristics. Therefore, the disclosed embodiments described above are merely illustrative in all respects and are not the only ones. All modifications within the scope of this invention or its equivalents are included in this invention.

Claims

1. A method for rapid processing of encrypted traffic in a distributed cross-domain PLC, characterized in that, include: Use the physical network card to acquire data packets; The data packets are filtered using the first filter of the physical network card driver layer to identify and extract encrypted data frames of the WireGuard protocol. The encrypted data frame is redirected to the user-space processing program; The key negotiation process of the WireGuard protocol stack is probed using the first probing mechanism in kernel mode to obtain key parameters; The key parameters are sent to the user-space processing program using an asynchronous transmission mechanism; The encrypted data frame is decrypted using the user-space processing program and the key parameters to obtain the decrypted original IP packet; The decrypted original IP packet is verified by checking the destination IP address to obtain the verification result. Based on the verification result, the original IP packet is processed as follows: if the destination IP address of the original IP packet is the local virtual IP address and conforms to the whitelist protocol, then the local control protocol is processed through the user-space processing program; if the destination IP address of the original IP packet is not the local virtual IP address or does not conform to the whitelist protocol, then the original IP packet is returned to the kernel protocol stack through the return interface and encrypted and forwarded through the WireGuard virtual network card. The method further includes: The user-mode processing program is used to establish a socket interface to generate the original IP packet to be sent. The first filter is used to receive the original IP packet and verify the original IP packet. When the verification is successful, the original IP packet is attached to the packet sending queue of the WireGuard virtual network card. The original IP packet is encrypted and encapsulated using the WireGuard protocol stack to obtain an encrypted packet. The corresponding physical network interface card (NIC) is determined based on the routing information in the original IP packet, and the encrypted packet is sent using the physical NIC.

2. The distributed cross-domain PLC encrypted traffic fast processing method according to claim 1, characterized in that, The first filter is an XDP program, the user-space processing program is a DPDK program, and the return interface is a DPDK KNI network card.

3. The distributed cross-domain PLC encrypted traffic fast processing method according to claim 2, characterized in that, The first probing mechanism is the Kprobe mechanism. The key parameters include a session key and an initialization vector. The process of using the kernel-mode first probing mechanism to probe the key negotiation process of the WireGuard protocol stack to obtain the key parameters, and then using an asynchronous transmission mechanism to send the key parameters to the user-mode processing program, includes: Hook functions used for key negotiation in the WireGuard protocol stack are extracted based on the Kprobe mechanism; In response to the completion of key negotiation, the hook function is triggered to capture the session key and the initialization vector; Store the session key and the initialization vector in the enhanced Berkeley packet filter mapping structure; The session key and the initialization vector are asynchronously transmitted to the DPDK program based on an asynchronous input / output mechanism.

4. The distributed cross-domain PLC encrypted traffic fast processing method according to claim 2, characterized in that, The step of verifying the destination IP address of the decrypted original IP packet to obtain the verification result includes: The enhanced Berkeley packet filter mapping structure is used to obtain a predetermined filtering strategy; Based on the filtering strategy, and using the DPDK program to perform destination IP address matching verification on the decrypted original IP packets, if the destination IP address of the decrypted original IP packet belongs to the local virtual IP address and passes the IP address whitelist, it is determined that the decrypted original IP packet conforms to the whitelist protocol.

5. The distributed cross-domain PLC encrypted traffic fast processing method according to claim 2, characterized in that, The process of decrypting the encrypted data frame using the user-mode processing program and the key parameters to obtain the decrypted original IP packet includes: The DPDK program runs through the rte_eth_AF_XDP driver; wherein, the rte_eth_AF_XDP monitors the status of the XDP program forwarding the receive queue packets; when it detects that the receive queue packets are empty, it switches to a sleep state; when it detects that the receive queue packets are not empty, it triggers the PMD thread through the interrupt mechanism; when the encrypted data frame is decrypted and the receive queue packets are empty again, it enables the interrupt and switches to a sleep state.

6. The distributed cross-domain PLC encrypted traffic fast processing method according to claim 1, characterized in that, The step of redirecting the encrypted data frame to the user-space processing program includes: Use the PMD driver in the DPDK program to create independent AF_XDP sockets for multiple receive queues of packets from the physical network card; Allocate a corresponding message processing thread for each AF_XDP socket to perform multi-queue parallel processing of received queue messages.

7. The distributed cross-domain PLC encrypted traffic fast processing method according to claim 4, characterized in that, The filtering strategy includes one or more of the following: IP address whitelist, WireGuard protocol port number, WireGuard protocol message type identifier, and negotiation frequency.

8. A distributed cross-domain PLC encrypted traffic rapid processing device, characterized in that, include: The acquisition module is used to acquire data packets using the physical network card; The filtering module is used to filter the data packets using the first filter of the physical network card driver layer, and to identify and extract encrypted data frames of the WireGuard protocol. A redirection module is used to redirect the encrypted data frame to a user-space processing program; The key negotiation module is used to probe the key negotiation process of the WireGuard protocol stack using the kernel-mode first probing mechanism to obtain key parameters; The key parameters are sent to the user-space processing program using an asynchronous transmission mechanism; The decryption module is used to decrypt the encrypted data frame using the user-mode processing program and the key parameters to obtain the decrypted original IP packet; The verification module is used to verify the destination IP address of the decrypted original IP packet and obtain the verification result. The traffic splitting module is used to process the original IP packet according to the verification result as follows: if the destination IP address of the original IP packet is the local virtual IP address and conforms to the whitelist protocol, then the local control protocol is processed through the user-space processing program; if the destination IP address of the original IP packet is not the local virtual IP address or does not conform to the whitelist protocol, then the original IP packet is sent back to the kernel protocol stack through the backhaul interface and encrypted and forwarded through the WireGuard virtual network card. The device further includes a message generation module, a mounting module, an encryption and encapsulation module, and a message sending module; the message generation module is used to generate the original IP message to be sent using the socket interface established by the user-mode processing program; The mounting module is used to receive raw IP packets using the first filter and verify the raw IP packets. When the verification is successful, the raw IP packets are mounted to the packet sending queue of the WireGuard virtual network card. The encryption and encapsulation module is used to encrypt and encapsulate the original IP packets using the WireGuard protocol stack to obtain encrypted packets; the packet sending module is used to determine the corresponding physical network card based on the routing information in the original IP packets and send the encrypted packets using the physical network card.

9. An electronic device, characterized in that, The method includes a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the steps of the method according to any one of claims 1-7.

Images