Method and apparatus for testing virtual private network

Abstract

This disclosure provides a testing method, apparatus, electronic device, storage medium, and computer program product for Virtual Private Networks (VPNs), relating to the field of computer technology, specifically VPNs, container orchestration engines, and remote office technologies, and applicable to VPN testing scenarios. The specific implementation involves: determining a specified number of containerized VPN clients; utilizing the VPN link between the VPN clients and the VPN gateway, and the intranet link between the VPN gateway and the test server, transmitting test packets between the test clients (which are containerized with the VPN clients) and the test server; and determining the VPN's carrying capacity based on network performance data during packet transmission. This disclosure provides a testing solution based on containerized VPN clients, significantly improving resource utilization and testing efficiency.

Description

Technical Field

[0001] This disclosure relates to the field of computer technology, specifically to the fields of virtual private networks, container orchestration engines, and remote office, and particularly to a testing method, apparatus, electronic device, storage medium, and computer program product for virtual private networks, which can be applied to testing scenarios for virtual private networks. Background Technology

[0002] With the increasing prevalence of digital transformation and remote work in enterprises, secure access methods for enterprise office networks are shifting from traditional leased lines and direct LAN connections to VPN (Virtual Private Network) tunnels with encrypted access. By establishing end-to-end encrypted channels, VPNs enable secure interconnection between employee devices and the enterprise intranet, becoming a core infrastructure for enterprise network security. They carry critical functions such as identity authentication, traffic encryption, and access control, and need to support tens or even hundreds of thousands of concurrent connections. Accurately assessing the user capacity limit, performance bottlenecks, and stability of a VPN system before product launch has become a major challenge for network operations and testing teams. Summary of the Invention

[0003] This disclosure provides a testing method, apparatus, electronic device, storage medium, and computer program product for virtual private networks.

[0004] According to the first aspect, a testing method for a virtual private network is provided, comprising: determining a specified number of containerized VPN clients; using the virtual private network link between the VPN clients and the VPN gateway, and the intranet link between the VPN gateway and the test server, to transmit test packets between the test clients and the test server, which are deployed in the same container as the VPN clients; and determining the carrying capacity of the virtual private network based on network performance data during packet transmission.

[0005] According to a second aspect, a testing apparatus for a virtual private network is provided, comprising: a client determination unit configured to determine a specified number of containerized VPN clients; a message transmission unit configured to transmit test messages between test clients and test servers deployed in the same container as the VPN clients using the virtual private network link between the VPN clients and the VPN gateway, and the intranet link between the VPN gateway and the test server; and a testing unit configured to determine the carrying capacity of the virtual private network based on network performance data during message transmission.

[0006] According to a third aspect, an electronic device is provided, comprising: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, the instructions being executed by the at least one processor to enable the at least one processor to perform a method as described in any implementation of the first aspect.

[0007] According to a fourth aspect, a non-transitory computer-readable storage medium is provided that stores computer instructions for causing a computer to perform the method described in any implementation of the first aspect.

[0008] According to a fifth aspect, a computer program product is provided, comprising: a computer program that, when executed by a processor, implements the method as described in any implementation of the first aspect.

[0009] According to the technology disclosed herein, a testing method and apparatus for virtual private networks (VPNs) are provided. This involves determining a specified number of containerized VPN clients; utilizing the VPN link between the VPN clients and the VPN gateway, and the intranet link between the VPN gateway and the test server, to transmit test packets between the test clients and the test server, which are deployed in the same container as the VPN clients; and determining the carrying capacity of the VPN based on network performance data during the transmission of the test packets. This provides a testing scheme based on containerized VPN clients. Based on container orchestration technology, a single physical node (host machine) can run multiple client containers containing VPN clients, significantly improving resource utilization and testing efficiency.

[0010] It should be understood that the description in this section is not intended to identify key or essential features of the embodiments of this disclosure, nor is it intended to limit the scope of this disclosure. Other features of this disclosure will become readily apparent from the following description. Attached Figure Description

[0011] The accompanying drawings are provided to better understand this solution and do not constitute a limitation of this disclosure. Wherein: Figure 1 This is an exemplary system architecture diagram that can be applied to an embodiment of this disclosure; Figure 2 This is a flowchart of one embodiment of the testing method for virtual private networks according to the present disclosure; Figure 3 This is a schematic diagram of a test architecture for a virtual private network according to this embodiment; Figure 4 This is a test flowchart of a virtual private network according to this embodiment; Figure 5 This is a schematic diagram of the transmission process of the test message according to this embodiment.

[0012] Figure 6 This is a flowchart of the simulated login process according to this embodiment; Figure 7 This is a schematic diagram illustrating an application scenario of the testing method for a virtual private network according to this embodiment; Figure 8 This is a flowchart of yet another embodiment of the testing method for virtual private networks according to the present disclosure; Figure 9 This is a structural diagram of one embodiment of a test apparatus for a virtual private network according to the present disclosure; Figure 10 This is a schematic diagram of the structure of a computer system suitable for implementing the embodiments of the present disclosure. Detailed Implementation

[0013] The exemplary embodiments of this disclosure are described below with reference to the accompanying drawings, including various details of the embodiments to aid understanding, and should be considered merely exemplary. Therefore, those skilled in the art will recognize that various changes and modifications can be made to the embodiments described herein without departing from the scope and spirit of this disclosure. Similarly, for clarity and brevity, descriptions of well-known functions and structures are omitted in the following description.

[0014] The technical solutions disclosed herein involve the collection, storage, use, processing, transmission, provision, and disclosure of various types of information, such as user personal information, in accordance with relevant laws and regulations and do not violate public order and good morals.

[0015] Figure 1 An exemplary architecture 100 is shown that can be used to test methods and apparatus for virtual private networks disclosed herein.

[0016] like Figure 1 As shown, the system architecture 100 may include terminal devices 101, 102, and 103, a network 104, and a server 105. The communication connections between terminal devices 101, 102, and 103 form a network topology. Network 104 serves as the medium for providing communication links between terminal devices 101, 102, and 103 and server 105. Network 104 may include various connection types, such as wired or wireless communication links or fiber optic cables, etc.

[0017] Terminal devices 101, 102, and 103 can be hardware or software that supports network connectivity for data acquisition, interaction, and processing. When terminal devices 101, 102, and 103 are hardware, they can be various electronic devices that support network connectivity, information acquisition, interaction, display, and processing functions, including but not limited to smartphones, tablets, e-book readers, laptops, and desktop computers. When terminal devices 101, 102, and 103 are software, they can be installed in the aforementioned electronic devices. They can be implemented as, for example, multiple software programs or software modules used to provide distributed services, or as a single software program or software module. No specific limitations are imposed here.

[0018] Server 105 can be a server that provides various services, such as acquiring a specified number of containerized VPN clients sent by terminal devices 101, 102, and 103 to test the virtual private network. As an example, server 105 could be a cloud server.

[0019] It should be noted that a server can be either hardware or software. When the server is hardware, it can be implemented as a distributed server cluster consisting of multiple servers, or as a single server. When the server is software, it can be implemented as multiple software programs or software modules (such as software programs or software modules used to provide distributed services), or as a single software program or software module. No specific limitations are made here.

[0020] It should also be noted that the virtual private network testing method provided in the embodiments of this disclosure is generally executed by a server, but the possibility of it being executed by a terminal device, or by a combination of the server and the terminal device, is not excluded. Accordingly, the various parts (e.g., various units) of the virtual private network testing apparatus can be all located in the server, all located in the terminal device, or separately located in the server and the terminal device.

[0021] It should be understood that Figure 1 The number of terminal devices, networks, and servers shown is merely illustrative. Any number of terminal devices, networks, and servers can be included depending on implementation needs. When the electronic devices on which the VPN testing method runs do not require data transmission with other electronic devices, the system architecture may consist only of the electronic devices (e.g., servers or terminal devices) on which the VPN testing method runs.

[0022] Please refer to Figure 2 , Figure 2 A flowchart illustrating a testing method for a Virtual Private Network (VPN) provided in this embodiment of the disclosure. Flowchart 200 includes the following steps: Step 201: Determine the specified number of containerized VPN clients.

[0023] In this embodiment, the entity executing the virtual private network testing method (e.g., Figure 1 (The server in the middle) determines a specified number of containerized VPN clients.

[0024] A VPN is a technology that enables secure and private communication between two or more network nodes by establishing an encrypted tunnel over a public network (such as the Internet or a corporate intranet). VPNs can encapsulate and encrypt transmitted data to prevent it from being eavesdropped on or tampered with, while also hiding the real network addresses of the communicating parties. They are widely used in scenarios such as remote work, branch office interconnection, and secure access.

[0025] A VPN client is a software entity running on the user's device, responsible for establishing an encrypted tunnel connection with the remote VPN gateway. In this embodiment, the VPN client has the following characteristics: Containerized deployment: Each VPN client runs in a separate container, which is managed and scheduled by a container orchestration platform such as Kubernetes.

[0026] Independent network namespace: Each VPN client container has its own independent network protocol stack, including virtual network interfaces, routing tables, etc.

[0027] Tunnel endpoint function: The VPN client is responsible for encrypting and encapsulating business messages and sending them to the VPN gateway through the tunnel; at the same time, it receives tunnel messages from the VPN gateway, performs decapsulation and decryption to restore the original business messages.

[0028] Deployed in the same container as the test client: The VPN client and the test client (such as iperf-client) coexist in the same container, sharing the container's network namespace, which allows the business packets sent by the test client to be directly intercepted by the VPN client and sent into the tunnel.

[0029] As an example, a Kubernetes Deployment resource file is pre-written, defining the template for the VPN client container (including container image, resource limits, environment variables, etc.) and setting the initial replica count to 0. When VPN capacity testing is required, testers use the `kubectl scale` command to adjust the replica count of this Deployment to a specified number (e.g., 100, 1000, or 10000). Upon receiving the command, the Kubernetes cluster automatically creates the corresponding number of Pods, each running an independent VPN client container. After each Pod starts, a pre-defined startup script is automatically executed to initialize the VPN client, establish a tunnel with the VPN gateway, and trigger subsequent load testing processes. By gradually increasing the replica count and observing the performance of the VPN gateway under different concurrent client counts, the carrying capacity of the VPN system can be accurately evaluated. After the load test, the replica count is reduced to 0 again using `kubectl scale`, terminating all VPN client Pods in batches and releasing cluster resources.

[0030] As another example, before testing begins, testers manually create a Pod list or Job configuration file containing multiple VPN client container definitions, based on the required number of VPN clients. For instance, using Kubernetes Pod or Job resources, a separate Pod is created for each VPN client, with the `replicas` field in the configuration file specifying the target value. Testers submit this configuration file to the Kubernetes cluster using the `kubectl apply -f` command, and the cluster then creates the specified number of VPN client Pods at once. After the VPN client containers within each Pod start, they sequentially execute tunnel establishment and load testing tasks. This approach is suitable for test scenarios requiring a fixed number of clients and where scaling is not frequent. After testing, the corresponding resource objects are deleted using the `kubectl delete` command to terminate all VPN client Pods.

[0031] In some optional implementations of this embodiment, the execution entity may also perform the following operation: determine the IP address of the main network interface of the VPN client under a preset network segment, wherein the preset network segment is different from the network segment of the intranet where the intranet link is located.

[0032] As an example, when deploying a Kubernetes cluster, the default network segment is set to 192.168.0.0 / 16 by configuring the IP address pool parameters of the Calico network plugin. This default network segment is completely different from the internal network segment of the enterprise's internal network links (such as 10.0.0.0 / 8 or 172.16.0.0 / 12). The Calico component assigns an independent IP address, such as 192.168.4.4 or 192.168.5.2, to the main network interface (eth0) of each created VPN client container based on this default network segment. Since the 192.168.0.0 / 16 network segment is generally not used for enterprise internal network planning, these container IP addresses will not occupy valuable internal network IP resources, nor will they cause address conflicts with existing business networks. At the same time, this default network segment provides approximately 65,000 available IP addresses, which can meet the allocation needs of tens of thousands of VPN client containers and achieve complete isolation between container networks and internal network resources.

[0033] In this implementation, by selecting a preset network segment different from the internal network to allocate the container's main network interface IP, address conflicts and resource consumption are avoided, and sufficient address space is provided, laying the foundation for large-scale containerized deployment of VPN clients.

[0034] Step 202: Using the virtual private network link between the VPN client and the VPN gateway, and the intranet link between the VPN gateway and the test server, transmit test messages between the test client and the test server, which are deployed in the same container as the VPN client.

[0035] In this embodiment, the aforementioned execution entity utilizes the virtual private network link between the VPN client and the VPN gateway, as well as the intranet link between the VPN gateway and the test server, to transmit test messages between the test client and the test server, which are deployed in the same container as the VPN client.

[0036] A VPN gateway is a network device (or software service) deployed at the network boundary or server, responsible for establishing and maintaining encrypted tunnel connections with multiple VPN clients. In this embodiment, the VPN gateway has the following functions: Tunnel endpoint: As the peer of the VPN tunnel, it receives tunnel encapsulation packets from various VPN clients, performs decapsulation and decryption, and restores the original test packets.

[0037] Connection Management: Maintains information such as session state, encryption keys, and assigned inner tunnel IP addresses for each VPN client.

[0038] Deployment methods: VPN gateways can run directly on physical machines or virtual machines (i.e., gateway nodes) as binary processes, or they can be deployed in containers, but they are usually deployed on host machines to obtain better network performance.

[0039] A test client is a software program (e.g., the client mode of iperf) deployed in the same container as the VPN client to generate business test traffic. The test client is responsible for initiating connection requests or data streams, and the destination address of the raw test packets it sends is the address of the test server. Because it resides in the same container as the VPN client, the packets sent by the test client can be directly captured by the VPN client and sent into the VPN tunnel without traversing an external network.

[0040] A test server is a software program (e.g., iperf server mode) running on a test node to receive business traffic from test clients. The test server listens on a specified port, receives test packets forwarded by the VPN gateway, and generates response packets to return to the VPN gateway. By measuring metrics such as throughput, latency, and packet loss rate between the test client and the test server, the performance of the VPN system when carrying business traffic can be evaluated.

[0041] As an example, the test message generated by the test client is first passed to the VPN client within the same container. The VPN client encapsulates the test message into a VPN tunnel message based on pre-configured tunnel parameters (such as the VPN gateway address and encryption key). The outer source address of this tunnel message is the network interface address of the client container, and the outer destination address is the main network interface address of the gateway node where the VPN gateway resides. The tunnel message is then sent from the client container, passes through the network protocol stack of the host machine, and is transmitted through the underlying physical network (such as a cloud virtual private cloud network or enterprise intranet) to the gateway node where the VPN gateway resides.

[0042] After receiving the tunnel packet, the VPN gateway performs a decapsulation operation to restore the test packet. Then, based on the destination address of the test packet (i.e., the address of the test server), the VPN gateway forwards the original business packet to the test server through the internal network link between the gateway node and the test server. The test server receives the packet, processes it, and can return the response packet back to the test client along the same path, thus forming a complete request-response loop.

[0043] As another example, a stable bidirectional VPN tunnel has already been pre-established between the VPN client and the VPN gateway. Before the test client starts sending test packets, the testers have configured internal network routing rules on the VPN gateway pointing to the test server, ensuring that any packets sent to the test server address will be received and forwarded by the VPN gateway.

[0044] After the test starts, the test client sends test packets (such as UDP data streams or TCP connection requests) to the VPN client in the same container. The VPN client uses the established VPN tunnel to encrypt the packets and add an outer header (the outer source address is the IP address of the client container, and the outer destination address is the IP address of the gateway node where the VPN gateway is located). This VPN tunnel packet is transmitted to the gateway node through the container host and the underlying network.

[0045] After receiving the tunnel packet, the VPN gateway process on the gateway node decapsulates it, restoring the original test packet. Then, the VPN gateway queries its local intranet routing table and sends the original test packet out from the gateway node's main network interface, delivering it to the test server via the intranet link. Upon receiving the packet, the test server can immediately begin recording performance metrics such as reception rate and packet loss rate. Simultaneously, any response packets generated by the test server are also returned to the VPN gateway via the same intranet link, and then sent back to the test client through the VPN tunnel, thus continuously measuring bidirectional transmission performance.

[0046] Continue to refer to Figure 3 This diagram illustrates a test architecture for a Virtual Private Network (VPN). VPN clients are deployed in client containers on nodes of a Kubernetes cluster; each Kubernetes node can include multiple client containers. Calico is used in the test architecture to manage the IP addresses of the client containers. Calico is an open-source Container Network Interface (CNI) plugin that provides high-performance Pod networking for Kubernetes clusters. Based on a pure Layer 3 routing model, it uses the BGP protocol to directly publish Pod IP routes to each node in the cluster, enabling direct communication between Pods across nodes.

[0047] The client node where the client container resides and the gateway node where the VPN gateway resides communicate via Calico, while the gateway node and the test node where the test server resides are connected via the intranet.

[0048] Continue to refer to Figure 4 The flowchart for testing a Virtual Private Network is shown.

[0049] In some optional implementations of this embodiment, the virtual private network link includes a bridging sub-link between the client container to which the VPN client belongs and the client node to which the client container belongs, as well as a cross-node sub-link between the client node and the gateway node to which the VPN gateway belongs.

[0050] The bridging sub-link consists of the eth0 virtual network interface card (NIC) within the client container, a virtual bridge on the client node (host machine) (such as the Linux Bridge or Calico veth pair), and a virtual Ethernet pair (vethpair) connecting the two. Its function is to directly connect the network namespace within the container to the network protocol stack of the client node: test packets sent from eth0 within the client container enter the virtual bridge on the client node via the veth pair and are then delivered to the routing or forwarding module of the client node; conversely, packets sent from the client node to the container are also sent to the eth0 of the client container via this bridging link. This link enables low-latency, high-throughput Layer 2 forwarding between the container and the host machine.

[0051] The cross-node sub-link consists of the physical network interface card (eth0) of the client node, the physical network interface card (eth0) of the gateway node, and the underlying physical network (such as an Ethernet switch or a cloud virtual private cloud network) connecting the two. Its function is to transmit test packets between the two hosts: the client node sends the test packet to the physical network through its eth0, and the network routes and forwards it according to the destination IP address of the test packet (i.e., the IP address of the gateway node), ultimately delivering it to the gateway node's eth0. This link enables Layer 3 network communication between components on different hosts (such as the VPN client container and the VPN gateway process).

[0052] The internal network link consists of the physical network interface card (eth0) of the gateway node, the physical network interface card (eth0) of the test node, and the enterprise internal network or cloud virtual private cloud network between them. Its function is to transmit test packets between the VPN gateway and the test server: the gateway node sends the original test packets, decapsulated by the VPN, through its eth0, which are then routed via the internal network to the eth0 of the test node, where the test server receives the test packets; conversely, the test packets from the test server are also returned to the gateway node via this link. This link is an existing network infrastructure within the enterprise and typically features high bandwidth and low latency.

[0053] In this implementation, the aforementioned execution entity performs step 202 and transmits test messages in the following ways: using the container-internal transmission link between the test client and the VPN client, test messages are transmitted between the test client and the VPN client; using the bridging sub-link and the cross-node sub-link, test messages are transmitted between the VPN client and the VPN gateway; and using the intranet link, test messages are transmitted between the gateway node and the test node to which the test server belongs.

[0054] As an example, testers first deploy a Deployment in a Kubernetes cluster. Within each client container (Pod) of this Deployment, both a test client (such as iperf-client) and a VPN client run concurrently. The VPN client and VPN gateway have already completed tunnel configuration via a login process. At the start of the test, the test client generates test packets destined for the test server (IP address 10.45.99.66).

[0055] The test message is first sent to the VPN client's listening port via the in-container transport link (i.e., the local network stack within the same Pod, without passing through any physical devices). After receiving the test message, the VPN client encapsulates it using the VPN tunnel configuration. The outer source IP address of the encapsulated message is the eth0 address of the client container (e.g., 192.168.4.4), and the outer destination IP address is the IP address of the main network interface of the gateway node where the VPN gateway is located (e.g., 10.38.151.10).

[0056] The encapsulated packet is sent from the client container's eth0 interface. Via the bridge sub-link, the packet enters the virtual bridge on the client node via the veth pair. The bridge determines which network protocol stack to send the encapsulated packet to based on the destination IP address. The client node queries its routing table and finds that the destination IP address 10.38.151.10 belongs to a directly connectable physical network segment. Therefore, the encapsulated packet is sent from the client node's eth0 physical network interface, forwarded through the cloud network via the cross-node sub-link, and finally reaches the gateway node's eth0 physical network interface.

[0057] The VPN gateway process on the gateway node receives the encapsulated packet from eth0 and decapsulates it to obtain the original test packet. Then, based on the destination IP address 10.45.99.66 of the original test packet, the gateway node queries its internal routing table and sends the test packet from its own eth0, transmitting it via the internal network link to the test node's eth0. The test server (such as iperf-server) receives the test packet, processes it, and can return a response packet in reverse along the same path, thus completing a full test packet transmission.

[0058] In this implementation, by dividing the transmission path into three sub-links—intra-container, bridged, and cross-node—VPN clients can be deployed and expanded modularly. At the same time, by utilizing existing container networks and physical network infrastructure, large-scale concurrent testing can be achieved.

[0059] Continue to refer to Figure 5 This diagram illustrates the transmission process of the test message.

[0060] In some optional implementations of this embodiment, the test message includes a request message. A request message is a raw data packet actively sent by the test client to the test server to trigger business interactions or performance measurements. This request message contains at least a source address (i.e., the network address of the VPN tunnel interface of the client container), a destination address (i.e., the network address of the test node to which the test server belongs), a transport layer protocol type (such as TCP or UDP), and a payload. For example, the destination address of the request message is the IP address of the test node to which the test server belongs (e.g., 10.45.99.66), and its source address is the IP address of the VPN tunnel interface of the client container (e.g., 100.0.0.2). The request message is the starting point of the test process; by observing and measuring its transmission process, performance indicators such as throughput, latency, and packet loss rate of the virtual private network can be obtained.

[0061] In this implementation, the aforementioned execution entity transmits test packets between the test client and the VPN client in the following manner: First, through local route hijacking, the request packet sent by the test client to the test server is transmitted to the VPN tunnel interface of the client container; then, using the intra-container transmission link, the request packet is transmitted from the VPN tunnel interface to the VPN client.

[0062] As an example, the test client (such as iperf-client) and the VPN client run within the same client container, sharing the network namespace of that client container. The test client generates a request message destined for the test server. The destination IP address of this message is the IP address of the test node to which the test server belongs (e.g., 10.45.99.66), and the source IP address is the IP address of the VPN tunnel interface of the client container (e.g., 100.0.0.2).

[0063] Local route hijacking refers to forcibly changing the flow of request packets that should be sent directly to the external network by configuring policy-based routing or iptables rules inside the container. The specific implementation is as follows: Add a static routing rule in the client container's network namespace to route all packets destined for the test server address (10.45.99.66) to the VPN client's virtual network interface (e.g., wg0). Alternatively, use iptables' REDIRECT or DNAT rules to redirect packets destined for 10.45.99.66 to the local port listened to by the VPN client. When the test client sends a request packet, the network protocol stack matches the hijacking rule during route lookup, thus transmitting the packet to the client container's VPN tunnel interface (i.e., the wg0 virtual network interface).

[0064] Since the test client and the VPN client reside within the same container, communication between them is entirely handled through the container's internal network protocol stack, without requiring any physical network interface card or virtual bridge. This constitutes the intra-container transmission link. Once a request message enters the wg0 interface, it is read by the VPN client process, which then performs subsequent encapsulation and transmission processing on the message.

[0065] In this implementation, request packets are captured directly within the container through local route hijacking, avoiding the involvement of additional network devices and reducing transmission latency; at the same time, business applications can seamlessly access the VPN tunnel, simplifying the configuration of test clients.

[0066] In some optional implementations of this embodiment, the execution entity transmits test packets between the VPN client and the VPN gateway in the following manner: First, the request packet is encapsulated using a VPN tunnel to obtain a VPN request packet, wherein the source address of the VPN request packet is the IP address of the main network interface of the client container, and the destination address is the IP address of the main network interface of the gateway node; then, the VPN request packet is transmitted to the client node using a bridge sub-link; then, the VPN request packet is transmitted to the VPN gateway using a cross-node sub-link; and finally, the VPN request packet is decapsulated using a VPN tunnel through the VPN gateway to obtain the request packet.

[0067] VPN tunnel encapsulation refers to the process by which a VPN client, according to a pre-negotiated tunneling protocol (such as WireGuard), uses the original request message as its inner payload and adds a new IP header (and possibly a UDP header) to the outer layer, forming a new data packet. The source address of the newly added outer IP header is set to the IP address of the client container's main network interface, and the destination address is set to the IP address of the main network interface of the gateway node where the VPN gateway resides. The encapsulated packet can be securely transmitted through the underlying network, while the original inner packet remains invisible during network transmission, thus achieving data encryption and isolation.

[0068] VPN tunnel decapsulation refers to the process by which a VPN gateway, upon receiving a VPN request message, removes the outer IP header (and possibly the UDP header) to reconstruct the original inner request message. During decapsulation, the VPN gateway also decrypts and verifies the integrity of the message according to the tunnel protocol, ensuring the message's authenticity and security. The original request message obtained after decapsulation is completely identical to the message before encapsulation by the VPN client.

[0069] As an example, the test client and the VPN client run within the same container, and the request packet has been transmitted to the VPN client's wg0 interface via local route hijacking. After reading the request packet, the VPN client encapsulates it using the WireGuard protocol for VPN tunneling. Specifically, the VPN client adds an outer UDP header and an IP header to the original request packet. The source address of the outer IP header is set to the IP address of the client container's main network interface (e.g., 192.168.4.4), the destination address is set to the IP address of the main network interface of the gateway node where the VPN gateway resides (e.g., 10.38.151.10), the UDP source port is the WireGuard default port (e.g., 7166), and the destination port is also (e.g., 7166). The resulting encapsulated packet is called a VPN request packet.

[0070] The VPN request message originates from the eth0 network interface card (NIC) of the client container and enters the network protocol stack of the client node (host machine) via the bridge sub-link (veth pair and host virtual bridge). The client node looks up the routing table based on the destination IP address 10.38.151.10 in the outer layer of the message and finds that the next hop for this address needs to be reached through the physical network. Therefore, the VPN request message is sent from the client node's physical NIC eth0 and transmitted to the gateway node where the VPN gateway is located via the cross-node sub-link (cloud network or physical network), and is received by the gateway node's eth0 NIC.

[0071] After receiving the VPN request message from eth0, the VPN gateway process on the gateway node identifies it as a WireGuard tunnel message. It then performs VPN tunnel decapsulation, removing the outer UDP and IP headers, decrypting and restoring the inner original request message. At this point, the obtained original request message is completely identical to the request message initially sent by the test client, with the source IP address being the test client's address within the container (e.g., 100.0.0.2) and the destination IP being the test server's address (e.g., 10.45.99.66).

[0072] In this implementation, the original request message is encapsulated into a VPN request message with the container IP as the outer source and the gateway IP as the destination. Then, bridging and cross-node link transmission are used to achieve secure and efficient tunnel communication between the VPN client in the container and the remote gateway, laying the foundation for large-scale concurrent testing.

[0073] In some optional implementations of this embodiment, the execution entity transmits test messages between the gateway node and the test node to which the test server belongs in the following manner: First, the source address of the request message is converted into the IP address of the main network interface of the gateway node to obtain the converted message; then, the converted message is transmitted to the test server through the intranet link.

[0074] This implementation uses SNAT (Source Network Address Translation) technology. SNAT is a network address translation technique used to modify the source IP address of data packets. When a data packet passes through an SNAT device, the device's source address is replaced with a specified IP address (usually the device's own interface address). Simultaneously, the device maintains a connection tracking table to reverse-engineer the destination address of the response.

[0075] The original request message obtained after decapsulation by the VPN gateway has a source IP address that is the VPN client's inner tunnel IP (e.g., 100.0.0.2). This address belongs to the VPN tunnel's dedicated address range and is not in the internal network routing table of the test server.

[0076] The test server (e.g., 10.45.99.66) cannot directly respond to packets with a source IP of 100.0.0.2 because its return packet route does not know how to reach the 100.0.0.0 / 8 network segment. By translating the source address of the request packet to the main network interface IP of the gateway node where the VPN gateway resides (e.g., 10.38.151.10), the test server sends the response packet to that gateway node. The gateway node then uses its connection tracking table to restore the response packet back to 100.0.0.2 and returns it to the client via the VPN tunnel, thus achieving bidirectional communication.

[0077] As an example, the gateway node where the VPN gateway resides (IP address 10.38.151.10) has completed the decapsulation of the VPN request message, obtaining the original request message. The content of the original request message is: source IP address 100.0.0.2 (the inner IP of the VPN client tunnel), destination IP address 10.45.99.66 (the IP address of the test server), and TCP / UDP payload.

[0078] Since the destination IP 10.45.99.66 is an internal network address, while the source IP 100.0.0.2 is not within the internal network routing range, the VPN gateway process calls the kernel's Netfilter framework to add an SNAT rule in the POSTROUTING chain of the nat table. This rule matches all packets with a source IP of 100.0.0.2 and a destination IP of 10.45.99.66, and translates their source address to the IP address of the gateway node's main network interface, 10.38.151.10. After the translation, the resulting packet has a source IP address of 10.38.151.10 and a destination IP address of 10.45.99.66.

[0079] The gateway node, where the VPN gateway resides, queries its local routing table and finds that the destination IP address 10.45.99.66 can be directly reached through the internal network interface (eth0). Therefore, the gateway node sends the translated packet from its eth0 network card, which is then transmitted through the internal network link. The switch or router in the internal network forwards the packet to the test node where the test server resides based on the destination address 10.45.99.66. The test node's eth0 network card receives the packet and delivers it to the test server process (such as iperf-server). The test server then receives a request from 10.38.151.10, interprets it as a direct request from the VPN gateway, and can therefore process it normally and generate a response packet.

[0080] In this implementation, SNAT is used to translate the source address of the request message into the IP address of the gateway node, enabling the test server to recognize and respond, thus establishing communication between the inner address of the VPN tunnel and the internal network, and ensuring a complete closed loop of the request-response link.

[0081] In some optional implementations of this embodiment, the test message includes a response message to the request message. The response message refers to the data packet generated by the test server after receiving the request message and returned to the requester based on the request content. The request message received by the test server (e.g., iperf-server) undergoes SNAT translation, with its source address being the main network interface IP of the gateway node where the VPN gateway resides (e.g., 10.38.151.10) and its destination address being the test server's own address (e.g., 10.45.99.66). Therefore, the source address of the response message generated by the test server is 10.45.99.66, and the destination address is 10.38.151.10. This response message is the test server's response to the request, transmitted to the VPN gateway via the internal network link, and then further processed by the VPN gateway and returned to the test client through the VPN tunnel.

[0082] In this implementation, the aforementioned execution entity transmits test messages between the gateway node and the test node to which the test server belongs in the following manner: the response message is transmitted from the test server to the gateway node using the intranet link.

[0083] As an example, the test server (10.45.99.66) has successfully received the request packet after SNAT translation (source IP address 10.38.151.10, destination IP address 10.45.99.66). The test server generates a corresponding response packet based on business logic (e.g., TCP echo or UDP measurement data from the iperf-server). The source IP address of this response packet is set to the test server's own IP address 10.45.99.66, and the destination IP address is set to the source IP address in the request packet, i.e., the IP address of the main network interface of the gateway node where the VPN gateway is located, 10.38.151.10.

[0084] The test node, where the test server is located, queries its internal network routing table based on the destination IP 10.38.151.10 of the response packet. Since 10.38.151.10 and the test server 10.45.99.66 belong to the same internal network (e.g., the same VPC or enterprise internal network), the routing table contains a directly connected route or static route to the 10.38.151.0 / 24 network segment. Therefore, the test node sends the response packet from its eth0 physical network interface card (NIC) and transmits it via the internal network link. Network devices within the internal network forward the packet to the gateway node where the VPN gateway resides based on the destination address 10.38.151.10, and it is ultimately received by the gateway node's eth0 NIC.

[0085] In this implementation, the response message is transmitted directly from the test server back to the VPN gateway via the intranet link. This utilizes the high bandwidth and low latency characteristics of the existing intranet, avoids complex routing configuration, lays the foundation for rapid restoration and return to the client, and improves the accuracy of VPN testing.

[0086] In some optional implementations of this embodiment, the execution entity transmits test packets between the VPN client and the VPN gateway in the following manner: First, the destination address of the response packet is converted to the IP address of the VPN tunnel interface of the client container to obtain the restored packet; then, the restored packet is encapsulated with a VPN tunnel to obtain a VPN response packet, wherein the source address of the VPN response packet is the IP address of the main network interface of the gateway node, and the destination address is the IP address of the main network interface of the client container; then, based on the destination address of the VPN response packet, the IP address of the client node is determined from the BGP routing table. The VPN response message is generated by IP address mapping, where the BGP routing table represents the mapping between the network segment corresponding to the client container and the IP address of the client node. Then, the VPN response message is encapsulated using IPIP based on the client node's IP address, resulting in a double-encapsulated message. The source address of the double-encapsulated message is the gateway node's IP address, and the destination address is the client node's IP address. Next, the double-encapsulated message is transmitted to the client node using a cross-node sub-link. Then, the double-encapsulated message is decapsulated using IPIP to obtain the VPN response message. Finally, the VPN response message is transmitted to the VPN client using a bridged sub-link.

[0087] IPIP encapsulation is a tunneling technique that uses IP packets as the inner payload and adds an outer IP header. The source address of the outer IP header is set to the physical IP address of the sending device, and the destination address is set to the physical IP address of the receiving device. The resulting IPIP-encapsulated message is called a double-layer IP message. The inner message (the original VPN response message) is not parsed by intermediate network devices during transmission, thus enabling direct communication between hosts across Layer 3 networks. In this embodiment, IPIP encapsulation is used to transmit VPN response messages from the gateway node to the client node, solving the problem that the Pod IP (i.e., the IP address of the client container's main network interface, 192.168.4.4) cannot be directly routed in the physical network.

[0088] IPIP decapsulation is the reverse process of IPIP encapsulation. After receiving a double-encapsulated packet, the receiving device (such as a client node) removes the outer IP header to reconstruct the inner VPN response packet. The decapsulated VPN response packet is completely identical to the original packet and can be directly processed by upper-layer protocols (such as the VPN client's listening process). In this implementation, the client node decapsulates the received IPIP packet to obtain the original VPN response packet, which is then forwarded to the VPN client via a bridged sublink.

[0089] As an example, the gateway node where the VPN gateway resides (e.g., with a physical IP address of 192.168.2.10 and a main network interface IP address of 10.38.151.10) has received a response message from the test server via the internal network link. The original content of this response message is: source IP address 10.45.99.66, destination IP address 10.38.151.10 (i.e., the main network interface address of the gateway node).

[0090] First, the VPN gateway translates the destination address of the response packet to the IP address 100.0.0.2 of the VPN tunnel interface of the client container based on the connection tracking table (conntrack), resulting in a restored packet with a source IP address of 10.45.99.66 and a destination IP address of 100.0.0.2. This restored packet is the response that the test client initially expected to receive.

[0091] Next, the VPN gateway performs VPN tunnel encapsulation (e.g., using WireGuard) on the restored packet to obtain a VPN response packet. After encapsulation, the source address in the outer IP header is set to the gateway node's main network interface IP address 10.38.151.10, and the destination address is set to the client container's main network interface IP address 192.168.4.4. At this point, the VPN response packet is a regular IP packet (source 10.38.151.10 → destination 192.168.4.4), but the destination IP 192.168.4.4 belongs to the Pod network segment managed by Calico and is not in the cloud network's direct routing table, requiring further encapsulation.

[0092] Therefore, the gateway node queries its local BGP routing table. The BGP routing table records the mapping between Pod subnets (e.g., 192.168.4.0 / 24) and their corresponding host physical IP addresses. Based on the destination address 192.168.4.4 of the VPN response packet, the corresponding subnet is matched from the BGP routing table, determining that the physical IP address of the client node hosting the Pod is 192.168.1.10.

[0093] Then, the gateway node's kernel network stack performs IPIP encapsulation on the VPN response message: adding a new outer IP header, setting the source address to the gateway node's physical IP address 192.168.2.10, and the destination address to the client node's physical IP address 192.168.1.10. This results in a double-encapsulated message, with the outer layer being the IPIP tunnel header and the inner layer being the VPN response message (outer source 10.38.151.10 → destination 192.168.4.4).

[0094] The double-encapsulated message is sent from the gateway node's eth0 physical network interface card and transmitted via cross-node sub-links (cloud network or physical network). The network device forwards the message to the client node based on the outer destination IP address 192.168.1.10, and the message is received by the client node's eth0 network interface card.

[0095] After receiving the double-encapsulated message, the client node identifies the protocol number in the outer IP header as 4 (IPIP), and then performs IPIP decapsulation: removing the outer IP header to restore the inner VPN response message (source 10.38.151.10 → destination 192.168.4.4). The decapsulated VPN response message then enters the client node's network protocol stack.

[0096] The client node queries its local routing table based on the destination address 192.168.4.4 of the packet and finds that the address belongs to the network segment of a certain Pod on the local node. Therefore, the packet is sent to the virtual bridge and transmitted to the eth0 network interface of the client container via the bridge sub-link (veth pair and eth0 of the client container), and is finally received by the VPN client process.

[0097] In this implementation, the mapping from Pod IP to host physical IP is achieved through the BGP routing table, and cross-node transmission is encapsulated using IPIP, which solves the routing isolation problem between the container network and the physical network and ensures that response packets can be accurately delivered to the remote VPN client container.

[0098] In some optional implementations of this embodiment, the execution entity transmits test messages between the test client and the VPN client in the following manner: decapsulates the VPN response message using a VPN tunnel to obtain the restored message; and uses the in-container transmission link to transmit the restored message from the VPN client to the test client.

[0099] As an example, the client container where the VPN client resides (main network interface IP is 192.168.4.4, VPN tunnel interface IP is 100.0.0.2) has received a VPN response message from the client node via the bridge sub-link. The outer source IP of this VPN response message is 10.38.151.10 (the IP address of the gateway node's main network interface), and the outer destination IP is 192.168.4.4 (the IP address of the client container's main network interface).

[0100] After the VPN client process reads the VPN response packet from the eth0 network interface card inside the container, it performs VPN tunnel decapsulation according to the pre-negotiated VPN tunnel protocol: verifying integrity, decrypting, removing the outer header, and restoring the original inner response packet. The content of the restored packet is: source IP 10.45.99.66 (the IP address of the test node where the test server is located), destination IP 100.0.0.2 (the IP address of the VPN tunnel interface of the client container).

[0101] Since the VPN client and the test client (such as iperf-client) run within the same container, they share the same network namespace, and the test client listens on port 5201 of 0.0.0.0. The VPN client submits the restored packets to the container's network protocol stack through the operating system interface. The protocol stack determines that the packet delivery is local based on the destination IP address 100.0.0.2, then locates the test client's listening socket based on port number 5201 and delivers the packet to the test client process. The test client successfully receives the response packet, thus completing the entire request-response loop, and performance metrics such as throughput and latency can be calculated based on this.

[0102] In this implementation, the VPN response message is directly decapsulated within the client container and forwarded to the test client via the local protocol stack, avoiding additional network overhead, achieving fast end-to-end response delivery, and ensuring the accuracy of performance measurements.

[0103] To further illustrate the entire transmission process, the following example is given: The uplink process of the request message is as follows: 1. The iperf-client (test client) initiates a request message as the traffic requester, requesting the iperf-server (test server) to perform a load test on the bandwidth (source IP address 100.0.0.2 -> destination IP address 10.45.99.66). 2. By hijacking the local route, the request message is forwarded to wg0 of the VPN client. The VPN client then reads the original request message from the iperf client through wg0.

[0104] 3. The VPN client adds a tunnel encapsulation to the original request message to obtain the VPN request message: Inner layer: Source IP address 100.0.0.2 -> Destination IP address 10.45.99.66 Outer layer: Source IP address 192.168.4.4 -> Destination IP address 10.38.151.10 4. The encapsulated VPN request message is tunneled through the eth0 network interface card of the client container.

[0105] 5. VPN request packets sent by the client container are directly bridged to the network kernel of the client node through Calico's virtual network interface card.

[0106] 6. The client node sends the VPN request message to the gateway node through the cloud network.

[0107] 7. After receiving the VPN request message, the VPN server decapsulates the VPN to obtain the original request message: source IP address 100.0.0.2 → destination IP address 10.45.99.66.

[0108] 8. The VPN server forwards the original request packet to the iperf server. The request packet first arrives at the VPN server's eth0. The gateway node performs SNAT on the original request packet and then sends the transformed packet (source IP address 10.38.151.10 -> destination IP address 10.45.99.66) to the iperf server (test server).

[0109] The downlink process of the response message is as follows: 1. The iperf-server returns a response message (source IP address 10.45.99.66 -> destination IP address 10.38.151.10).

[0110] 2. The gateway node performs SNAT on the response packet to obtain the restored packet (source IP address 10.45.99.66 -> destination IP address 100.0.0.2).

[0111] 3. The restored packet is routed to wg0 on the gateway node, and the VPN server reads the restored packet from wg0.

[0112] 4. The VPN server encapsulates the restored packets into a VPN tunnel to obtain the VPN response packet: Inner layer: Source IP address 10.45.99.66 -> Destination IP address 100.0.0.2 Outer layer: Source IP address 10.38.151.10 -> Destination IP address 192.168.4.4 5. VPN response messages are transmitted via VPN tunnel in the cloud network. This is a Node-to-Pod forwarding process. The VPN response message is first routed to the gateway node's calico tunnel0, where a calico tunnel encapsulation (IPIP encapsulation) is added, resulting in a double-encapsulated message. Inner layer: Source IP address 10.38.151.10 -> Destination IP address 192.168.4.4 Outer layer: Source IP address 192.168.2.10 -> Destination IP address 192.168.1.10 6. The double-encapsulated message is forwarded to the tunnel0 network card of the client node through the cloud network.

[0113] 7. After receiving the double-encapsulated packet, the tunnel0 network interface card of the client node performs IPIP decapsulation. The decapsulated packet is a zero-trust tunnel packet (VPN response packet): Inner layer: Source IP address 10.45.99.66 -> Destination IP address 100.0.0.2 Outer layer: Source IP address 10.38.151.10 -> Destination IP address 192.168.4.4 8. The client node sends the zero-trust tunnel packet to the calico virtual network interface card.

[0114] 9. The virtual network interface card forwards zero-trust tunnel packets directly to the client container's eth0 via bridging.

[0115] 10. The zero-trust tunnel packet is forwarded to the VPN client through the client container's local network, where it undergoes zero-trust VPN tunnel decapsulation to obtain the original response packet (source IP address 10.45.99.66 -> destination IP address 100.0.0.2).

[0116] 11. VPN client forwards the decapsulated original response message to IPerf client.

[0117] In some optional implementations of this embodiment, a login client is also deployed in the client container. The login client is an auxiliary process (e.g., login-app) deployed within the client container; it is a customizable VPN login client that simulates client-side processing in the VPN login process.

[0118] A login server (e.g., login-server) is a customizable VPN login server that simulates the VPN login process.

[0119] In this implementation, the aforementioned execution entity can also perform the following operations: First, in response to the login request from the login client, it generates configuration parameters for the virtual private network link through the login server; then, it sends the gateway-side parameters in the configuration parameters to the VPN gateway, and sends the client-side parameters in the configuration parameters to the VPN client through the login client; and establishes a virtual private network link between the VPN client using the client-side parameters and the VPN gateway using the gateway-side parameters.

[0120] Continue to refer to Figure 6 The flowchart shown illustrates the simulated login process.

[0121] After the login client starts, it first generates its own long-term public-private key pair, including the private key privkey_client and the public key pubkey_client. Then, it constructs a login request message, carrying the simulated user identity information (such as username / password) and the generated client public key pubkey_client, and sends it to the login server (for example, the pre-configured address 10.38.151.9).

[0122] Upon receiving the request, the login server verifies the user's identity. If verification is successful, it assigns a unique IP address to the client from the tunnel's inner IP address pool, for example, 100.0.0.2. Then, the login server generates two sets of configuration parameters: Gateway-side parameters include the client's public key `pubkey_client`, the inner tunnel IP address (100.0.0.2) assigned to the client, and the tunnel subnet mask. These parameters are used to configure the VPN server so that it can recognize and accept connections from this client.

[0123] Client-side parameters include the VPN server's inner tunnel IP (i.e., gateway address 100.0.0.1), the client's own tunnel IP address 100.0.0.2, the DNS server address (e.g., 10.0.0.2), and the routing rules that need to be hijacked (e.g., traffic destined for the 10.45.99.0 / 24 segment is sent into the tunnel).

[0124] The login server sends gateway-side parameters directly to the VPN gateway process via a secure channel. Upon receiving the data, the VPN gateway creates a client mapping table locally, recording the correspondence between pubkey_client and 100.0.0.2, and allows tunnel connections from that client.

[0125] Meanwhile, the login server encapsulates the client-side parameters in the login response message and returns it to the login client inside the client container.

[0126] After receiving the parameters from the client side, the login client starts the VPN-client child process and sends the parameters (including DNS, hijacking routes, the IP address of the VPN tunnel interface 100.0.0.2, the gateway address 100.0.0.1, the client's own private key privkey_client, and the server's public key pubkey_server) to the VPN-client via inter-process communication. Based on this, the VPN-client creates a virtual network interface wg0, configures the IP address 100.0.0.2, adds policy routes to hijack specified traffic, and configures DNS.

[0127] The VPN client uses its own long-term private key `privkey_client` and the peer's long-term public key `pubkey_server`, combined with the WireGuard protocol, to generate a temporary Diffie-Hellman key pair (a one-time temporary public key), and then initiates a handshake with the VPN server. During the handshake, both parties calculate a shared session key using the Curve25519 elliptic curve algorithm, which is used for subsequent data encryption. The VPN server uses the previously issued client public key `pubkey_client` to authenticate the client and confirm the tunnel configuration. After a successful handshake, the VPN server returns a confirmation that the tunnel has been successfully established. At this point, the virtual private network link is officially established and can be used for subsequent test packet transmission.

[0128] In this implementation, the login client and server work together to generate and distribute keys, thereby achieving automated and secure VPN tunnel establishment, avoiding manual configuration, and supporting rapid deployment and unified management of a large number of clients.

[0129] Step 203: Determine the carrying capacity of the virtual private network based on the network performance data during the transmission of the test message.

[0130] In this embodiment, the aforementioned execution entity determines the carrying capacity of the virtual private network based on the network performance data during the transmission of the test message.

[0131] Network performance data refers to quantifiable indicators that reflect network transmission quality, device processing capabilities, and system stability during the transmission of test packets. For example, network performance data includes, but is not limited to, one or more of the following: Throughput refers to the amount of data successfully transmitted between the test client and the test server per unit of time, usually measured in bits per second or data packets per second.

[0132] Message round-trip delay represents the time it takes for a test client to send a request message and receive the corresponding response message, reflecting the real-time response speed of the network.

[0133] Packet loss rate represents the proportion of packets lost during transmission out of the total number of packets sent, reflecting the reliability of the network.

[0134] Concurrent connections represent the number of VPN tunnel connections that the VPN gateway can maintain simultaneously, reflecting the scale of online clients that the system can support.

[0135] CPU utilization represents the percentage of the central processing unit (CPU) of the node where the VPN gateway is located, reflecting the processing load.

[0136] Memory usage indicates the amount of physical memory consumed by the VPN gateway process or node, reflecting resource consumption.

[0137] Connection establishment success rate represents the ratio of the number of successful tunnel connections established by a VPN client to the total number of attempts, reflecting the system's processing capacity under concurrent requests.

[0138] Connection establishment time represents the time required from when the client initiates a connection request to when the tunnel is fully established, reflecting the system's response efficiency.

[0139] As an example, testers pre-set one or more acceptance thresholds for network performance data (e.g., maximum throughput no less than 1Gbps, maximum packet loss rate no more than 1%, maximum concurrent connections no less than 5000). After the test begins, the number of containerized VPN clients is gradually increased (e.g., starting from 100 and increasing by 100 each time), and each phase is kept running stably for a period of time, collecting various network performance data for the current phase. When the performance data of a certain phase first falls below the preset threshold (e.g., packet loss rate exceeds 1%) or the system becomes unstable (e.g., a large number of connection failures, CPU utilization consistently approaching 100%), the number of VPN clients in the previous phase is considered the upper limit of the carrying capacity of the VPN in the current environment. At the same time, the various performance indicators corresponding to this upper limit are recorded as the capacity baseline.

[0140] As another example, the number of VPN clients is continuously increased while the trend of network performance data is recorded in real time. The number of VPN clients is used as the load variable, and performance data as the dependent variable, to plot relationship curves (e.g., throughput-client count curve, latency-client count curve). When a clear inflection point appears on the curve (e.g., throughput no longer increases with the number of clients, latency increases sharply, packet loss rate suddenly deteriorates), the number of clients corresponding to that inflection point is determined to be the VPN's capacity limit. Furthermore, the system's stability under sustained high pressure can be observed by maintaining a load near the maximum capacity for an extended period (e.g., 90% of the capacity limit). If performance data fluctuates within an acceptable range over a long period, the system is considered to have the corresponding stable capacity. The final output is a capacity report, including key information such as maximum concurrent connections, maximum throughput, and resource usage range during stable operation.

[0141] See also Figure 7 , Figure 7 This is a schematic diagram of application scenario 700 of the virtual private network (VPN) testing method according to this embodiment. User 701 sends a specified number of instruction operations to server 703 through terminal device 702. Server 703 deploys a containerized orchestration engine (e.g., a Kubernetes cluster). The server first determines a specified number of containerized VPN clients; then, using the VPN link between the VPN clients and the VPN gateway, and the intranet link between the VPN gateway and the test server, it transmits test packets between the test clients deployed in the same container as the VPN clients and the test server; then, based on the network performance data during the transmission of the test packets, it determines the carrying capacity of the VPN.

[0142] In this embodiment, a test scheme based on containerized VPN clients is provided by determining a specified number of containerized VPN clients; utilizing the virtual private network link between the VPN clients and the VPN gateway, and the intranet link between the VPN gateway and the test server, test packets are transmitted between the test clients and the test server deployed in the same container as the VPN clients; and determining the carrying capacity of the virtual private network based on the network performance data during the transmission of the test packets. Based on container orchestration technology, a single physical node (host machine) can run multiple client containers containing VPN clients, which greatly improves resource utilization and test efficiency.

[0143] Continue to refer to Figure 8 This illustrates an illustrative flow 800 of yet another embodiment of a testing method for virtual private networks according to the present disclosure. Flow 800 includes the following steps: Step 801: Determine a specified number of containerized VPN clients and determine the IP address of the main network interface of the VPN clients within a preset network segment.

[0144] The default network segment is different from the network segment of the internal network where the internal network link is located.

[0145] Step 802: Through local route hijacking, the request message sent by the test client to the test server is transmitted to the VPN tunnel interface of the client container.

[0146] Step 803: Using the in-container transport link, the request message is transmitted from the VPN tunnel interface to the VPN client.

[0147] Step 804: Perform VPN tunnel encapsulation on the request message to obtain a VPN request message.

[0148] In this context, the source address of the VPN request message is the IP address of the client container's main network interface, and the destination address is the IP address of the gateway node's main network interface.

[0149] Step 805: Use the bridged sublink to transmit the VPN request message to the client node.

[0150] Step 806: Use cross-node sub-links to transmit VPN request messages to the VPN gateway.

[0151] Step 807: The VPN request message is decapsulated through the VPN tunnel via the VPN gateway to obtain the request message.

[0152] Step 808: Convert the source address of the request message to the IP address of the main network interface of the gateway node to obtain the converted message.

[0153] Step 809: Transmit the converted message to the test server via the intranet link.

[0154] Step 810: Use the intranet link to transmit the response message from the test server to the gateway node.

[0155] Step 811: Convert the destination address of the response message to the IP address of the VPN tunnel interface of the client container to obtain the restored message.

[0156] Step 812: Perform VPN tunnel encapsulation on the restored message to obtain a VPN response message.

[0157] In this context, the source address of the VPN response message is the IP address of the main network interface of the gateway node, and the destination address is the IP address of the main network interface of the client container.

[0158] Step 813: Determine the IP address of the client node from the BGP routing table based on the destination address of the VPN response message.

[0159] The BGP routing table represents the mapping relationship between the network segment corresponding to the client container and the IP address of the client node.

[0160] Step 814: Perform IPIP encapsulation on the VPN response message based on the IP address of the client node to obtain a double-encapsulated message.

[0161] In this case, the source address of the double-encapsulated message is the IP address of the gateway node, and the destination address is the IP address of the client node.

[0162] Step 815: Use cross-node sub-links to transmit the double-encapsulated message to the client node.

[0163] Step 816: Decapsulate the double-encapsulated message using IPIP to obtain the VPN response message.

[0164] Step 817: Use the bridged sublink to transmit the VPN response message to the VPN client.

[0165] Step 818: Decapsulate the VPN response message using the VPN tunnel to obtain the restored message.

[0166] Step 819: Using the in-container transmission link, the restored message is transmitted from the VPN client to the test client.

[0167] Step 820: Determine the carrying capacity of the virtual private network based on the network performance data during message transmission.

[0168] The virtual private network testing method process 800 in this embodiment, compared with the above-mentioned process 200, specifically describes the message transmission process in the uplink and downlink stages, provides a specific testing scheme for VPN clients based on containerized deployment, and further improves the reliability of the testing scheme.

[0169] Continue to refer to Figure 9 As an implementation of the methods shown in the above figures, this disclosure provides an embodiment of a testing apparatus for a virtual private network. This system embodiment is similar to... Figure 2 Corresponding to the method embodiments shown, the system can be specifically applied to various electronic devices.

[0170] like Figure 9As shown, the VPN testing apparatus 900 includes: a client determination unit 901, configured to determine a specified number of containerized VPN clients; a message transmission unit 902, configured to transmit test messages between the test clients and the test server, which are deployed in the same container as the VPN clients, using the VPN link between the VPN clients and the VPN gateway, and the intranet link between the VPN gateway and the test server; and a testing unit 903, configured to determine the carrying capacity of the VPN based on network performance data during message transmission.

[0171] In some optional implementations of this embodiment, the virtual private network link includes a bridging sub-link between the client container to which the VPN client belongs and the client node to which the client container belongs, and a cross-node sub-link between the client node and the gateway node to which the VPN gateway belongs. The message transmission unit 902 is further configured to: transmit test messages between the test client and the VPN client using the intra-container transmission link between the test client and the VPN client; transmit test messages between the VPN client and the VPN gateway using the bridging sub-link and the cross-node sub-link; and transmit test messages between the gateway node and the test node to which the test server belongs using the intranet link.

[0172] In some optional implementations of this embodiment, the test message includes a request message, and the message transmission unit 902 is further configured to: transmit the request message sent by the test client to the test server to the VPN tunnel interface of the client container through local route hijacking; and transmit the request message from the VPN tunnel interface to the VPN client using the in-container transmission link.

[0173] In some optional implementations of this embodiment, the message transmission unit 902 is further configured to: encapsulate the request message using a VPN tunnel to obtain a VPN request message, wherein the source address of the VPN request message is the IP address of the main network interface of the client container, and the destination address is the IP address of the main network interface of the gateway node; transmit the VPN request message to the client node using a bridge sub-link; transmit the VPN request message to the VPN gateway using a cross-node sub-link; and decapsulate the VPN request message using a VPN tunnel through the VPN gateway to obtain the request message.

[0174] In some optional implementations of this embodiment, the message transmission unit 902 is further configured to: convert the source address of the request message into the IP address of the main network interface of the gateway node to obtain the converted message; and transmit the converted message to the test server through the intranet link.

[0175] In some optional implementations of this embodiment, the test message includes a response message to the request message, and the message transmission unit 902 is further configured to transmit the response message from the test server to the gateway node using an intranet link.

[0176] In some optional implementations of this embodiment, the message transmission unit 902 is further configured to: convert the destination address of the response message to the IP address of the VPN tunnel interface of the client container to obtain the restored message; perform VPN tunnel encapsulation on the restored message to obtain a VPN response message, wherein the source address of the VPN response message is the IP address of the main network interface of the gateway node, and the destination address is the IP address of the main network interface of the client container; determine the IP address of the client node from the BGP routing table based on the destination address of the VPN response message, wherein the BGP routing table represents the mapping relationship between the network segment corresponding to the client container and the IP address of the client node; perform IPIP encapsulation on the VPN response message according to the IP address of the client node to obtain a double-encapsulated message, wherein the source address of the double-encapsulated message is the IP address of the gateway node, and the destination address is the IP address of the client node; transmit the double-encapsulated message to the client node using a cross-node sub-link; perform IPIP decapsulation on the double-encapsulated message to obtain a VPN response message; and transmit the VPN response message to the VPN client using a bridging sub-link.

[0177] In some optional implementations of this embodiment, the message transmission unit 902 is further configured to: perform VPN tunnel decapsulation on the VPN response message to obtain the restored message; Using the in-container transport link, the restored message is transmitted from the VPN client to the test client.

[0178] In some optional implementations of this embodiment, a login client is also deployed in the client container, and the above-mentioned device further includes a login unit (not shown in the figure), which is configured to: generate configuration parameters of the virtual private network link through the login server in response to the login request of the login client; send the gateway-side parameters in the configuration parameters to the VPN gateway, and send the client-side parameters in the configuration parameters to the VPN client through the login client; and establish a virtual private network link between the VPN client using the client-side parameters and the VPN gateway using the gateway-side parameters.

[0179] In some optional implementations of this embodiment, the above-mentioned device further includes an address allocation unit (not shown in the figure), which is configured to: determine the IP address of the main network interface of the VPN client under a preset network segment, wherein the preset network segment is different from the network segment of the intranet where the intranet link is located.

[0180] This embodiment provides a testing device for a Virtual Private Network (VPN). A client determination unit determines a specified number of containerized VPN clients. A message transmission unit uses the VPN link between the VPN client and the VPN gateway, and the intranet link between the VPN gateway and the test server, to transmit test messages between the test client and the test server, which are deployed in the same container as the VPN clients. The testing unit determines the carrying capacity of the VPN based on network performance data during message transmission, thereby providing a testing scheme based on containerized VPN clients. Based on container orchestration technology, a single physical node (host machine) can run multiple client containers containing VPN clients, significantly improving resource utilization and testing efficiency.

[0181] According to embodiments of this disclosure, this disclosure also provides an electronic device, the electronic device comprising: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, the instructions being executed by the at least one processor to enable the at least one processor to implement the virtual private network testing method described in any of the above embodiments.

[0182] According to embodiments of this disclosure, this disclosure also provides a readable storage medium storing computer instructions that, when executed by a computer, enable the computer to implement the test method for the virtual private network described in any of the above embodiments.

[0183] This disclosure provides a computer program product that, when executed by a processor, can implement the virtual private network testing method described in any of the above embodiments.

[0184] Figure 10 A schematic block diagram of an example electronic device 1000 that can be used to implement embodiments of the present disclosure is shown. The electronic device is intended to represent various forms of digital computers, such as laptop computers, desktop computers, workstations, personal digital assistants, servers, blade servers, mainframe computers, and other suitable computers. The electronic device may also represent various forms of mobile devices, such as personal digital processors, cellular phones, smartphones, wearable devices, and other similar computing devices. The components shown herein, their connections and relationships, and their functions are merely illustrative and are not intended to limit the implementation of the present disclosure described and / or claimed herein.

[0185] like Figure 10As shown, device 1000 includes a computing unit 1001, which can perform various appropriate actions and processes according to a computer program stored in read-only memory (ROM) 1002 or a computer program loaded into random access memory (RAM) 1003 from storage unit 1008. The RAM 1003 may also store various programs and data required for the operation of device 1000. The computing unit 1001, ROM 1002, and RAM 1003 are interconnected via bus 1004. Input / output (I / O) interface 1005 is also connected to bus 1004.

[0186] Multiple components in device 1000 are connected to I / O interface 1005, including: input unit 1006, such as keyboard, mouse, etc.; output unit 1007, such as various types of monitors, speakers, etc.; storage unit 1008, such as disk, optical disk, etc.; and communication unit 1009, such as network card, modem, wireless transceiver, etc. Communication unit 1009 allows device 1000 to exchange information / data with other devices through computer networks such as the Internet and / or various telecommunications networks.

[0187] The computing unit 1001 can be various general-purpose and / or special-purpose processing components with processing and computing capabilities. Some examples of the computing unit 1001 include, but are not limited to, a central processing unit (CPU), a graphics processing unit (GPU), various special-purpose artificial intelligence (AI) computing chips, various computing units running machine learning model algorithms, a digital signal processor (DSP), and any suitable processor, controller, microcontroller, etc. The computing unit 1001 performs the various methods and processes described above, such as a virtual private network (VPN) testing method. For example, in some embodiments, the VPN testing method may be implemented as a computer software program tangibly contained in a machine-readable medium, such as storage unit 1008. In some embodiments, part or all of the computer program may be loaded and / or installed on device 1000 via ROM 1002 and / or communication unit 1009. When the computer program is loaded into RAM 1003 and executed by the computing unit 1001, one or more steps of the VPN testing method described above may be performed. Alternatively, in other embodiments, the computing unit 1001 may be configured to perform a test method for a virtual private network by any other suitable means (e.g., by means of firmware).

[0188] Various embodiments of the systems and techniques described above herein can be implemented in digital electronic circuit systems, integrated circuit systems, field-programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), application-specific standard products (ASSPs), systems-on-a-chip (SoCs), payload-programmable logic devices (CPLDs), computer hardware, firmware, software, and / or combinations thereof. These various embodiments may include implementations in one or more computer programs that can be executed and / or interpreted on a programmable system including at least one programmable processor, which may be a dedicated or general-purpose programmable processor, capable of receiving data and instructions from a storage system, at least one input device, and at least one output device, and transmitting data and instructions to the storage system, the at least one input device, and the at least one output device.

[0189] The program code used to implement the methods of this disclosure may be written in any combination of one or more programming languages. This program code may be provided to the processor or controller of a test apparatus of a general-purpose computer, special-purpose computer, or other programmable virtual private network, such that when executed by the processor or controller, the program code causes the functions / operations specified in the flowcharts and / or block diagrams to be implemented. The program code may be executed entirely on a machine, partially on a machine, as a standalone software package partially on a machine and partially on a remote machine, or entirely on a remote machine or server.

[0190] In the context of this disclosure, a machine-readable medium can be a tangible medium that may contain or store a program for use by or in conjunction with an instruction execution system, apparatus, or device. A machine-readable medium can be a machine-readable signal medium or a machine-readable storage medium. A machine-readable medium can be, but is not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatus, or devices, or any suitable combination of the foregoing. More specific examples of machine-readable storage media include electrical connections based on one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination of the foregoing.

[0191] To provide interaction with a user, the systems and techniques described herein can be implemented on a computer having: a display device for displaying information to the user (e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor); and a keyboard and pointing device (e.g., a mouse or trackball) through which the user provides input to the computer. Other types of devices can also be used to provide interaction with the user; for example, feedback provided to the user can be any form of sensory feedback (e.g., visual feedback, auditory feedback, or tactile feedback); and input from the user can be received in any form (including sound input, voice input, or tactile input).

[0192] The systems and technologies described herein can be implemented in computing systems that include backend components (e.g., as a data server), or computing systems that include middleware components (e.g., an application server), or computing systems that include frontend components (e.g., a user computer with a graphical user interface or web browser through which a user can interact with implementations of the systems and technologies described herein), or any combination of such backend, middleware, or frontend components. The components of the system can be interconnected via digital data communication of any form or medium (e.g., a communication network). Examples of communication networks include local area networks (LANs), wide area networks (WANs), and the Internet.

[0193] Computer systems can include clients and servers. Clients and servers are generally geographically separated and typically interact via communication networks. The client-server relationship is created by computer programs running on the respective computers and having a client-server relationship with each other. Servers can be cloud servers, also known as cloud computing servers or cloud hosts, which are hosting products within the cloud computing service system to address the management difficulties and weak business scalability inherent in traditional physical hosts and Virtual Private Servers (VPS) services; they can also be servers for distributed systems or servers incorporating blockchain technology.

[0194] According to the technical solution of the embodiments of this disclosure, a testing method and apparatus for a Virtual Private Network (VPN) are provided. This method involves determining a specified number of containerized VPN clients; utilizing the VPN link between the VPN clients and the VPN gateway, and the intranet link between the VPN gateway and the test server, to transmit test packets between the test clients and the test server, which are deployed in the same container as the VPN clients; and determining the carrying capacity of the VPN based on network performance data during the transmission of the test packets. This provides a testing scheme based on containerized VPN clients. Based on container orchestration technology, a single physical node (host machine) can run multiple client containers containing VPN clients, significantly improving resource utilization and testing efficiency.

[0195] It should be understood that the various forms of processes shown above can be used to reorder, add, or delete steps. For example, the steps described in this disclosure can be executed in parallel, sequentially, or in different orders, as long as the desired result of the technical solution provided in this disclosure can be achieved, and this is not limited herein.

[0196] The specific embodiments described above do not constitute a limitation on the scope of protection of this disclosure. Those skilled in the art should understand that various modifications, combinations, sub-combinations, and substitutions can be made according to design requirements and other factors. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of this disclosure should be included within the scope of protection of this disclosure.

Claims

1. A testing method for a Virtual Private Network, comprising: Determine a specified number of containerized VPN clients; Using the virtual private network link between the VPN client and the VPN gateway, and the intranet link between the VPN gateway and the test server, test messages are transmitted between the test client deployed in the same container as the VPN client and the test server. The carrying capacity of the virtual private network is determined based on network performance data during message transmission.

2. The method according to claim 1, wherein, The virtual private network link includes a bridging sub-link between the client container to which the VPN client belongs and the client node to which the client container belongs, and a cross-node sub-link between the client node and the gateway node to which the VPN gateway belongs. The method of transmitting test packets between the test client (deployed in the same container as the VPN client) and the test server using the virtual private network link between the VPN client and the VPN gateway, and the intranet link between the VPN gateway and the test server, includes: The test message is transmitted between the test client and the VPN client using the in-container transport link between the test client and the VPN client; The test message is transmitted between the VPN client and the VPN gateway using the bridging sub-link and the cross-node sub-link; The test message is transmitted between the gateway node and the test node to which the test server belongs, using the intranet link.

3. The method according to claim 2, wherein, The test message includes a request message, and The step of transmitting the test message between the test client and the VPN client using the in-container transport link includes: By hijacking local routes, the request message sent by the test client to the test server is transmitted to the VPN tunnel interface of the client container. The request message is transmitted from the VPN tunnel interface to the VPN client using the intra-container transmission link.

4. The method according to claim 3, wherein, The transmission of the test message between the VPN client and the VPN gateway using the bridging sub-link and the cross-node sub-link includes: The request message is encapsulated with a VPN tunnel to obtain a VPN request message, wherein the source address of the VPN request message is the IP address of the main network interface of the client container, and the destination address is the IP address of the main network interface of the gateway node. The VPN request message is transmitted to the client node using the bridge sub-link; The VPN request message is transmitted to the VPN gateway using the cross-node sub-link; The VPN request message is obtained by decapsulating the VPN tunnel through the VPN gateway.

5. The method according to claim 4, wherein, The step of transmitting the test message between the gateway node and the test node to which the test server belongs using the intranet link includes: The source address of the request message is converted to the IP address of the main network interface of the gateway node to obtain the converted message; The converted message is transmitted to the test server via the intranet link.

6. The method according to claim 2, wherein, The test message includes a response message to the request message, and The step of transmitting the test message between the gateway node and the test node to which the test server belongs using the intranet link includes: The response message is transmitted from the test server to the gateway node using the intranet link.

7. The method according to claim 6, wherein, The transmission of the test message between the VPN client and the VPN gateway using the bridging sub-link and the cross-node sub-link includes: The destination address of the response message is converted to the IP address of the VPN tunnel interface of the client container to obtain the restored message; The restored message is encapsulated using a VPN tunnel to obtain a VPN response message, wherein the source address of the VPN response message is the IP address of the main network interface of the gateway node, and the destination address is the IP address of the main network interface of the client container. Based on the destination address of the VPN response message, the IP address of the client node is determined from the BGP routing table, wherein the BGP routing table represents the mapping relationship between the network segment corresponding to the client container and the IP address of the client node; The VPN response message is encapsulated using IPIP based on the IP address of the client node to obtain a double-encapsulated message, wherein the source address of the double-encapsulated message is the IP address of the gateway node, and the destination address is the IP address of the client node. The double-encapsulated message is transmitted to the client node using the cross-node sub-link; The double-encapsulated message is decapsulated using IPIP to obtain the VPN response message; The VPN response message is transmitted to the VPN client using the bridge sub-link.

8. The method according to claim 7, wherein, The step of transmitting the test message between the test client and the VPN client using the in-container transport link includes: The VPN response message is decapsulated using the VPN tunnel to obtain the restored message; Using the intra-container transmission link, the restored message is transmitted from the VPN client to the test client.

9. The method according to any one of claims 1-8, wherein, The client container also deploys a login client, and Also includes: In response to the login request from the login client, the configuration parameters of the virtual private network link are generated by the login server; The gateway-side parameters in the configuration parameters are sent to the VPN gateway, and the client-side parameters in the configuration parameters are sent to the VPN client through the login client; Establish a virtual private network link between a VPN client using the client-side parameters and a VPN gateway using the gateway-side parameters.

10. The method according to claim 1, wherein, Also includes: The IP address of the main network interface of the VPN client is determined under a preset network segment, wherein the preset network segment is different from the network segment of the intranet where the intranet link is located.

11. A testing apparatus for a virtual private network, comprising: The client determination unit is configured to determine a specified number of containerized VPN clients; The message transmission unit is configured to use the virtual private network link between the VPN client and the VPN gateway, and the intranet link between the VPN gateway and the test server, to transmit test messages between the test client deployed in the same container as the VPN client and the test server. The test unit is configured to determine the carrying capacity of the virtual private network based on network performance data during message transmission.

12. An electronic device, characterized in that, include: At least one processor; as well as A memory communicatively connected to the at least one processor; wherein, The memory stores instructions executable by the at least one processor, which, when executed by the at least one processor, enables the at least one processor to perform the method of any one of claims 1-10.

13. A non-transitory computer-readable storage medium storing computer instructions, characterized in that, The computer instructions are used to cause the computer to perform the method according to any one of claims 1-10.

14. A computer program product comprising: A computer program that, when executed by a processor, implements the method according to any one of claims 1-10.

Images