Communication method and system for cloud edge collaboration

Abstract

The invention provides a communication method and system oriented to cloud side collaboration, and relates to the technical field of computer networks, and the method comprises the steps that a cloud service receives a registration request of an edge device, distributes a tunnel network address and a target VPN gateway after authentication, and sending a first configuration instruction containing connection information of the target VPN gateway node to the edge device and sending a second configuration instruction containing an allocated tunnel network address to the target VPN gateway node, so that the target VPN gateway node dynamically updates a peer list of the target VPN gateway node under the condition of not interrupting the existing service, and establishes a VPN tunnel with the edge device. And the cloud service also determines a second tunnel network address corresponding to the target edge device in response to a domain name access request for the domain name identifier associated with the target edge device, and sends the domain name access request to the second tunnel network address through the corresponding VPN tunnel. According to the application, full-automatic deployment, uninterrupted updating, transparent access and centralized management of the virtual private network are realized.

Description

Technical Field

[0001] This invention relates to the field of computer network technology, and specifically to a communication method and system for cloud-edge collaboration. Background Technology

[0002] In cloud-edge collaborative computing architectures, numerous edge devices, such as IoT gateways and edge servers, need to establish secure and reliable communication connections with the cloud center. VPN (Virtual Private Network) technology, due to its ability to build encrypted tunnels, has become a common solution for achieving such connections. WireGuard is a specific implementation of VPN technology.

[0003] However, traditional VPN deployment methods have significant drawbacks. First, each edge device requires manual configuration, including generating key pairs, setting peer information, and precisely configuring routing rules. This is inefficient and prone to errors. Second, configuration changes (such as changes to edge device IP addresses or the addition of new edge devices) require restarting the VPN service, leading to service interruptions and failing to meet the elastic scaling and high availability requirements of cloud-edge collaboration scenarios. Third, the lack of a unified control plane for scheduling device connections or updating configurations makes operation and maintenance extremely inconvenient. Finally, access to edge devices can only be achieved through fixed IP addresses or reverse tunnels, making the entire process opaque and inconvenient.

[0004] Therefore, how to achieve automated VPN configuration, dynamic expansion, centralized management, and transparent access has become an urgent technical problem to be solved. Summary of the Invention

[0005] In view of this, in order to solve the above-mentioned technical problems, the present invention provides a communication method and system for cloud-edge collaboration.

[0006] The present invention adopts the following technical solution: In a first aspect, the present invention provides a communication method for cloud-edge collaboration, comprising: An edge proxy module deployed on an edge device initiates a registration request to a cloud service; the registration request includes the edge device's identity credentials and VPN public key. After the identity credentials are successfully authenticated, the cloud service allocates network resources to the edge device and obtains a resource allocation result; the resource allocation result includes a first tunnel network address and a target VPN gateway node selected from the VPN gateway node cluster. Based on the resource allocation result, the cloud service sends a first configuration instruction containing connection information of the target VPN gateway node to the corresponding edge proxy module, and sends a second configuration instruction containing the VPN public key and the first tunnel network address to the target VPN gateway node. The target VPN gateway node responds to the second configuration command by dynamically updating its peer list without interrupting existing services; In response to the first configuration command, the edge proxy module establishes a VPN tunnel with the target VPN gateway node; When the cloud service receives a domain name access request for a domain name identifier associated with a target edge device, it determines the second tunnel network address corresponding to the target edge device based on the domain name identifier, and sends the domain name access request to the second tunnel network address through the corresponding VPN tunnel.

[0007] Optionally, the target VPN gateway node, in response to the second configuration command, dynamically updates its peer list without interrupting existing services, specifically including: In response to the second configuration instruction, the gateway proxy module on the target VPN gateway node loads the VPN public key and the first tunnel network address from the second configuration instruction into a temporary configuration file, and calls a specific system instruction to hot-load the information in the configuration file into the local VPN service, thereby adding the edge device as a member of the peer list without interrupting the existing VPN service.

[0008] Optionally, this method also includes: In the second configuration instruction, the allowed communication IP address range set for the edge device only includes its own tunnel network address.

[0009] Optionally, before the cloud service determines the second tunnel network address corresponding to the target edge device based on the domain name identifier, this method further includes: The cloud service performs identity authentication and permission verification on the domain name access request, and after the identity authentication and permission verification are passed, determines the second tunnel network address corresponding to the target edge device based on the domain name identifier.

[0010] Optionally, the target VPN gateway node selected by the cloud service from the VPN gateway node cluster specifically includes: The cloud service selects a target VPN gateway node from the VPN gateway node cluster according to a preset selection strategy. The preset selection strategy includes selecting a target VPN gateway node from the VPN gateway node cluster based on the VPN gateway node's real-time load, geographical location, and network latency.

[0011] Optionally, the VPN tunnel is a WireGuard tunnel.

[0012] Secondly, the present invention provides a communication system for cloud-edge collaboration, comprising: edge devices, a VPN gateway node cluster, and cloud services; The edge devices, VPN gateway node cluster, and cloud services are used to execute the cloud-edge collaborative communication method described above.

[0013] Compared with the prior art, this application has the following beneficial effects: 1. Fully automated deployment and operation and maintenance are achieved. Through a closed-loop process of automatic registration of edge devices, automatic allocation of network resources and distribution of configuration by cloud services, the tedious and error-prone manual configuration problems in traditional solutions are completely solved, greatly reducing the complexity of large-scale edge network deployment and management, and significantly improving operation and maintenance efficiency and scalability.

[0014] 2. Ensures high availability of services. By implementing hot reloading and uninterrupted dynamic updates of configurations at the VPN gateway node, service restarts and connection interruptions caused by network topology changes are avoided, ensuring the stability of cloud-edge communication and business continuity.

[0015] 3. Provides a transparent and convenient access experience. By introducing a domain name resolution mechanism, users can directly access services on edge devices through fixed, human-readable domain names, without needing to worry about complex internal network addresses and topologies, greatly improving ease of use.

[0016] 4. Enhanced overall security. By implementing basic network isolation at the VPN network layer using strict routing rules (setting the allowed communication IP address range for the edge device to only include its own tunnel network address), and performing unified identity authentication and permission verification at the application layer, a dual network-application security barrier is constructed, enabling more granular access control and effectively preventing unauthorized access.

[0017] 5. Centralized monitoring and auditing are achieved. The registration information, connection status, network topology, and access requests of all edge devices are uniformly managed by cloud services, providing a data foundation for centralized monitoring, troubleshooting, and security auditing, and improving observability and manageability. Attached Figure Description

[0018] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0019] Figure 1 This is a schematic diagram of the structure of a cloud-edge collaborative communication system provided in an embodiment of the present invention; Figure 2 This is a flowchart illustrating a cloud-edge collaborative communication method provided in an embodiment of the present invention. Detailed Implementation

[0020] To make the objectives, technical solutions, and advantages of this invention clearer, the technical solutions of this invention will be described in detail below. Obviously, the described embodiments are merely some embodiments of this invention, and not all embodiments. Based on the embodiments of this invention, all other implementation methods obtained by those skilled in the art without creative effort are within the scope of protection of this invention.

[0021] Example 1 This embodiment provides a basic implementation scheme for a communication method and system oriented towards cloud-edge collaboration. Figure 1 This is a schematic diagram of the structure of a cloud-edge collaborative communication system provided in an embodiment of the present invention. Figure 1 As shown, this communication system includes: a cloud service 11 located in the cloud, a VPN gateway node cluster 12 consisting of one or more VPN gateway nodes, and edge devices 13 deployed in network edge environments (such as factories, stores, or data centers). The VPN gateway nodes can specifically be WireGuard nodes.

[0022] Specifically, cloud service 11 is a composite system integrating multiple functions, which can be further divided into multiple logical modules. The ingress gateway 111, as the unified traffic entry point for the entire cloud service, is responsible for receiving and distributing requests from external networks. In one embodiment of this application, the ingress gateway 111 can be implemented by a high-performance reverse proxy server, such as Nginx. The user platform 112 is a management platform that provides a user interface for administrators to perform user management, device pre-registration, permission configuration, and other operations, and is responsible for authenticating access requests. The control plane 113 is the core of the entire automated management process, responsible for executing key logic such as edge device registration, network resource allocation, and configuration command generation and distribution. The device database (DeviceDB) 114 is a persistent storage system, such as a relational database or key-value store, used to record and maintain edge device information, network resource configuration, VPN gateway node status data, such as the mapping relationship between edge device unique identifiers, VPN public keys, allocated tunnel network addresses, associated gateway nodes, and dedicated domain names.

[0023] VPN gateway node cluster 12 consists of one or more VPN gateway nodes. These nodes serve as cloud access points for VPN tunnels to edge devices, responsible for establishing and maintaining encrypted communication with a large number of edge devices. It should be noted that, in addition to running standard VPN services, each VPN gateway node also has a VPN gateway proxy module deployed on it. The VPN gateway proxy module is used to receive VPN configuration instructions from the control plane 113 and dynamically update the local VPN configuration according to the instructions.

[0024] Edge device 13 is a computing unit deployed in the field, which can be, but is not limited to, an IoT gateway, an edge server, or an embedded device. Each edge device 13 runs a lightweight edge proxy module. The edge proxy module is responsible for communicating with the cloud service 11 on behalf of the edge device to complete the automated registration, configuration, and tunnel establishment process.

[0025] The following will combine Figure 2 The complete workflow of this embodiment will be described, wherein, Figure 2 This is a flowchart illustrating a cloud-edge collaborative communication method provided in an embodiment of the present invention. The complete workflow of this embodiment can be divided into two main stages: the first is the control plane process, used for the automatic registration of edge devices and the establishment of VPN tunnels; the second is the data plane process, used for transparent access by external users to services on edge devices.

[0026] like Figure 2 As shown, this communication method includes: Step 201: The edge proxy module deployed on the edge device initiates a registration request to the cloud service; the registration request includes the edge device's identity credentials and VPN public key.

[0027] Step 202: After the cloud service successfully authenticates the identity credentials, it allocates network resources to the edge device and obtains the resource allocation result. The resource allocation result includes the first tunnel network address and the target VPN gateway node selected from the VPN gateway node cluster.

[0028] Step 203: Based on the resource allocation results, the cloud service sends a first configuration instruction containing connection information of the target VPN gateway node to the corresponding edge proxy module, and sends a second configuration instruction containing the VPN public key and the first tunnel network address to the target VPN gateway node.

[0029] Step 204: The target VPN gateway node responds to the second configuration instruction by dynamically updating its peer list without interrupting existing services.

[0030] Step 205: The corresponding edge proxy module responds to the first configuration command and establishes a VPN tunnel with the target VPN gateway node.

[0031] Step 206: When the cloud service receives a domain name access request for a domain name identifier associated with the target edge device, it determines the second tunnel network address corresponding to the target edge device based on the domain name identifier, and sends the domain name access request to the second tunnel network address through the corresponding VPN tunnel.

[0032] The control plane process (steps 201 to 205) consists of the following steps: Before deploying edge device 13, the system administrator first logs into the cloud-based user (Admin) platform 112 via a user browser. On the user platform 112, the administrator creates a device record for an edge device 13 that is about to be deployed (this invention uses the edge device with device ID "Device123" as an example). As part of this process, the user platform 112 generates a unique pair of identity credentials for the edge device. The identity credentials may include an access key (such as ak123) and a secret key (such as sk456). This pair of identity credentials will be used for authentication during subsequent edge device registration. After obtaining the identity credentials, the administrator securely configures them in the configuration file of the edge agent module of the edge device to be deployed.

[0033] Once edge device 13 is powered on and its edge proxy module service is started, the automated registration process begins. The edge proxy module first uses a VPN (such as WireGuard) client tool locally to generate a new key pair, including a private key and a public key, which is the VPN public key corresponding to the edge device.

[0034] Subsequently, edge device 13 initiates a registration request to cloud service 11. Specifically, the edge proxy module constructs an HTTPS registration request targeting the unified API entry point of cloud service 11, such as https: / / api.yourdomain.com / register. The header of this registration request typically contains the access key (such as ak123) from the identity credentials, while the body of the registration request contains the information to be registered, such as the edge device ID and the VPN public key just generated. To ensure communication security, the edge proxy module encrypts the request body using a pre-set secret key (such as sk456).

[0035] After receiving a registration request from edge device 13, ingress gateway 111 forwards the registration request to user platform 112. User platform 112 uses the access key in the registration request to verify the identity and legitimacy of the edge device. After the identity verification is successful, user platform 112 uses a secret key to decrypt the registration request and forwards the decrypted registration request to control plane 113.

[0036] Control plane 113 allocates network resources to edge device 13. On one hand, it allocates a unique first tunnel network address (e.g., 10.10.1.5) to edge device 13 from a predefined private IP address pool (e.g., 10.10.0.0 / 16) within the entire VPN network. On the other hand, control plane 113 needs to select the most suitable target VPN gateway node for edge device 13 from the VPN gateway node cluster 12. Various selection strategies are possible; in this basic embodiment, a simple round-robin or random selection strategy can be used. Assume control plane 113 selects the wg_gw_1 node as the target VPN gateway node. Simultaneously, control plane 113 can also generate a unique, easy-to-remember domain name identifier for edge device 13, such as device123.yourdomain.com, for subsequent data plane access. After resource allocation, control plane 113 stores these newly established mapping relationships—edge device ID -> first tunnel network address -> target VPN gateway node -> domain name identifier—completely in the device database 114 for subsequent queries.

[0037] Subsequently, control plane 113 sends configuration instructions to the edge device and the target VPN gateway node. Specifically, control plane 113 needs to generate and send two different configuration instructions, namely the first configuration instruction and the second configuration instruction. The first configuration instruction is provided to edge device 13 and contains all the information required to establish a VPN tunnel, specifically including: the first tunnel network address (10.10.1.5) assigned to edge device 13, and the connection information of the target VPN gateway node (node ​​wg_gw_1). This connection information includes at least its publicly accessible endpoint address (e.g., wg-gw-1.yourdomain.com:51820) and the node's own VPN public key (e.g., pubkey_gw1). This configuration is returned to the edge proxy module on edge device 13 via the original path (i.e., through user platform 112 and ingress gateway 111) as an HTTPS response to the initial registration request.

[0038] The second configuration instruction is provided to the target VPN gateway node (node ​​wg_gw_1) to inform it how to establish a connection with the new edge device 13. Essentially, the second configuration instruction contains peer information for the new edge device 13, including its VPN public key and the first tunnel network address assigned to it. This address is used here as the "AllowedIPs" parameter, specifying the source IP addresses allowed to route from this peer. The control plane 113 pushes the second configuration instruction to the gateway agent module running on the target VPN gateway node via an internal secure channel (e.g., a gRPC call or message queue).

[0039] Accordingly, the target VPN gateway node dynamically updates its local VPN configuration based on the second configuration instruction. Specifically, after receiving the second configuration instruction from control plane 113, the VPN gateway proxy module of the target VPN gateway node performs a crucial non-disruptive update operation. It does not restart the entire VPN service process, as this would cause all connected devices on the node to disconnect. Instead, it appends the received second configuration instruction to a temporary configuration file and then invokes a specific system instruction. This instruction enables the system to hot-load the information from the configuration file into the local VPN service, allowing the edge device to be added as a peer to the target VPN gateway node without interrupting the existing VPN service.

[0040] Finally, the edge device establishes a VPN tunnel with the target VPN gateway node. On edge device 13, after receiving the HTTPS response containing the first configuration command, the edge proxy module parses the first tunnel network address, the endpoint address of the target VPN gateway node, and the VPN public key of the target VPN gateway node. Combined with its own private key, the edge proxy module now possesses all the information needed to establish a VPN connection. It generates a complete local VPN configuration file and starts or configures the local VPN network interface. Subsequently, the local VPN client automatically initiates a handshake to the endpoint address of the target VPN gateway node according to the configuration. Since the target VPN gateway node has now recognized this new peer through dynamic updates, the handshake process completes successfully, and an encrypted VPN tunnel is successfully established between edge device 13 and the target VPN gateway node. At this point, the entire control plane process is complete, and edge device 13 has securely and automatically connected to the cloud VPN network.

[0041] The specific steps of the data plane process (step 206) are as follows: When an external user wishes to access a service (such as a web management interface) deployed on a target edge device, they send a user platform login command to the ingress gateway 111 via their browser. The ingress gateway 111 forwards the login command to the user platform 112, which then returns the user platform operation interface to the user through the ingress gateway 111. Next, the user does not need to know the internal IP address of the target edge device; they only need to enter the domain name identifier associated with the target edge device through the user platform operation interface to send a domain name access request to the cloud service 11. The dedicated domain name identifier is, for example, http: / / device123.yourdomain.com.

[0042] Ingress gateway 111 first receives the domain name access request. This HTTP request is sent over the public internet and eventually reaches ingress gateway 111 of cloud service 11.

[0043] Subsequently, the ingress gateway 111 queries the second target tunnel network address corresponding to the domain name identifier. Understandably, the ingress gateway 111 is configured with special processing logic; for example, it could be a reverse proxy with custom scripts (such as Nginx using Lua scripts). When it receives a request for the *.yourdomain.com domain, it extracts the subdomain portion, device123, as the unique domain name identifier for the target edge device. Then, the ingress gateway 111 initiates an internal DNS resolution request to the user platform 112 to query the second target tunnel network address and VPN gateway node corresponding to the unique domain name identifier device123. The user platform 112 forwards this DNS resolution request to the control plane 113.

[0044] Upon receiving the resolution request, the control plane 113 immediately queries the device database 114. In the database, it finds the previously stored mapping record based on the unique domain name identifier (device123) in the resolution request, obtains the corresponding second target tunnel network address and VPN gateway node, and returns the second target tunnel network address and VPN gateway node as the query result to the user platform 112. The user platform 112 then forwards the query result to the ingress gateway 111.

[0045] After obtaining the second target tunnel network address and the VPN gateway node, the ingress gateway 111 proxies the domain name access request to the second target tunnel network address. Specifically, the ingress gateway 111, having determined the final destination of the domain name access request, acts as a reverse proxy, forwarding the original domain name access request unchanged to the second target tunnel network address. Since this second target tunnel network address is an address within the VPN network, the domain name access request originating from the ingress gateway 111 will be routed to the VPN gateway node cluster 12.

[0046] Because the target edge device is connected through a VPN gateway node, the domain name access request will be received by the corresponding VPN gateway node. The VPN gateway node checks the second target tunnel network address of the domain name access request, finds that the address belongs to the target edge device in its peer list, and then encrypts and securely sends the domain name access request to the remote target edge device 13 through the established VPN tunnel.

[0047] Finally, the domain name access request response data returns along the original path. Specifically, the VPN client on the target edge device 13 receives and decrypts the domain name access request and forwards it to the locally running web service. After processing the domain name access request, the web service generates domain name access request response data. This response data is repackaged, with its source address being the second target tunnel network address and its destination address being the internal address of the ingress gateway 111. The domain name access request response data is sent back to the corresponding VPN gateway node along the VPN tunnel, and then forwarded by the VPN gateway node to the ingress gateway 111. The ingress gateway 111 finally returns this domain name access request response data to the user browser that initiated the request.

[0048] Through the above process, users complete an access to the target edge device's services. The entire process is just like accessing a regular internet website, completely eliminating the need to be aware of the underlying complex VPN network topology and IP addresses, thus achieving a convenient and transparent access experience. At the same time, the entire process enables "plug-and-play" access to the target edge device, greatly improving deployment and maintenance efficiency.

[0049] Example 2 This embodiment, based on Embodiment 1, provides a further detailed description of the security isolation mechanism implemented by the system. The method and system provided in this application embodiment can construct a dual security barrier at the network layer and application layer to achieve more refined and robust security isolation, effectively preventing unauthorized access and lateral attacks within the network.

[0050] First, regarding the implementation of network layer isolation. The goal of network layer isolation is to ensure that even if multiple edge devices are connected to the same VPN gateway node, they cannot directly communicate with each other, thereby achieving strict isolation between tenants or devices. In the scheme of this application, this isolation mechanism is achieved through precise control of VPN routing rules.

[0051] Specifically, when control plane 113 generates the second configuration instruction for the target VPN gateway node, it makes special settings for the first tunnel network address (the crucial "AllowedIPs" parameter). For each edge device 13, for example, edge device Device 123 assigned the first tunnel network address 10.10.1.5, the AllowedIPs parameter in the peer configuration generated by control plane 113 is strictly set to 10.10.1.5 / 32. The / 32 subnet mask here means that the routing rule only matches the single IP address 10.10.1.5.

[0052] Once this configuration is dynamically loaded by the target VPN gateway node, it establishes a rule at the VPN kernel level: only packets with a source IP address of 10.10.1.5 are allowed to flow out of the VPN tunnel associated with the pubkey_dev public key. Conversely, packets sent from the cloud to edge device 13 must also have a destination IP of 10.10.1.5. Assuming another edge device, Device456, is also connected to the current target VPN gateway node and assigned a first tunnel network address of 10.10.1.6, its corresponding AllowedIPs would be 10.10.1.6 / 32. If Device 123 (with a first tunnel network address of 10.10.1.5) attempts to send a data packet to Device 456 (with a first tunnel network address of 10.10.1.6), upon arrival at the current target VPN gateway node, the gateway will find that the source IP 10.10.1.5 and its destination 10.10.1.6 do not match any allowed routing policy (because packets originating from Device 123's tunnel should have their destination address in the cloud network, not the tunnel address of another edge device), and therefore the data packet will be discarded. Similarly, any attempt to communicate directly between edge devices will be blocked at the network layer by the VPN gateway due to non-compliance with the strict limitations of AllowedIPs.

[0053] In this way, the embodiments of this application construct an independent "network island" for each edge device at the VPN network layer, which cannot communicate with others, fundamentally eliminating the possibility of lateral communication between devices under the same VPN gateway and achieving strong network layer isolation.

[0054] Secondly, regarding the implementation of application-layer isolation. The goal of application-layer isolation is to perform dual verification of identity and permissions at the entry point for user access services, ensuring that only legitimate users can access the device resources they are authorized to access. As an optional implementation method, this isolation mechanism is achieved in the data plane access process of Embodiment 1 by enhancing the functionality of the user platform 112.

[0055] In this embodiment, before the user platform 112 forwards the parsing request from the ingress gateway 111 to the control plane 113, a pre-authentication and authorization step is added. Specifically, the user's domain name access request usually carries the user's identity credentials, such as an authentication token (e.g., a JSON Web Token) carried in a cookie or in the HTTP Authorization header. This identity credential is also carried in the parsing request. After obtaining the identity credential from the parsing request, the user platform 112 authenticates the identity credential, verifying its validity and whether the user to whom the identity credential belongs has permission to access the corresponding edge device. Specifically, it first verifies the basic information of the identity credential, such as its signature and validity period. After successful verification, it further checks whether there is an authorization relationship between the user and the corresponding edge device. For example, the system may define that user A can access edge devices device123 and device124, but cannot access edge device456.

[0056] After verifying that the user's identity is legitimate and that they have permission to access the corresponding edge device, user platform 112 queries control plane 113 for the second target tunnel network address and VPN gateway node. Conversely, if user platform 112 finds that the user's identity is illegitimate or they do not have permission to access the corresponding edge device, it will return a failure response (e.g., HTTP 401 Unauthorized or 403 Forbidden) to ingress gateway 111. Upon receiving the failure response, ingress gateway 111 will immediately interrupt the processing of the domain name access request and directly return the corresponding 401 or 403 error page to the user's browser.

[0057] This mechanism establishes an application-layer access control checkpoint. Any request to access services on the edge device must first pass authentication and authorization verification. This ensures that even if an attacker knows the proprietary domain name of a device, their access request will be blocked before reaching the VPN network, provided they lack legitimate, authorized user credentials.

[0058] In summary, this embodiment constructs a defense-in-depth system of "authentication and authorization first, then network isolation" through precise control via AllowedIPs at the network layer and unified authentication and authorization via the application layer's entry gateway. Network layer isolation ensures that even if a single edge device is compromised, it cannot laterally attack other devices in the network; while application layer isolation ensures that only legitimate users can initiate access to specific devices. These two security mechanisms work together to significantly enhance the security of the entire cloud-edge collaborative communication system.

[0059] Example 3 This embodiment details how the control plane 113 implements an intelligent target VPN gateway node selection strategy to optimize the load balancing of the entire system, reduce network latency, and improve reliability.

[0060] In large-scale cloud-edge collaborative deployment scenarios, the VPN gateway node cluster 12 may contain dozens or even hundreds of VPN gateway nodes distributed across different geographical locations and data centers. Simply using a round-robin or random strategy to allocate newly connected edge devices 13 may result in some nodes being overloaded while others remain idle, or edge devices 13 connecting to geographically distant nodes, thereby increasing network communication latency and impacting service experience. The intelligent selection strategy provided in this embodiment aims to solve these problems.

[0061] To enable intelligent selection, the control plane 113 maintains a "gateway node status table". This table can be stored in memory and periodically persisted to the device database 114, or it can be implemented directly using a memory database that supports high-speed read and write (such as Redis). This status table records various status indicators of all VPN gateway nodes (e.g., wg-gw-1, wg-gw-2, wg-gw-3, etc.) in the VPN gateway node cluster 12 in real time or near real time.

[0062] These status indicators are primarily reported periodically to control plane 113 by gateway proxy modules deployed on each VPN gateway node. For example, each gateway proxy module can be configured to send a heartbeat and status report to a specific API endpoint of control plane 113 every 30 seconds. The report content may include: 1. CPU utilization: Reflects the current node's consumption of computing resources.

[0063] 2. Memory utilization: Reflects the memory resource consumption of the current node.

[0064] 3. Current Connections: The number of established VPN tunnels, which directly reflects the connection load of the node.

[0065] 4. Network bandwidth: The outbound and inbound bandwidth usage of the current node reflects the network load of the node.

[0066] 5. Node health status: An indicator of whether the node's services are functioning normally.

[0067] In addition to the load information reported by the nodes, the control plane 113 can also obtain context information about the edge device 13. For example, when the edge agent module initiates a registration request, the source IP address of the registration request can be used by the control plane 113 to determine the approximate geographical area or network service provider where the edge device is located.

[0068] When a new edge device 13 (e.g., whose registration request source IP address indicates it is located in the Shanghai area) initiates a registration request and is received by the control plane 113, the control plane 113 will execute a multi-dimensional intelligent selection logic, rather than a simple random allocation. This logic may include the following steps: First, a geographic location affinity screening is performed. Control plane 113 queries the IP geographic location database based on the requested source IP address to determine that the edge device 13 is located in the "East China" region. Then, it filters the "Gateway Node Status Table" to select all VPN gateway nodes also deployed in data centers within the "East China" region. This aims to prioritize nodes with closer physical distances, thereby reducing network round-trip time and communication latency on a macro level.

[0069] Next, a health status filter is performed. In the filtered list of nodes in the "East China" region, control plane 113 removes all nodes currently in an "unhealthy" state or with a timeout heartbeat. This ensures that new devices are not assigned to nodes that have already failed or are about to fail, improving the initial success rate and stability of the connection.

[0070] Then, the shortlisted candidate nodes are subjected to comprehensive load calculation and ranking. For all healthy, geographically matched candidate nodes, control plane 113 calculates a comprehensive load score based on their latest reported status indicators. This score can be calculated using a weighted average model, and administrators can adjust the weights according to the business priorities. For example, a possible formula for calculating the load score LoadScore is: LoadScore=w1×CPUutil+w2×Memutil+w3×Conncurrent / Connmax+w4×BWcurrent / BWtotal Where w1, w2, w3, and w4 are weighting coefficients; CPUutil is CPU utilization; Memutil is memory utilization; Conncurrent is the current number of connections; Connmax is the maximum number of connections designed for the node; BWcurrent is the current bandwidth; and BWtotal is the total bandwidth of the node.

[0071] Using formula (1), control plane 113 calculates a quantized load value for each candidate node.

[0072] Ultimately, control plane 113 selects the node with the lowest LoadScore from all candidate nodes as the target VPN gateway node. This ensures that new connection load is distributed to the currently least busy node, thus achieving load balancing across the entire cluster and preventing overload of any single node.

[0073] Furthermore, this intelligent selection mechanism also possesses failover capabilities. Control plane 113 can promptly detect the loss of connectivity of a VPN gateway node (e.g., the wg_gw_1 node) through periodic heartbeat checks. Once a VPN gateway node is detected as unavailable, control plane 113 immediately marks it as unavailable in its "Gateway Node Status Table" and will not assign any new devices to it. For edge devices already connected to the failed VPN gateway node, their edge proxy modules will attempt automatic reconnection upon detecting a tunnel interruption. When their reconnection requests (essentially new registration requests) reach control plane 113, control plane 113 will find that their previously assigned VPN gateway nodes are unavailable, thus automatically triggering a new, complete intelligent selection process to reassign them to a healthy, low-load new node.

[0074] By employing the aforementioned intelligent selection strategy based on geographical location, health status, and multi-dimensional load indicators, this application embodiment not only achieves dynamic load balancing of the VPN gateway cluster, avoiding performance bottlenecks, but also optimizes network latency through geographical affinity selection, and enhances the fault tolerance and high availability of the entire system through fault detection and automatic redistribution mechanisms.

[0075] It is understood that the same or similar parts in the above embodiments can be referred to each other, and the contents not described in detail in some embodiments can be referred to the same or similar contents in other embodiments.

[0076] It should be noted that in the description of this invention, the terms "first," "second," etc., are used for descriptive purposes only and should not be construed as indicating or implying relative importance. Furthermore, in the description of this invention, unless otherwise stated, "a plurality of" means at least two.

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

[0078] It should be understood that various parts of the present invention can be implemented in hardware, software, firmware, or a combination thereof. In the above embodiments, multiple steps or methods can be implemented in software or firmware stored in memory and executed by a suitable instruction execution system. For example, if implemented in hardware, as in another embodiment, it can be implemented using any one or a combination of the following techniques known in the art: discrete logic circuits having logic gates for implementing logical functions on data signals, application-specific integrated circuits (ASICs) having suitable combinational logic gates, programmable gate arrays (PGAs), field-programmable gate arrays (FPGAs), etc.

[0079] Those skilled in the art will understand that all or part of the steps of the methods in the above embodiments can be implemented by a program instructing related hardware. The program can be stored in a computer-readable storage medium, and when executed, the program includes one or a combination of the steps of the method embodiments.

[0080] Furthermore, the functional units in the various embodiments of the present invention can be integrated into a processing module, or each unit can exist physically separately, or two or more units can be integrated into a module. The integrated module can be implemented in hardware or as a software functional module. If the integrated module is implemented as a software functional module and sold or used as an independent product, it can also be stored in a computer-readable storage medium.

[0081] The storage media mentioned above can be read-only memory, disk, or optical disk, etc.

[0082] In the description of this specification, references to terms such as "one embodiment," "some embodiments," "example," "specific example," or "some examples," etc., indicate that a specific feature, structure, material, or characteristic described in connection with that embodiment or example is included in at least one embodiment or example of the invention. In this specification, the illustrative expressions of the above terms do not necessarily refer to the same embodiment or example. Furthermore, the specific features, structures, materials, or characteristics described may be combined in any suitable manner in one or more embodiments or examples.

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

Claims

1. A cloud edge collaboration oriented communication method, characterized in that, Comprising: An edge agent module deployed on an edge device initiates a registration request to a cloud service; the registration request contains identity credentials and a VPN public key of the edge device; The cloud service allocates network resources to the edge device after authenticating the identity credentials, obtaining a resource allocation result; the resource allocation result includes a first tunnel network address and a target VPN gateway node selected from a VPN gateway node cluster; The cloud service sends a first configuration instruction containing the connection information of the target VPN gateway node to the corresponding edge agent module according to the resource allocation result, and sends a second configuration instruction containing the VPN public key and the first tunnel network address to the target VPN gateway node; The target VPN gateway node dynamically updates its peer list without interrupting existing services in response to the second configuration instruction; The corresponding edge agent module establishes a VPN tunnel with the target VPN gateway node in response to the first configuration instruction; When the cloud service receives a domain name access request for a domain name identifier associated with a target edge device, it determines the second tunnel network address corresponding to the target edge device according to the domain name identifier, and sends the domain name access request to the second tunnel network address through the corresponding VPN tunnel.

2. The cloud-edge collaboration oriented communication method according to claim 1, wherein, The target VPN gateway node dynamically updates its peer list without interrupting existing services in response to the second configuration instruction, specifically including: The gateway agent module on the target VPN gateway node loads the VPN public key and the first tunnel network address in the second configuration instruction into a temporary configuration file, and calls a specific system instruction to hot load the information in the configuration file to the local VPN service, so as to add the edge device as a member of the peer list without interrupting the existing VPN service. 3.The cloud-edge collaboration oriented communication method according to claim 1, characterized in that, Further comprising: In the second configuration instruction, the allowed communication IP address range set for the edge device only contains its own tunnel network address.

4. The cloud-edge collaboration oriented communication method according to claim 1, wherein, Before the cloud service determines the second tunnel network address corresponding to the target edge device according to the domain name identifier, it further comprises: The cloud service performs identity authentication and permission verification on the domain name access request, and determines the second tunnel network address corresponding to the target edge device according to the domain name identifier after identity authentication and permission verification.

5. The cloud-edge collaboration oriented communication method according to claim 1, wherein, The target VPN gateway node selected by the cloud service from the VPN gateway node cluster specifically includes: The cloud service selects the target VPN gateway node from the VPN gateway node cluster according to a preset selection strategy; The preset selection strategy includes selecting the target VPN gateway node from the VPN gateway node cluster based on the real-time load, geographical location and network delay of the VPN gateway node.

6. The cloud-edge collaboration oriented communication method according to claim 1, wherein, The VPN tunnel is a WireGuard tunnel.

7. A cloud edge collaboration oriented communication system, characterized by, Comprising: An edge device, a VPN gateway node cluster and a cloud service; The edge device, the VPN gateway node cluster and the cloud service are configured to perform the cloud-edge collaborative communication method as claimed in any one of claims 1 to 6.

Images