Message processing method, message processing device, gateway device, medium and product

Abstract

This application discloses a message processing method, message processing apparatus, gateway device, computer-readable storage medium, and computer program product. The method includes: determining tunnel parameters for creating a Point-to-Point Tunneling Protocol (PTP) Virtual Private Network (VPN); creating a point-to-point tunnel and corresponding session entries based on the tunnel parameters; and forwarding messages generated by one end of the client device and the server device to the other end device based on the point-to-point tunnel, the session entries, and a pre-created vector packet processing node. Thus, this application can achieve message forwarding based on the message batch processing capabilities of the vector packet processing node. Compared to implementing a PTP VPN through the kernel, this reduces CPU interrupt and memory copy overhead, thereby improving the message forwarding performance of the PTP VPN.

Description

Technical Field

[0001] This application relates to the field of communication technology, and in particular to a message processing method, message processing apparatus, gateway device, computer-readable storage medium, and computer program product. Background Technology

[0002] Among related technologies, PPTP VPN (Point-to-Point Tunneling Protocol Virtual Private Network) is widely used for enterprise branch office interconnection and mobile office due to its advantages of easy deployment and cross-system compatibility. However, traditional PPTP VPN implementations rely on the PPTP (Point-to-Point Tunneling Protocol) module in the Linux kernel, and PPTP VPNs implemented through the Linux kernel have low performance, making it difficult to meet the current requirements of high-performance gateways. Summary of the Invention

[0003] This application provides a message processing method, a message processing apparatus, a gateway device, a computer-readable storage medium, and a computer program product.

[0004] This application provides a message processing method applied to a gateway device, wherein a client device connects to a server device through the gateway device, and the method includes:

[0005] Determine the tunnel parameters used to create a point-to-point tunneling protocol virtual private network; Based on the tunnel parameters, a point-to-point tunnel and a corresponding session table entry are created. The client device communicates with the server device through the point-to-point tunnel. The session table entry is used to determine the message processing rules when the client device and the server device communicate. Based on the point-to-point tunnel, the session entry, and the pre-created vector packet processing node, packets generated by one of the client devices and the server devices are forwarded to the other device.

[0006] Thus, in this embodiment, tunnel parameters for creating a point-to-point tunneling protocol virtual private network can be determined, and point-to-point tunnels and corresponding session entries can be created based on the tunnel parameters. Based on the point-to-point tunnels, session entries, and pre-created vector packet processing nodes, packets generated by one end device (client device or server device) are forwarded to the other end device. This allows packet forwarding based on the packet batch processing capabilities of the vector packet processing nodes. Compared to implementing a point-to-point tunneling protocol virtual private network through the kernel, this reduces CPU interrupt and memory copy overhead, thereby improving the packet forwarding performance of the point-to-point tunneling protocol virtual private network.

[0007] In some embodiments of this application, determining the tunnel parameters used to create a point-to-point tunneling protocol virtual private network includes: Based on the target configuration information of the obtained point-to-point tunneling protocol virtual private network, the tunnel parameters are obtained through negotiation with the server device.

[0008] Thus, in this embodiment of the application, the tunnel parameters can be obtained by negotiating with the server device based on the target configuration information of the point-to-point tunneling protocol virtual private network, thereby achieving robust acquisition of tunnel parameters.

[0009] In some embodiments of this application, the step of negotiating with the server device based on the obtained target configuration information of the peer-to-peer tunneling protocol virtual private network to obtain the tunnel parameters includes: Given the target configuration information of the point-to-point tunneling protocol virtual private network, the tunnel parameters are obtained by negotiating with the server device through a pre-determined challenge handshake authentication protocol process.

[0010] Thus, in this embodiment of the application, given the target configuration information of the point-to-point tunneling protocol virtual private network, the negotiation process with the server device can be performed through a pre-determined challenge handshake authentication protocol process to obtain the tunnel parameters. This allows the negotiation with the server device to be executed through the challenge handshake authentication protocol, thereby ensuring the validity of the negotiation result.

[0011] In some embodiments of this application, the negotiation process includes: Establish a communication connection with the server device; Send a first control message to the server device for performing the negotiation process; Receive a second control message sent by the server device for performing the negotiation process.

[0012] Thus, in this embodiment of the application, a communication connection can be established with the server device, and a first control message for negotiation processing can be sent to the server device, and a second control message for negotiation processing can be received from the server device, thereby completing the negotiation between the gateway device and the client device.

[0013] In some embodiments of this application, the gateway device includes a switching chip, and sending a first control message to the server device for performing the negotiation process includes: Upon receiving a first control message sent by the kernel protocol stack through the first virtual network interface, the target data interaction port on the switching chip corresponding to the first virtual network interface is determined, and the target physical port on the switching chip used to send the first control message is determined. The first control message and the first tag are encapsulated to obtain a first encapsulated message, wherein the first tag is used to identify the target physical port on the switching chip used to send the first control message; The first encapsulated message is sent to the switching chip through the target data interaction port. When the switching chip receives the first encapsulated message, it sends the first encapsulated message to the target physical port according to the first tag in the first encapsulated message, so as to send the first encapsulated message to the server device.

[0014] Thus, in this embodiment of the application, when a first control message sent by the kernel protocol stack is received through the first virtual network interface, the target data interaction port on the switching chip corresponding to the first virtual network interface is determined, the target physical port on the switching chip used to send the first control message is determined, and the first control message and the first tag are encapsulated to obtain a first encapsulated message. The first encapsulated message is then sent to the switching chip through the target data interaction port, thereby achieving efficient transmission of the first control message.

[0015] In some embodiments of this application, receiving the second control message sent by the server device for performing the negotiation process includes: The second control message and the second tag sent by the switching chip are received through the target data interaction port. When the switching chip receives the second control message, it determines the second tag of the second control message. The second tag is used to identify the physical port on the switching chip that receives the second control message. Based on the second tag and the pre-determined tag interface mapping data, a second virtual network interface corresponding to the second tag is determined, wherein the tag interface mapping data includes multiple tags and the virtual network interface corresponding to each tag; The second control message is sent to the kernel protocol stack through the second virtual network interface.

[0016] Thus, in this embodiment of the application, the second control message and the second tag sent by the switching chip can be received through the target data interaction port, and the second virtual network interface corresponding to the second tag can be determined according to the second tag and the predetermined tag interface mapping data, and the second control message can be sent to the kernel protocol stack through the second virtual network interface, thereby realizing the reception of the second control message.

[0017] In some embodiments of this application, the method further includes: Detect whether the configuration information has been updated in the target database; If an update to the configuration information is detected, the updated configuration information is read from the target database to obtain the target configuration information.

[0018] Thus, in this embodiment, it is possible to detect whether the configuration information in the target database has been updated, and if the update is detected, the updated configuration information in the target database is read to obtain the target configuration information, so that subsequent negotiation processing can be based on the updated configuration information, thereby ensuring the robust execution of the negotiation processing.

[0019] In some embodiments of this application, the method further includes: If the configuration information sent by the client device is obtained, the configuration information sent by the client device is stored in the target database to trigger the update of the configuration information in the target database.

[0020] Thus, in this embodiment of the application, when the configuration information sent by the client device is obtained, the configuration information sent by the client device can be stored in the target database to trigger the update of the configuration information in the target database, thereby realizing the timely update of the target configuration information.

[0021] In some embodiments of this application, forwarding packets generated by one of the client device and the server device to the other device based on the point-to-point tunnel, the session entry, and a pre-created vector packet processing node includes: Upon receiving the first original message sent by the client device, the first source network address information in the first original message is replaced according to the first vector packet processing node and the point-to-point tunnel to obtain the second original message. The second vector packet processing node queries routing information that matches the first destination network address in the first original message; If the routing information is the point-to-point tunnel, the second original packet is encapsulated using the point-to-point tunnel and the session entry to obtain the first encapsulated packet; Based on the point-to-point tunnel and the third vector packet processing node, the first encapsulated message is sent to the server device.

[0022] Thus, in this embodiment, upon receiving a first original message from a client device, the first source network address information in the first original message is replaced according to the first vector packet processing node and the point-to-point tunnel to obtain a second original message. Then, the routing information matching the first destination network address in the first original message is queried through the second vector packet processing node. If the routing information is a point-to-point tunnel, the second original message is encapsulated through the point-to-point tunnel and session entries to obtain a first encapsulated message. Finally, the first encapsulated message is sent to the server device according to the point-to-point tunnel and the third vector packet processing node, thereby realizing message uplink from the client device to the server device.

[0023] In some embodiments of this application, the method further includes: When a third original message is received at the local area network interface, the third original message is parsed to obtain the physical address, source network address and second destination network address of the third original message. Verify the physical address; If the physical address is verified, the source network address matches the client device, and the second destination network address matches the server device, the third original message is used to determine the first original message sent by the client device.

[0024] Thus, in this embodiment, when a third original message is received at the local area network interface, the third original message can be parsed to obtain its physical address, source network address, and second destination network address. The physical address is then verified. If the physical address passes verification, the source network address matches the client device, and the second destination network address matches the server device, the third original message is identified as the first original message sent by the client device. This filters out irrelevant and malicious attack messages within the local area network, preventing gateway device resources from being occupied by invalid or malicious attack messages. It ensures that the gateway device's processing capacity is focused on forwarding business messages between the client and server, thereby guaranteeing overall forwarding efficiency.

[0025] In some embodiments of this application, when the first destination network address in the first original message is the network address of the server device, the routing information is the point-to-point tunnel.

[0026] In some embodiments of this application, the first source network address information includes a first Internet Protocol address and a first network port number. Upon receiving the first original message sent by the client device, the first source network address information in the first original message is replaced according to the first vector packet processing node and the point-to-point tunnel to obtain a second original message, including: Upon receiving the first original message, the first vector packet processing node replaces the first Internet Protocol address with the first Internet Protocol address bound to the point-to-point tunnel, and replaces the first network port number with a randomly determined second network port number to obtain the second original message.

[0027] Thus, in this embodiment of the application, upon receiving the first original message, the first vector packet processing node replaces the first Internet Protocol address with the second Internet Protocol address bound to the point-to-point tunnel, and replaces the first network port number with a randomly determined second network port number to obtain the second original message. This achieves the replacement of the first Internet Protocol address with the private attributes of the intranet with the second Internet Protocol address bound to the tunnel, and avoids the conflict problem caused by the fixed port by using the randomly generated second network port number, thus ensuring the security of cross-network communication between the client and the server.

[0028] In some embodiments of this application, forwarding packets generated by one of the client device and the server device to the other device based on the point-to-point tunnel, the session entry, and a pre-created vector packet processing node includes: Upon receiving the second encapsulated message sent by the server device, the fourth vector packet processing node performs parsing processing to obtain the fourth original message, target tunnel parameters, and third destination network address in the second encapsulated message. By querying the session table entry using the target tunnel parameters and the third destination network address, a target peer-to-peer tunnel corresponding to both the target tunnel parameters and the third destination network address is determined. The session table entry includes multiple peer-to-peer tunnels and includes the tunnel parameters and destination network address corresponding to each peer-to-peer tunnel. Based on the target point-to-point tunnel, the second source network address information in the fourth original message is restored to obtain the fifth original message; The fifth original message is sent to the client device via the fifth vector packet processing node.

[0029] Thus, in this embodiment of the application, when the second encapsulated message sent by the server device is received, the fourth vector packet processing node performs parsing processing to obtain the fourth original message, target tunnel parameters, and third destination network address in the second encapsulated message. The session table entry is then queried using the target tunnel parameters and the third destination network address to determine the target point-to-point tunnel that corresponds to both the target tunnel parameters and the third destination network address. Based on the target point-to-point tunnel, the second source network address information in the fourth original message is restored to obtain the fifth original message. Finally, the fifth original message is sent to the client device through the fifth vector packet processing node, thereby realizing the downlink message transmission from the server device to the client device.

[0030] In some embodiments of this application, the step of parsing the second encapsulated message sent by the server device to obtain the fourth original message, target tunnel parameters, and third destination network address from the second encapsulated message includes: When the second encapsulated message is received at the WAN interface, the header of the second encapsulated message is parsed by the sixth vector packet processing node to obtain the message header parsing result. If the protocol field in the parsing result of the message header is the target field, the fourth vector packet processing node performs parsing processing to obtain the fourth original message, target tunnel parameters and third destination network address in the second encapsulated message.

[0031] Thus, in this embodiment, when the second encapsulated message is received at the WAN interface, the header of the second encapsulated message is parsed by the sixth vector packet processing node to obtain the message header parsing result. If the protocol field in the message header parsing result is a target field, it is parsed by the fourth vector packet processing node to obtain the fourth original message, target tunnel parameters, and third destination network address in the second encapsulated message. This allows for filtering out irrelevant messages whose protocol fields are not target fields through message header parsing, thus avoiding logical confusion caused by parsing irrelevant messages and improving the accuracy of extracting the fourth original message, target tunnel parameters, and third destination network address. Furthermore, based on the batch parsing mechanism of the vector packet processing node, multiple messages can be parsed at once, ensuring message parsing speed and thus ensuring that downlink messages can be quickly delivered to the target client.

[0032] In some embodiments of this application, the second source network address information includes a third Internet Protocol address and a third port number, the third Internet Protocol address being bound to the target peer-to-peer tunnel. The step of performing information restoration processing on the second source network address information in the fourth original message based on the target peer-to-peer tunnel to obtain a fifth original message includes: Replace the third Internet Protocol address with the fourth Internet Protocol address corresponding to the third Internet Protocol address in the address translation data corresponding to the target point-to-point tunnel; The third port number is replaced with the fourth port number corresponding to the third port number to obtain the fifth original message.

[0033] Thus, in this embodiment of the application, the third Internet Protocol address can be replaced with the fourth Internet Protocol address corresponding to the third Internet Protocol address in the address translation data corresponding to the target point-to-point tunnel, and the third port number can be replaced with the fourth port number corresponding to the third port number to obtain the fifth original message. This realizes the restoration of Internet Protocol address and port number, thereby enabling the client to accurately identify the source of the server message, thereby ensuring the robust downlink of the message.

[0034] This application provides a message processing apparatus for use in a gateway device, wherein a client device is connected to a server device through the gateway device, and the apparatus includes: The parameter determination module is used to determine the tunnel parameters used to create a point-to-point tunneling protocol virtual private network; A creation module is used to create a point-to-point tunnel and a corresponding session entry based on the tunnel parameters. The client device communicates with the server device through the point-to-point tunnel, and the session entry is used to determine the message processing rules when the client device and the server device communicate. The forwarding module is used to forward packets generated by one of the client devices and the server devices to the other device based on the point-to-point tunnel, the session entries, and the pre-created vector packet processing nodes.

[0035] This application provides a gateway device, including a memory and a processor. The memory stores a computer program, which, when executed by the processor, implements the above-described message processing method.

[0036] This application provides a computer-readable storage medium storing a computer program that, when executed by one or more processors, implements the above-described message processing method.

[0037] This application provides a computer program product, including a computer program / instruction, which, when executed by a processor, implements the above-described message processing method.

[0038] The message processing apparatus, gateway device, computer-readable storage medium, and computer program product provided in this application can determine tunnel parameters for creating a point-to-point tunneling protocol virtual private network (P2P network), and create point-to-point tunnels and corresponding session entries based on the tunnel parameters. Furthermore, based on the point-to-point tunnels, session entries, and pre-created vector packet processing nodes, it forwards messages generated by one end device (client device or server device) to the other end device. This enables message forwarding based on the packet batch processing capabilities of the vector packet processing nodes. Compared to implementing a P2P network through the kernel, this reduces CPU interrupt and memory copy overhead, thereby improving the message forwarding performance of the P2P network.

[0039] Additional aspects and advantages of embodiments of this application will be set forth in part in the description which follows, and in part will be obvious from the description, or may be learned by practice of embodiments of this application. Attached Figure Description

[0040] The above and / or additional aspects and advantages of this application will become apparent and readily understood from the description of the embodiments taken in conjunction with the following drawings, wherein: Figure 1 This is a flowchart illustrating a message processing method in certain embodiments of this application; Figure 2 This is a schematic diagram of a message processing apparatus in some embodiments of this application; Figure 3 This is a schematic diagram of a gateway device in some embodiments of this application; Figure 4 This is a flowchart illustrating a message processing method in certain embodiments of this application; Figure 5 This is a flowchart illustrating a message processing method in certain embodiments of this application; Figure 6 This is a flowchart illustrating a message processing method in certain embodiments of this application; Figure 7 This is a schematic diagram illustrating application scenarios in some embodiments of this application; Figure 8 This is a schematic diagram illustrating application scenarios in some embodiments of this application; Figure 9 This is a schematic diagram illustrating application scenarios in some embodiments of this application. Detailed Implementation

[0041] The embodiments of this application are described in detail below. Examples of the embodiments are shown in the accompanying drawings, wherein the same or similar reference numerals denote the same or similar elements or elements having the same or similar functions throughout. The embodiments described below with reference to the accompanying drawings are exemplary and are only used to explain the embodiments of this application, and should not be construed as limiting the embodiments of this application.

[0042] Among related technologies, PPTP VPN (Point-to-Point Tunneling Protocol Virtual Private Network) is widely used in enterprise branch office interconnection and mobile office access scenarios due to its ease of deployment and cross-operating system compatibility, as it is built into and supported by systems such as Windows and Linux. Understandably, PPTP VPN achieves secure remote access by establishing a point-to-point tunneling protocol (PPTP).

[0043] For example, an end user (or client) initiates a connection request through the PPTP VPN client gateway. Upon response, the server assigns an inner-tunnel IP (Internet Protocol) address to the client, establishing the tunnel. When a user's request packet for accessing intranet resources reaches the gateway device, the gateway performs SNAT (Source Network Address Translation) to replace the source IP address of the original packet with its own public IP address. Then, it encapsulates the address-translated packet into PPTP data format using GRE (Generic Routing Encapsulation). Finally, the gateway device transmits the encapsulated packet through the outer-tunnel Internet to the PPTP VPN server according to its routing policy. Upon receiving the packet, the server performs decapsulation, route lookup, and other processing sequentially. The response data is then returned to the client via the reverse path, forming an end-to-end bidirectional communication channel.

[0044] It is worth noting that the traditional implementation of PPTP VPN relies on the Linux kernel, such as the control plane negotiation function based on the PPTP module in the kernel, and the packet forwarding function based on the GRE (Generic Routing Encapsulation) protocol processing module and the PPP (Point-to-Point Protocol) module in the kernel.

[0045] Specifically, in the control plane negotiation function implemented based on the PPTP module in the kernel, the kernel module on the server side creates a listening socket through the TCP (Transmission Control Protocol) Socket API (Application Programming Interface). The client initiates a PPTP connection request. After the client and server establish a TCP connection, the PPTP module in the kernel parses the PPTP control messages sent by the client, such as SCCRQ and SCCRP, and completes the link control protocol negotiation, authentication protocol interaction, and network control protocol parameter configuration.

[0046] Furthermore, in the packet forwarding function implemented based on the GRE protocol processing module and PPP module in the kernel, after the control negotiation successfully establishes a PPTP session, the kernel allocates a GRE tunnel endpoint for the session. For inbound packets, the kernel module verifies the GRE header and matches the corresponding PPTP session and virtual interface according to the Call ID. After stripping the GRE header, a PPP (Point-to-Point Protocol) frame is obtained. This PPP frame is delivered to the kernel PPP module, which strips the PPP header, restores the original IP packet, and re-injects it into the upper layer of the kernel protocol stack for routing and forwarding. For outbound packets, the original IP packet is routed to the virtual interface, where the kernel PPP module adds a PPP frame header. Subsequently, the GRE module adds an enhanced GRE header to it, carrying the Call ID. Finally, the GRE module encapsulates the packet with an outer IP header and sends it out through the system's physical network card.

[0047] Understandably, this PPTP VPN solution, implemented entirely based on kernel modules, handles data plane traffic through the kernel protocol stack. Consequently, the per-packet processing mechanism of the kernel protocol stack can lead to high CPU (Central Processing Unit) interrupt frequencies and memory copy overhead, resulting in limited throughput and ultimately poor performance, making it difficult to meet the line-speed forwarding requirements of high-performance gateways. Furthermore, due to the high latency of switching between kernel and user modes and the inability to effectively utilize the parallel capabilities of multi-core CPUs, performance drops sharply when the number of concurrent connections surges, resulting in insufficient scalability.

[0048] Therefore, to address the various issues in the aforementioned PPTP VPN implementation schemes, a PPTP VPN implementation scheme based on VPP (Vector Packet Processing) has been proposed in related technologies. This involves implementing PPTP VPN through the DPDK (Data Plane Development Kit) and VPP (Vector Packet Processing) architecture. VPP, as a high-performance user-space protocol stack, is characterized by operating in user space and providing high-performance network data processing capabilities, making it suitable for fields such as cloud computing, network function virtualization, high-performance gateways, edge computing, and the Internet of Things.

[0049] Furthermore, VPP deployment is often achieved through DPDK (Data Plane Development Kit) and the VPP architecture. DPDK provides a high-performance I / O (Input / Output) foundation, while VPP integrates DPDK drivers as plug-ins. However, in PPTP VPN scenarios, VPP has two key shortcomings: first, it lacks a control plane, failing to implement the control plane negotiation functions required by PPTP, such as TCP port connection and Call-ID negotiation; second, its data plane is incomplete, lacking standard PPTP GRE / PPP dual-layer encapsulation and decapsulation, and lacking PPP protocol field processing logic, such as protocol compression.

[0050] Based on the issues mentioned above, please refer to Figure 1 This application provides a message processing method for use in a gateway device, wherein a client device connects to a server device through the gateway device, and the method includes: 01: Determine the tunnel parameters used to create a Point-to-Point Tunneling Protocol Virtual Private Network; 02: Based on the tunnel parameters, create point-to-point tunnels and corresponding session entries. The client device communicates with the server device through the point-to-point tunnel, and the session entries are used to determine the message processing rules when the client device and the server device communicate. 03: Based on the point-to-point tunnel, session entries, and pre-created vector packet processing nodes, forward packets generated by one end device (client device or server device) to the other end device.

[0051] Please see Figure 2This application provides a message processing apparatus 200. The message processing method of this application can be implemented by the message processing apparatus 200. Specifically, the message processing apparatus 200 includes a parameter determination module 210, a creation module 220, and a forwarding module 230. The parameter determination module 210 is used to determine the tunnel parameters for creating a point-to-point tunneling protocol virtual private network. The creation module 220 is used to create a point-to-point tunnel and a corresponding session entry based on the tunnel parameters. The client device communicates with the server device through the point-to-point tunnel, and the session entry is used to determine the message processing rules when the client device and the server device communicate. The forwarding module 230 is used to forward messages generated by one end device (client device or server device) to the other end device based on the point-to-point tunnel, the session entry, and a pre-created vector packet processing node.

[0052] Please see Figure 3 This application also provides a gateway device 300, which includes a memory 310 and a processor 320. The message processing method of this application can be implemented by the gateway device 300. Specifically, the memory 310 stores a computer program 311, and the processor 320 is used to determine tunnel parameters for creating a point-to-point tunneling protocol virtual private network, and to create point-to-point tunnels and corresponding session entries based on the tunnel parameters, and to forward messages generated by one end device (client device or server device) to the other end device based on the point-to-point tunnels, session entries, and pre-created vector packet processing nodes. The client device communicates with the server device through the point-to-point tunnel, and the session entries are used to determine the message processing rules when the client device and the server device communicate.

[0053] Specifically, considering the performance limitations and insufficient scalability of implementing PPTP VPN entirely through the kernel, this application provides a PPTP VPN implementation based on control-forwarding separation and VPP. Specifically, in the packet processing method provided in this application, the electronic device can determine the tunnel parameters used to create the PPTP VPN, and based on the tunnel parameters, create a point-to-point tunnel and corresponding session entries, and based on the created point-to-point tunnel, the generated session entries, and the pre-created VPP nodes, forward packets generated by one end of the client device and the server device to the other end device.

[0054] In some implementations, a gateway device can be understood as a network device that connects the local area network where the client device is located to the public network (or wide area network) where the server device is located, and undertakes key functions such as packet forwarding, protocol processing, security authentication, and address translation.

[0055] In some examples, the gateway device may include a high-performance gateway device suitable for the campus.

[0056] In some examples, a gateway device can be understood as a network device that requires high-performance network processing and VPN functionality, such as a VPN router or PPTP server.

[0057] In some implementations, a client device can be understood as a terminal device or a node within a local area network that needs to access the server device via PPTP VPN to obtain resources or communicate.

[0058] In some examples, client devices include personal computers, office computers, enterprise branch network terminals, mobile office devices, etc.

[0059] In some implementations, the server device can be understood as a network device that provides PPTP VPN services and has the ability to receive client connection requests, complete tunnel negotiation, verify client identity, and provide resource access entry points.

[0060] In some implementations, PPTP VPN (i.e., Point-to-Point Tunneling Protocol Virtual Private Network) refers to a VPN (Virtual Private Network) built on PPTP (Point-to-Point Tunneling Protocol), which enables secure data transmission between client devices and server devices by establishing encrypted tunnels over public networks (such as the Internet).

[0061] In some implementations, tunnel parameters can be understood as the critical configuration and negotiation information required to create a PPTP VPN tunnel.

[0062] In some examples, tunnel parameters include tunnel identifier (Call ID), encryption key, inner tunnel IP (Internet Protocol) address, tunnel endpoint IP address, authentication-related parameters, etc.

[0063] In some implementations, a point-to-point tunnel can be understood as a logical communication channel established between a client device and a server device based on the PPTP protocol, which can hide private data packets in packets transmitted over a public network through encapsulation technology.

[0064] In some implementations, a session entry can be understood as a configuration and status information table stored in the gateway device corresponding to a specific PPTP tunnel, used to constrain the message processing rules for client devices and server devices sending and receiving messages.

[0065] In some implementations, session entries include network address mappings at both ends of the tunnel, packet encapsulation / decapsulation rules, encryption / decryption context, routing information, etc.

[0066] In some implementations, a vector packet processing node can be understood as a message processing unit built on VPP (Vector Packet Processing) technology, which adopts a batch processing and vectorized operation mechanism and can process multiple messages at once.

[0067] To more clearly illustrate the implementation methods of this application, please refer to the following exemplary description: The gateway device first obtains the PPTP VPN configuration information sent by the client, such as the server address, authentication method, encryption policy, etc., and establishes a communication connection with the server device, such as based on TCP (Transmission Control Protocol), through the control plane negotiation process (such as the pppd process), to complete the link control protocol negotiation, authentication interaction, network control protocol parameter configuration and other processes, and finally determines the tunnel parameters.

[0068] Then, the gateway device creates a point-to-point tunnel in the data plane according to the tunnel parameters obtained through negotiation, and generates a corresponding session entry. It stores information such as Call ID, encryption key, and IP address mapping in the session entry, as well as information such as packet encapsulation format, routing path, and encryption method in the session entry.

[0069] Based on this, when the original message generated by the client enters through the LAN interface of the gateway device, the VPP node first parses the message, verifies the physical address, and extracts the network address. Then, through the NAT (Network Address Translation) node, the client's source IP is replaced with the public IP bound to the point-to-point tunnel, and the address mapping relationship is recorded, that is, the mapping relationship between the client's source IP and the public IP bound to the point-to-point tunnel. Subsequently, the routing table is queried and the point-to-point tunnel is matched. According to the rules in the session table, the message is encapsulated with PPP frames and GRE headers. Finally, it is sent in batches to the server device through the vector packet processing node.

[0070] Conversely, when the encapsulated message sent by the server enters through the WAN interface of the gateway device, the VPP node parses the message header, identifies the GRE protocol fields, and then decapsulates it, stripping away the GRE header and PPP frame header. Then, it queries the session table entry using the Call ID and inner destination IP to match the corresponding tunnel and encryption key, thereby completing the data decryption. Finally, it restores the client's original address through NAT reverse translation and forwards the message to the client device through routing lookup.

[0071] Thus, in this embodiment, tunnel parameters for creating a point-to-point tunneling protocol virtual private network can be determined, and point-to-point tunnels and corresponding session entries can be created based on the tunnel parameters. Based on the point-to-point tunnels, session entries, and pre-created vector packet processing nodes, packets generated by one end device (client device or server device) are forwarded to the other end device. This allows packet forwarding based on the packet batch processing capabilities of the vector packet processing nodes. Compared to implementing a point-to-point tunneling protocol virtual private network through the kernel, this reduces CPU interrupt and memory copy overhead, thereby improving the packet forwarding performance of the point-to-point tunneling protocol virtual private network.

[0072] Furthermore, because the packet forwarding between client and server devices is handled by vector packet processing nodes, the tunnel protocol virtual private network can be flexibly expanded, thereby meeting the performance requirements of the gateway.

[0073] In some embodiments of this application, step 01 includes: negotiating with the server device based on the target configuration information of the obtained point-to-point tunneling protocol virtual private network to obtain tunnel parameters.

[0074] The parameter determination module in this application embodiment is also used to negotiate with the server device based on the target configuration information of the obtained point-to-point tunnel protocol virtual private network to obtain tunnel parameters.

[0075] The processor in this embodiment is also used to negotiate with the server device based on the target configuration information of the obtained point-to-point tunneling protocol virtual private network to obtain tunnel parameters.

[0076] Specifically, in order to determine the tunnel parameters, in some embodiments provided in this application, the gateway device can obtain the target configuration information of the PPTP VPN and negotiate with the server device through the information to finally obtain the tunnel parameters required to create the PPTP VPN.

[0077] In some implementations, target configuration information can be understood as configuration data used to guide the establishment of PPTP VPN tunnels, or as information sent by the client according to actual communication needs.

[0078] In some examples, the target configuration information includes, but is not limited to, PPTP server address, authentication method, encryption policy, tunnel priority, maximum transmission unit count, etc.

[0079] In some implementations, the negotiation process can be understood as a series of interactive processes carried out by the gateway device and the server device based on the target configuration information and in accordance with the relevant PPTP protocol specifications. This process can confirm the communication capabilities of both parties and reach a consensus on parameters, ultimately generating the key parameters required for tunnel establishment.

[0080] In some examples, the negotiation process may include link negotiation, authentication verification, parameter configuration, and other steps.

[0081] To more clearly illustrate the implementation methods of this application, please refer to the following exemplary description: Users send PPTP VPN configuration information through the UI (User Interface) displayed on the client device or through a dedicated interface. Correspondingly, the gateway device obtains the PPTP VPN configuration information from the client device through pre-defined receiving channels such as the management plane interface or database subscription. After verifying the format of the PPTP VPN configuration information and confirming that no fields are missing and that the parameters are valid, the gateway device determines the configuration information as the target configuration information that can be used for negotiation.

[0082] Then, the gateway device initiates a TCP connection request to the server device based on the server address in the target configuration information. The request may carry negotiation fields from the target configuration information, such as authentication method identifier and encryption capability declaration, thereby informing the server device of the baseline requirements for this negotiation.

[0083] Then, link control protocol negotiation, authentication protocol interaction, and network control protocol parameter configuration can be performed.

[0084] Link control protocol negotiation can be understood as the process by which gateway devices and server devices negotiate with each other based on parameters such as MTU (Maximum Transmission Unit) settings and link timeout thresholds in the target configuration information, thereby establishing a data link connection.

[0085] The authentication protocol interaction can be understood as the gateway device sending an authentication request to the server device according to the authentication method specified in the target configuration information. This request may contain the username, encrypted password, etc. After the server device verifies the authentication, it returns an authentication confirmation message.

[0086] Network control parameter configuration can be understood as the negotiation between the gateway device and the client device on the IP address allocation scheme within the tunnel, determining the private IP addresses used by the client and the server within the tunnel, and confirming network parameters such as the DNS (Domain Name System) server address and routing priority.

[0087] When the link control protocol negotiation, authentication protocol interaction, and network control negotiation parameter configuration are all completed and there are no conflicts, the gateway device and the server device reach a communication consensus. The gateway device extracts key information from the negotiation results and integrates it into complete tunnel parameters, including Call ID (unique tunnel identifier), encryption key, client inner IP, server inner IP, and public network endpoint addresses at both ends of the tunnel.

[0088] Thus, in this embodiment of the application, the tunnel parameters can be obtained by negotiating with the server device based on the target configuration information of the point-to-point tunneling protocol virtual private network, thereby achieving robust acquisition of tunnel parameters.

[0089] In some embodiments of this application, the step of negotiating with the server device to obtain tunnel parameters based on the obtained target configuration information of the point-to-point tunneling protocol virtual private network includes: Given the target configuration information of the point-to-point tunneling protocol virtual private network, the tunnel parameters are obtained by negotiating with the server device through a pre-determined challenge handshake authentication protocol process.

[0090] The parameter determination module in this application embodiment is further used to obtain tunnel parameters by negotiating with the server device through a pre-determined challenge handshake authentication protocol process, based on the target configuration information of the obtained point-to-point tunnel protocol virtual private network.

[0091] The processor in this embodiment is further configured to, upon obtaining the target configuration information of the point-to-point tunneling protocol virtual private network, negotiate with the server device through a predetermined challenge handshake authentication protocol process to obtain tunnel parameters.

[0092] Specifically, to ensure robustness and security during the negotiation process, in one embodiment provided in this application, after obtaining the target configuration information of the PPTP VPN, the electronic device can conduct a complete negotiation process with the server device through a pre-determined Challenge Handshake Authentication Protocol process, thereby robustly creating the tunnel parameters required for the PPTP VPN.

[0093] In some implementations, the challenge handshake authentication protocol process can be understood as a dedicated control plane processing unit based on the challenge handshake authentication protocol (CHAP), or as a process component pre-deployed in the control layer of the gateway device.

[0094] In some implementations, the challenge handshake authentication protocol process can send a random challenge code from the server to the client. The client generates a response message using its own key, and the server verifies the validity of the response to complete the identity authentication. The entire process does not transmit plaintext passwords, thus providing high security.

[0095] Thus, in this embodiment of the application, given the target configuration information of the point-to-point tunneling protocol virtual private network, the tunnel parameters can be obtained by negotiating with the server device through a pre-determined challenge handshake authentication protocol process. This allows the negotiation with the server device to be executed through the challenge handshake authentication protocol, thereby ensuring the validity of the negotiation results.

[0096] In some embodiments of this application, the negotiation process includes: establishing a communication connection with a server device, sending a first control message for negotiation processing to the server device, and receiving a second control message for negotiation processing sent by the server device.

[0097] The parameter determination module in this application embodiment is also used to establish a communication connection with the server device, send a first control message for negotiation processing to the server device, and receive a second control message for negotiation processing sent by the server device.

[0098] The processor in this embodiment is also configured to establish a communication connection with a server device, send a first control message for negotiation processing to the server device, and receive a second control message for negotiation processing sent by the server device.

[0099] Specifically, in some embodiments provided in this application, the negotiation process may include three steps: establishing a communication connection, sending a first control message, and receiving a second control message, thereby jointly realizing the standardized interaction between the gateway device and the server device and ensuring that the tunnel parameters can be negotiated accurately and efficiently.

[0100] In some implementations, a communication connection can be understood as a connection-oriented network connection established between a gateway device and a server device based on the Transmission Control Protocol, which provides a communication link for the reliable transmission of control messages.

[0101] In some implementations, the first control message can be understood as a message sent by the gateway device to the server device to initiate a negotiation request.

[0102] In some examples, the first control message contains configuration information required for tunnel establishment, such as authentication parameters and client network configuration requirements. It is understood that the first control message conforms to the PPTP protocol specification and related industry standards, such as RFC2637.

[0103] In some implementations, the second control message can be understood as a message returned by the server device to the gateway device after responding to the first control message.

[0104] In some examples, the second control message contains server confirmation of the negotiation request, as well as server-side configuration parameters, such as the assigned tunnel identifier and server network address.

[0105] To more clearly illustrate the implementation methods of this application, please refer to the following exemplary description: First, the gateway device initiates a connection request to the server device via Transmission Control Protocol (TCP) based on the acquired target configuration information. The server device listens on a preset negotiation port and, upon receiving the connection request, confirms the connection, completes the three-way handshake process, and establishes a stable TCP communication connection between the gateway device and the server device.

[0106] After the communication connection is established, the gateway device constructs a first control message based on the target configuration information and sends the first control message to the server device in sequence through the established TCP communication connection. Simultaneously, a timeout retransmission mechanism is initiated. If no response is received from the server within a preset time, the first control message is retransmitted to ensure successful reception by the server. The first control message may contain key configuration information required for tunnel establishment, such as the authentication methods supported by the client, the network protocol version, and the tunnel establishment request identifier.

[0107] After receiving the first control message, the server device parses it and extracts the negotiation request information. Based on its PPTP VPN configuration policy, the server device generates a second control message. This second control message then contains key information such as confirmation of the negotiation result, the assigned tunnel identifier (Call ID), the server's public IP address, and allowed network configuration parameters.

[0108] Then, the server device returns the second control message to the gateway device through the previously established TCP communication connection.

[0109] After receiving the second control message, the gateway device verifies its integrity and validity, such as checking the header checksum and ensuring the acknowledgment identifier matches the request identifier. If the verification passes, the gateway device extracts key information from the message, such as the tunnel identifier, and ultimately completes the negotiation process.

[0110] Thus, in this embodiment of the application, a communication connection can be established with the server device, and a first control message for negotiation processing can be sent to the server device, and a second control message for negotiation processing can be received from the server device, thereby completing the negotiation between the gateway device and the client device.

[0111] In some embodiments provided in this application, the gateway device includes a switching chip. The step of sending a first control message for negotiation processing to the server device includes: upon receiving a first control message sent by the kernel protocol stack through a first virtual network interface, determining a target data interaction port on the switching chip corresponding to the first virtual network interface, determining a target physical port on the switching chip for sending the first control message, encapsulating the first control message and a first tag to obtain a first encapsulated message, and sending the first encapsulated message to the switching chip through the target data interaction port. The first tag is used to identify the target physical port on the switching chip for sending the first control message. Upon receiving the first encapsulated message, the switching chip sends the first encapsulated message to the target physical port according to the first tag in the first encapsulated message, thereby sending the first encapsulated message to the server device.

[0112] The parameter determination module in this application embodiment is further configured to, upon receiving a first control message sent by the kernel protocol stack through the first virtual network interface, determine the target data interaction port on the switching chip corresponding to the first virtual network interface, determine the target physical port on the switching chip used to send the first control message, encapsulate the first control message and a first tag to obtain a first encapsulated message, and send the first encapsulated message to the switching chip through the target data interaction port. The first tag is used to identify the target physical port on the switching chip used to send the first control message. Upon receiving the first encapsulated message, the switching chip sends the first encapsulated message to the target physical port according to the first tag in the first encapsulated message, thereby sending the first encapsulated message to the server device.

[0113] The processor in this embodiment is further configured to, upon receiving a first control message sent by the kernel protocol stack through a first virtual network interface, determine a target data interaction port on the switching chip corresponding to the first virtual network interface, determine a target physical port on the switching chip used to send the first control message, encapsulate the first control message and a first tag to obtain a first encapsulated message, and send the first encapsulated message to the switching chip through the target data interaction port. The first tag is used to identify the target physical port on the switching chip used to send the first control message. Upon receiving the first encapsulated message, the switching chip sends the first encapsulated message to the target physical port according to the first tag in the first encapsulated message, thereby sending the first encapsulated message to the server device.

[0114] Specifically, in PPTP VPN scenarios where gateway devices integrate switching chips, the forwarding of the first control message needs to consider the interface mapping between the kernel protocol stack and the switching chip. In other words, if the virtual network interface and the physical port of the switching chip cannot be accurately matched, it can easily lead to disordered message forwarding paths. At the same time, in traditional forwarding methods, the switching chip needs to query data such as the MAC (Media Access Control Address) table to determine the forwarding port, which increases message processing latency and makes it difficult to guarantee the transmission stability of control messages.

[0115] Based on this, in some embodiments provided in this application, the electronic device can establish a correspondence between the first virtual network interface and the data interaction port of the switching chip and the target physical port through preset rules, add a first tag identifying the target physical port to the first control message and encapsulate it, and finally send the encapsulated message to the switching chip through the target data interaction port. The switching chip forwards the message directly to the target physical port according to the tag, thereby realizing the efficient and accurate transmission of the first control message to the server.

[0116] In some implementations, the switching chip can be understood as the core hardware component in the gateway device responsible for data link layer forwarding, with multi-port data switching capability, enabling message forwarding between different ports, and used to connect virtual network interfaces and physical ports.

[0117] In some implementations, the first virtual network interface can be understood as a virtual interface in the gateway device used to realize data interaction between the kernel protocol stack and the switching chip, such as the TAP interface, or as a logical channel for the kernel protocol stack to transmit the first control message to the switching chip.

[0118] In some implementations, the kernel protocol stack can be understood as a collection of software modules within the operating system kernel that implement network protocols such as TCP / IP and PPP, responsible for handling logic such as protocol parsing and encapsulation initialization of control messages. It is understood that after generating the first control message, the kernel protocol stack outputs it through a virtual network interface.

[0119] In some implementations, the first control message can be understood as a control-type data frame used for negotiating PPTP VPN tunnel parameters.

[0120] In some examples, the first control message contains LCP (Link Control Protocol) negotiation requests, authentication parameters, IPCP (Internet Protocol Control Protocol) configuration information, and other content.

[0121] In some implementations, the target data interaction port can be understood as a pre-configured port on the switching chip that uniquely corresponds to the first virtual network interface, such as a CPU direct output port. It is understood that the target data interaction port can be used to receive messages from the first virtual network interface, thereby enabling hardware-level data interaction between the virtual interface and the switching chip.

[0122] In some implementations, the target physical port can be understood as the physical interface on the switching chip used to connect to the Wide Area Network (WAN), that is, the hardware exit point from which the first control message is sent from the gateway device to the server device.

[0123] In some implementations, the first tag can be understood as a tag field containing the identification information of the target physical port of the switching chip, such as the TCI (Tag Control Information) field in the DSA (Distributed Switch Architecture) tag, which is unique and used to identify the forwarding destination of the packet.

[0124] To more clearly illustrate the implementation methods of this application, please refer to the following exemplary description: First, after the kernel protocol stack completes the generation and protocol processing of the first control message, it sends the message to the processing module of the gateway device, such as the VPP module, through the pre-bound first virtual network interface.

[0125] Then, after the VPP module detects the packet input of the first virtual network interface, it determines the target data interaction port of the switching chip corresponding to the virtual interface (such as the CPU direct output port) according to the preset interface-port mapping rules. At the same time, it determines the target physical port (such as the WAN physical interface) used to send the packet according to the server address and routing information in the VPN configuration.

[0126] Subsequently, the VPP module calls the encapsulation interface to encapsulate and integrate the first tag containing the target physical port identifier with the first control message. That is, the first tag is added to the message header, such as the TCI field in the DSA header, thereby generating the first encapsulated message.

[0127] Then, the VPP module transmits the first encapsulated message to the switching chip via the target data interaction port in a hardware-accelerated manner.

[0128] Finally, after receiving the first encapsulated message, the switching chip parses the first tag in the header, extracts the target physical port identifier, and directly forwards the first encapsulated message to the corresponding target physical port without querying the MAC table or other routing table entries. The target physical port then sends the first encapsulated message to the server device through the wide area network link, completing the transmission of the first control message.

[0129] Thus, in this embodiment of the application, when a first control message sent by the kernel protocol stack is received through the first virtual network interface, the target data interaction port on the switching chip corresponding to the first virtual network interface is determined, the target physical port on the switching chip used to send the first control message is determined, and the first control message and the first tag are encapsulated to obtain a first encapsulated message. The first encapsulated message is then sent to the switching chip through the target data interaction port, thereby achieving efficient transmission of the first control message.

[0130] In addition, by using a three-layer mapping of "virtual interface - data interaction port - physical port" and the unique identifier of the first tag, port confusion during switching chip forwarding is avoided, ensuring that the first control message is accurately sent to the server device and avoiding negotiation failure due to path errors.

[0131] Furthermore, the introduction of the first tag eliminates the need for complex operations such as MAC table lookups by the switching chip, allowing direct forwarding based on the tag, significantly reducing the switching chip's packet processing time. Simultaneously, the target data interaction port enables direct data interaction between the virtual interface and the switching chip, reducing intermediate forwarding steps and further lowering end-to-end latency, ensuring efficient negotiation processes. Moreover, when the gateway device adds physical ports or virtual interfaces, only the tag-to-port mapping rules need to be extended, meeting the needs of VPN deployments of different scales, thus enhancing compatibility and scalability.

[0132] In some embodiments of this application, the step of receiving a second control message sent by a server device for negotiation processing includes: receiving a second control message and a second tag sent by a switching chip through a target data interaction port; determining a second virtual network interface corresponding to the second tag based on the second tag and pre-determined tag interface mapping data; and sending the second control message to the kernel protocol stack through the second virtual network interface. Specifically, when the switching chip receives the second control message, it determines the second tag of the second control message. The second tag is used to identify the physical port on the switching chip that receives the second control message. The tag interface mapping data includes multiple tags and the virtual network interface corresponding to each tag.

[0133] The parameter determination module in this embodiment is further configured to receive a second control message and a second tag sent by the switching chip through a target data interaction port, determine a second virtual network interface corresponding to the second tag based on the second tag and pre-determined tag interface mapping data, and send the second control message to the kernel protocol stack through the second virtual network interface. Specifically, when the switching chip receives the second control message, it determines the second tag of the second control message. The second tag is used to identify the physical port on the switching chip that receives the second control message. The tag interface mapping data includes multiple tags and the virtual network interface corresponding to each tag.

[0134] The processor in this embodiment is further configured to receive a second control message and a second tag sent by a switching chip through a target data interaction port, determine a second virtual network interface corresponding to the second tag based on the second tag and pre-determined tag interface mapping data, and send the second control message to the kernel protocol stack through the second virtual network interface. Specifically, when the switching chip receives the second control message, it determines the second tag of the second control message. The second tag is used to identify the physical port on the switching chip that receives the second control message. The tag interface mapping data includes multiple tags and the virtual network interface corresponding to each tag.

[0135] Specifically, during the control plane negotiation process of a PPTP VPN, the second control message returned by the server needs to be transmitted to the kernel protocol stack through the gateway device's switching chip to complete subsequent critical processes such as LCP negotiation, authentication interaction, and IPCP parameter configuration. However, the gateway device has multiple physical ports and virtual network interfaces, which may lead to problems such as message mismatch with the target interface and chaotic transmission paths, resulting in control message loss or mistransmission, and thus interrupting the control plane negotiation.

[0136] Based on this, in some embodiments provided in this application, after the switching chip of the gateway device receives the second control message, it adds a second tag identifying the receiving physical port. Then, after the gateway device obtains the tagged second control message through the target data interaction port, it can match the corresponding second virtual network interface according to the pre-set tag interface mapping data, and finally transmit the second control message to the kernel protocol stack through the virtual network interface to ensure the smooth progress of control plane negotiation.

[0137] In some implementations, the second control message can be understood as a control plane data frame that the server responds to the client's first control message, used to complete the PPTP VPN control negotiation process.

[0138] In some examples, the second control message contains LCP negotiation response, authentication confirmation, IPCP parameter configuration, etc.

[0139] In some implementations, the second tag can be understood as an identification field added by the switching chip to the second control message, used to uniquely identify the physical port on the switching chip that receives the second control message, thereby ensuring that the gateway device can accurately identify the receiving port of the message.

[0140] In some implementations, the tag interface mapping data can be understood as a set of configuration data pre-stored in the gateway device, which includes a one-to-one correspondence between multiple "tags" and multiple "virtual network interfaces", specifically including multiple second tags and the virtual network interface information that each second tag is bound to / corresponds to.

[0141] In some implementations, the second virtual network interface can be understood as a logical interface in the gateway device used to connect the switching chip and the kernel protocol stack, such as the TAP interface. It is understood that the second virtual network interface has data forwarding and protocol conversion capabilities; it can strip the tags from tagged packets transmitted by the switching chip and inject them into the kernel protocol stack, while also supporting the reverse transmission of control packets from the kernel protocol stack.

[0142] In some implementations, the target data interaction port can be understood as the data transmission port between the switching chip and the kernel protocol stack (or VPP) in the gateway device, or as the channel through which control messages flow between the switching chip and the kernel protocol stack, responsible for receiving tagged second control messages forwarded by the switching chip.

[0143] In some implementations, the kernel protocol stack can be understood as a module in the operating system kernel responsible for network protocol processing. After receiving the second control message, it can parse the negotiation information in it and complete the subsequent control plane interaction, such as driving the pppd process to complete the subsequent control plane interaction.

[0144] To more clearly illustrate the implementation methods of this application, please refer to the following exemplary description: After the second control message sent by the server is transmitted over the public network, it arrives at the physical WAN port of the gateway device. The switching chip first receives the message, determines the specific physical port receiving the message through hardware detection, and adds a second tag to the second control message. The second tag may contain unique identification information of the receiving physical port, such as port number, interface type, etc.

[0145] The switching chip forwards tagged combined data to the processing module of the gateway device, such as the VPP processing module, through a preset target data interaction port (such as the CPU direct output port), thus completing the transmission of the message from the switching chip to the processing unit.

[0146] After receiving the combined data, the VPP processing module extracts the second tag of the packet and calls the tag interface mapping data for querying. Based on the physical port identifier in the second tag, it matches the second virtual network interface corresponding to the physical port identifier, such as the tap0 interface.

[0147] Finally, the gateway processing unit strips the second tag from the second control message and sends the second control message data to the kernel protocol stack through the matched second virtual network interface. After receiving the second control message, the kernel protocol stack can parse the negotiation response information in the second control message and pass the parsed negotiation response information to the pppd process to continue the control plane negotiation process, such as confirming the authentication result and synchronizing IPCP parameters.

[0148] Thus, in this embodiment of the application, the second control message and the second tag sent by the switching chip can be received through the target data interaction port, and the second virtual network interface corresponding to the second tag can be determined according to the second tag and the predetermined tag interface mapping data, and the second control message can be sent to the kernel protocol stack through the second virtual network interface, thereby realizing the reception of the second control message.

[0149] Furthermore, interface matching is achieved by identifying the physical port and the tag interface mapping data through the second tag identifier, thereby avoiding message loss and mistransmission caused by mismatch between control messages and interfaces, ensuring the continuity of control plane negotiation, and improving the tunnel establishment success rate.

[0150] Furthermore, by utilizing the hardware tag addition and forwarding capabilities of the switching chip, the overhead of traditional software-level port identification and interface matching is avoided, reducing the transmission latency of control messages, improving the establishment speed of VPN tunnels, and optimizing transmission efficiency.

[0151] Furthermore, the second virtual network interface (such as the TAP interface) is compatible with the existing kernel protocol stack's receiving mechanism, thus eliminating the need for significant kernel modifications. Simultaneously, the tag interface mapping data supports dynamic updates; adding new physical ports or virtual interfaces only requires expanding the mapping table, adapting to gateway device architectures of different sizes.

[0152] Please see Figure 4 In some embodiments provided in this application, the method further includes: 04: Check if configuration information has been updated in the target database; 05: If an update to the configuration information is detected, read the updated configuration information from the target database to obtain the target configuration information.

[0153] The message processing apparatus of this application embodiment also includes an update detection module and a configuration reading module. The update detection module is used to detect whether an update of configuration information has occurred in the target database. The configuration reading module is used to read the updated configuration information from the target database to obtain the target configuration information when an update of configuration information is detected.

[0154] The processor in this embodiment is also used to detect whether the configuration information in the target database has been updated, and if the update of the configuration information is detected, to read the updated configuration information in the target database to obtain the target configuration information.

[0155] Specifically, during PPTP VPN packet processing, the client's PPTP VPN configuration information (such as server address, authentication method, encryption policy, etc.) may be modified due to changes in business requirements, network topology adjustments, or security policy upgrades. In traditional solutions, updating configuration information often requires manually restarting the gateway device or VPN service to take effect, which is not only cumbersome and costly to maintain, but may also lead to the interruption of existing VPN sessions, affecting business continuity.

[0156] Based on this, in some embodiments provided in this application, when the configuration information stored in the target database is updated by adding, modifying or deleting, the gateway device will detect the change in a timely manner and actively read the updated configuration information as the target configuration information, providing configuration information reference for subsequent negotiation and processing with the server device, without manual intervention or service restart, and realizing dynamic activation of the configuration.

[0157] In some implementations, the target database can be understood as a distributed data storage system specifically designed to store PPTP VPN static configuration information. It supports operations such as storing, updating, and querying configuration information, has high availability and real-time data synchronization capabilities, and can provide a unified configuration access point for all components of the gateway device.

[0158] In one example, the target database is a database within Redis.

[0159] In some implementations, configuration information can be understood as various static parameter settings required to build a PPTP VPN, including but not limited to PPTP server address, authentication method, encryption policy, timeout parameters related to tunnel establishment, and mapping rules between internal network segments and public network addresses. The PPTP server address can be a public IP address or domain name, the authentication method can be based on protocols such as PAP (Password Authentication Protocol) or CHAP (Challenge-Handshake Authentication Protocol), and the encryption policy can be understood as an encryption method based on a specific encryption algorithm and key length.

[0160] In some implementations, updating configuration information can be understood as adding, modifying, or deleting configuration information stored in the target database.

[0161] In some implementations, configuration information updates are triggered when a user issues new configurations, adjusts existing configuration parameters, or deletes invalid configurations through the UI interface.

[0162] In some implementations, target configuration information can be understood as the latest and valid PPTP VPN configuration information read from the database after the gateway device detects an update to the configuration information in the target database.

[0163] To more clearly illustrate the implementation methods of this application, please refer to the following exemplary description: After the gateway device starts up, its management plane component can establish a stable connection with the target database and continuously monitor the configuration storage status of the target database through preset monitoring logic. For example, in a periodic monitoring mode, the version number, update timestamp, and other identifiers of the configuration information in the database are queried at fixed time intervals and compared with the historical configuration identifiers cached locally to determine whether an update has occurred. Alternatively, in a callback mode, when a user submits a new configuration or modifies an existing configuration through the UI, the configuration information is written to the target database, and the database actively triggers a callback notification. The gateway device's management plane component promptly receives this notification to confirm that the configuration has been updated.

[0164] When an update to the configuration information is detected, the management plane component can send a query request to the target database to retrieve the complete updated configuration information according to the preset data format specifications, such as newly added configuration parameters, modified parameter values, or retained valid configuration items. The component can also perform a validity check on the retrieved configuration information, such as checking the server address format and encryption policy compatibility, to ensure that the configuration information is valid.

[0165] After successful verification, the updated configuration information is identified as the target configuration information. The management plane component then passes it to the negotiation process on the control plane, such as the pppd process, thereby ensuring that the negotiation process is executed based on the latest configuration and enabling dynamic application of configuration changes.

[0166] Thus, in this embodiment, it is possible to detect whether the configuration information in the target database has been updated, and if the update is detected, the updated configuration information in the target database is read to obtain the target configuration information, so that subsequent negotiation processing can be based on the updated configuration information, thereby ensuring the robust execution of the negotiation processing.

[0167] In some embodiments provided in this application, the message processing method further includes: upon obtaining configuration information sent by the client device, storing the configuration information sent by the client device into a target database to trigger an update of the configuration information in the target database.

[0168] Specifically, during the deployment and use of PPTP VPN, after the client modifies the configuration, the components of the gateway device may fail to synchronously obtain the latest configuration, leading to negotiation failures due to configuration inconsistencies. Therefore, in some embodiments provided in this application, the gateway device first receives the PPTP VPN configuration information sent by the client, and then stores this configuration information uniformly in a preset target database, thereby triggering the update of the original configuration information in the target database. It is worth noting that if a corresponding old configuration exists in the database, the old configuration is overwritten by the new configuration; otherwise, a new configuration is added.

[0169] Thus, in this embodiment of the application, when the configuration information sent by the client device is obtained, the configuration information sent by the client device can be stored in the target database to trigger the update of the configuration information in the target database, thereby realizing the timely update of the target configuration information.

[0170] Furthermore, by storing the configuration information sent by the client in a unified target database, the problems of configuration information loss or corruption are avoided. Even if the control process or gateway device restarts, the configuration can be quickly restored from the target database, ensuring the continuity of VPN configuration.

[0171] Please see Figure 5 In some embodiments provided in this application, step 03 includes: 030: Upon receiving the first original message sent by the client device, based on the first vector group processing node and the point-to-point tunnel, information replacement processing is performed on the first source network address information in the first original message to obtain the second original message; 031: Through the second vector packet processing node, query the routing information that matches the first destination network address in the first original message; 032: When the routing information is a point-to-point tunnel, the second original packet is encapsulated using the point-to-point tunnel and session entries to obtain the first encapsulated packet; 033: Based on the point-to-point tunnel and the third vector packet processing node, the first encapsulated message is sent to the server device.

[0172] The forwarding module in this embodiment is further configured to, upon receiving a first original packet sent by a client device, perform information replacement processing on the first source network address information in the first original packet according to the first vector packet processing node and the point-to-point tunnel to obtain a second original packet, and query routing information matching the first destination network address in the first original packet through the second vector packet processing node, and, if the routing information is a point-to-point tunnel, encapsulate the second original packet through the point-to-point tunnel and the session table entry to obtain a first encapsulated packet, and send the first encapsulated packet to the server device according to the point-to-point tunnel and the third vector packet processing node.

[0173] The processor in this embodiment is further configured to, upon receiving a first original message sent by a client device, perform information replacement processing on the first source network address information in the first original message according to the first vector packet processing node and the point-to-point tunnel to obtain a second original message; query routing information matching the first destination network address in the first original message through the second vector packet processing node; and, if the routing information is a point-to-point tunnel, encapsulate the second original message through the point-to-point tunnel and session table entries to obtain a first encapsulated message; and send the first encapsulated message to the server device according to the point-to-point tunnel and the third vector packet processing node.

[0174] Specifically, in the uplink scenario where the client transmits data to the server via PPTP VPN, the per-packet address translation of the traditional kernel protocol stack is inefficient and prone to address mapping confusion. At the same time, there is a risk that packets may fail to enter the VPN tunnel correctly due to routing misjudgment. Ultimately, this results in low throughput, high latency, and poor reliability of packet transmission from the client to the server, making it unsuitable for scenarios with stringent requirements for transmission efficiency, such as cloud computing and enterprise-level networks.

[0175] Based on this, in some embodiments provided in this application, after the gateway device receives the first original message sent by the client, it first replaces the first source network address information of the message with the first vector packet processing node to obtain the second original message adapted for public network transmission. Then, the second vector packet processing node queries the routing information that matches the first destination network address. If the route points to a point-to-point tunnel, the second original message is encapsulated based on the tunnel and the session table entry to generate the first encapsulated message. Finally, the first encapsulated message is efficiently sent to the server through the third vector packet processing node, thereby realizing secure and high-speed data transmission from the client to the server.

[0176] In some implementations, the first raw message can be understood as a raw data message sent by the client device to the server device without any network processing, which includes the client's access request data, the original source network address information (i.e., the internal network IP and port) and the destination network address information (i.e., the server's public network IP).

[0177] In some implementations, the first vector packet processing node can be understood as a dedicated processing unit built on vector packet processing (VPP) technology, which is responsible for batch replacement of the source network address information of the packets, has high throughput and low latency address translation capabilities, and can process the address modification of multiple packets at one time.

[0178] In some implementations, the first source network address information can be understood as key information in the first original message used to identify the network location of the client device, specifically including the client's Internet Protocol address and network port number.

[0179] In some implementations, the second original message can be understood as the message after the node address of the first vector packet processing has been replaced. For example, the first source network address information is replaced with a public IP address bound to the PPTP tunnel and a randomly assigned new port, thereby meeting the address specification requirements for public network transmission and retaining the data content and destination network address information of the original message.

[0180] In some implementations, the second vector packet processing node can be understood as a vector packet processing unit responsible for route lookup, which can parse the destination network address of the packet and match the corresponding routing information to determine the forwarding path of the packet.

[0181] In some implementations, the first destination network address can be understood as the address information in the first original message that identifies the network location of the server device.

[0182] In one example, the first destination network address is the server's public IP address.

[0183] In some implementations, routing information can be understood as forwarding path configuration data stored in the gateway device, including key information such as the next-hop device address, forwarding interface, and tunnel binding relationship, which is used to guide packets to be correctly forwarded from the client side to the server side.

[0184] In some implementations, the first encapsulated message can be understood as the final transmission message after the second original message is encapsulated using PPTP tunneling.

[0185] In some implementations, the first encapsulated message consists of an outer IP header, an Enhanced-GRE header, a PPP frame header, and the data content of the second original message.

[0186] In some implementations, when the first destination network address in the first original message is the network address of the server device, the routing information is a point-to-point tunnel. That is, when the first destination network address of the first original message sent by the client is the network address of the server device, the routing information obtained by the gateway device from the routing table is the pre-created point-to-point tunnel, thereby ensuring that messages from the client to the server can be directly forwarded through the PPTP VPN tunnel.

[0187] In some implementations, the third vector packet processing node can be understood as a vector packet processing unit responsible for sending messages.

[0188] In the example, the third vector packet processing node integrates the DPDK (Data Plane Development Kit) high-performance I / O (Input / Output) driver, which supports zero-copy transmission of batch packets, maximizing the utilization of network bandwidth and reducing packet transmission latency.

[0189] To more clearly illustrate the data uplink process in the embodiments of this application, please refer to the following exemplary description: Based on the client device's need to access server resources, it generates a first raw message containing request data, which is sent to the gateway device through the local area network interface. The message carries the client's internal IP address, internal port number (first source network address information), and the server's public IP address (i.e., the first destination network address). After receiving the message, the gateway device's input interface submits it to the first vector packet processing node.

[0190] After receiving the first original packet, the first vector packet processing node reads the NAT address pool configuration recorded in the session table, selects a public IP address bound to the PPTP tunnel from the NAT address pool configuration, and replaces the internal source IP address in the first original packet with this public IP address. Simultaneously, the first vector packet processing node randomly assigns an unused public port number and replaces the internal port number in the original packet, forming the second original packet. In some implementations, the first vector packet processing node also stores the internal IP address, internal port, public IP address, and new public port obtained during this process in the NAT table, providing a basis for reverse address translation of the server's response packet.

[0191] After the second vector packet processing node obtains the second raw packet, it extracts the first destination network address (i.e., the server's public IP address) from the second raw packet and calls the built-in routing retrieval algorithm to query the gateway device's routing table. It is worth noting that since the first destination network address is a public IP address, the routing table will hit the default route, and the query result shows that the next hop points to the PPTP virtual tunnel interface, that is, the routing information is the preset point-to-point tunnel.

[0192] Subsequently, based on the routing query results, the gateway device directs the second original packet to the point-to-point tunnel interface and uses the tunnel parameters (such as Call ID, encryption key, etc.) stored in the session table for encapsulation. For example, first, a PPP frame header is added, filled with parameters such as the address control field and protocol number. Then, an Enhanced-GRE header is added, carrying key information such as the Call ID, checksum, and sequence number. Finally, an outer IP header is encapsulated, with the source IP set to the public IP bound to the tunnel, the destination IP set to the server's public IP, the protocol field set to 47 corresponding to GRE, and the TTL set to 64, forming a complete first encapsulated packet.

[0193] Finally, after the third vector packet processing node obtains the first encapsulated packet, it calls the multi-queue sending function of the physical network card through the DPDK driver, and sends the packets in batches to the public network using zero-copy technology. The packets are transmitted to the server device via the public network. After receiving the packets, the server can decapsulate them based on the parameters in the encapsulation header, obtain the original request data, and respond, completing one data transmission from the client to the server.

[0194] Thus, in this embodiment, upon receiving a first original message from a client device, the first source network address information in the first original message is replaced according to the first vector packet processing node and the point-to-point tunnel to obtain a second original message. Then, the routing information matching the first destination network address in the first original message is queried through the second vector packet processing node. If the routing information is a point-to-point tunnel, the second original message is encapsulated through the point-to-point tunnel and session entries to obtain a first encapsulated message. Finally, the first encapsulated message is sent to the server device according to the point-to-point tunnel and the third vector packet processing node, thereby realizing message uplink from the client device to the server device.

[0195] In some embodiments provided in this application, the method further includes: when a third original message is received at the local area network interface, parsing the third original message to obtain the physical address, source network address, and second destination network address of the third original message; verifying the physical address; and if the physical address passes verification, the source network address matches the client device, and the second destination network address matches the server device, determining the third original message as the first original message sent by the client device.

[0196] Specifically, in the PPTP VPN packet forwarding process, the gateway device's Local Area Network (LAN) interface receives a massive number of packets from various devices within the LAN. These packets include valid request packets from the client to the server, irrelevant packets from other devices, and even malicious attack packets with spoofed addresses. Therefore, if these packets are not accurately filtered and all received packets are directly included in the subsequent processing flow of the PPTP VPN (such as address translation and encapsulation forwarding), the gateway device's resources will be occupied by invalid packets, significantly reducing packet forwarding efficiency. Furthermore, malicious packet injection may lead to security risks, compromising the stability and security of VPN communication.

[0197] Based on this, in some embodiments provided in this application, after the LAN interface of the gateway device receives the third original packet, it obtains key address information by parsing the packet, verifies the legality of the physical address, and matches the source / destination network address. The received third original packet is then filtered. Only when all three conditions are met—physical address verification, source network address matching the client device's network address, and second destination network address matching the server device's network address—is the third original packet identified as the first original packet sent by the client. This packet then enters the subsequent PPTP VPN processing flow, such as address translation, encapsulation, and forwarding, thereby achieving accurate packet filtering and targeted processing.

[0198] In some implementations, the third original message can be understood as a raw network message received by the gateway device through the LAN interface without undergoing any PPTP VPN-related processing. It is understood that the source of the third original message may be a client device, other unrelated devices within the LAN, or a malicious attack device.

[0199] In some implementations, the LAN interface can be understood as the physical network interface on the gateway device that connects to the client's LAN, responsible for receiving various raw packets sent by devices within the LAN. It is understood that when a client sends a packet through the gateway device, the packet flows into the gateway device through the LAN interface.

[0200] In some implementations, the physical address, also known as the media access control address, is a unique hardware identifier for network devices. It is stored in the network interface card and used for link-layer communication addressing between devices within the local area network, as well as for verifying the legitimacy of the message sending device.

[0201] In some implementations, the source network address can be understood as the network address of the message sender recorded in the third original message, such as the IP address of the sending device, which is used to identify the network node to which the source device of the message belongs.

[0202] In some implementations, the second destination network address can be understood as the network address of the message recipient recorded in the third original message, such as the IP address of the server device, which is used to identify the network node to which the message receiving device belongs.

[0203] In some implementations, the first original message can be understood as the target message that, after being screened and confirmed, is sent by the client device to the server device and needs to be further processed (address translation, encapsulation and forwarding, etc.) through PPTP VPN.

[0204] To more clearly illustrate the implementation methods of this application, please refer to the following exemplary description: After receiving various third-party raw packets from the local area network in real time through the local area network interface, the gateway device first parses the link layer header of the packet to extract the physical address of the packet (i.e., the MAC address of the packet sender), and then parses the network layer header of the packet to extract the source network address (i.e., the IP address of the packet sender) and the second destination network address (i.e., the IP address of the packet receiver).

[0205] Then, the gateway device invokes preset physical address verification rules to validate the legality of the parsed physical address. For example, it verifies whether the parsed physical address is in a pre-registered client MAC whitelist, or whether the parsed MAC address conforms to the format required by the gateway's LAN interface communication protocol. Understandably, if the physical address fails verification—for example, if it's not in the whitelist and / or has an incorrect format—then the third-party original packet is discarded and not processed further.

[0206] After physical address verification is successful, the resolved source network address can be compared with the preset client device network address to confirm whether the packet originates from the target client device. The resolved second destination network address can also be compared with the preset server device network address to confirm whether the packet's receiving target is the PPTP VPN server. Understandably, when the source network address matches the client device and the second destination network address matches the server device, the gateway device can identify this third original packet as the first original packet sent by the client and trigger subsequent PPTP VPN processing steps such as address translation, encapsulation, and forwarding.

[0207] Thus, in this embodiment, when a third original message is received at the local area network interface, the third original message can be parsed to obtain its physical address, source network address, and second destination network address. The physical address is then verified. If the physical address passes verification, the source network address matches the client device, and the second destination network address matches the server device, the third original message is identified as the first original message sent by the client device. This filters out irrelevant and malicious attack messages within the local area network, preventing gateway device resources from being occupied by invalid or malicious attack messages. It ensures that the gateway device's processing capacity is focused on forwarding business messages between the client and server, thereby guaranteeing overall forwarding efficiency.

[0208] In some embodiments provided in this application, the first source network address information includes a first Internet Protocol address and a first network port number. Therefore, step 030 includes: upon receiving the first original message, replacing the first Internet Protocol address with a second Internet Protocol address bound to the point-to-point tunnel through a first vector packet processing node, and replacing the first network port number with a randomly determined second network port number to obtain the second original message.

[0209] Specifically, in the uplink scenario where the client sends packets to the server via PPTP VPN, the first original packet generated by the client usually carries a private address on the internal network, which contains the first Internet Protocol address and the first network port number. This address cannot be directly routed and transmitted on the public network and requires address translation. However, traditional address translation relies on the kernel protocol stack to process packets one by one, which has the problems of high CPU overhead and low translation efficiency, making it difficult to adapt to the high-performance forwarding requirements of batch packets.

[0210] Based on this, in some embodiments provided in this application, after receiving the first original message sent by the client, the gateway device uses the batch processing capability of the first vector packet processing node to replace the first Internet Protocol address (i.e., the private IP address of the intranet) in the message with the public IP address (i.e., the second Internet Protocol address) bound to the point-to-point tunnel, and at the same time replaces the fixed first network port number with the randomly generated second network port number, and finally generates a second original message that can be transmitted on the public network.

[0211] In some implementations, the first Internet Protocol address can be understood as the client device's private Internet Protocol address within its local area network (LAN). It is assigned by the LAN where the client is located, is only valid within the LAN, and cannot be directly routed on the public network. It is the initial source IP address in the first original message.

[0212] In some implementations, the first Internet Protocol address bound to the point-to-point tunnel is also the public Internet Protocol address pre-associated with the PPTP VPN point-to-point tunnel. It is allocated by the public address pool of the gateway device and has public network routing capabilities. It is used to replace the private Internet Protocol address of the internal network, so that the packets can be routed in the public network.

[0213] In some implementations, the first network port number can be understood as the initial port number corresponding to the client process in the first original message, used to identify the communication process inside the client. It is usually a fixed value, which may cause port conflicts and security risks.

[0214] In some implementations, the second network port number can be understood as a port number randomly generated by the gateway device, used to replace the first network port number, thus avoiding the security risks associated with a fixed port.

[0215] In some implementations, the second original message can be understood as a message whose IP address and port number have been replaced by the first vector packet processing node, and the source network address information of the message is updated from "'first Internet Protocol address' and 'first network port number'" to "'public IP address bound to the point-to-point tunnel' and 'random port number'".

[0216] To more clearly illustrate the implementation methods of this application, please refer to the following exemplary description: After the gateway device receives the first raw packet sent by the client through the local area network interface, the first raw packet is pushed to the first vector packet processing node. The first vector packet processing node first parses the transport layer header of the packet and extracts the first Internet Protocol address (e.g., 192.168.1.100) and the first network port number (e.g., 5000) from the first source network address information.

[0217] Subsequently, the first vector packet processing node queries the preset tunnel configuration information, obtains the public IP address bound to the current PPTP point-to-point tunnel (that is, the first Internet Protocol address bound to the point-to-point tunnel, such as 203.0.113.1), and replaces the first Internet Protocol address in the first original packet with this public IP address.

[0218] Additionally, the first vector packet processing node initiates a random port generation algorithm to generate an unused second network port number (e.g., 62345) within a preset port range (e.g., 1024-65535), and replaces the first network port number (5000) in the packet with this random port number.

[0219] Then, the second original message with address replacement is output, and the mapping relationship is recorded, such as "192.168.1.100,5000"-"203.0.113.1,62345", which facilitates the reverse conversion of subsequent messages.

[0220] Finally, the second original message is pushed to the next processing stage, such as querying the route through the second vector packet processing node, tunneling, and then sending it to the server device.

[0221] Thus, in this embodiment of the application, upon receiving the first original message, the first vector packet processing node replaces the first Internet Protocol address with the second Internet Protocol address bound to the point-to-point tunnel, and replaces the first network port number with a randomly determined second network port number to obtain the second original message. This achieves the replacement of the first Internet Protocol address with the private attributes of the intranet with the second Internet Protocol address bound to the tunnel, and avoids the conflict problem caused by the fixed port by using the randomly generated second network port number, thus ensuring the security of cross-network communication between the client and the server.

[0222] In addition, since the IP address and port number replacement is achieved by using the first vector packet processing node, and relying on the batch processing mechanism of the first vector packet processing node, the gateway device can complete the IP address and port number replacement of multiple packets at one time. This avoids the high CPU overhead and frequent context switching of traditional kernel packet-by-packet processing, greatly improves the address translation throughput, and adapts to and meets the line-speed forwarding requirements of high-performance VPNs.

[0223] Please see Figure 6In some embodiments provided in this application, step 03 includes: 034: Upon receiving the second encapsulated message sent by the server device, the fourth vector packet processing node performs parsing processing to obtain the fourth original message, target tunnel parameters, and third destination network address from the second encapsulated message; 035: By querying the session table entries using the target tunnel parameters and the third destination network address, the target point-to-point tunnel corresponding to both the target tunnel parameters and the third destination network address is determined. The session table entries include multiple point-to-point tunnels, and include the tunnel parameters and destination network address corresponding to each point-to-point tunnel. 036: Based on the target point-to-point tunnel, perform information restoration processing on the second source network address information in the fourth original message to obtain the fifth original message; 037: The fifth original message is sent to the client device through the fifth vector packet processing node.

[0224] The forwarding module in this embodiment is further configured to, upon receiving a second encapsulated message sent by a server device, perform parsing processing through a fourth vector packet processing node to obtain a fourth original message, target tunnel parameters, and a third destination network address from the second encapsulated message; query a session table entry using the target tunnel parameters and the third destination network address to determine a target point-to-point tunnel corresponding to both the target tunnel parameters and the third destination network address; perform information restoration processing on the second source network address information in the fourth original message based on the target point-to-point tunnel to obtain a fifth original message; and send the fifth original message to the client device through a fifth vector packet processing node. The session table entry includes multiple point-to-point tunnels and includes tunnel parameters and a destination network address corresponding to each point-to-point tunnel.

[0225] The processor in this embodiment is further configured to, upon receiving a second encapsulated message sent by a server device, perform parsing processing through a fourth vector packet processing node to obtain a fourth original message, target tunnel parameters, and a third destination network address from the second encapsulated message; query a session table entry using the target tunnel parameters and the third destination network address to determine a target point-to-point tunnel corresponding to both the target tunnel parameters and the third destination network address; perform information restoration processing on the second source network address information in the fourth original message based on the target point-to-point tunnel to obtain a fifth original message; and send the fifth original message to a client device through a fifth vector packet processing node. The session table entry includes multiple point-to-point tunnels and includes tunnel parameters and a destination network address corresponding to each point-to-point tunnel.

[0226] Specifically, in downlink communication scenarios where server devices send messages to client devices via PPTP VPN, the encapsulated messages sent by traditional servers contain multiple layers of structure, such as outer tunnel headers and encrypted fields. However, due to the low efficiency of parsing packets one by one in the traditional kernel protocol stack, high latency is easily generated. At the same time, the matching of tunnel parameters and messages depends on kernel-mode table lookup, which can easily lead to matching errors in concurrent scenarios, resulting in message forwarding failure.

[0227] Based on this, in some embodiments provided in this application, the gateway device can extract key information from the encapsulated packets sent by the server based on the batch parsing capability of the vector packet processing node, accurately match the corresponding point-to-point tunnel through the session table entry, restore the network address based on the address translation rules associated with the tunnel, and finally efficiently forward the original packet to the client.

[0228] In some implementations, the second encapsulated message can be understood as a message generated by the server in response to a client request, encapsulated by a PPTP VPN tunnel, containing multiple layers such as an outer IP header, GRE header, PPP frame header, encrypted data, and an inner original message. It needs to be parsed by the gateway device to be restored into the original message that the client can recognize.

[0229] In some implementations, the fourth vector packet processing node can be understood as a vector packet processing unit that parses downlink encapsulated packets (i.e., second encapsulated packets), supports a batch processing mechanism, and can parse multiple second encapsulated packets at once.

[0230] In some examples, the fourth vector packet processing node has functions such as GRE / PPP two-layer decapsulation, tunnel parameter extraction, and original packet restoration.

[0231] In some implementations, the fourth original message can be understood as the data message obtained after the second encapsulated message is decapsulated by the fourth vector packet processing node. It is the original business data sent by the server to the client, but it has not yet undergone address restoration processing. The destination address of the message is still the public network address bound to the tunnel.

[0232] In some implementations, the target tunnel parameters can be understood as key information extracted from the second encapsulated message that identifies a specific PPTP VPN tunnel.

[0233] In some examples, target tunnel parameters include tunnel identifier (Call ID), public IP addresses at both ends of the tunnel, encryption key identifier, etc.

[0234] In some implementations, the third destination network address can be understood as the destination network address recorded in the fourth original message, i.e., the public network address bound to the tunnel, such as the second Internet Protocol address mentioned above.

[0235] In some implementations, the target point-to-point tunnel can be understood as a PPTP VPN logical channel corresponding to the second encapsulated message, which is the tunnel corresponding to a specific session established between the client and the server, and the tunnel parameters of the tunnel are consistent with the target tunnel parameters extracted from the encapsulated message.

[0236] In some implementations, the second source network address information can be understood as the source network address information recorded in the fourth original message, which needs to be restored to an internal network address format that the client can recognize.

[0237] In some implementations, the second source network address information includes the server's public Internet Protocol address (i.e., the third Internet Protocol address) and the corresponding network port number (i.e., the third port number).

[0238] In some implementations, information restoration processing can be understood as the process of converting the public network source address information in the fourth original message into the private address information of the local area network where the client is located, based on the address translation data associated with the target point-to-point tunnel.

[0239] In some implementations, the fifth original message can be understood as the final original message obtained after information restoration processing. The source network address of the message can be identified by the client, and the destination network address of the message is the private address of the client's intranet.

[0240] In some implementations, the fifth vector packet processing node can be understood as a vector packet processing unit responsible for forwarding the fifth original packet to the client. It has functions such as intranet routing query and LAN interface adaptation, and can locate the LAN port where the client is located to achieve low-latency packet forwarding.

[0241] To more clearly illustrate the implementation methods of this application, please refer to the following exemplary description: After the server generates the business data to respond to the client, it encapsulates it into a second encapsulated message via the PPTP VPN tunnel and sends it to the gateway device through the WAN. The gateway device's WAN interface receives the second encapsulated message and forwards it to the fourth vector packet processing node.

[0242] The fourth vector packet processing node employs a batch processing mechanism to parse multiple second-encapsulated packets at once. Specifically, for each second-encapsulated packet, the fourth vector packet processing node can extract the target tunnel parameters, such as the Call ID and the public IP address of the tunnel, while simultaneously reconstructing the encrypted fourth original packet and reading the third destination network address from the fourth original packet.

[0243] Subsequently, the gateway device queries a pre-created session table entry based on the extracted target tunnel parameters and the third destination network address. This session table entry stores the tunnel parameters, destination network address, and corresponding address translation data for each PPTP VPN tunnel.

[0244] After determining the target point-to-point tunnel, the gateway device calls the address translation data associated with the tunnel to restore the second source network address information of the fourth original message, thereby obtaining the fifth original message.

[0245] After the fifth original message is generated, the fifth vector packet processing node queries the intranet routing table, determines the corresponding LAN interface based on the client's intranet address in the fifth original message, and sends the fifth original message to the client device through the interface so that the client can receive, parse and process the message, and complete one communication interaction in the downlink direction.

[0246] Thus, in this embodiment of the application, when the second encapsulated message sent by the server device is received, the fourth vector packet processing node performs parsing processing to obtain the fourth original message, target tunnel parameters, and third destination network address in the second encapsulated message. The session table entry is then queried using the target tunnel parameters and the third destination network address to determine the target point-to-point tunnel that corresponds to both the target tunnel parameters and the third destination network address. Based on the target point-to-point tunnel, the second source network address information in the fourth original message is restored to obtain the fifth original message. Finally, the fifth original message is sent to the client device through the fifth vector packet processing node, thereby realizing the downlink message transmission from the server device to the client device.

[0247] Furthermore, the batch parsing mechanism of the fourth vector packet processing node replaces the traditional kernel's packet-by-packet processing, thereby reducing parsing latency and CPU overhead. Therefore, in high-concurrency scenarios, multi-layer decapsulation of the second-encapsulated packets can be completed quickly, ensuring the real-time performance of downlink packet processing. Moreover, the entire downlink process relies on the vector packet processing node, bypassing the context switching and memory copy overhead of the traditional kernel protocol stack, improving packet throughput, meeting the line-speed forwarding requirements of high-performance gateways, and adapting to scenarios with stringent downlink communication performance requirements such as cloud computing and edge computing.

[0248] In some embodiments provided in this application, step 034 includes: when the second encapsulated message is received at the WAN interface, the header of the second encapsulated message is parsed by the sixth vector packet processing node to obtain the message header parsing result; when the protocol field in the message header parsing result is the target field, the fourth vector packet processing node is used for parsing to obtain the fourth original message, target tunnel parameters and third destination network address in the second encapsulated message.

[0249] The forwarding module in this embodiment is further configured to, when the second encapsulated message is received at the WAN interface, parse the header of the second encapsulated message through the sixth vector packet processing node to obtain the message header parsing result; if the protocol field in the message header parsing result is the target field, parse the message through the fourth vector packet processing node to obtain the fourth original message, target tunnel parameters and third destination network address in the second encapsulated message.

[0250] The processor in this embodiment is further configured to, when the second encapsulated message is received at the wide area network interface, parse the header of the second encapsulated message through the sixth vector packet processing node to obtain the message header parsing result; and if the protocol field in the message header parsing result is the target field, parse the message through the fourth vector packet processing node to obtain the fourth original message, target tunnel parameters and third destination network address in the second encapsulated message.

[0251] Specifically, in the downlink data transmission scenario of PPTP VPN, if the gateway device performs invalid parsing on packets that do not conform to the PPTP protocol, it consumes a large amount of computing resources and reduces the overall processing efficiency. Therefore, in some embodiments provided in this application, after receiving the second encapsulated packet sent by the server through the WAN interface, the gateway device can perform preliminary parsing of the packet header based on the sixth vector packet processing node. It can then filter out valid PPTP VPN packets by verifying whether the protocol field is the target field. The fourth vector packet processing node then performs deep parsing on the valid packets, ultimately extracting the fourth original packet, target tunnel parameters, and the third destination network address.

[0252] In some implementations, the fourth vector packet processing node can be understood as a single VPP node or a combination of multiple VPP nodes with GRE / PPP dual-layer decapsulation capability, which can strip the outer encapsulation header from the second encapsulated message and extract the original message, tunnel parameters and destination network address.

[0253] In some implementations, the WAN interface can be understood as the physical network interface in the gateway device that connects to the WAN, and is the entry point for receiving the second encapsulated message sent by the server.

[0254] In some implementations, the sixth vector packet processing node is a vector packet processing unit dedicated to preliminary parsing and protocol filtering of the packet header. It is capable of parsing the outer header of the second encapsulated packet and extracting protocol field information.

[0255] In some implementations, the message header parsing result can be understood as the set of key information obtained by the sixth vector packet processing node after parsing the outer header of the second encapsulated message.

[0256] In some implementations, the message header parsing result includes protocol fields, outer source IP, outer destination IP, TTL, etc.

[0257] In some implementations, the protocol field can be understood as a field in the packet header parsing result that identifies the type of the upper-layer protocol carried by the packet. It is understood that different protocols correspond to fixed field values, such as the GRE protocol corresponding to field value 47.

[0258] In some implementations, the target field can be understood as a pre-defined protocol field value corresponding to the PPTP VPN protocol. For example, since PPTP VPN implements tunnel encapsulation through the GRE protocol, and the field value of the GRE protocol is 47, the target field is 47.

[0259] To more clearly illustrate the implementation methods of this application, please refer to the following exemplary description: The second encapsulated message sent by the server is transmitted to the gateway device via the wide area network (WAN). After receiving the message through the WAN interface, the gateway device hands over the received second encapsulated message to the sixth vector packet processing node. The sixth vector packet processing node parses the outer IP header of the second encapsulated message, extracting key information such as protocol fields, outer source IP, and outer destination IP, forming a complete message header parsing result.

[0260] Next, the protocol field in the packet header parsing result is verified. If the value of this field matches the preset target field, such as the value 47 corresponding to the GRE protocol, it indicates that the packet is a valid encapsulated packet of the PPTP VPN tunnel, thus triggering the subsequent parsing process. Conversely, if the field value does not match, it is determined to be a non-PPTP protocol packet and processed according to preset rules, such as being discarded or forwarded to other protocol processing modules to avoid unnecessary resource consumption.

[0261] Subsequently, for valid packets that pass the protocol screening, the gateway device hands them over to the fourth vector packet processing node. The fourth vector packet processing node first strips the outer IP header of the packet, parses the GRE header and extracts the target tunnel parameters, such as the Call ID, and then strips the PPP frame header to restore the original data packet sent by the server, which is the fourth original packet. At the same time, it extracts the third destination network address from the decapsulated packet.

[0262] Finally, the fourth vector packet processing node synchronizes the extracted fourth original packet, target tunnel parameters, and third destination network address to the subsequent processing module, thereby performing subsequent steps such as session entry matching, address restoration, and client forwarding.

[0263] Thus, in this embodiment, when the second encapsulated message is received at the WAN interface, the header of the second encapsulated message is parsed by the sixth vector packet processing node to obtain the message header parsing result. If the protocol field in the message header parsing result is a target field, it is parsed by the fourth vector packet processing node to obtain the fourth original message, target tunnel parameters, and third destination network address in the second encapsulated message. This allows for filtering out irrelevant messages whose protocol fields are not target fields through message header parsing, thus avoiding logical confusion caused by parsing irrelevant messages and improving the accuracy of extracting the fourth original message, target tunnel parameters, and third destination network address. Furthermore, based on the batch parsing mechanism of the vector packet processing node, multiple messages can be parsed at once, ensuring message parsing speed and thus ensuring that downlink messages can be quickly delivered to the target client.

[0264] In some embodiments provided in this application, the second source network address information includes a third Internet Protocol address and a third port number. The third Internet Protocol address is bound to the target point-to-point tunnel. Therefore, step 036 includes: replacing the third Internet Protocol address with the fourth Internet Protocol address corresponding to the third Internet Protocol address in the address translation data corresponding to the target point-to-point tunnel; and replacing the third port number with the fourth port number corresponding to the third port number to obtain the fifth original message.

[0265] The forwarding module in this application is further used to replace the third Internet Protocol address with the fourth Internet Protocol address corresponding to the third Internet Protocol address in the address translation data corresponding to the target point-to-point tunnel, and to replace the third port number with the fourth port number corresponding to the third port number, to obtain the fifth original message.

[0266] The processor in this application embodiment is further configured to replace the third Internet Protocol address with the fourth Internet Protocol address corresponding to the third Internet Protocol address in the address translation data corresponding to the target point-to-point tunnel, and to replace the third port number with the fourth port number corresponding to the third port number, to obtain the fifth original message.

[0267] Specifically, in a downlink communication scenario where the server sends messages to the client device via PPTP VPN, the original message sent by the server is usually replaced with the public network address bound to the point-to-point tunnel through address translation before being transmitted through the tunnel, in order to adapt to the security requirements of public network transmission. The client device can only recognize the original internal network address of the server and cannot directly process messages carrying the public network source address.

[0268] Based on this, in some embodiments provided in this application, the gateway device locates the corresponding address translation data through the target point-to-point tunnel, first replaces the public IP (i.e., the third Internet Protocol address) in the message with the client's internal network original IP (i.e., the fourth Internet Protocol address), then replaces the public port (i.e., the third port number) with the client's internal network original port (i.e., the fourth port number), and finally generates a fifth original message that the client can directly recognize.

[0269] In some implementations, the second source network address information can be understood as the set of source address identifiers carried in the fourth original message sent by the server, including the third Internet Protocol address and the third port number. It is the source address identifier when the message is transmitted on the public network, and is allocated and bound to the target point-to-point tunnel by the gateway device during the uplink phase of the message.

[0270] In some implementations, the third Internet Protocol address can be understood as the IP address field in the second source network address information, which is a public IP address bound to the target point-to-point tunnel and used to locate the source tunnel endpoint of the packet in the public network environment.

[0271] In some implementations, the third port number can be understood as the port field in the second source network address information. It is the public network port assigned by the gateway device to the current PPTP VPN session. In conjunction with the third Internet Protocol address, it realizes a unique session identifier at the public network level and avoids confusion between different session packets.

[0272] In some implementations, the target point-to-point tunnel can be understood as a PPTP VPN logical communication channel corresponding to a server message, determined by querying a session table entry.

[0273] In some implementations, address translation data can be understood as a mapping table of "public network address" and "internal network address" stored in the gateway device. It is generated during the uplink phase of the message and bound to the target point-to-point tunnel. Specifically, it records the one-to-one correspondence between the third Internet Protocol address and the fourth Internet Protocol address, and the one-to-one correspondence between the third port number and the fourth port number.

[0274] In some implementations, the fourth Internet Protocol address can be understood as the client device's original internal IP address, which is the target IP field after address restoration and belongs to the private IP address of the client's local area network.

[0275] In some implementations, the fourth port number can be understood as the original intranet port number used by the client device when initiating communication. It is the target port field after address restoration, which, together with the fourth Internet Protocol address, uniquely identifies the application process on the client side.

[0276] In some implementations, the fifth original message can be understood as the final message generated after address restoration processing. The source network address of this message has been completely restored to the client's original internal network address, which is the fourth Internet Protocol address and the fourth port number, and can then be directly identified and processed by the client.

[0277] To more clearly illustrate the implementation methods of this application, please refer to the following exemplary description: The gateway device receives the second encapsulated message sent by the server through the WAN interface. After being parsed by the fourth vector packet processing node, it obtains the fourth original message, the target tunnel parameters (such as Call ID) and the third destination network address (client intranet address). At the same time, it extracts the second source network address information (third Internet Protocol address, third port number) from the fourth original message.

[0278] The gateway device queries the session table entry by the target tunnel parameters and the third destination network address to determine the corresponding target point-to-point tunnel and obtain the address translation data associated with the tunnel, such as "192.168.1.100,5000"-"203.0.113.1,62345" in the aforementioned implementation.

[0279] Subsequently, the fourth Internet Protocol address (IPA) corresponding to the third IP address (i.e., the server's original IP address) is retrieved from the address translation data, and the third IP address in the fourth original packet is replaced with this fourth IP address. Also, the fourth port number (i.e., the server's original source port) corresponding to the third port number is retrieved from the address translation data, and the third port number in the fourth original packet is replaced with this fourth port number, thus completing the address restoration.

[0280] After address restoration is completed, the original fourth original packet is transformed into the fifth original packet. The source network address of this packet has been restored to the original server address information that the client can recognize. Then, the fifth vector packet processing node queries the internal network route and sends the fifth original packet to the client device.

[0281] Thus, in this embodiment of the application, the third Internet Protocol address can be replaced with the fourth Internet Protocol address corresponding to the third Internet Protocol address in the address translation data corresponding to the target point-to-point tunnel, and the third port number can be replaced with the fourth port number corresponding to the third port number to obtain the fifth original message. This realizes the restoration of Internet Protocol address and port number, thereby enabling the client to accurately identify the source of the server message, thereby ensuring the robust downlink of the message.

[0282] To more clearly illustrate the application scenarios of the message processing method provided in this application, please refer to [link / reference needed]. Figure 7 , Figure 7These are schematic diagrams illustrating application scenarios for certain embodiments of this application. Specifically, such as... Figure 7 As shown, the company headquarters, branch offices, and employees working outside the company environment (such as hotels) are located in different physical locations and network environments—the company intranet, the hotel public network, and the mobile network, respectively. It's understandable that directly accessing company intranet resources, such as email servers and office automation (OA) servers, through the public network poses risks of data leakage and communication insecurity. It's also understandable that direct communication across network segments is impossible; the headquarters (IP address 192.168.0.0 / 24) cannot directly communicate with the branch office (IP address 192.168.1.0 / 24), thus requiring the establishment of a logical channel for communication.

[0283] Based on this, by designating the company headquarters as the server and corresponding server devices, and branch offices, personal computers, and mobile terminals as clients and corresponding client devices, a PPTP VPN can be constructed using the message processing method provided in the aforementioned embodiments, and secure communication can be achieved through the PPTP VPN.

[0284] For the server side, the corresponding network segment is 192.168.0.0 / 24. The server-side equipment includes an email server, an office automation server, and intranet terminals, with local connections between the various intranet devices achieved through switches. The server side also includes a VPN router, which is the server-side gateway device for the PPTP VPN. It serves as the connection node between the company headquarters intranet (i.e., the server-side equipment) and the external network (i.e., the client-side equipment). It is responsible for negotiating tunnel parameters with clients, creating PPTP point-to-point tunnels, maintaining session entries, and handling packet encapsulation / decapsulation and address translation.

[0285] For the clients, the company branch office, acting as one client, operates on the 192.168.1.0 / 24 network segment and has a dedicated VPN router serving as the client gateway. This VPN router connects to the headquarters VPN router via a PPTP VPN tunnel, enabling branch office terminals to access network resources on the server. Additionally, hotel terminals, acting as a second client, utilize personal computers as client devices. These computers can directly initiate PPTP VPN connection requests via the public network, establishing a tunnel with the headquarters VPN router to access headquarters resources. Furthermore, outdoor mobile terminals, acting as a third client, connect to base stations via 4G, 5G, or other mobile communication networks and then initiate PPTP VPN connections to access the headquarters intranet.

[0286] When a branch office terminal needs to access the headquarters email server, the branch office VPN router initiates a PPTP connection request to the headquarters VPN router. Both parties negotiate tunnel parameters, such as tunnel identifier, encryption key, and internal / external IP address mappings for the branch office / headquarters. Then, based on the negotiated tunnel parameters, the headquarters VPN router creates a PPTP point-to-point tunnel and generates corresponding session entries to record the tunnel's address mapping, encryption context, routing rules, etc. Afterward, the branch office terminal generates the original packet to access the email server. This packet is encapsulated by the branch office VPN router and transmitted through the PPTP tunnel to the headquarters VPN router over the public network. Upon receiving the packet, the headquarters VPN router decapsulates and restores the address using the packet vector processing node based on the session entries, then forwards the packet to the email server on the headquarters' internal network. Conversely, when the email server needs to send data to a branch office terminal, the email server's response packet is encapsulated by the headquarters VPN router and transmitted back to the branch office VPN router through the PPTP tunnel. The branch office VPN router then decapsulates the packet and forwards it to the branch office terminal, completing one communication loop.

[0287] It is understandable that the communication process of personal computers and outdoor mobile terminals is consistent with the above logic, so it will not be repeated here to avoid repetition.

[0288] To more clearly illustrate the implementation of the message processing method provided in this application, please refer to [link / reference needed]. Figure 8 , Figure 8 These are all schematic diagrams illustrating application scenarios provided by certain embodiments of this application.

[0289] Specifically, such as Figure 8 As shown, the message processing method provided in this application can be implemented based on a five-layer architecture: management plane, control plane, data plane, gateway hardware layer, and external device.

[0290] The management interface is specifically implemented by a UI Process Set, which includes a WEB Server (World Wide Web Server), a CU Server (Command Line Interface), an ECS (Elastic Compute Service), and a UIRequest Parser. The UI Process Set serves as the entry point for receiving user operations. Specifically, users can send PPTP VPN configuration information, such as server addresses and authentication information, through the UI interface. This configuration information is then parsed and written to the database.

[0291] There are three databases: a configuration database, a status database, and a forwarding database. The configuration database is... Figure 7 Database1 in the context refers to the state database. Figure 7 Database2 in the middle, forwarding database, i.e. Figure 7 Database 3 is a subset of Database 1. Database 1 stores static configuration information, such as VPN parameters issued by the user, which can be subscribed to by pptp-proxy (Point-to-Point Tunneling Protocol-proxy). Database 2 maintains runtime state, such as tunnel connection status and packet statistics. Database 3 transmits data plane configuration, such as tunnel parameters and address translation mappings, supporting VPP in creating session entries.

[0292] pptp-proxy subscribes to configuration updates in Database1 through the Pub / Sub (Publish / Subscribe) mechanism supported by the database, and dynamically distributes the configuration to the pppd (point-to-point protocol daemon) process in the control plane; at the same time, it receives PPP port information reported by the pppd process, such as CallID, encryption key, etc., and publishes the received PPP port information to Database2 and Database3.

[0293] The pptpd (point-to-point tunneling protocol daemon) process on the server and the pptd process on the client work together to integrate the complete PPTP protocol stack functions and jointly complete the negotiation process, such as establishing TCP connections, LCP link negotiation, PAP / CHAP authentication, IPCP parameter configuration, etc., and finally generate tunnel parameters, such as CallID, inner IP, etc.

[0294] Both user space and kernel space can be understood as the processing space for control plane packets. The pppd process runs in user space and interacts with kernel space through virtual interfaces, avoiding the direct processing of data plane traffic by the kernel protocol stack.

[0295] host-tap0, ppp0, and vhost-net are all interfaces for control plane message interaction. Host-tap0 is the communication interface between the pppd process in user space and kernel space, responsible for forwarding control messages between user and kernel modes. ppp0 is a virtual interface for the PPP protocol, responsible for encapsulating PPP frames for the control plane. vhost-net is a virtualized network interface that optimizes message transmission efficiency between user and kernel modes and reduces memory copying.

[0296] In the data plane, VPP implements zero-copy packet transmission and reception based on DPDK. Specifically, it receives the tunnel configuration of Database3 through the VPPAPI, creates pptptunnel0 (a point-to-point tunnel interface), and then performs operations such as packet encapsulation / decapsulation, NAT address translation, and address restoration, achieving line-rate forwarding based on a vector batch processing mechanism.

[0297] DMP-VPP (Device Management Platform-Vector Packet Processing) is a data plane adaptation layer process that can subscribe to tunnel parameters in Database3 and call VPPAPI (Vector Packet Processing, Application Programming Interface) to send the configuration to VPP, thereby triggering the creation of the tunnel interface (i.e., pptptunnel0) and session entries.

[0298] Additionally, the DSA-tag in the data plane is used to identify the physical port of the switching chip, thereby enabling the routing of control messages between the switching chip and the VPP. NAT can be understood as replacing the internal network source IP with the public IP bound to the tunnel in the uplink message, while DNAT can be understood as restoring the public IP to the original internal network IP in the downlink message.

[0299] The SWTCH chip (switching chip) provides front panel ports such as GE1 / 0 / 1, GE1 / 0 / 2, and GE1 / 0 / 3. GE1 / 0 / 1 connects to the internal network side interface (LAN VLAN 101), while GE1 / 0 / 2 and GE1 / 0 / 3 connect to the public network side interface (WAN VLAN 102). Specifically, GE1 / 0 / 1 can connect to the LAN port of internal network devices, and VLAN 101 identifies internal network traffic. GE1 / 0 / 3 can connect to the WAN port of the PPTP server (public network VPN server), and VLAN 102 identifies public network traffic. GE1 / 0 / 2 can be considered a reserved interface that can be expanded to connect other network devices.

[0300] eth0 is the physical Ethernet interface of the gateway device, used to interact with the external network, that is, the entry and exit point for data plane packets.

[0301] The internal network devices, also known as the client-side devices of the PPTP VPN, connect to the gateway device through LAN VLAN 101, sending raw packets or receiving restored packets after data plane processing. The PPTP Server, the VPN server-side device on the public network, establishes a tunnel connection with the gateway through WAN VLAN 102, receiving encapsulated packets or sending server response packets.

[0302] based on Figure 8 In the architecture shown, users can send configurations via UI Process Set. The UI Request Parser receives and parses the configurations, then writes the results to Database1. pptp-proxy subscribes to updates on Database1 and distributes the configurations to the control plane pppd process. After successful negotiation between the pppd process and the server-side pptpd process, the tunnel parameters are published to Database3 via pptp-proxy. DMP-VPP subscribes to Database3, calls the VPP API to send the configurations, and then VPP creates the pptptunnel0 tunnel and session entries.

[0303] During the negotiation process, the pppd process generates control messages, such as SCCRQ and SCCRP. These messages are passed to VPP via interfaces such as host-tap0, vhost-net, and tap0. VPP adds a DSA-tag to the messages to identify the target physical port, and then passes them through a bridge (i.e., Figure 8 The packet (the dashed line in the diagram) is forwarded to the SWTCH chip. The SWTCH chip, based on the DSA-tag, sends the packet from GE1 / 0 / 2 (WAN VLAN 102) to the PPTPServer. Correspondingly, when the PPTPServer receives a response packet, the response packet enters the SWTCH chip via GE1 / 0 / 2, has a DSA-tag added, and is forwarded to the VPP. The VPP parses the tag and passes it to the pppd process via tap0, vhost-net, and host-tap0.

[0304] After negotiation, for the uplink scenario, that is, the scenario of sending data from the internal network to the public network, the original packet of the client device enters the SWTCH chip through GE1 / 0 / 1. The SWTCH chip forwards the original packet to VPP. VPP performs NAT translation through the first vector packet processing node, that is, replaces the internal network source IP with the tunnel public network IP, then matches the session table entry, performs packet encapsulation, and after adding DSA-tag, sends it to PPTPServer through GE1 / 0 / 2, thereby completing the uplink packet forwarding.

[0305] Conversely, for the downlink process, i.e., the scenario of sending data from the public network to the internal network, the encapsulated packet of the PPTPServer enters the SWTCH chip via GE1 / 0 / 2. The SWTCH chip forwards the encapsulated packet to the VPP. The fourth vector packet processing node of the VPP parses the packet, extracts the tunnel parameters and destination address, and then the VPP queries the address translation data according to the target point-to-point tunnel, restores the third Internet Protocol address to the fourth Internet Protocol address, and restores the third port number to the fourth port number. Finally, it is forwarded to the client device via GE1 / 0 / 1, thus completing the downlink packet forwarding.

[0306] To more clearly illustrate the message uplink and downlink processes in the embodiments of this application, please refer to [link to relevant documentation]. Figure 9 , Figure 9 This is a schematic diagram illustrating application scenarios in some embodiments of this application.

[0307] Specifically, for the uplink direction of the message (i.e. Figure 9The direction indicated by the dashed arrow (i.e., the scenario of sending data from the internal network to the public network) is shown in the diagram. The dpdk-input node, acting as the input node for the data base, receives raw packets from the LAN port via hardware acceleration and passes them to the VPP data plane in a zero-copy manner. The ethernet-input node parses the Ethernet frame header of the received packets to verify the MAC address. The ip4-input node extracts the outer IPv4 header of the packets to verify whether the source IP is a private internal network address and whether the destination IP is a public network address. The nat44-in2out node, based on the NAT address pool, replaces the internal network source IP with the public IP bound to the PPTP tunnel and randomly assigns a new port. It also records the mapping relationship between the internal network IP and port, and between the public IP and the new port, ensuring that return traffic can achieve reverse translation. The ip4-lookup node queries the routing table; since the destination IP is a public network address, the default route is hit, and the next hop points to the PPTP virtual tunnel interface pptp_tunnel0. The `pptp_build_rewrite()` node generates the encapsulation template, automatically filling in the outer IPv4 header. For example, protocol field 47 identifies the GRE protocol and includes information such as the local public network endpoint source IP, the peer tunnel endpoint destination IP, and TTL=64. It also automatically fills in the Enhance-GRE header, specifically including flags, protocol type 0x880B identifying the PPP frame, and the CallID obtained through tunnel negotiation. It can also fill in relevant fields in the PPP frame header. The `pptp_fixup()` node updates dynamic fields in real time, including incrementing the global sequence number and writing it to the GRE header, filling in the PPP protocol number based on the inner IP version, and recalculating the outer IPv4 checksum to ensure the accuracy and compliance of the encapsulation fields. The `ip4-rewrite` node completes address rewriting adaptation before packet forwarding. The `interface-output` node sends the fully encapsulated packet to the server device via the physical port, completing the uplink packet forwarding.

[0308] And, for the downlink direction of the message (i.e. Figure 9The image shows the direction indicated by the solid arrow, representing a scenario where data is sent from the public network to the internal network. The dpdk-input node receives PPTP encapsulated packets from the WAN-side physical port and sends them to the VPP data plane using a zero-copy method. The ethernet-input node performs link-layer processing on the packets, parsing the Ethernet frame header. The ip4-input node parses the outer IPv4 header, identifying if the protocol field is 47 (i.e., the destination field). The ip4-lookup node queries the routing table; since the outer destination IP is the endpoint of the local public network tunnel, it directs the packet to the ip4-receive path. The gre4-input node parses the GRE header, identifies the Enhanced-GRE flag, and then hands the packet over to the pptp_input decapsulation node. The pptp_input decapsulation node performs three types of judgments in the vector loop. If the GRE length field is 0, or the protocol number after parsing the PPP address control field is neither IPv4 nor IPv6, it marks it as an error-punt, stops querying the session, and only performs sequence number synchronization and PPP header stripping on the data frame. It then queries the session table using the inner destination IP and Call ID to match the corresponding PPTP tunnel interface pptp_tunnel0, and writes the soft interface index of that tunnel interface into the receive interface field of the packet buffer. The nat44-out2in node queries the NAT table based on the public IP and port, and reverse-translates the destination IP and port to the original internal network address. The ip4-lookup node queries the internal network route based on the inner destination IP to determine the forwarding path. The interface-output node sends the decapsulated and address-translated packet to the client device via the LAN port, completing the downlink packet forwarding.

[0309] This application provides a computer-readable storage medium storing a computer program that, when executed by one or more processors, implements the above-described message processing method.

[0310] This application provides a computer program product, including a computer program / instruction, which, when executed by a processor, implements the above-described message processing method.

[0311] In this specification, the terms "specifically," "furthermore," "particularly," "understandably," etc., refer to specific features, structures, materials, or characteristics described in connection with embodiments or examples that are included in at least one embodiment or example of this application. In this specification, the illustrative expressions of the above terms do not necessarily refer to the same embodiment or example. Furthermore, the specific features, structures, materials, or characteristics described may be combined in any suitable manner in one or more embodiments or examples. Moreover, without contradiction, those skilled in the art can combine and integrate the different embodiments or examples described in this specification, as well as the features of different embodiments or examples.

[0312] Any process or method described in the flowchart or otherwise herein can be understood as representing a module, segment, or portion of code comprising one or more executable instructions for implementing a particular logical function or process, and the scope of the preferred embodiments of this application includes additional implementations in which functions may be performed not in the order shown or discussed, including substantially simultaneously or in reverse order depending on the function involved, as will be understood by those skilled in the art to which embodiments of this application pertain.

[0313] Although embodiments of this application have been shown and described above, it is understood that the above embodiments are exemplary and should not be construed as limiting this application. Those skilled in the art can make changes, modifications, substitutions and variations to the above embodiments within the scope of this application.

Claims

1. A method of processing a packet, the method comprising: Applied to a gateway device, through which a client device connects to a server device, the method includes: Determine the tunnel parameters used to create a point-to-point tunneling protocol virtual private network; Based on the tunnel parameters, a point-to-point tunnel and a corresponding session table entry are created. The client device communicates with the server device through the point-to-point tunnel. The session table entry is used to determine the message processing rules when the client device and the server device communicate. Based on the point-to-point tunnel, the session entry, and the pre-created vector packet processing node, packets generated by one of the client devices and the server devices are forwarded to the other device.

2. The packet processing method of claim 1, wherein, The determination of tunnel parameters used to create a point-to-point tunneling protocol virtual private network includes: Based on the target configuration information of the obtained point-to-point tunneling protocol virtual private network, the tunnel parameters are obtained through negotiation with the server device.

3. The packet processing method of claim 2, wherein, The process of negotiating with the server device based on the obtained target configuration information of the peer-to-peer tunneling protocol virtual private network to obtain the tunnel parameters includes: Given the target configuration information of the point-to-point tunneling protocol virtual private network, the tunnel parameters are obtained by negotiating with the server device through a pre-determined challenge handshake authentication protocol process.

4. The packet processing method of claim 2 or 3, wherein, The negotiation process includes: Establish a communication connection with the server device; Send a first control message to the server device for performing the negotiation process; Receive a second control message sent by the server device for performing the negotiation process.

5. The packet processing method of claim 4, wherein, The gateway device includes a switching chip, and the sending of a first control message to the server device for performing the negotiation process includes: Upon receiving a first control message sent by the kernel protocol stack through the first virtual network interface, the target data interaction port on the switching chip corresponding to the first virtual network interface is determined, and the target physical port on the switching chip used to send the first control message is determined. The first control message and the first tag are encapsulated to obtain a first encapsulated message, wherein the first tag is used to identify the target physical port on the switching chip used to send the first control message; The first encapsulated message is sent to the switching chip through the target data interaction port. When the switching chip receives the first encapsulated message, it sends the first encapsulated message to the target physical port according to the first tag in the first encapsulated message, so as to send the first encapsulated message to the server device.

6. The packet processing method of claim 5, wherein, The receipt of the second control message sent by the server device for performing the negotiation process includes: The second control message and the second tag sent by the switching chip are received through the target data interaction port. When the switching chip receives the second control message, it determines the second tag of the second control message. The second tag is used to identify the physical port on the switching chip that receives the second control message. Based on the second tag and the pre-determined tag interface mapping data, a second virtual network interface corresponding to the second tag is determined, wherein the tag interface mapping data includes multiple tags and the virtual network interface corresponding to each tag; The second control message is sent to the kernel protocol stack through the second virtual network interface.

7. The packet processing method of claim 2, wherein, The method further includes: Detect whether the configuration information has been updated in the target database; If an update to the configuration information is detected, the updated configuration information is read from the target database to obtain the target configuration information.

8. The packet processing method of claim 7, wherein, The method further includes: If the configuration information sent by the client device is obtained, the configuration information sent by the client device is stored in the target database to trigger the update of the configuration information in the target database.

9. The packet processing method of claim 1, wherein, The step of forwarding packets generated by one of the client devices and the server devices to the other device based on the point-to-point tunnel, the session entry, and the pre-created vector packet processing node includes: Upon receiving the first original message sent by the client device, the first source network address information in the first original message is replaced according to the first vector packet processing node and the point-to-point tunnel to obtain the second original message. The second vector packet processing node queries routing information that matches the first destination network address in the first original message; If the routing information is the point-to-point tunnel, the second original packet is encapsulated using the point-to-point tunnel and the session entry to obtain the first encapsulated packet; Based on the point-to-point tunnel and the third vector packet processing node, the first encapsulated message is sent to the server device.

10. The message processing method according to claim 9, characterized in that, The method further includes: When a third original message is received at the local area network interface, the third original message is parsed to obtain the physical address, source network address and second destination network address of the third original message. Verify the physical address; If the physical address is verified, the source network address matches the client device, and the second destination network address matches the server device, the third original message is used to determine the first original message sent by the client device.

11. The message processing method according to claim 9, characterized in that, If the first destination network address in the first original message is the network address of the server device, the routing information is the point-to-point tunnel.

12. The message processing method according to claim 9, characterized in that, The first source network address information includes a first Internet Protocol address and a first network port number. Upon receiving the first original message sent by the client device, the first source network address information in the first original message is replaced according to the first vector packet processing node and the point-to-point tunnel to obtain a second original message, including: Upon receiving the first original message, the first vector packet processing node replaces the first Internet Protocol address with the second Internet Protocol address bound to the point-to-point tunnel, and replaces the first network port number with a randomly determined second network port number, thereby obtaining the second original message.

13. The message processing method according to claim 1, characterized in that, The step of forwarding packets generated by one of the client devices and the server devices to the other device based on the point-to-point tunnel, the session entry, and the pre-created vector packet processing node includes: Upon receiving the second encapsulated message sent by the server device, the fourth vector packet processing node performs parsing processing to obtain the fourth original message, target tunnel parameters, and third destination network address in the second encapsulated message. By querying the session table entry using the target tunnel parameters and the third destination network address, a target peer-to-peer tunnel corresponding to both the target tunnel parameters and the third destination network address is determined. The session table entry includes multiple peer-to-peer tunnels and includes the tunnel parameters and destination network address corresponding to each peer-to-peer tunnel. Based on the target point-to-point tunnel, the second source network address information in the fourth original message is restored to obtain the fifth original message; The fifth original message is sent to the client device via the fifth vector packet processing node.

14. The message processing method according to claim 13, characterized in that, Upon receiving the second encapsulated message sent by the server device, the fourth vector packet processing node performs parsing processing to obtain the fourth original message, target tunnel parameters, and third destination network address from the second encapsulated message, including: When the second encapsulated message is received at the WAN interface, the header of the second encapsulated message is parsed by the sixth vector packet processing node to obtain the message header parsing result; If the protocol field in the parsing result of the message header is the target field, the fourth vector packet processing node performs parsing processing to obtain the fourth original message, target tunnel parameters and third destination network address in the second encapsulated message.

15. The message processing method according to claim 13, characterized in that, The second source network address information includes a third Internet Protocol address and a third port number. The third Internet Protocol address is bound to the target peer-to-peer tunnel. Based on the target peer-to-peer tunnel, the second source network address information in the fourth original message is restored to obtain the fifth original message, which includes: Replace the third Internet Protocol address with the fourth Internet Protocol address corresponding to the third Internet Protocol address in the address translation data corresponding to the target point-to-point tunnel; The third port number is replaced with the fourth port number corresponding to the third port number to obtain the fifth original message.

16. A message processing apparatus, characterized in that, Applied to gateway devices, through which client devices connect to server devices, the device includes: The parameter determination module is used to determine the tunnel parameters used to create a point-to-point tunneling protocol virtual private network; A creation module is used to create a point-to-point tunnel and a corresponding session entry based on the tunnel parameters. The client device communicates with the server device through the point-to-point tunnel, and the session entry is used to determine the message processing rules when the client device and the server device communicate. The forwarding module is used to forward packets generated by one of the client devices and the server devices to the other device based on the point-to-point tunnel, the session entries, and the pre-created vector packet processing nodes.

17. A gateway device, characterized in that, The method includes a memory and a processor, wherein the memory stores a computer program, and when the computer program is executed by the processor, it implements the method according to any one of claims 1-15.

18. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that, when executed by one or more processors, implements the method according to any one of claims 1-15.

19. A computer program product comprising a computer program / instructions, characterized in that, When the computer program / instructions are executed by the processor, they implement the method described in any one of claims 1-15.

Images