SSL VPN system based on layered architecture and message processing method

Abstract

This invention discloses an SSL VPN system and packet processing method based on a layered architecture. This solution establishes a completely decoupled architecture between the control plane and the data plane, configuring the SSL VPN process specifically for processing encrypted control layer packets, while configuring raw data layer packets to be directly delivered to an independent high-performance forwarding engine via a bypass mechanism. This invention provides multi-core support for high-volume, high-concurrency data packet scenarios while preserving SSL VPN security. Furthermore, it relies on the shared memory channel of the forwarding engine to avoid performance losses associated with CPU kernel-mode / user-mode context switching and packet copying processes in traditional forwarding models.

Description

A Layered Architecture-Based SSL VPN System and Packet Processing Method Technical Field

[0001] This invention relates to network equipment design technology, specifically to high-performance encrypted communication technology implemented in a multi-core processor environment. Background Technology

[0002] Current SSL VPN implementations typically process packets through socket interfaces and encrypt and decrypt packets using the kernel or by actively calling cryptographic libraries such as OpenSSL. This approach suffers from the following technical limitations, leading to significant performance and scalability challenges in practical applications:

[0003] Performance bottlenecks caused by kernel protocol stack dependencies;

[0004] Traditional architectures employ a single-process model, relying on the operating system kernel protocol stack to handle all network traffic. Control packets (such as handshake negotiation and key updates) and data packets (application layer traffic) are both submitted to the kernel for processing via the socket API, and encryption and decryption operations are implemented in kernel space using libraries such as OpenSSL. This design causes processes to frequently enter the kernel, resulting in high context switching overhead.

[0005] Inefficient concurrency caused by multi-core scalability limitations;

[0006] Traditional architectures suffer from severe lock contention issues when scaling in multi-core environments. The single-process, multi-threaded model requires contending for a global session table lock, and cross-core access to encryption / decryption contexts results in excessively low L3 cache hit rates. This situation prevents data forwarding performance from increasing linearly with the number of processor cores, creating a significant performance bottleneck.

[0007] (3) Compatibility barriers with modern high-speed forwarding architectures;

[0008] The emerging user-space high-speed forwarding framework improves performance through two core mechanisms:

[0009] Completely bypass the kernel protocol stack to achieve zero-copy direct access from the network card to the application;

[0010] Poll mode driver is used to eliminate interrupt overhead.

[0011] However, traditional SSL VPNs are fundamentally in conflict with modern forwarding architectures due to their encryption coupling (SSL encryption and decryption are deeply bound to the kernel network stack and cannot be executed in the user-space forwarding pipeline) and architectural contradictions (high-speed forwarding frameworks require data flow to reside in user space throughout the process, while SSL VPNs force data flow through the kernel).

[0012] Based on the above analysis, it can be seen that existing SSL VPN technologies mainly face the following core problems:

[0013] (1) Poor processing performance: Due to kernel protocol stack dependency and frequent context switching, it cannot meet the throughput requirements in high bandwidth scenarios;

[0014] (2) Insufficient multi-core scalability: Lock contention and cache failure prevent performance from increasing linearly with the number of CPU cores;

[0015] (3) Poor architecture compatibility: It cannot take advantage of the performance of modern user-space high-speed forwarding frameworks, resulting in a waste of hardware resources;

[0016] (4) Lack of resource isolation: Control messages and data messages are mixed and processed, causing security-critical operations (such as key negotiation) to be impacted by data traffic. Summary of the Invention

[0017] To address the performance bottleneck of SSL VPNs in existing network architectures, this invention provides an SSL VPN solution based on a layered architecture. This solution aims to significantly improve the processing performance and scalability of SSL VPNs in multi-core environments by completely decoupling the control plane and data plane.

[0018] To achieve the above objectives, the present invention provides an SSL VPN system based on a layered architecture, wherein the control plane and the data plane of the system are physically separated and run on different processor cores. The control plane is equipped with an SSL VPN control process unit, which, based on the kernel protocol stack, exclusively uses the physical main core to process control layer messages for SSL / TLS handshake negotiation, key management and session maintenance.

[0019] The data plane is equipped with an independent forwarding engine unit, which exclusively occupies the last N physical cores and can completely bypass the kernel protocol stack to handle data packet encryption / decryption and forwarding.

[0020] A shared memory channel is provided between the SSL VPN control process unit in the control plane and the forwarding engine unit in the data plane. The shared memory channel is configured to synchronize the session key between the SSL VPN control process unit and the forwarding engine unit.

[0021] The system also includes an intelligent packet classifier, which is connected to the network interface driver layer. It is used to identify and distinguish between control layer packets and data layer packets, and directs control layer packets to the kernel protocol stack for processing by the SSLVPN control process unit, while delivering data layer packets directly to the forwarding engine unit for processing by bypassing the kernel protocol stack, thus completely bypassing the kernel protocol stack.

[0022] Furthermore, the control plane and the data plane are configured to communicate via a shared memory channel, forming a one-way communication between the control plane and the data plane.

[0023] Furthermore, the intelligent message classifier is directly connected to the forwarding engine unit in the data plane via a zero-copy channel.

[0024] Furthermore, the intelligent message classifier identifies VPN messages based on the SSL corresponding UDP port number, and identifies and distinguishes control layer messages and data layer messages through the VPN message header type field.

[0025] Furthermore, the intelligent packet classifier calculates the hash value of the data layer packet based on the IP 5-tuple, and then allocates the data layer packet to the corresponding forwarding engine receiving queue according to the hash value. Each receiving queue is exclusively processed by the corresponding processor physical core.

[0026] Furthermore, the forwarding engine unit includes a virtual VPN port, a session key storage module, and an encryption / decryption module.

[0027] The virtual VPN port is bound to a VPN subnet address and has a registered encrypted sending callback function. When the target IP address of the packet received by the physical port belongs to the bound VPN subnet, the encrypted callback function of the virtual VPN port is triggered and sent.

[0028] The session key storage module is used to store all key materials related to the session;

[0029] The encryption / decryption module can perform high-speed encryption and decryption operations on data layer messages in user space based on the key materials stored in the session key storage module.

[0030] To achieve the above objectives, the present invention provides an SSL VPN packet processing method based on a layered architecture. The data processing method is based on the aforementioned SSL VPN system. For packets received at the network interface driver layer, the method first identifies whether the packet is a VPN packet based on the UDP port number corresponding to the SSL. Then, it identifies and distinguishes the VPN packet into data packets and control packets by parsing specific fields in the VPN header or SSL record layer header.

[0031] If it is determined to be a control message, it is submitted to the kernel protocol stack and processed by the SSL VPN control process in the control plane;

[0032] If it is determined to be a data packet, it is directly delivered to the forwarding engine in the data plane for processing through a bypass mechanism.

[0033] Furthermore, in the message processing method, the forwarding engine matches the pre-configured VPN subnet route according to the destination IP address of the received data packet. If a match is found, the data packet is determined to be a VPN plaintext packet that needs to be encrypted before transmission.

[0034] Furthermore, when sending encrypted VPN plaintext packets, the system first looks up the corresponding session information in the session table using the source IP address or destination IP address of the packet to obtain the encryption key and static IV vector. Then, it generates a dynamic IV vector by combining the packet counter value of the current session. Based on the dynamic IV vector, the encryption key is used to encrypt the packet payload. Finally, a VPN header, a new UDP header, and an outer IP header are added to the encrypted packet, and the forwarding engine sends it directly to the VPN client through the physical network card.

[0035] Furthermore, in the message processing method, encrypted messages from the VPN service port are received by the network driver layer and identified as VPN messages based on the SSL corresponding UDP port number by an intelligent message classifier. Then, the VPN header fields are parsed to determine the message type.

[0036] If it is a control layer message, it is redirected by the forwarding engine to the SSL VPN control process in the control plane for processing via a shared memory channel.

[0037] If it is a data layer packet, the encryption / decryption module in the forwarding engine unit first extracts the session ID from the VPN ciphertext header, looks up the corresponding decryption key and static IV vector in the session key storage unit, then generates a dynamic IV vector by combining it with the package id in the packet, and decrypts the packet payload based on the generated dynamic IV vector. After verifying that the decrypted payload is a valid IP packet, it is re-injected into the normal forwarding pipeline of the forwarding engine.

[0038] The SSL VPN system and data processing scheme based on a layered architecture provided by this invention constructs an architecture that completely decouples the control plane and the data plane, allowing the SSL VPN process to be dedicated to processing control plane packets, ensuring the reliability of secure operations, while delivering data plane packets to an independent high-performance forwarding engine through a bypass mechanism, achieving zero-copy processing in user space.

[0039] Building upon this foundation, further technologies such as intelligent packet classification and lock-free session management enable linear performance scaling in multi-core environments; and it is fully compatible with modern user-space forwarding engines, fully leveraging the potential of hardware acceleration.

[0040] The SSL VPN system and data processing scheme based on a layered architecture provided by this invention ensures that the processing performance scales linearly with the number of CPU cores based on session affinity and lock-free design; the user-space zero-copy processing mechanism based on the forwarding engine completely eliminates the overhead of kernel-mode / user-mode switching and packet copying; and the shared memory channel provides efficient key synchronization for dual planes.

[0041] The SSL VPN system and data processing solution based on a layered architecture provided by this invention retains the security features of SSL VPN while perfectly adapting to modern multi-core processors and user-space forwarding frameworks, providing a new generation of high-performance security gateway solutions for high-concurrency scenarios such as financial transactions and remote work. Attached Figure Description

[0042] The present invention will be further described below with reference to the accompanying drawings and specific embodiments.

[0043] Figure 1 is a block diagram of the SSL VPN system based on a layered architecture in this invention;

[0044] Figure 2 is a system architecture diagram of the SSL VPN system based on a layered architecture in this invention;

[0045] Figure 3 is a flowchart of the SSL VPN message forwarding process in this invention. Detailed Implementation

[0046] To make the technical means, creative features, objectives and effects of this invention easier to understand, the invention will be further described below with reference to specific illustrations.

[0047] In traditional SSL VPN implementations, the server process listens on a specific TCP or UDP port via a socket. After establishing a TCP connection with the client (this step can be skipped if using the UDP protocol), both parties encrypt control messages via a TLS handshake (or DTLS handshake for UDP). This includes negotiating the encryption algorithm and key for data packets, determining the packet MTU size, and the server assigning VPN network segment addresses and proxy routes to the client. Once the data packet key is negotiated and determined via the control messages, the server and client can send encrypted IP packets based on the established TCP connection or UDP session. Control messages and data packets use the same port for transmission and are distinguished only by the opcode type in the VPN header.

[0048] In this architecture, all packets must be copied from the kernel socket to the application layer and processed uniformly by the SSL VPN process. When faced with large volumes of data packets, the data copying between the kernel and the application layer, as well as the frequent context switching between kernel mode and user mode, severely degrades system performance.

[0049] To address the performance bottlenecks of traditional SSL VPN processing models, this invention provides a layered architecture-based SSL VPN system solution, as shown in Figure 1. This solution achieves a completely decoupled control plane and data plane architecture in SSL VPN. By completely decoupling the control plane and data plane, control packets and data packets in SSL VPN are processed separately. Control packets are processed by the SSL VPN process through kernel sockets, ensuring protocol compatibility and security. Data packets are directly injected into the user-space forwarding engine by bypassing the kernel, and rely on its encryption processing and hardware offloading capabilities to complete packet encryption, encapsulation, and forwarding, thereby achieving high-performance, low-latency, multi-core-friendly SSL VPN data processing.

[0050] Based on the concept of decoupled layered architecture, the present invention fundamentally restructures the traditional SSL VPN processing flow. The SSL VPN process is configured to be dedicated to processing encrypted control layer messages, including SSL / TLS handshake negotiation, key management, and session maintenance signaling interactions. Meanwhile, the raw data layer messages, which account for a large proportion of traffic, are directly delivered to an independent, high-performance forwarding engine located in user space for processing through a bypass mechanism. This achieves a complete separation of the control plane and the data plane both physically and logically.

[0051] Based on this, the present invention makes the following optimizations and improvements to the existing technology when implementing the SSL VPN system solution based on a layered architecture:

[0052] In traditional SSL VPN processing, control messages and data messages are processed together. High-volume data messages can easily overwhelm the control plane, affecting the real-time performance and reliability of critical security operations such as handshake and key negotiation. Therefore, strict resource isolation and priority scheduling are required.

[0053] Modern user-space forwarding engines typically lack built-in encryption capabilities, and their stateless, multi-core concurrent design pattern fundamentally contradicts the traditional stateful, context-dependent SSL / TLS encryption and decryption process. Therefore, it is necessary to seamlessly integrate low-latency, stateful encryption and decryption modules into the forwarding engine while maintaining its high-performance forwarding characteristics.

[0054] To fully leverage the performance of multi-core processors, an efficient session-level affinity scheduling mechanism needs to be designed to ensure that all packets in the same encrypted session are processed by the same core, thereby maintaining the locality of the encryption / decryption context and avoiding the performance overhead and timing disruptions caused by cross-core access.

[0055] A secure and efficient key synchronization and session status notification mechanism needs to be established between the control plane and the data plane. Under the premise of ensuring the security of key materials, low-latency real-time synchronization of events such as session creation, key update and session destruction should be achieved to ensure that the forwarding engine can obtain the latest keys and policies.

[0056] Referring to Figure 2, it shows the system architecture diagram of the SSL VPN system based on a layered architecture as presented in this invention.

[0057] As illustrated in the figure, the core of the SSL VPN system 100 based on a layered architecture presented in this invention is mainly composed of three functional units: an intelligent packet classifier 110, an SSL VPN process 120, and an independent data plane forwarding engine 130.

[0058] The message classifier 110 in this system is specifically deployed in the network driver layer, and it achieves accurate message differentiation based on multi-level rules.

[0059] Specifically, the instinctive message classifier 110 first performs preliminary screening based on the destination port (such as TCP 443 or UDP 1194), and then performs deep parsing of the ContentType field in the SSL record layer header (22 for handshake message, 20 for key update, and 23 for application data) to accurately identify and distinguish between control messages and data messages.

[0060] Furthermore, an RSS hash-based flow distribution strategy is adopted for packets. The hash value is calculated based on the IP 5-tuple (source IP, destination IP, source port, destination port, protocol type) of the packet, and all packets of the same session are directed to the same dedicated packet receiving queue, ensuring that each queue is polled by a fixed processor core.

[0061] This ensures that the context of the same encrypted session (such as encryption / decryption status and sequence number) is maintained and accessed only on a single core, fundamentally avoiding lock contention, context switching overhead, and out-of-order message problems that may result from multiple cores concurrently processing the same session, thus laying the foundation for linear scaling across multiple cores.

[0062] After completing the classification, the intelligent message classifier submits control messages to the kernel protocol stack for processing by the SSL VPN process 120; data messages are directly pushed to the data receiving ring of the data plane forwarding engine 130 through a zero-copy channel.

[0063] The independent data plane forwarding engine 130 in this system is configured to be directly connected to the intelligent packet classifier 110 for processing data packets.

[0064] The data plane forwarding engine 130 is equipped with functional units such as virtual VPN ports, session key storage units, and encryption / decryption modules.

[0065] The virtual VPN port is configured to be bound to a VPN subnet address (e.g., 192.168.10.1 / 24), and an encrypted transmission callback function is registered. This way, when the forwarding engine determines that the target IP belongs to the bound VPN subnet, the encrypted transmission process is triggered.

[0066] The session key storage unit uses a double hash table structure to store all key materials related to the session, supporting fast lookup with O(1) time complexity.

[0067] The primary keys of this dual-hash table structure are the session ID and the client VPN IP, respectively. The storage structure includes key fields such as encryption key, decryption key, static initialization vector (IV), and dynamic packet counter. Simultaneously, all key materials are locked in physical memory via the `mlock` system call to prevent them from being swapped out to the swap space, and are destroyed through secure interfaces such as `explicit_bzero` to prevent memory residue.

[0068] Furthermore, this session key storage unit receives session key information synchronized from the SSL VPN process 120 via the shared memory channel 140, thereby providing the encryption / decryption module with a real-time and efficient key query service. This security design ensures the confidentiality and integrity of key materials.

[0069] The encryption / decryption module is used for high-speed encryption and decryption of data packets in user space. This module specifically supports multiple symmetric encryption algorithms such as AES-GCM and SM4-CTR, and can be offloaded using a hardware acceleration card (such as Intel QAT).

[0070] Compared to conventional techniques, this encryption / decryption module employs a dynamic IV generation mechanism to effectively defend against codebook attacks. To further explain, under this dynamic IV generation mechanism, the encryption / decryption module uses the current packet's package ID (a 32-bit monotonically increasing counter) as the high 32 bits, combining it with the initially negotiated static IV (96 bits) to form a complete 128-bit IV vector. This ensures that the same plaintext produces different ciphertexts each time it is encrypted. During encryption, the key and static IV are retrieved from the session key storage unit, combined with a local counter to generate a dynamic IV, and then encryption is performed. During decryption, the package ID is extracted from the packet, combined with the static IV in the session key storage unit to form a dynamic IV, and then decryption is performed. This dynamic IV generation mechanism can fully adapt to the stateless, multi-core parallel processing mode of the forwarding engine while ensuring security.

[0071] In this system, the SSL VPN process 120 processes control messages through kernel sockets. It is configured to listen for and receive socket requests, respond to client control messages, and add, update, and delete data packet key information to the session key storage unit in the data plane forwarding engine 130 through a specific API interface.

[0072] The layered architecture-based SSL VPN system solution developed based on the above approach effectively overcomes the performance bottleneck of traditional SSL VPNs in multi-core environments. Through intelligent flow classification and session affinity design, it achieves lock-free processing, enabling system throughput to increase approximately linearly with the number of CPU cores. Data packets are completely bypassed by the kernel, achieving zero-copy processing in user space, and integrated hardware encryption acceleration, significantly reducing processing latency and CPU load. Physical isolation between the control plane and data plane ensures that critical security operations such as key negotiation are not impacted by data plane traffic surges, enhancing system reliability. The innovative dynamic IV mechanism and user-space encryption module design allow SSL VPNs to be seamlessly integrated into modern user-space forwarding frameworks, fully leveraging their high-performance advantages.

[0073] See Figure 3, which shows the specific logical process of data processing in this layered SSL VPN system solution.

[0074] Based on the diagram, the data processing process of this layered SSL VPN system 100 mainly includes the following steps:

[0075] Step (1): Message reception and classification;

[0076] After the network interface card (NIC) driver layer receives a packet, the intelligent packet classifier located in the network driver layer first detects its destination port (such as UDP 1194). If the port matches, it further parses specific fields (such as opcode or ContentType) in the SSL record header or VPN header of the packet, and accurately determines whether it is a VPN payload packet (control or data) or a normal network packet according to predefined rules.

[0077] If the message is determined to be a normal message, it is sent to the data plane forwarding engine for regular forwarding pipeline.

[0078] If it is determined to be a VPN payload packet, further traffic routing will be performed based on its type:

[0079] If the VPN payload message is a control message, it is submitted to the kernel protocol stack and processed by the SSL VPN process; if the VPN payload message is a data message, it is directly injected into the data plane forwarding engine through a bypass mechanism.

[0080] This approach enables early and accurate classification and physical routing of messages, ensuring that control messages and data messages enter different processing paths from the entry point, laying the foundation for subsequent parallel processing.

[0081] Step (2): Encryption and transmission of plaintext messages (from intranet to internet)

[0082] The data plane forwarding engine further determines whether the received data packets are plaintext packets belonging to the VPN's specified IP network segment. The engine matches the packet's destination IP address against pre-configured VPN subnet routing rules. If a match is found, the packet is determined to be a VPN plaintext packet requiring encryption; otherwise, it is considered a regular plaintext packet.

[0083] Furthermore, for VPN plaintext packets that need to be encrypted, the encryption / decryption module in the data plane forwarding engine first looks up the corresponding session information in the session key storage unit using the source IP address (or destination IP, depending on the session table design) of the packet to obtain the encryption key and static IV; at the same time, it generates a dynamic IV by combining the packet counter value (packageid) of the current session, and encrypts the packet payload using the encryption key; then, it adds a VPN header (including session ID, etc.), a new UDP header, and an outer IP header; finally, the encrypted packet is sent directly to the VPN client by the forwarding engine through the physical network card, bypassing the kernel protocol stack throughout the process.

[0084] This achieves efficient and secure encryption and encapsulation of data packets in user space, completely avoiding kernel-to-user space switching and memory copy overhead, and significantly improving sending performance.

[0085] Step (3): Receiving and decrypting encrypted messages (Internet to intranet)

[0086] For packets received by the network interface card (NIC) from the Internet, the intelligent packet classifier determines whether the received packet is a VPN encrypted packet to be processed by judging whether the destination port of the packet received by the NIC is a specified VPN service port (such as UDP 1194).

[0087] For VPN encrypted packets identified as pending processing, the intelligent packet classifier further analyzes specific fields (such as opcode) in the VPN packet header to determine the packet type.

[0088] If it is a control message, the data plane forwarding engine will send it to the SSL VPN process for processing via mechanisms such as shared memory. After the control process decrypts the message, it can perform configuration operations such as adding, deleting, and updating keys in the session table of the data plane forwarding engine.

[0089] If it is a data packet: Extract the session ID from the VPN header, query the corresponding decryption key and static IV in the session key storage unit of the data plane forwarding engine, and generate a dynamic IV by combining it with the package id field in the packet header, then decrypt the packet payload. After verifying that the decrypted payload is a valid IP packet, reinject it into the normal forwarding pipeline of the data plane forwarding engine.

[0090] This achieves accurate classification and efficient decryption of encrypted messages, allowing control messages to be reliably processed by a dedicated process, while data messages are quickly decrypted and forwarded in user space without interference, thus balancing security and performance.

[0091] Regarding the SSL VPN system solution based on a layered architecture proposed in this invention, the following examples illustrate some implementation schemes that may be involved in specific implementations.

[0092] In some implementations of this system solution, a multi-core lock-free session processing mechanism is further introduced.

[0093] Under this multi-core lock-free session processing mechanism, this system solution configures a hash calculation module based on the IP five-tuple: source / destination IP, source / destination port, and protocol type at the user-space driver layer; and dynamically binds network traffic to the exclusive packet receiving queue of a specific CPU core through hash values ​​to ensure that all packets of the same SSL session are always processed by the same CPU core.

[0094] In this way, the overhead of session state synchronization in multi-core concurrent scenarios can be completely eliminated, and the cache invalidation problem caused by cross-core migration of encryption and decryption context can be avoided. In actual tests, the session processing speed is improved by 3.2 times in scenarios with frequent requests from multiple clients.

[0095] In some implementations of this system solution, a collaborative architecture between the control plane and the data plane is constructed. Under this collaborative architecture, the SSL VPN control process and the data plane forwarding engine can achieve collaborative operation, specifically in the following aspects:

[0096] (1) Virtual Interface Creation

[0097] Parse the configuration file to obtain the VPN private subnet address range, such as 192.168.10.0 / 24;

[0098] A virtual encrypted interface, named ovpn0, is dynamically created in the user-space forwarding framework.

[0099] Establish subnet routing mapping rules: traffic destined for the VPN subnet is forced to be routed to this virtual interface.

[0100] (2) Key synchronization mechanism

[0101] After the SSL VPN process completes the TLS handshake and key negotiation with the client, it transmits the session key packet to the data plane forwarding module through the inter-process communication channel protected by shared memory and semaphores. The session key packet contains:

[0102] Encryption direction algorithm and key (e.g., AES-256-GCM Key);

[0103] Decryption direction algorithm and key;

[0104] Encryption initialization vector IV (12 bytes in length);

[0105] Decrypt the initialization vector IV;

[0106] Client VPN network segment IP address (identifies the tunnel endpoint);

[0107] The client's actual public IP address;

[0108] VPN Session ID (64-bit unique identifier);

[0109] The data plane forwarding module constructs a dual hash index structure:

[0110] Primary index: Session ID → Key packet pointer;

[0111] Secondary index: Client VPN network segment IP → Session ID;

[0112] Session lifecycle management;

[0113] Destroyed after timeout:

[0114] The data plane forwarding module has a built-in session timer (default timeout T=600s).

[0115] Timeout sessions are automatically moved to the recycling queue, triggering a secure erase that overwrites the key with a zero value.

[0116] Active termination:

[0117] When the client sends a close_notify control message;

[0118] The SSL VPN process uses authenticated IPC commands (including a digitally signed session ID).

[0119] The data plane forwarding module is instructed to immediately delete the session entry and destroy the key.

[0120] In some implementations of this system solution, a corresponding high-speed forwarding framework is constructed to process SSL VPN packets.

[0121] For ease of explanation later, the VPN message format is listed below:

[0122] opcode (5 bits, which can be used to determine whether the message type is data);

[0123] key id (3 bits, used to specify the new key id after session key renegotiation);

[0124] Session ID (24 bits, a unique identifier for a session);

[0125] Package ID (32 bits, session one-way message counter);

[0126] tags (128 bits, message integrity verification field, generated by the encryption algorithm);

[0127] payload (encrypted payload message).

[0128] (1) Message encryption processing mainly involves the following stages:

[0129] (1.1) Encryption trigger judgment: The destination IP of the packet is verified by the destination address matching engine to see if it belongs to the pre-configured VPN subnet address range (e.g., 192.168.10.0 / 24). If the match is successful, the encryption pipeline is activated; otherwise, it is transferred to the normal forwarding path.

[0130] (1.2) Session key retrieval: The forwarding framework will look up session information through a hash table based on the destination IP address; if the session information cannot be found, it will be processed according to the normal packet routing table forwarding process.

[0131] (1.3) Dynamic encryption mechanism against codebook attacks

[0132] Dynamic IV synthesis: Obtain the packet counter value (32-bit monotonically increasing integer) of the current session. Combine this value (high 32 bits) with a pre-stored static IV vector (low 96 bits) to generate a 128-bit dynamic IV.

[0133] Encryption execution: Using authentication and encryption modes such as AES-GCM, with dynamic IV as input, the original IP packet payload is encrypted and a 128-bit integrity label (GMAC) is generated. The current packet counter value is then filled into the VPN header package id.

[0134] (1.4) Layered Protocol Encapsulation

[0135] The forwarding engine encapsulates packets according to session information. The format of the encapsulated packets is as follows:

[0136] IP header (new);

[0137] UDP header (new);

[0138] VPN message header (new);

[0139] Raw IP packet payload (encrypted).

[0140] (2) After the message is encapsulated, the encapsulated message is submitted to the physical network card sending queue through the network card queue pass-through technology in accordance with the normal forwarding process.

[0141] (3) Message decryption processing mainly involves the following stages:

[0142] When the user-space forwarding engine receives a UDP packet destined for port 1194, the system executes the following decryption pipeline:

[0143] (3.1) Separate control messages from data messages;

[0144] The first-layer classification engine performs judgment based on the VPN header opcode field. When the opcode is data, it enters the forwarding engine decryption process. Packets with control type opcodes will be sent to the SSL VPN control process for processing.

[0145] Physical isolation mechanism: Control messages are transmitted through the kernel protocol stack throughout the entire process, decoupled from the data plane.

[0146] (3.2) Dynamic decryption vector synthesis;

[0147] Retrieve the session context, query the session hash table using the 24-bit session ID in the VPN header as the primary key, obtain the pre-stored IV vector (lower 96 bits), and combine it with the package id (higher 32 bits) carried in the VPN header to form a complete dynamic IV vector.

[0148] (3.3) Decryption and integrity verification;

[0149] Input the encryption payload, message decryption key, and dynamic IV vector. Decrypt the message using a session-specified decryption algorithm (such as AES-GCM) and generate an integrity verification field. If the generated field matches the tag field carried in the message, the message is considered tamper-proof.

[0150] Check if the package id carried in the message is greater than the last valid sequence number locally. If so, update the sequence number; otherwise, discard the message.

[0151] (3.4) Payload compliance detection and forwarding;

[0152] Check if the payload header is a correct IP packet:

[0153] Is the IP protocol number IPv4 or IPv6?

[0154] Is the IP packet length correct?

[0155] Is the IP header checksum correct?

[0156] If the detection is normal, the packet is sent to the user-space driver via the zero-copy channel through the specified output port of the forwarding engine; if the detection is abnormal, the packet is discarded.

[0157] The implementation process of the SSL VPN system solution based on a layered architecture proposed in this invention will be further illustrated below through specific examples.

[0158] Example 1: Cooperative control of the control plane and data plane.

[0159] This example details the implementation process of a decoupled architecture between the control plane and data plane in an SSL VPN system. In this example, the control plane is dedicated to session management and key negotiation, while the data plane is dedicated to packet forwarding and encryption. The two are synchronized securely and efficiently through a shared memory channel, achieving complete physical and logical separation.

[0160] 1.1 Session Establishment and Key Synchronization

[0161] TLS handshake:

[0162] The SSL VPN process (control plane) completes the standard TLS 1.3 handshake on TCP port 443.

[0163] Generate session key material, which is used for encryption and decryption operations of all subsequent data plane messages.

[0164] c

[0165] struct session_keys {

[0166] uint8_t enc_key

[32] ; / / Encryption key (AES-256)

[0167] uint8_t dec_key

[32] ; / / Decryption key

[0168] uint8_t static_iv

[12] ; / / Static IV vector

[0169] };

[0170] Key synchronization:

[0171] Keys are transmitted via a shared memory ring buffer (memory addresses are pre-mapped using mmap).

[0172] Synchronization protocol:

[0173] Control process -> Forwarding engine: Write the key packet to the ring [tail]

[0174] Control process -> Forwarding engine: Atomic write tail+1

[0175] Forwarding Engine ->> Forwarding Engine: Detects tail changes

[0176] Forwarding Engine ->> Forwarding Engine: Reads the key from ring[head]

[0177] Forwarding engine ->> Control process: Atomic write head+1

[0178] 1.2 Session Table Construction

[0179] Data Structures:

[0180] c

[0181] struct vpn_session {

[0182] uint64_t session_id; / / Session ID (primary key)

[0183] uint32_t client_vpn_ip; / / Client VPN internal network IP

[0184] uint32_t client_public_ip; / / Client's public IP address

[0185] struct session_keys keys; / / Key material

[0186] atomic_t tx_package_counter; / / Send counter (atomic variable)

[0187] time_t last_active; / / Last active timestamp

[0188] };

[0189] Hash table implementation:

[0190] Main table: Jenkins hash with session ID as key (bucket size = 217)

[0191] Supplementary table: CRC32 hash of the client VPN IP as the key (for fast routing)

[0192] The session table and key synchronization mechanism constructed in this embodiment will provide fundamental support for data packet processing in Embodiment 2. When processing packets, the data plane directly relies on the synchronized key materials and the constructed session table, achieving efficient collaboration between the control and data planes under a decoupled architecture.

[0193] Example 2: Data Packet Encryption / Decryption Processing Chain

[0194] This embodiment is based on the session foundation and key materials established in Embodiment 1. The encryption and decryption process of data packets in the data plane is described in detail below.

[0195] 2.1 Sending path (Internal network → Internet)

[0196] Encryption trigger:

[0197] Virtual interface ovpn0 receives IP packets destined for 192.168.10.0 / 24.

[0198] Query the auxiliary table to obtain the session ID (matching the client_vpn_ip field).

[0199] Dynamic IV synthesis:

[0200] Atomic increment counter: counter = atomic_add(&session->tx_package_counter, 1)

[0201] Constructing a 128-bit IV:

[0202] Python

[0203] dynamic_iv[0:4] = counter.to_bytes(4) # High 32 bits

[0204] dynamic_iv[4:16] = session->keys.static_iv # lower 96 bits

[0205] Layered packaging, the specific packaging scheme is shown in Table 1:

[0206] Table 1

[0207] The implementation method of layered encapsulation is as follows: The original IP payload is encrypted using AES-GCM. The OpenSSL encryption library is called. The VPN header uses session ID + opcode(DATA) to be directly written to memory. The UDP header source port is randomized / destination port is 1194. The outer IP header is calculated based on stream hashing: source = server public IP, destination = client public IP. The session table `client_public_ip` is looked up. surface

[0208] 2.2 Receiving path (Internet → Intranet)

[0209] Message Classification:

[0210] The network card driver layer filters UDP packets destined for port 1194.

[0211] Parsing the VPN header opcode field:

[0212] opcode=0x01 (control message) → Submit kernel protocol stack

[0213] opcode=0x02 (data packet) → Enter decryption pipeline

[0214] Dynamic IV Reconstruction:

[0215] Extract the 32-bit package_id from the message as the high 32 bits of the IV.

[0216] Combine the 96-bit static IV stored in the session to form the complete decryption vector.

[0217] Decryption and Verification:

[0218] Decryption process:

[0219] c

[0220] int auth_ok = qat_aes_gcm_decrypt(

[0221] ciphertext,

[0222] session->keys.dec_key,

[0223] dynamic_iv,

[0224] gmac_tag,

[0225] plaintext

[0226] );

[0227] Dual authentication mechanism:

[0228] GMAC verification: auth_ok == 1

[0229] Anti-replay: package_id > session->last_package_id

[0230] Payload forwarding:

[0231] Verify that the decrypted payload is a valid IP packet (check the IP version field).

[0232] Inject into the input queue of the user-space forwarding framework (zero copy)

[0233] This embodiment fully demonstrates how the data plane can achieve efficient message processing using the key materials and session information provided in Embodiment 1. The entire process does not rely on the control plane, showcasing the core advantage of a decoupled architecture.

[0234] Example 3: Fault Handling and Security Enhancement

[0235] This embodiment, based on the processing schemes given in Embodiments 1 and 2, provides a complete reliability assurance mechanism to ensure the industrial-grade availability of the decoupled architecture.

[0236] 3.1 Exception Handling Mechanism

[0237] The exception handling mechanism given in this embodiment is shown in Table 2:

[0238] Table 2

[0239] Fault Scenario Handling Strategy: Security Log Event Session ID Lookup Failure - Discard Packet + Send SESSION_INVALID Control Alarm; EVENT_SESSION_MISSG MAC Authentication Failure - Discard Packet; EVENT_AUTH_FAIL Non-IP Payload - Discard Packet + Record Payload Fingerprint; EVENT_INVALID_PAYLOAD surface

[0240] 3.2 Key Lifecycle Management

[0241] By employing techniques such as memory locking and secure erasure, the security of the synchronized key materials in Example 1 is ensured during storage and destruction, preventing key leakage.

[0242] Storage security:

[0243] c

[0244] mlock(session->keys, sizeof(struct session_keys)); / / Lock physical memory

[0245] madvise(session->keys, sizeof(struct session_keys), MADV_DONTDUMP); / / Disable kernel dump

[0246] Destruction process:

[0247] c

[0248] explicit_bzero(session->keys, sizeof(struct session_keys)); / / Secure erase

[0249] munlock(session->keys, sizeof(struct session_keys)); / / Unlock

[0250] 3.3 Performance Degradation Response

[0251] Control channel interrupted:

[0252] The forwarding engine maintains key forwarding (TTL=300 seconds).

[0253] Asynchronous reconnection control process

[0254] If the VPN service is not restored within the timeout period, the VPN service will be shut down.

[0255] The foregoing has shown and described the basic principles, main features, and advantages of the present invention. Those skilled in the art should understand that the present invention is not limited to the above embodiments. The embodiments and descriptions in the specification are merely illustrative of the principles of the invention. Various changes and modifications can be made to the invention without departing from its spirit and scope, and all such changes and modifications fall within the scope of the present invention as claimed. The scope of protection of this invention is defined by the appended claims and their equivalents.

Claims

1. An SSL VPN system based on a layered architecture, characterized in that, The control plane and data plane of the system are physically separated and run on different processor cores. The control plane includes an SSL VPN control process unit, which, based on the kernel protocol stack, exclusively uses the physical main core to process control layer messages for SSL / TLS handshake negotiation, key management, and session maintenance. The data plane includes an independent forwarding engine unit, which exclusively uses the last N physical cores and can handle data packet encryption / decryption and forwarding entirely by bypassing the kernel protocol stack. The forwarding engine unit includes a virtual VPN port, a session key storage module, and an encryption / decryption module. The virtual VPN port is bound to a VPN subnet address and has a registered encryption callback function. When the destination IP address of a message received by the physical port belongs to the bound VPN subnet, the encryption callback function of the virtual VPN port is triggered and the message is sent. The session key storage module stores all key materials related to the session. The encryption / decryption module can perform high-speed encryption and decryption operations on data layer messages in user space based on the key materials stored in the session key storage module. A shared memory channel is established between the SSL VPN control process unit in the control plane and the forwarding engine unit in the data plane. This shared memory channel is configured for SSL synchronization. The system also includes a session key between the VPN control process unit and the forwarding engine unit; the intelligent packet classifier is connected to the network interface driver layer and is used to identify and distinguish between control layer packets and data layer packets, and directs control layer packets to the kernel protocol stack for processing by the SSL VPN control process unit, and delivers data layer packets directly to the forwarding engine unit for processing by bypassing the kernel protocol stack, completely bypassing the kernel protocol stack.

2. The SSL VPN system based on a layered architecture according to claim 1, characterized in that, The control plane and the data plane are configured to communicate via a shared memory channel, enabling one-way communication between the control plane and the data plane.

3. The SSL VPN system based on a layered architecture according to claim 1, characterized in that, The intelligent message classifier is directly connected to the forwarding engine unit in the data plane via a zero-copy channel.

4. The SSL VPN system based on a layered architecture according to claim 1, characterized in that, The intelligent message classifier identifies VPN messages based on the SSL corresponding UDP port number, and identifies and distinguishes control layer messages and data layer messages through the VPN message header type field.

5. The SSL VPN system based on a layered architecture according to claim 4, characterized in that, The intelligent packet classifier calculates the hash value of data layer packets based on the IP 5-tuple, and then allocates the data layer packets to the corresponding forwarding engine unit's packet receiving queue according to the hash value. Each packet receiving queue is exclusively processed by the corresponding processor physical core.

6. A method for processing SSL VPN packets based on a layered architecture, characterized in that, The message processing method is based on the SSL VPN system of any one of claims 1-5. For messages received at the network interface driver layer, it first identifies whether the message is a VPN message based on the UDP port number corresponding to the SSL. Then, it parses specific fields in the VPN header or SSL record layer header of the VPN message to identify and distinguish them as data messages and control messages. If it is determined to be a control message, it is submitted to the kernel protocol stack for processing by the SSL VPN control process in the control plane. If it is determined to be a data message, it is directly delivered to the forwarding engine unit in the data plane for processing through a bypass mechanism.

7. The SSL VPN packet processing method based on a layered architecture according to claim 6, characterized in that, In the message processing method, the forwarding engine unit matches the pre-configured VPN subnet route according to the destination IP address of the received data packet. If a match is found, the data packet is determined to be a VPN plaintext packet that needs to be encrypted before transmission.

8. The SSL VPN packet processing method based on a layered architecture according to claim 7, characterized in that, When sending a VPN plaintext packet, the system first looks up the corresponding session information in the session table using the source IP address or destination IP address of the packet to obtain the encryption key and static IV vector. Then, it generates a dynamic IV vector by combining the packet counter value of the current session. Based on the dynamic IV vector, the encryption key is used to encrypt the packet payload. Next, a VPN header, a new UDP header, and an outer IP header are added to the encrypted packet. Finally, the forwarding engine unit sends the packet directly to the VPN client through the physical network card.

9. The SSL VPN packet processing method based on a layered architecture according to claim 7, characterized in that, In the packet processing method, encrypted packets from the VPN service port are received by the network interface driver layer and identified as VPN packets based on the SSL corresponding UDP port number by the intelligent packet classifier. Then, the VPN header fields are parsed to determine the packet type: if it is a control layer packet, the forwarding engine unit redirects it to the SSL VPN control process in the control plane for processing through the shared memory channel; if it is a data layer packet, the encryption / decryption module in the forwarding engine unit first extracts the session ID from the VPN encrypted header, looks up the corresponding decryption key and static IV vector in the session key storage module, then generates a dynamic IV vector by combining it with the packageid in the packet, and decrypts the packet payload based on the generated dynamic IV vector. After verifying that the decrypted payload is a valid IP packet, it is re-injected into the normal forwarding pipeline of the forwarding engine unit.

Images