Load balancing VPN traffic

Abstract

A non-transitory machine-readable storage medium for load balancing (VPN) traffic, and a load balancer are provided. In some examples, a load balancer establishes respective secure connections between it and a plurality of destination servers in a trusted network, and performs load balancing of encrypted virtual private network (VPN) traffic across the plurality of destination servers. A load balancer receives, from a client device, an encrypted data packet including a VPN message header having a destination identification field associated with identifying a destination server in a trusted network. The load balancer determines whether a selected destination server in the trusted network is identified based on a value of a destination identification field in the VPN message header, the selected destination server being one of the plurality of destination servers. Based on determining that the selected destination server is identified based on a value of a destination identification field in the VPN header, the load balancer sends the encrypted data packet to the selected destination server.

Description

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS

[0002] This application claims the benefit under 35 U.S.C. §119(e) of U.S. Provisional Patent Application No. 63 / 516,664, filed on July 31, 2023, which is incorporated herein by reference. Technical Field

[0003] The present application relates to a non-transitory machine-readable storage medium for communication, and a load balancer, and particularly, but not limited to, a non-transitory machine-readable storage medium for load balancing VPN services, and a load balancer. Background Art

[0004] In network computing, a secure network protocol suite allows clients and servers to communicate in a secure manner over a public network, such as the Internet. This is advantageous because public networks are not secure and therefore present security risks. Public networks also form part of the backbone of global communications and are therefore widely used. Summary of the invention

[0005] In general, embodiments of the present disclosure provide a non-transitory machine-readable storage medium for load balancing VPN services, and a load balancer.

[0006] In a first aspect, a non-transitory machine-readable storage medium is provided, the non-transitory machine-readable storage medium including instructions that, when executed, cause a load balancer to: establish corresponding secure connections between the load balancer and multiple destination servers in a trusted network; perform load balancing of encrypted virtual private network (VPN) services across multiple destination servers; receive an encrypted data packet from a client device, the encrypted data packet including a VPN message header, the VPN message header including a destination identification field related to identifying a destination server in the trusted network; determine whether a selected destination server in the trusted network is identified based on a value of the destination identification field in the VPN message header, the selected destination server being one of the multiple destination servers; and based on determining that the selected destination server is identified based on the value of the destination identification field in the VPN header, send an encrypted data packet from the load balancer to the selected destination server.

[0007] In a second aspect, a load balancer is provided, comprising: a processor; and a non-transitory storage medium storing instructions, the instructions being executable on a hardware processor to: establish corresponding secure connections between the load balancer and a plurality of destination servers in a trust network; perform load balancing of encrypted virtual private network (VPN) services across the plurality of destination servers; receive an encrypted data packet from a client device, the encrypted data packet comprising a VPN message header, the VPN message header comprising a destination identification field set to a value from a plurality of different values, the plurality of different values ​​comprising: a first value indicating that no destination server selection is made, and a plurality of destination server values ​​representing corresponding different destination servers among the plurality of destination servers; determine whether the value of the destination identification field is a destination server value representing a selected destination server among the plurality of destination servers; and based on determining that the value of the destination identification field is a destination server value representing the selected destination server, send the encrypted data packet from the load balancer to the selected destination server. BRIEF DESCRIPTION OF THE DRAWINGS

[0008] Some implementations of the present disclosure are described with respect to the following figures.

[0009] Figure 1 is a block diagram of an arrangement including a client device, a load balancer, a zero-trust network, and a secure network environment according to some examples.

[0010] Figure 2 is a block diagram of an encrypted data packet including a WireGuard segment according to some examples.

[0011] Figure 3 is a block diagram of a storage medium storing machine-readable instructions according to some examples.

[0012] Figure 4 is a block diagram of a load balancer according to some examples.

[0013] Figure 5 is a flow diagram of a load balancer process according to some examples.

[0014] Throughout the drawings, the same reference numerals denote similar, but not necessarily identical, elements. The drawings are not necessarily drawn to scale, and the dimensions of certain components may be exaggerated to more clearly illustrate the examples shown. In addition, the drawings provide examples and / or implementations consistent with the description; however, the description is not limited to the examples and / or implementations provided in the drawings. DETAILED DESCRIPTION

[0015] It is noteworthy that the embodiments disclosed herein are merely examples of many advantageous uses of the innovative teachings herein. In general, the statements made in the specification of the present application do not necessarily limit any of the various embodiments claimed for protection. In addition, some statements may apply to some inventive features but not to others. In general, unless otherwise stated, singular elements may be plural and vice versa without loss of generality. In the accompanying drawings, similar numbers represent similar parts through several views.

[0016] Zero Trust Networks use a security model that establishes trust by continuously authenticating and monitoring every network access attempt by entities (such as users, devices, and programs). Entities are not trusted implicitly or by default (such as when an entity performs network access from a local network that is assumed to be more secure than an external network). Instead, each time a network is accessed, the entity must be verified before network access is granted to the entity.

[0017] A zero trust network includes destination servers, which are computing entities (physical servers or virtual servers) to which secure connections can be established by devices seeking to access target endpoints through the zero trust network. In some examples, a virtual private network (VPN) can be established with the destination server to carry encrypted data packets to prevent unauthorized access. When a VPN is used, the destination server may also be referred to as a VPN backend server. The use of a VPN may raise issues associated with balancing VPN traffic among multiple destination servers in a zero trust network. Load balancing seeks to distribute the load among multiple destination servers to reduce the likelihood that any destination server of the zero trust network will become overburdened by VPN traffic. Encrypted data packets are sent in the VPN. If encrypted data packets must be decrypted to apply load balancing, this will increase the workload of the load balancer because the decryption operation consumes a lot of processing resources.

[0018] In some cases, a transport protocol such as the User Datagram Protocol (UDP) may be used to transport data packets in a VPN. UDP is a connectionless protocol that allows for the transmission of data packets without establishing a connection between endpoints over a network. However, the use of UDP may make it challenging to maintain affinity for data packets of a given client device to a particular destination server when load balancing is performed between connections to multiple destination servers. Maintaining affinity refers to preferring communications of data packets of a given client device to a particular destination server over communications of other destination servers. Affinity may improve efficiency because a particular destination server may maintain state information for communications for a given client device, while other destination servers may not have state information.

[0019] According to some implementations of the present disclosure, a load balancer is used to provide load balancing of VPN services between multiple destination servers of a trust network, wherein the load balancing seeks to distribute the VPN services between the multiple destination servers while also taking into account the destination server selection made by the client device. In some examples of the present disclosure, the destination server selection by the client device is indicated using a field in a VPN message header of an encrypted data packet. The field in the VPN message header is accessible by the load balancer without decrypting the encrypted data packet. Different values ​​of the field represent corresponding unique identifiers of multiple destination servers of the trust network. The field of the VPN message header contains load balancing metadata that affects how the load balancer forwards the encrypted data packet.

[0020] If the identifier of the destination server is not included in the VPN message header of the first data packet, the load balancer may apply a load balancing algorithm to distribute the first data packet to the destination server selected by the load balancing algorithm. Load balancing may be applied by the load balancer without decrypting the encrypted data packets in the VPN. For example, the load balancing algorithm may include one or more of the following: a round-robin algorithm that selects a destination server in a round-robin manner; a random selection algorithm that randomly selects a destination server from a plurality of destination servers; a weighted selection algorithm that assigns weights to destination servers and selects a destination server based on the weights; a selection algorithm that considers metrics of the destination server (such as metrics related to processing resource usage or performance, memory usage or performance, communication resource usage or performance, etc.). The load balancer is able to adapt to changing conditions (such as conditions of the destination server of a metric-based trust network) by allocating VPN traffic based on the conditions of the destination server.

[0021] On the other hand, if a value representing an identifier of a destination server ("identified destination server") is included in the VPN message header of the second data packet, the load balancer will forward the second data packet to the identified destination server instead of applying the load balancing algorithm. By allowing the client device to include a value representing an identifier of a destination server in a field of the VPN message header, affinity with the corresponding destination server can be maintained so that the load balancer directs the data packet containing the identifier of the destination server to the specific identified destination server.

[0022] As used herein, a "trust network" may refer to a network environment in which a computing entity performs authorization of access requests from a client device. An example of a trust network is a zero trust network. A "destination server" in a trust network refers to a resource of the trust network with which a secure connection can be established. In some examples, the destination server may also perform authorization of the access request. Alternatively, the destination server may forward the access request to another entity in the trust network to perform the authorization. Examples of destination servers include any one or a combination of the following: an access portal server, a virtual computing entity such as a container (e.g., a Kubernetes container) or a VM, a serverless function, or other type of resource.

[0023] The access request may include a control message sent by the requester for connecting to the target endpoint. In other examples, the access request may include a data packet sent by the requester for reaching the target endpoint. In some examples, the destination server may also be referred to as a front-end server or a VPN back-end server.

[0024] A secure communications protocol suite, such as the Internet Protocol Security (IPSec) suite, may be used for secure communications. In some examples, IPSec may be used to protect communications in a VPN. A secure network tunnel may be established using IPSec as a tunneling protocol. The IPSec network tunnel protects communications of the VPN. When transmitting data through an IPSec network tunnel, an encryption algorithm is applied to encrypt data packets, such as Internet Protocol (IP) data packets. The encrypted data packets are wrapped within an outer header, including an authentication header (AH) or an encapsulating security payload (ESP) header.

[0025] In other examples, different secure communication protocols can be employed for VPN. An example of a different secure communication protocol is the WireGuard protocol, which is an open source protocol that runs on top of UDP. In other examples, other secure communication protocols (e.g., OpenVPN) can be used for VPN.

[0026] When a VPN implementing any of the above secure communication protocols (e.g., IPSec, WireGuard, OpenVPN, etc.) is employed, load balancing becomes challenging because decrypting encrypted data packets for the purpose of distributing the packets to destination servers of a trusting network (as part of load balancing) is computationally expensive. Additionally, decrypting encrypted data packets in a VPN increases security risks because the decrypted data packets may become accessible to an attacker at the load balancer. On the other hand, if the load balancer is unable to decrypt encrypted data packets routed through the load balancer, the load balancer may not be able to determine where the data packets should be directed.

[0027] As described above, a VPN message header can be used to indicate how a data packet is processed by a load balancer. The VPN message header of an encrypted data packet is not encrypted, i.e., the VPN message header can be accessed by the load balancer without decrypting the encrypted data packet. Therefore, end-to-end encryption and privacy can be maintained while still allowing load balancing by the load balancer. A field in a VPN message header may refer to a set of any bits that can be set to any of a plurality of values. A "VPN message header" may refer to a header of an encrypted data packet carried in a VPN, wherein the header includes information that can be accessed without performing decryption. In an example where WireGuard is employed, the VPN message header may be a WireGuard header that complies with the WireGuard protocol.

[0028] The WireGuard header includes various fields, including reserved fields that are not defined by the current version of the WireGuard protocol for any particular purpose. According to some examples of the present disclosure, the reserved fields of the WireGuard header can be used to determine how the load balancer forwards encrypted data packets in the VPN. The reserved field includes a predetermined number of reserved bits. If the reserved field is set to a first value (e.g., "0" or a different value), it indicates that the requester sending the encrypted data packet has not yet selected a destination server of the trust network. In this case, the load balancer applies a load balancing algorithm to select the destination server to which the encrypted data packet in the trust network is to be sent. However, if the reserved field is set to another value representing a destination server identifier, the load balancer directs the encrypted data packet to the identified destination server. It is advantageous to determine where the encrypted data packet will be forwarded by the load balancer without decrypting the encrypted data packet in the VPN because it can maintain the security of the VPN and reduce the computational load of the load balancer, while also allowing the data packets to be distributed for load balancing purposes, and maintaining the affinity of the data packets of a given client device to a specific destination server by consistently directing the data packets of a given client device to a specific destination server.

[0029] Figure 1is a block diagram of an example arrangement including a client device 110 communicating with destination servers 152 and 154 in a zero trust network 150 through a load balancer 130. The load balancer 130 may be implemented using one or more computers. The client device 110 may be a router, a gateway, or another type of network device through which electronic devices may connect to other endpoints. More generally, the client device 110 includes a computing device. The computing device may be a personal computing device, a mobile phone, a smart phone, a tablet, a laptop, or other electronic device. Although a zero trust network is mentioned in some examples, it should be noted that other types of trust networks may be employed in other examples. In some examples, the client device 110 initiates communication with the zero trust network 150 to obtain access to target resources in a secure network environment 160 that is not directly accessible to the client device. As shown in FIG. Figure 1 As shown, the client device 110 establishes a client-side secure network tunnel 120 with the load balancer 130 .

[0030] In an example where there are multiple client devices, multiple client-side secure network tunnels can be established between the load balancer 130 and the multiple client devices so that each client device has a unique client-side secure network tunnel with the load balancer 130. Establishing separate client-side secure network tunnels between the load balancer 130 and the multiple client devices is more secure than multiple client devices sharing a common client-side secure network tunnel. For example, a shared common client-side secure network tunnel may mean that multiple client devices share a key used to encrypt the business carried in the shared common client-side secure network tunnel, which is less secure. If one of the multiple client devices sharing the same key is compromised, the communication for each of the other client devices sharing the key will be compromised.

[0031] In some examples, client device 110 communicates over an unsecured network, such as the Internet. To protect the communication of sensitive data transmitted over the unsecured network to or from a destination server 164 in a secure network environment 160, client device 110 is configured to communicate with destination server 164 over zero trust network 150. Target server 164 may be an application server, a web server, a cloud server, or any other type of target resource. Figure 1 , but in other examples, the secure network environment 160 includes multiple target servers. Additionally, in other examples, the zero trust network 150 can provide protected access to target servers in multiple secure network environments.

[0032] In some examples, the zero trust network 150 provides various security services. For example, the zero trust network 150 (e.g., the destination servers 152, 154) can provide any one or some combination of the following: remote desktop protocol (RDP) service between the client device 110 and the target server 164, secure shell (SSH) access to the target server 164, isolated SSH access to the target server 164, secure web gateway (SWG) (filtering traffic, enforcing policies and ensuring regulatory compliance), or other services.

[0033] The client device 110 sends a data packet (destined for a target server 164) to the load balancer 130 through the client secure network tunnel 120. The destination of the data packet may include one or more target servers in the secure network environment 160. The source (origin) of the data packet may include one or more requesters 170. "Requester" may refer to an entity that can access a target resource, such as a physical electronic device or a virtual computing entity.

[0034] In some examples, the load balancer 130 initiates multiple server-side secure network tunnels 142, 144 with the zero trust network 150. Each server-side secure network tunnel is established between the load balancer 130 and a corresponding destination server of the zero trust network 150. For example, the server-side secure network tunnel 142 is established between the load balancer 130 and the destination server 152, and the server-side secure network tunnel 144 is established between the load balancer 130 and the destination server 154. Each server-side secure network tunnel 142 or 144 can be established using IPSec. Note that multiple secure network tunnels can be established between the load balancer 130 and any given destination server.

[0035] In one example, the destination server 152 or 154 of the zero trust network 150 can provide a secure service (such as an RDP service, an SSH service, a SWG service, or another service) between the client device 110 and the target server 164. The destination server 152 or 154 establishes the service by communicating with the backend server 156 of the zero trust network 150. The "backend server" may refer to a server in the zero trust network 150 that is responsible for communicating with a network environment (e.g., a secure network environment 160) including a target resource to be accessed by the requester 170. The backend server 156 may communicate with a connector 162 in the secure network environment 160. In one example, the connector 162 forwards data packets between the zero trust network 150 and the target resources (including the target server 164) of the secure network environment 160.

[0036] In some examples, the load balancer 130 is deployed in the zero trust network 150 or outside of the zero trust network 150. In other examples, multiple load balancers 130 may be deployed. In examples where the zero trust network 150 includes a load balancer 130 deployed therein, it is not necessary to establish a secure network tunnel between the load balancer 130 and a destination server 152 or 154 in the zero trust network 150. In such examples, the connection between the load balancer 130 and the destination server in the zero trust network 150 is implicitly secure. In other examples, if the load balancer 130 is outside the zero trust network 150, a server-side secure network tunnel is established between the load balancer 130 and resources of the zero trust network 150 (such as a destination server).

[0037] According to some examples of the present disclosure, the load balancer 130 includes a VPN message header (VMH) parser 146 to read a VPN message header of an incoming encrypted data packet received by the load balancer 130 from one or more client devices. The VMH parser 146 can be implemented using one or more hardware processing circuits or machine-readable instructions of the load balancer 130. The encrypted data packet 122 sent in the VPN between the requester 170 and the target server 164 is received by the load balancer 130. The VMH parser 146 can read a VPN message header (VMH) 124 in the encrypted data packet 122 without decrypting the encrypted data packet 122. The VPN message header 124 is part of the plaintext of the encrypted data packet 122.

[0038] The VMH parser 146 is capable of reading a reserved field in the VPN message header 124 to determine how to forward the encrypted data packet 122 to the zero trust network 150. As described above, if the reserved field is set to a first value (e.g., "0" or a different value), it indicates that the requester (e.g., 170) that sent the encrypted data packet has not yet selected a destination server of the trust network. In this case, the load balancer 130 applies a load balancing algorithm to select a destination server in the trust network to which the encrypted data packet will be sent. However, if the reserved field is set to another value representing an identifier of a destination server, the load balancer 130 will direct the encrypted data packet to the identified destination server.

[0039] The destination server 152 or 154 receiving the encrypted data packet 122 forwarded by the load balancer 130 may send the encrypted data packet 122 to the target server 164 through the backend server 156 and the connector 162. The target server 164 responds by sending a response packet, which is received by the destination server 152 or 154. The destination server 152 or 154 sends the response packet to the load balancer 330. The response packet received by the load balancer 130 includes an identifier (e.g., an IP address and a UDP port) of the destination server that sent the response packet. The IP address and UDP port of the destination server may be included in the destination IP address field and the destination UDP port field of the IP header and the UDP header of the response packet, respectively. The response packet is sent to the client device 110. If the client device 110 is a network device, the client device 110 may forward the response packet to the requester 170. If the client device 110 is a computing device, the client device 110 may be the target of the response packet. In either case, requester 170 or client device 110 (whichever is the target of the response packet) can record the identifier of the destination server included in the response packet. A value representing the identifier of the destination server can be added to a reserved field of a VPN message header of a subsequent encrypted data packet sent by requester 170 or client device 110 to load balancer 130, so that load balancer 130 can use the value added to the reserved field of the subsequent encrypted data packet to identify the destination server to which the subsequent encrypted data packet is to be sent.

[0040] Figure 2 1 is a block diagram of a portion of an encrypted data packet 122 that can be communicated in a VPN. The encrypted data packet 122 carries encrypted data. In some examples, the encrypted data packet 122 includes an IP header 202, a UDP header 204, and a WireGuard segment 206 (or more generally, a segment for a secure communication protocol). The WireGuard segment 206 includes a WireGuard header 208 and a payload 210. The payload 210 carries the encrypted data. Note that the IP header 202, the UDP header 204, and the WireGuard header 208 are not encrypted, so the load balancer 130 is able to access the information in the IP header 202, the UDP header 204, and the WireGuard header 208 without decrypting the encrypted data packet 122.

[0041] WireGuard header 208 is Figure 1 WireGuard header 208 includes a type field 212 (used to indicate the message type), a reserved field 214, and other header fields (not shown).

[0042] The IP header 202 includes a source address field 216, which includes the source IP address of the source of the encrypted data packet 122 (e.g., the client device 110 or the requester 170), and a destination address field 218, which includes the destination IP address of the destination of the encrypted data packet 122 (e.g., the target server 164).

[0043] UDP header 204 includes a source port field 220 including a source UDP port of the source, and a destination port field 222 including a destination UDP port of the destination.

[0044] In some examples, the reserved field 214 of the WireGuard header 208 can be set to any of a variety of different values. For example, if the reserved field 214 is set to a first value (e.g., "0"), it indicates that no destination server is selected by the source of the encrypted data packet 122. Therefore, the load balancer 130 assigns a destination server from a plurality of destination servers based on a load balancing algorithm.

[0045] The reserved field 214 of the WireGuard header 208 may also be set to other values ​​representing identifiers of different corresponding destination servers in the zero trust network 150. For example, if the reserved field 214 is set to a second value representing the identifier of the destination server 152, the load balancer 130 will forward the encrypted data packet 122 to the destination server 152 (and will not apply the load balancing algorithm). Similarly, if the reserved field 214 is set to a third value representing the identifier of the destination server 154, the load balancer 130 will forward the encrypted data packet 122 to the destination server 154 (and will not apply the load balancing algorithm).

[0046] In some examples, the value in the reserved field 214 may represent an IP address, a portion of an IP address, or any identifier of a destination server. For example, a function (e.g., an encoding function) may be applied to the IP address (or portion of the IP address) of the destination server to derive a value representing the (portion of) the IP address. In a more specific example, the last three digits (or some of the least significant bits) of the IP address are encoded as a value added to the reserved field 214. The last three digits (or some of the least significant bits) of the IP address are typically sufficient to determine which destination server to route a data packet to.

[0047] Figure 3 is a block diagram of a non-transitory machine-readable or computer-readable storage medium 300 storing machine-readable instructions that, when executed, cause a load balancer to perform various tasks.

[0048] The machine-readable instructions include secure connection establishment instructions 302 for establishing corresponding secure connections between the load balancer and a plurality of destination servers in the trust network. The destination servers may include Figure 1 The destination servers 152 and 154 in the zero trust network 150 of FIG. The server-side secure connection may include a corresponding server-side secure network tunnel, such as Figure 1 142 and 144. In other examples where the load balancer 130 is located within a trust network (e.g., zero trust network 150), a server-side secure connection can be established through a network link within the trust network without establishing a secure network tunnel.

[0049] The machine-readable instructions include VPN traffic load balancing instructions 304. The encrypted VPN traffic includes encrypted data packets containing a payload of encrypted data sent through one or more VPNs. The encrypted data packets are received from one or more client devices, such as Figure 1 The client device 110.

[0050] The machine-readable instructions include encrypted data packet receiving instructions 306 for receiving a given encrypted data packet from a client device. The given encrypted data packet includes a VPN message header, such as Figure 2 WireGuard header 208. The VPN message header includes a destination identification field associated with identifying a destination server in a trusted network. An example of a destination identification field is Figure 2 Reserved field 214 of the WireGuard header 208.

[0051] The machine-readable instructions include a destination identification field value determination instruction 308 for determining whether a selected destination server in the trusted network is identified based on a value of a destination identification field in a VPN message header. The selected destination server is a destination server among a plurality of destination servers. The destination identification field can be set to one of various possible values. A first value in the destination identification field indicates that the destination server is not identified by the VPN message header. Other possible values ​​in the destination identification field represent identifiers of corresponding destination servers.

[0052] The machine-readable instructions include encrypted data packet sending instructions 310 for sending the encrypted data packet to the selected destination server based on determining that the selected destination server is identified based on the value of the destination identification field in the VPN header.

[0053] In some examples, the identifier of the corresponding destination server includes a corresponding portion (e.g., a subset of bits) of the network address of the corresponding destination server. For example, the network address may include an IP address. The value representing the network address of the destination server may include a portion of the network address, or may be based on applying a function to all or part of the network address. For example, the function may be an encoding function that generates an encoded value based on encoding at least a portion of the network address of the destination server.

[0054] In some examples, the value of the destination identification field in the VPN message header is set by the source of the encrypted data packet. The source can be a client device (e.g., Figure 1 130) or a requester (e.g., 170).

[0055] In some examples, the value of the destination identification field is a predetermined value, indicating that no destination server has been selected. The load balancer receives an additional encrypted data packet from the client device, the additional encrypted data packet including a VPN message header having a destination identification field. The load balancer detects that the destination identification field in the VPN message header of the additional encrypted data packet is set to a predetermined value, indicating that a destination server in the trusted network has not been selected. Based on detecting that the destination identification field in the VPN message header of the additional encrypted data packet is set to a predetermined value, the load balancer applies a load balancing algorithm to select an additional destination server from the plurality of destination servers, and the load balancer sends the additional encrypted data packet to the additional destination server.

[0056] In some examples, the load balancer sends a response packet received from the additional destination server to the client device, the response packet including an identifier of the additional destination server. The load balancer receives a subsequent encrypted data packet from the client device, the encrypted data packet including a VPN message header having a destination identification field set to a value representing the identifier of the additional destination server.

[0057] In some examples, the encrypted data packet includes an IP header and a UDP header.

[0058] In some examples, fields of the encrypted data packet may be accessed by the load balancer without decryption of the encrypted data packet.

[0059] In some examples, the secure connection between the load balancer and the destination server includes a server-side secure network tunnel between the load balancer and the destination server.

[0060] Figure 4 is a block diagram of a load balancer 400 according to some examples. One example of a load balancer 400 is Figure 1The load balancer 130 of FIG. 400 includes a processing circuit system 410 coupled to a storage medium 430 .

[0061] Processing circuit system 410 may be implemented as one or more hardware logic components and circuits. For example, but not limited to, exemplary types of hardware logic components that may be used include field programmable gate arrays (FPGAs), application specific integrated circuits (ASICs), application specific standard products (ASSPs), system-on-chip systems (SOCs), graphics processing units (GPUs), tensor processing units (TPUs), general-purpose microprocessors, microcontrollers, digital signal processors (DSPs), etc., or any other hardware logic components that can perform calculations or other information operations. One or more hardware logic components and circuits may be referred to as one or more hardware processors.

[0062] Storage medium 430 may include memory or storage. The memory may be volatile (e.g., random access memory, etc.), non-volatile (e.g., read-only memory, flash memory, etc.), or a combination thereof. The memory may include on-chip memory, off-chip memory, a combination thereof, etc. The memory may include temporary storage for processing circuit system 410. Storage medium 430 may alternatively or additionally include magnetic storage, optical storage, solid-state storage, a combination thereof, etc., such as flash memory, a hard drive or other memory technology, or any other medium that can be used to store information.

[0063] In some examples, machine-readable instructions for performing the various tasks discussed herein may be stored in storage medium 430. Machine-readable instructions may include any one or some combination of the following: software, firmware, middleware, microcode, hardware description language, or others. Machine-readable instructions may include code (e.g., source code format, binary code format, executable code format, or any other suitable code format). The machine-readable instructions, when executed by processing circuit system 410, cause processing circuit system 410 to perform the various processes described herein.

[0064] The machine-readable instructions include secure connection establishment instructions 412 for establishing corresponding secure connections between the load balancer and multiple destination servers in the trust network. The machine-readable instructions include VPN service load balancing instructions 414 for performing load balancing of encrypted VPN services across multiple destination servers in the trust network.

[0065] The machine-readable instructions include encrypted data packet receiving instructions 416 for receiving an encrypted data packet from a client device. The encrypted data packet includes a VPN message header, and a destination identification field of the VPN message header is set to a value from a plurality of different values. The plurality of different values ​​includes a first value indicating that no destination server selection is performed, and a plurality of destination server values ​​representing respective different destination servers of the plurality of destination servers.

[0066] The machine-readable instructions include destination identification field value determination instructions 418 for determining whether the value of the destination identification field is a destination server value representing a selected destination server from a plurality of destination servers.

[0067] The machine-readable instructions include encrypted data packet sending instructions 420 for sending the encrypted data packet from the load balancer to the selected destination server based on determining that the value of the destination identification field is a destination server value representing the selected destination server.

[0068] In some examples, the encrypted data packet includes a payload including encrypted data, and a VPN message header in the encrypted data packet is not encrypted.

[0069] In some examples, the destination server value in the destination identification field is based on a subset of bits of the network address of the selected destination server.

[0070] Figure 5 is a load balancer according to some examples of the present disclosure (e.g., Figure 1 Flowchart of process 500 of a load balancer 130 of FIG. 502 . At 502 , the load balancer establishes a client-side secure network tunnel between the load balancer and the client device. An example of a client-side secure network tunnel is shown in FIG. Figure 1 It is depicted as 120.

[0071] At 504, the load balancer establishes a plurality of server-side secure connections between the load balancer and corresponding destination servers of the trust network.

[0072] At 506, the load balancer performs load balancing of the encrypted VPN traffic across the multiple destination servers. The load balancing is in accordance with a load balancing algorithm.

[0073] At 508, the load balancer receives an encrypted data packet from a client device through a client-side secure network tunnel. The encrypted data packet includes a VPN message header having a destination identification field set to a value from a plurality of different values. The plurality of different values ​​includes a first value indicating that no destination server selection is performed, and a plurality of destination server values ​​representing respective different destination servers from a plurality of destination servers.

[0074] At 510, the load balancer determines whether the value of the destination identification field is a destination server value representing a selected destination server from among a plurality of destination servers.

[0075] At 512, based on determining that the value of the destination identification field is a destination server value representing the selected destination server, the load balancer sends the encrypted data packet to the selected destination server.

[0076] In some examples, the load balancer can establish a server-side secure network tunnel to the XFRM interface. In an example, the XFRM interface can communicate with a TUNnel (TUN) device of the destination server. XFRM refers to a framework for implementing IPSec data packet path functions. The TUN device provides a virtual interface that implements software-based network abstraction by emulating the behavior of a physical network card (such as an Ethernet or Wi-Fi card).

[0077] In another example, the ability to establish multiple server-side secure connections (e.g., server-side secure network tunnels) between the load balancer and the trust network allows client-side secure network tunnels (e.g., Figure 1 120) is maintained between the client device and the load balancer while some of the traffic of the client connection in the client-side secure network tunnel is transferred from one server-side secure connection to another server-side secure connection, such as when a front-end server in the trust network becomes unavailable. This transfer capability allows additional destination servers to be provisioned in the trust network to replace destination servers that have become unavailable. A destination server may become unavailable due to a failure of the destination server, a failure of a communication link to the destination server, the destination server being updated (for repair or maintenance, such as updating an operating system (OS), firmware, or software), or the destination server becoming overloaded with workload. In addition, the increased workload can be handled by adding more destination servers (e.g., physical servers or virtual servers).

[0078] In some examples, when a given destination server is marked as requiring maintenance, the load balancer can stop assigning new secure network tunnels to the given destination server. However, the existing secure network tunnel to the given destination server remains uninterrupted. Data packets of the existing secure network tunnel are allowed to be "drained" from the given destination server, which refers to allowing the communication of data packets through the existing secure network tunnel to complete. However, new traffic is not forwarded to the given destination server that will be shut down for maintenance.

[0079] If a client device is connected directly to a destination server using a secure network tunnel, and the destination server becomes unavailable, the secure network tunnel must be terminated and a new secure network tunnel established between the client device and the destination server. This can disrupt the client device's communications. By adding a load balancer between the client device and the trust network, the client-side secure network tunnel can be kept active between the client device and the load balancer, while the traffic of the client connection in the client-side secure network tunnel is transferred to (multiple) another server-side secure network tunnel, whether existing or newly established. For example, another destination server can be applied to transfer the client device's traffic instead of terminating the secure network tunnel between the client device and the destination server. "Client connection" can refer to a connection established by a client device with a target endpoint.

[0080] All examples and conditional language described herein are intended to help the reader understand the principles of the disclosed examples, and should be interpreted as not being limited to these specifically described examples and conditions. In addition, the statements of all principles, aspects, and examples described herein are intended to cover both their structural and functional equivalents. In addition, these equivalents are intended to include both currently known equivalents and equivalents developed in the future, that is, any element that performs the same function, regardless of the structure.

[0081] It should be understood that any reference to an element using names such as "first", "second" etc. herein does not generally limit the number or order of those elements. On the contrary, these names are generally used as a convenient method to distinguish two or more elements or element instances in this article. Therefore, the reference to the first and second elements does not mean that only two elements can be adopted there, nor does it mean that the first element must be located before the second element in some way. In addition, unless otherwise stated, an element set includes one or more elements.

[0082] In the present disclosure, the use of the terms "a", "an" or "the" is intended to include the plural forms as well, unless the context clearly indicates otherwise. In addition, the terms "includes", "including", "comprises", "comprising", "have" or "having" when used in the present disclosure specify the presence of the elements described, but do not exclude the presence or addition of other elements.

[0083] In the foregoing description, many details are set forth to provide an understanding of the subject matter disclosed herein. However, implementations may be practiced without these details. Other implementations may include modifications and variations from the above details. The appended claims are intended to cover such modifications and variations.

Claims

1. A non-transitory machine-readable storage medium comprising instructions that, when executed, cause a load balancer to: establishing corresponding secure connections between the load balancer and a plurality of destination servers in the trust network; performing load balancing of encrypted virtual private network (VPN) traffic across the plurality of destination servers; receiving an encrypted data packet from a client device, the encrypted data packet comprising a VPN message header, the VPN message header comprising a destination identification field associated with identifying a destination server in the trusted network; determining whether a selected destination server in the trusted network is identified based on a value of the destination identification field in the VPN message header, the selected destination server being one of a plurality of destination servers; as well as Based on determining that the selected destination server is identified based on the value of the destination identification field in the VPN header, the encrypted data packet is sent from the load balancer to the selected destination server. 2 . The non-transitory machine-readable storage medium of claim 1 , wherein different values ​​of the destination identification field in the VPN message header represent respective identifiers of the plurality of destination servers in the trust network.

3. The non-transitory machine-readable storage medium of claim 2, wherein the respective identifiers of the plurality of destination servers comprise: Respective portions of the network addresses of the plurality of destination servers.

4. The non-transitory machine-readable storage medium of claim 3, wherein the network address comprises an Internet Protocol (IP) address, and wherein the identifier of a given destination server in the plurality of destination servers comprises: A subset of the bits of the IP address of the given destination server.

5. The non-transitory machine-readable storage medium of claim 1 , wherein the value of the destination identification field in the VPN message header comprises: Based on an encoded value encoding at least a portion of a network address of the selected destination server.

6. The non-transitory machine-readable storage medium of claim 1, wherein the value of the destination identification field in the VPN message header is set by a source of the encrypted data packet.

7. The non-transitory machine-readable storage medium of claim 1 , wherein the instructions, when executed, cause the load balancer to: receiving, from the client device, an additional encrypted data packet, the additional encrypted data packet comprising a VPN message header, the VPN message header comprising a destination identification field; detecting that the destination identification field in the VPN message header of the further encrypted data packet is set to a predetermined value, the predetermined value indicating that a destination server in the trusted network is not selected; applying, by the load balancer, a load balancing algorithm to select an additional destination server from the plurality of destination servers based on detecting that the destination identification field in the VPN message header of the additional encrypted data packet is set to the predetermined value; as well as The further encrypted data packets are sent from the load balancer to the further destination server.

8. The non-transitory machine-readable storage medium of claim 7, wherein the instructions, when executed, cause the load balancer to: sending, from the load balancer to the client device, a response packet received from the additional destination server, the response packet including an identifier of the additional destination server; and A subsequent encrypted data packet is received at the load balancer from the client device, the subsequent encrypted data packet comprising a VPN message header including a destination identification field set to a value representing an identifier of the additional destination server.

9. The non-transitory machine-readable storage medium of claim 1, wherein the encrypted data packet comprises: User Datagram Protocol UDP header.

10. The non-transitory machine-readable storage medium of claim 1, wherein the destination identification field of the encrypted data packet is accessible by the load balancer without decryption of the encrypted data packet.

11. The non-transitory machine-readable storage medium of claim 1, wherein the secure connection comprises a secure network tunnel between the load balancer and the plurality of destination servers.

12. The non-transitory machine-readable storage medium of claim 1, wherein the VPN message header comprises a WireGuard header, and the destination identification field is included in the WireGuard header.

13. The non-transitory machine-readable storage medium of claim 1, wherein the encrypted data packet comprises a payload including the encrypted data, and wherein the encrypted data packet comprises an Internet Protocol (IP) header, a User Datagram Protocol (UDP) header, and the VPN message header.

14. A load balancer, comprising: processor; as well as A non-transitory storage medium storing instructions executable on a hardware processor to: establishing corresponding secure connections between the load balancer and a plurality of destination servers in the trust network; performing load balancing of encrypted virtual private network (VPN) traffic across the plurality of destination servers; receiving, from a client device, an encrypted data packet including a VPN message header, the VPN message header including a destination identification field set to a value from a plurality of different values, the plurality of different values ​​including: a first value indicating that no destination server selection was made, and a plurality of destination server values ​​representing respective different destination servers from the plurality of destination servers; determining whether the value of the destination identification field is a destination server value representing a selected destination server from among the plurality of destination servers; and Based on determining that the value of the destination identification field is the destination server value representing the selected destination server, sending the encrypted data packet from the load balancer to the selected destination server.

15. The load balancer of claim 14, wherein the encrypted data packet comprises: The payload contains encrypted data, and the VPN message header in the encrypted data packet is not encrypted.

16. The load balancer of claim 14, wherein the instructions are executable on the processor to: receiving, from the client device, an additional encrypted data packet, the additional encrypted data packet comprising a VPN message header, the VPN message header comprising a destination identification field; detecting that the destination identification field in the VPN message header of the further encrypted data packet is set to the first value, the first value indicating that no destination server selection is performed; applying, by the load balancer, a load balancing algorithm to select an additional destination server from the plurality of destination servers based on detecting that the destination identification field in the VPN message header of the additional encrypted data packet is set to the first value; as well as The further encrypted data packets are sent from the load balancer to the further destination server.

17. The load balancer of claim 16, wherein the instructions are executable on the processor to: sending, from the load balancer to the client device, a response packet received from the additional destination server, the response packet including an identifier of the additional destination server; and Receiving, at the load balancer, a subsequent encrypted data packet from the client device, the subsequent encrypted data packet comprising a VPN message header, the VPN message header comprising: A destination identification field is set to a destination server value representing an identifier of the additional destination server.

18. The load balancer of claim 14, wherein the destination server value in the destination identification field is based on a subset of bits of a network address of the selected destination server.

19. A method comprising: Establishing, by the load balancer, a client-side secure network tunnel between the load balancer and the client device; establishing, by the load balancer, a plurality of server-side secure connections between the load balancer and a plurality of destination servers of a trust network; performing, by the load balancer, load balancing of encrypted virtual private network VPN traffic across the plurality of destination servers; receiving, by the load balancer from the client device through the client secure network tunnel, an encrypted data packet including a VPN message header, the VPN message header including a destination identification field set to a value from a plurality of different values, the plurality of different values ​​including: a first value indicating that no destination server selection was made, and a plurality of destination server values ​​representing respective different destination servers from the plurality of destination servers; determining, by the load balancer, whether the value of the destination identification field is a destination server value representing a selected destination server from among the plurality of destination servers; and Based on determining that the value of the destination identification field is the destination server value representing the selected destination server, sending the encrypted data packet from the load balancer to the selected destination server.

20. The method of claim 19, wherein the client device comprises a network device through which the electronic device connects to the target endpoint via the trusted network.

Images