Delayed hot backup method, system and equipment suitable for SDWAN (Software Definition Wide Area Network)

Abstract

The invention discloses a delay-free hot backup method, system and equipment suitable for an SDWAN (Software Defined Wide Area Network), and relates to the field of computer networks. Comprising the steps that a first IPSEC tunnel is established between first equipment and a client gateway; a first device and a client gateway negotiate security association SA information, a first HA module of the first device adopts an encryption tunnel between the first HA module of the first device and a second HA module of a second device to synchronize the security association SA information to the second HA module, and the second device stores the security association SA information; under the condition that the first equipment is abnormal, the first VRRP module sends a second notification message to the first HA module; and the second device establishes a second IPSEC tunnel with the client gateway, and performs data interaction with the client gateway through the second IPSEC tunnel by using the stored security association SA information, so as to realize safe and time-delay-free switching of the data service after main-standby switching.

Description

Technical Field

[0001] This invention relates to the field of computer networks, and more particularly to a latency-free hot backup method, system, and device suitable for SDWAN. Background Technology

[0002] With the development of SDWAN (Software-Defined Wide Area Network), customers have increasingly higher requirements for network stability when using SDWAN networks to access the cloud from their local data centers. In scenarios where customers establish IPsec VPNs through local firewall devices and cloud resource pool VPN gateway nodes, customers have high requirements for the stability of IPsec VPN services between local devices and cloud resource pool VPN nodes, as well as high requirements for the IPsec negotiation mechanism.

[0003] Some VPN gateways employ dual-machine hot standby systems, requiring these systems to have a short-latency primary / backup failover mechanism. In traditional SDWAN access dual-machine hot standby systems, when establishing an IPsec connection with a customer, the primary device in the hot standby system is responsible for IPsec negotiation and data forwarding, with the IPsec negotiation information stored on the primary device. If the system fails and the service switches to the standby device, the standby device lacks the SA information for the IPsec tunnel. A new IPsec negotiation needs to be initiated across the entire link, and only after successful negotiation can data forwarding on the standby device be guaranteed. This traditional process increases the data migration time of the hot standby system, causing service interruptions during hot standby system failover and degrading the customer experience. Summary of the Invention

[0004] In view of the above-mentioned technical problems, the present invention provides a latency-free hot backup method, system and device suitable for SDWAN, which aims to overcome the above problems or at least partially solve the above problems.

[0005] The first aspect of this invention provides a latency-free hot backup method suitable for SDWAN, the method comprising: The first VRRP module of the first device in the VPN gateway sends a first notification message to the first HA module of the first device; the first notification message indicates that the first device is the primary device. The first device establishes a first IPSEC tunnel with the client gateway; The first device negotiates Security Association (SA) information with the client gateway, and the Security Association (SA) information is used to encrypt and decrypt data exchanged between the client gateway and the VPN gateway. The first HA module of the first device uses an encrypted tunnel with the second HA module of the second device in the VPN gateway to synchronize the security association (SA) information to the second HA module, and the second device stores the security association (SA) information. In the event of an anomaly in the first device, the first VRRP module sends a second notification message to the first HA module of the first device; the second notification message indicates that the first device is a backup device. The second device establishes a second IPSEC tunnel with the client gateway and uses the stored Security Association (SA) information to interact with the client gateway through the second IPSEC tunnel.

[0006] A second aspect of the present invention provides a latency-free hot backup system suitable for SDWAN, the system comprising at least: a client gateway and a VPN gateway; the VPN gateway comprising a first device and a second device; The first device is used for: The first VRRP module sends a first notification message to the first HA module; the first notification message indicates that the first device is the primary device. Establish the first IPsec tunnel with the client gateway; Negotiate Security Association (SA) information with the client gateway, wherein the Security Association (SA) information is used to encrypt and decrypt data exchanged between the client gateway and the first device; The security association (SA) information is synchronized to the second HA module through an encrypted tunnel between the first HA module and the second HA module of the second device, and the second device stores the security association (SA) information. In the event of an abnormality in the first device, a second notification message is sent to the first HA module of the first device via the first VRRP module; the second notification message indicates that the first device is a backup device. The second device is used to establish a second IPSEC tunnel with the client gateway and to interact with the client gateway through the second IPSEC tunnel using the stored Security Association (SA) information.

[0007] A third aspect of the present invention provides an electronic device comprising a processor, a memory, and a program or instructions stored in the memory and executable on the processor, wherein the program or instructions, when executed by the processor, implement the steps of the delay-free hot backup method for SDWAN as described in the first aspect of the present invention.

[0008] In the latency-free hot standby method for SDWAN proposed in this invention, the VPN gateway employs a dual-machine hot standby system, including a first device and a second device. The first VRRP module of the first device synchronizes the primary / standby status to the first HA module, informing the first device that it is the primary / standby device and ensuring that the first device provides normal IPsec negotiation and data interaction functions. An encrypted tunnel is established between the first and second devices through the first HA module of the first device and the second HA module of the second device. The first device synchronizes the Security Association (SA) information negotiated by the first device to the second device via this encrypted tunnel. At this time, the second device only stores the SA information, ensuring that the first and second devices have the same SA information. In the event of a failure of the first device, when switching to the standby device via VRRP, the second device can provide normal IPsec data interaction functions to the client gateway using the existing SA information. Thus, in the hot standby system of the VPN gateway of this invention, the HA function of STRONGSWAN is used. Based on the primary / standby status provided by VRRP and the encrypted tunnel between the HA modules of the hot standby systems, the SA information between the hot standby systems is synchronized in real time, thereby achieving secure and latency-free switching of data services after primary / standby switching. Attached Figure Description

[0009] To more clearly illustrate the technical solutions of the embodiments of the present invention, the drawings used in the description of the embodiments of the present invention 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.

[0010] Figure 1 This is a flowchart illustrating the steps of a latency-free hot backup method for SDWAN according to an embodiment of the present invention; Figure 2 This is a schematic diagram of an SDWAN network according to an embodiment of the present invention; Figure 3 This is a schematic diagram of the software framework of a VPN gateway according to an embodiment of the present invention; Figure 4 This is a schematic diagram illustrating a hot standby system HA configuration according to an embodiment of the present invention; Figure 5 This is a schematic diagram illustrating the HA message communication process according to an embodiment of the present invention; Figure 6 This is a schematic diagram illustrating a hot standby switching process according to an embodiment of the present invention; Figure 7 This is a structural block diagram of a latency-free hot backup system for SDWAN provided in an embodiment of the present invention; Figure 8 This is a schematic diagram of an electronic device according to an embodiment of the present invention. Detailed Implementation

[0011] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some, not all, of the embodiments of the present invention. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0012] In traditional processes, when the primary or backup device fails and services switch to the backup device, the backup device needs to initiate a new IPsec negotiation. Only after a successful negotiation can data be successfully forwarded on the backup device, increasing data migration time and negatively impacting customer experience. The proposed solution optimizes this process. Some SD-WAN solutions implement a customizable protocol extension to VRRP (Version-Agent Protocol for Internet Protocol) that supports the transmission of IPsec and IKE SA information between hot standby systems (SATP). This solution uses VRRP status and generated negotiation information to synchronize the IPsec SA information negotiated by the primary device between hot standby systems via SATP. After a hot standby switchover, the standby device, having stored the synchronized IPsec SA information, can achieve a seamless IPsec switchover. However, this solution, which synchronizes the VRRP-based SATP protocol, requires additional protocol encoding and SA synchronization mechanisms on top of the existing VRRP protocol. The encoding and SA synchronization mechanism implementation of the SATP protocol are complex, and the SA synchronization messages are transmitted in plaintext, resulting in low overall system security.

[0013] Based on this, in order to at least partially solve one or more of the above problems and other potential problems, this invention proposes a latency-free hot backup method for SDWAN. In this method, the hot backup systems of the VPN gateway adopt the HA function of STRONGSWAN. Based on the primary and backup status provided by VRRP, and the encrypted tunnel between the HA modules of the hot backup systems, the security association (SA) information between the hot backup systems is synchronized in real time. This ensures that the security association (SA) information between the hot backup systems is synchronized in real time and has strong security, thereby realizing secure and latency-free switching of data services after primary and backup switching in the SDWAN hot backup system.

[0014] Please refer to Figure 1 , Figure 1 This is a flowchart illustrating the steps of a latency-free hot backup method for SDWAN, as shown in an embodiment of the present invention. Figure 1As shown, the latency-free hot backup method for SDWAN provided in this embodiment includes at least the following steps: Step S11: The first VRRP module of the first device in the VPN gateway sends a first notification message to the first HA module of the first device.

[0015] In this embodiment, the SDWAN network includes at least: a client data center, a client gateway, a VPN gateway, and cloud node resources. Data communication between the client data center and cloud node resources can be achieved through the client gateway and VPN gateway. SDWAN applies the concept of SDN (Software-Defined Networking) to a wide area network scenario, centrally managing multiple WAN connections through software, thus providing intelligent and flexible network services.

[0016] This embodiment of the VPN gateway employs a dual-machine hot standby system, including a first device and a second device. The first device includes at least a first VRRP module and a first HA module, and the second device includes at least a second VRRP module and a second HA module. The first VRRP module is the module in the first device used to implement VRRP functionality, and the second VRRP module is the module in the second device used to implement VRRP functionality. VRRP (Virtual Router Redundancy Protocol) is a protocol used to improve network reliability and stability. It ensures that network traffic can be seamlessly transferred to backup routers when the primary router fails by creating multiple virtual routers (also called backup routers), thereby maintaining network continuity and availability. The first HA module is the module in the first device used to implement HA functionality for STRONGSWAN, and the second HA module is the module in the second device used to implement HA functionality for STRONGSWAN. STRONGSWAN is a complete IPSec solution that provides encryption and authentication for servers and clients, ensuring the security of remote network communication.

[0017] In this embodiment, "hot standby" is implemented through a VRRP module: the first VRRP module records the primary / standby status and sends a first notification message to the first HA module, indicating that the first device is the primary device. Simultaneously, the second VRRP module records the same primary / standby status as the first VRRP module and can send a fourth notification message to the second HA module, indicating that the second device is the standby device. This allows for real-time synchronization of the primary / standby status to the HA module via the VRRP module. In an optional embodiment, the VRRP module can synchronize the primary / standby status to the HA module via a second API.

[0018] Step S12: The first device establishes a first IPSEC tunnel with the client gateway.

[0019] In this embodiment, after the first device becomes the primary and backup device, the first device can establish a first IPSEC tunnel with the client gateway for negotiation and data interaction. The first IPSEC tunnel is the IPSEC tunnel between the first device and the client gateway; IPSEC (Internet Protocol Security) is a protocol packet that protects the IP protocol network transport protocol suite by encrypting and authenticating IP protocol packets.

[0020] Step S13: The first device negotiates security association (SA) information with the client gateway.

[0021] In this embodiment, the first device can negotiate a first IPsec tunnel with the client gateway via STRONGSWAN to generate Security Association (SA) information. SA is a unidirectional logical connection unit in the IPSec protocol that defines protection policies and keys, uniquely identified by a triplet of Security Parameter Index (SPI), destination IP address, and security protocol identifier. The SA information provides algorithms and data packets, providing the parameters required for AH and ESP operations. This SA information is used to encrypt and decrypt data exchanged between the client gateway and the VPN gateway.

[0022] Step S14: The first HA module of the first device uses an encrypted tunnel with the second HA module of the second device in the VPN gateway to synchronize the security association (SA) information to the second HA module, and the second device stores the security association (SA) information.

[0023] In this embodiment, after the first device negotiates and obtains the Security Association (SA) information, it stores the SA information in the first device. The first device can encrypt and decrypt the data interacting with the client gateway based on the SA information to realize the forwarding of IPSEC data services. At the same time, an encrypted tunnel is established between the first HA module of the first device and the second HA module of the second device. The first HA module will also synchronize the SA information to the second HA module through the encrypted tunnel. The second device receives and stores the SA information based on the second HA module.

[0024] Step S15: In the event of an anomaly in the first device, the first VRRP module sends a second notification message to the first HA module of the first device.

[0025] In this embodiment, when the first device (the primary device at this time) malfunctions, a primary / standby switchover is performed through the VRRP module. At this time, the first VRRP module can send a second notification message to the first HA module, which indicates that the first device is a standby device. Meanwhile, the second VRRP module records the same primary / standby status as the first VRRP module. At this time, the second VRRP module can send a third notification message to the second HA module, which indicates that the second device is the primary device. This enables the primary / standby status to be synchronized to the HA module in real time through the VRRP module during hot standby switchover.

[0026] Step S16: The second device establishes a second IPSEC tunnel with the client gateway, and uses the stored security association (SA) information to perform data interaction with the client gateway through the second IPSEC tunnel.

[0027] In this embodiment, after the second device becomes the primary device, it can establish a second IPsec tunnel with the client gateway for data interaction. This second IPsec tunnel is the IPsec tunnel between the second device and the client gateway. Since the second device stores the Security Association (SA) information synchronized from the first device, it does not need to renegotiate the SA information with the client gateway. The second device can directly utilize the stored SA information to interact with the client gateway through the second IPsec tunnel, thereby achieving zero-latency data service switching after primary / standby failover.

[0028] In one embodiment, a pre-defined renegotiation timeout is established between the VPN gateway and the client gateway. This renegotiation timeout represents the time interval for renegotiation of Security Association (SA) information between the VPN gateway and the client gateway. When the second device becomes the primary device and the renegotiation timeout for the client gateway is reached (i.e., at the end of the renegotiation timeout), the second device can act as the primary device to renegotiate the SA information with the client gateway. Furthermore, the second HA module of the second device uses an encrypted tunnel with the first HA module of the first device to synchronize the renegotiation SA information to the first HA module, allowing the first device to store the renegotiation SA information. In the event of an anomaly in the second device, a primary / backup switchover is performed via the VRRP module. At this time, the second VRRP module can send a fourth notification message to the second HA module, indicating that the second device is the backup device. Simultaneously, the first VRRP module records the same primary / backup status as the second VRRP module. The first VRRP module can then send a first notification message to the first HA module, indicating that the first device is the primary device, thus enabling a successful primary / backup switchover. After the first device switches to become the primary device, it can re-establish the first IPSEC tunnel with the client gateway and use the stored synchronized Security Association (SA) information to interact with the client gateway through the first IPSEC tunnel.

[0029] In this embodiment, the VPN gateway employs a dual-machine hot standby system, including a first device and a second device. The first VRRP module of the first device synchronizes the primary / standby status to the first HA module, informing the first device that it is the primary / standby device and ensuring that the first device provides normal IPsec negotiation and data interaction functions. An encrypted tunnel is established between the first and second devices through the first HA module of the first device and the second HA module of the second device. The first device synchronizes the Security Association (SA) information negotiated by the first device to the second device via this encrypted tunnel. At this time, the second device only stores the SA information, ensuring that the first and second devices have the same SA information. In the event of a failure of the first device, when switching to the standby device via VRRP, the second device can provide normal IPsec data interaction functions to the client gateway using the existing SA information. Thus, in the hot standby system of the VPN gateway of this invention, the HA function of STRONGSWAN is used. Based on the primary / standby status provided by VRRP and the encrypted tunnel between the HA modules of the hot standby systems, the SA information between the hot standby systems is synchronized in real time, thereby achieving secure and delay-free data service switching after primary / standby switching.

[0030] In conjunction with the above embodiments, in one implementation, the present invention also provides a latency-free hot backup method suitable for SDWAN, wherein, in addition to the above steps, the method may further include steps S21 and S22: Step S21: The first negotiation module of the first device synchronizes the security association (SA) information to the first data forwarding module of the first device through the first API.

[0031] In this embodiment, the software architecture of the first device and the second device is completely identical. The first device further includes a first negotiation module and a first data forwarding module, and the second device further includes a second negotiation module and a second data forwarding module. The first negotiation module is used in the first device to negotiate IPSEC, and the second negotiation module is used in the second device to negotiate IPSEC. Based on the negotiation module (either the first or second negotiation module), security association (SA) information can be negotiated with the client gateway. The first data forwarding module is used in the first device to perform data forwarding, and the second data forwarding module is used in the second device to perform data forwarding. Based on the data forwarding module (either the second or first data forwarding module), data interaction can be performed with the client gateway and cloud node resources.

[0032] The first negotiation module and the first HA module are deployed on the first layer of the first device, and the second negotiation module and the second HA module are deployed on the first layer of the second device. The first layer is the STRONGSWAN layer. The first data forwarding module and the first VRRP module are deployed on the second layer of the first device, and the second data forwarding module and the second VRRP module are deployed on the second layer of the second device. The second layer is the VPP layer, which can be understood as the data forwarding plane.

[0033] In this embodiment, the first negotiation module of the first device can synchronize the negotiated security association (SA) information to the first data forwarding module of the first device through the first API.

[0034] Step S22: The first data forwarding module uses the security association (SA) information to interact with the client gateway through the first IPSEC tunnel.

[0035] In this embodiment, the first data forwarding module can use the received Security Association (SA) information to interact with the client gateway through the first IPSEC tunnel. For example, the first data forwarding module can use the received SA information to encrypt the data to be sent and then send it to the client gateway through the first IPSEC tunnel; and, after receiving encrypted data sent by the client gateway through the first IPSEC tunnel, the first data forwarding module can use the received SA information to decrypt the encrypted data before sending it to the cloud node resource.

[0036] Accordingly, after the second device becomes the primary device and negotiates the Security Association (SA) information with the client gateway, the second negotiation module of the second device can synchronize the negotiated SA information to the second data forwarding module of the second device via the first API. The second data forwarding module can then use the received SA information to interact with the client gateway through the second IPsec tunnel.

[0037] In one embodiment, such as Figure 2 As shown, Figure 2 This is a schematic diagram of an SDWAN network according to an embodiment of the present invention. Figure 2 The main data plane includes the local gateway (i.e., the client gateway) of the local data center (i.e., the client data center), the local IPsec firewall, and the VPN gateway at the cloud node entry point, as well as resources within the cloud node. The client data center can establish an IPsec tunnel between the local gateway and the VPN gateway, enabling communication between cloud node resources and the client data center. Figure 2 The VPN gateway in the system employs a dual-machine hot standby system (i.e., master (primary device) and backup (standby device)) to ensure uninterrupted service during master-slave failover when the primary VPN device malfunctions. Figure 2 The left side of the diagram indicates that the current master device is the primary device, and the local gateway is connected to the master through an IPsec tunnel. Figure 2 The right side of the diagram indicates a current primary / backup switchover, where the backup device becomes the primary device, and the local gateway connects to the backup via an IPsec tunnel. In common hot standby systems, when the local gateway establishes an IPsec connection with the primary VPN device, SA (Service Agent) information is only stored on the primary VPN device. If the VPN fails and services switch to the backup VPN device, the backup VPN device lacks the SA information for the IPsec tunnel, requiring renegotiation of IPsec for data service recovery, resulting in service interruptions during hot standby system switchovers. While some solutions reduce switchover time by synchronizing SA between hot standby systems, this synchronization mechanism lacks security and reliability. Figure 2 The principle of zero-latency hot standby is as follows: the hot standby system uses the HA function of STRONGSWAN, and synchronizes information such as SA between VPN hot standby systems in real time through HA based on the VRRP primary and standby status. The information is synchronized using encrypted tunnels to achieve zero-latency switching of data services after the switch.

[0038] In one embodiment, such as Figure 3 As shown, Figure 3 This is a schematic diagram of the software framework of a VPN gateway according to an embodiment of the present invention. Figure 3In this VPN gateway (either the first or second device), there are two layers. The first layer is the STRONGSWAN layer, which includes a negotiation module and a HA module. The second layer is the VPP layer, which includes a data forwarding module and a VRRP module. The negotiation module negotiates a Security Association (SA) information (i.e., IPsec SA) with the client gateway. After obtaining the IPsec SA, it synchronizes the IPsec SA to the data forwarding module via an API (such as the first API). The data forwarding module then interacts with the client gateway based on the IPsec SA through an IPsec tunnel. The VPN gateway implements hot standby through the VRRP module. The VRRP protocol records the primary and standby status. The VRRP module synchronizes the primary and standby status to the HA module in real time via an API (such as the second API). After the primary device negotiates the IPsec SA, it can synchronize the IPsec SA to the standby device through the HA module, thus completing the IPsec SA synchronization between the primary and standby devices based on the HA module.

[0039] In conjunction with any of the above embodiments, the present invention also provides a latency-free hot backup method suitable for SDWAN, wherein, in addition to the above steps, the method may further include the following steps S31 to S33: Step S31: The first HA module configures the first host address as the local tunnel address and the second host address as the remote tunnel address.

[0040] Step S32: The second HA module configures the second host address as the local tunnel address and the first host address as the remote tunnel address.

[0041] In this embodiment, the HA module is a plugin in the STRONGSWAN layer for synchronizing Security Association (SA) information. To synchronize SA information between the first and second devices, a dedicated encrypted tunnel needs to be configured to transmit the synchronization HA message body, thus providing security and reliability for the scheme in this embodiment. Therefore, the first and second devices in this embodiment need to perform HA configuration: configuring the tunnel address separately to obtain tunnel address configuration information.

[0042] In this embodiment, the first device and the second device have different host addresses, wherein the first device has a first host address and the second device has a second host address. The first device can configure the first host address as a local tunnel address and the second host address as a remote tunnel address through a first HA module. The second device can configure the second host address as a local tunnel address and the first host address as a remote tunnel address through a second HA module, thereby obtaining tunnel address configuration information.

[0043] Step S33: The first HA module establishes an encrypted tunnel between the first HA module and the second HA module based on the tunnel address configuration information through the management port of the first device and the management port of the second device.

[0044] In this embodiment, considering that implementing HA by solely using a device interface is wasteful of resources, and that the HA synchronization security association (SA) information is relatively small compared to the data service volume, this embodiment uses the device's management port to create an HA encrypted tunnel: the first HA module establishes an encrypted tunnel between itself and the second HA module based on the tunnel address configuration information obtained by configuring the tunnel address, through the management port of the first device and the management port of the second device. In one embodiment, the encrypted tunnel between the first HA module and the second HA module is an IKEv2 encrypted tunnel.

[0045] In this embodiment, the IPsec hot standby system implemented using the HA plugin supported by STRONGSWAN in conjunction with the traditional VRRP handover scheme not only ensures real-time synchronization of IPsec tunnel negotiation information between systems, guaranteeing zero-latency handover of the hot standby system, but also simplifies the networking of HA functions between systems. Because the amount of synchronized SA information data is relatively small, only a dedicated IKEv2 tunnel needs to be configured on the management interface between systems, saving interface resources. The dedicated IKEv2 channel offers higher security, ensuring that critical tunnel information is not stolen.

[0046] In one embodiment, such as Figure 4 As shown, Figure 4 This is a schematic diagram illustrating a hot standby (HA) configuration between systems according to an embodiment of the present invention. Figure 4 In this configuration, VPN1 is the first device, host1 is the first host address, and VPN2 is the second device, with host2 being the second host address. Both devices undergo HA configuration to set parameters such as local tunnel address, remote tunnel address, and synchronization heartbeat. Specifically, the first device configures the first host address as the local tunnel address and the second host address as the remote tunnel address; similarly, the second device configures the second host address as the local tunnel address and the first host address as the remote tunnel address. Finally, based on the configured tunnel address information, an IKEv2 encrypted tunnel is established between the first and second HA modules via the management ports of both devices.

[0047] In conjunction with any of the above embodiments, in one implementation, the present invention also provides a latency-free hot backup method suitable for SDWAN. In this method, step S14 above, "the first HA module of the first device uses an encrypted tunnel with the second HA module of the second device in the VPN gateway to synchronize the security association (SA) information to the second HA module," specifically may include the following step S41, and, in addition to the above steps, may also include steps S42 to S44: Step S41: The first HA module uses an encrypted tunnel with the second HA module to send the IKE add message and the CHILD add message to the second HA module, so as to synchronize the security association (SA) information to the second HA module.

[0048] In this embodiment, the HA module supports the synchronization of security association (SA) information. After the first device negotiates the security association SA information with the client gateway, the first HA module can use an encrypted tunnel with the second HA module to send IKE add messages (such as IKE ADD) and CHILD add messages (such as CHILD ADD) to the second HA module on the second device to synchronize the negotiated security association SA information to the second HA module.

[0049] Step S42: When the renegotiation timeout period ends, the first device and the client gateway renegotiation of the security association (SA) information.

[0050] In this embodiment, a pre-defined renegotiation timeout period is established between the VPN gateway and the client gateway. This renegotiation timeout period represents the time interval for renegotiating the Security Association (SA) information between the VPN gateway and the client gateway. When the first device reaches the time for renegotiation with the client gateway, that is, when the renegotiation timeout period ends, the first device needs to renegotiate the SA information with the client gateway.

[0051] Step S43: The first HA module uses an encrypted tunnel with the second HA module to send IKE add messages and CHILD add messages to the second HA module to synchronize the renegotiation security association (SA) information to the second HA module, and sends IKE delete messages and CHILD delete messages to the second HA module to instruct the second HA module to delete the earliest stored security association (SA) information.

[0052] In this embodiment, after the first device obtains the renegotiation security association (SA) information, it needs to update the synchronized SA information. At this time, the first device can use the first HA module, employing an encrypted tunnel with the second HA module, to send IKE add messages and CHILD add messages to the second HA module, thereby synchronizing the renegotiation SA information to the second HA module. Similarly, the first device can use the first HA module, employing an encrypted tunnel with the second HA module, to send IKE delete messages (such as IKE DELDTE) and CHILD delete messages (CHILD DELDTE) to the second HA module, instructing the second HA module to delete the earliest stored SA information. The second device can then obtain the renegotiation SA information through the second HA module and delete the earliest stored SA information in the second device, thus achieving synchronous updating of the SA information.

[0053] Step S44: If the negotiation between the first device and the client gateway for the security association (SA) information times out, the first HA module uses an encrypted tunnel with the second HA module to send the IKE deletion message and the CHILD deletion message to the second HA module, instructing the second HA module to delete the stored security association (SA) information.

[0054] In this embodiment, a preset negotiation duration is defined. If the time taken for the first device to negotiate the security association (SA) information with the client gateway exceeds the preset negotiation duration, it can be determined that the negotiation between the first device and the client gateway for the security association (SA) information has timed out. The primary device in this embodiment can be a device that negotiates and synchronizes simultaneously. If the negotiation between the first device and the client gateway for the security association (SA) information times out, the first device can send IKE deletion messages and CHILD deletion messages to the second HA module through the first HA module using an encrypted tunnel between the first HA module and the second HA module, instructing the second HA module to delete the stored security association (SA) information.

[0055] In one embodiment, the HA module supports SA information synchronization messages, and the supported message body types (i.e., HA SA synchronization messages) are as follows: ; In this way, HA SA synchronization messages can support the addition, deletion, and updating of IKE and IPSec SAs. HA SA synchronization messages can ensure that the security association SA information between the primary and backup HAs can be synchronized in real time, ensuring that the key parameters for the hot standby system to switch over without delay exist on both the primary and backup devices.

[0056] In conjunction with any of the above embodiments, in one implementation, the present invention also provides a latency-free hot backup method suitable for SDWAN. In this method, after step S13, step S51 may be included; and after "the second device stores the security association SA information" in step S14, step S52 may be included: Step S51: The first HA module sets the status of the security association SA information to active.

[0057] In this embodiment, after the first device negotiates and obtains the security association (SA) information with the client gateway, the first HA module sets the status of the security association (SA) information on the first device (primary device) to an active state.

[0058] Step S52: The second HA module sets the status of the stored security association (SA) information to passive state.

[0059] In this embodiment, after the second device synchronously stores the security association (SA) information, the second HA module sets the state of the security association (SA) information stored by the second device (backup device) to a passive state.

[0060] In conjunction with any of the above embodiments, in one implementation, the present invention also provides a latency-free hot backup method suitable for SDWAN. In this method, after "the first VRRP module sends a second notification message to the first HA module of the first device" in step S15, step S61 may be included; and, in addition to the above steps, steps S62 to S63 may be included: Step S61: The first HA module switches the status of the security association SA information from active to passive.

[0061] In this embodiment, during the primary / standby switchover: after setting the first device as the standby device and the second device as the primary device, the first HA module on the first device will switch the status of the security association SA information on the first device from active to passive.

[0062] Step S62: In the event of an anomaly in the first device, the second VRRP module of the second device sends a third notification message to the second HA module of the second device.

[0063] In this embodiment, if the first device (the primary device at this time) malfunctions, a primary / backup switch is performed through the VRRP module. At this time, the second VRRP module of the second device can send a third notification message to the second HA module, which indicates that the second device is the primary device.

[0064] Step S63: The second HA module switches the status of the stored security association (SA) information from passive to active.

[0065] In this embodiment, after the second device becomes the primary device, the second HA module can switch the state of the security association (SA) information stored in the second device from a passive state to an active state.

[0066] In one embodiment, such as Figure 5 As shown, Figure 5 This is a schematic diagram illustrating the HA message communication process according to an embodiment of the present invention. Figure 5 In this system, the primary HA (e.g., the first HA module) of the primary device and the backup HA (e.g., the second HA module) of the backup device synchronize messages between the primary and backup devices via an IKEv2 encrypted tunnel. The process is as follows: 1) The primary device is responsible for negotiating the IPsec link. Once there are events such as adding or deleting SA information, the primary HA encapsulates the event into a data format that HA can recognize and sends it to the backup device through the dedicated IKEv2 IPsec tunnel. After receiving the message, the backup device decapsulates it and adds or deletes the relevant SA information. The SA information on the primary device is uniformly in an active state, while the SA information on the backup device is in a passive state. 2) The system supports the backup device to obtain all SA information from the primary device.

[0067] In one embodiment, during primary / standby switchover: 1) The VRRP module of the primary device notifies the HA module of the primary device to become the primary device, and the HA module of the primary device switches the SA information in the passive state on the primary device to the active state; 2) The VRRP module of the standby device notifies the HA module of the standby device to become the standby device, and the HA module of the standby device converts all SA information in the active state on the standby device to the passive state; 3) The primary device encapsulates all SA information in the active state into a data format supported by HA and sends it to the standby device through the HA-dedicated IKEV2 tunnel. After receiving the message, the standby device deduplicates and generates SA information and changes the state to passive.

[0068] In conjunction with any of the above embodiments, in one implementation, the present invention also provides a latency-free hot backup method suitable for SDWAN. In this method, before step S14 above, where "the first HA module of the first device uses an encrypted tunnel with the second HA module of the second device in the VPN gateway to synchronize the security association (SA) information to the second HA module," step S71 may be included; and, in addition to the above steps, steps S72 to S74 may be included: Step S71: The first HA module sends a SEGMENT TAKE control message to the second HA module to notify the second HA module that the first HA module is ready to synchronize the security association (SA) information to the second HA module.

[0069] In this embodiment, the HA module, in addition to supporting SA synchronization messages, also needs to support control messages. Specifically, the first HA module can send a SEGMENT TAKE control message to the second HA module before synchronizing the negotiated security association SA information to the second HA module. The first HA module then prepares to synchronize the security association SA information to the second HA module. This SEGMENT TAKE control message is used to control the first HA module to synchronize the security association SA information to the second HA module, and to notify the second HA module that the first HA module is prepared to synchronize the security association SA information to the second HA module.

[0070] Step S72: In the event of an anomaly in the first device, the first HA module sends a SEGMENT DROP control message to the second HA module to notify the second HA module that the first HA module stops synchronizing the security association (SA) information to the second HA module.

[0071] In this embodiment, if the first device (primary device) malfunctions, the first HA module will also send a SEGMENT DROP control message to the second HA module, and then the first HA module will stop synchronizing the Security Association (SA) information to the second HA module. This SEGMENT DROP control message is used to control the first HA module to stop synchronizing the SA information to the second HA module, and to notify the second HA module that the first HA module has stopped synchronizing the SA information to the second HA module.

[0072] Step S73: If some of the security association SA information in the security association SA information needs to be synchronized, the first HA module sends a RESYNC control message to the second HA module to notify the second HA module that the first HA module will synchronize the partial security association SA information to the second HA module.

[0073] In this embodiment, if some of the Security Association (SA) information obtained through negotiation needs to be synchronized to the backup device (i.e., the second device), the first HA module can send a RESYNC control message to the second HA module, and then the first HA module will synchronize the partial SA information to the second HA module. This RESYNC control message is used to control the first HA module to synchronize the partial SA information to the second HA module, and to notify the second HA module that the first HA module is synchronizing the partial SA information to the second HA module.

[0074] Step S74: The first HA module and the second HA module periodically send STATUS control messages to each other to periodically check the HA status of each other.

[0075] In this embodiment, the control messages supported by the HA module also include STATUS control messages: the first HA module and the second HA module can periodically send STATUS control messages to each other to periodically check the HA status of the other party. The STATUS control message is used to implement the periodic check of the HA status.

[0076] In this embodiment, the control message supports the standby HA module initiating a new round of SA information synchronization requests. This synchronization message enables the acquisition of all SA information from the new primary HA device after a device failure. The control message ensures the synchronization detection mechanism of the primary and standby HA message bodies and guarantees the correctness of HA synchronization between the primary and standby devices.

[0077] In one embodiment, the HA module also has a primary and a backup. The HA module supports control messages, which mainly control the status of SA messages and implement basic heartbeats. Control messages include: heartbeat detection between the primary and backup HA modules, synchronization IV information between the primary and backup HA modules, and also support feedback on the synchronization status of the HA synchronization SA message body. For example, the supported control messages are as follows: ; When the primary and backup devices are synchronizing SA information with the backup device, control messages are sent to determine the current SA information. For example, if the SA information needs to be synchronized with the backup device by the HA module, the control message is: SEGMENT TAKE. If the SA information does not need to be synchronized with the backup device due to an anomaly, the control message is: SEGMENT DROP. The control message for the keep-alive heartbeat between the primary and backup HA is: STATUS, which is sent periodically to periodically check the HA status. When certain SA information needs to be resynchronized, the control message: RESYNC is required to control the synchronization of the control messages. In addition, the control message IKE IV is a special operation. After primary / backup switchover, some algorithms depend on IV; otherwise, data decryption cannot be achieved after the switchover. Therefore, it is necessary to implement periodic IV synchronization.

[0078] In conjunction with any of the above embodiments, in one implementation, the present invention also provides a latency-free hot backup method suitable for SDWAN. In this method, after step S11, step S81 may be included; step S12 may specifically include step S82; and after "the first VRRP module sends a second notification message to the first HA module of the first device" in step S15, step S83 may be included; and step S16 may specifically include step S84. Step S81: The first VRRP module configures the second public IP address for the first device.

[0079] In this embodiment, the client gateway has a first public IP address, and the VPN gateway has a second public IP address. After the first VRRP module of the first device determines that the first device is the primary device, the first VRRP module can configure the second public IP address for the first device.

[0080] Step S82: The first device establishes the first IPSEC tunnel based on the second public IP address, and the client gateway establishes the first public IP address.

[0081] In this embodiment, after the first device is configured with a second public IP address, the first device can establish a first IPsec tunnel between the first device and the client gateway based on the second public IP address and the first public IP address. In other words, the first IPsec tunnel is an IPsec tunnel between the first public IP address and the second public IP address.

[0082] Step S83: The second VRRP module of the second device configures the second public IP address for the second device.

[0083] In this embodiment, if the first device (primary device) malfunctions and a primary / backup switch is performed, the second VRRP module of the second device (the primary device after the switch) can configure a second public IP address for the second device.

[0084] Step S84: The second device establishes a second IPSEC tunnel based on the second public IP address, and the client gateway establishes a second IPSEC tunnel based on the first public IP address. The second device uses the stored security association (SA) information to perform data interaction with the client gateway through the second IPSEC tunnel.

[0085] In this embodiment, after the second device switches to the primary device and is configured with a second public IP address, the second device can establish a second IPsec tunnel between itself and the client gateway based on the second public IP address, while the client gateway can establish a second public IP address based on the first public IP address. After the switchover, the second device can use the security association (SA) information stored in its storage to interact with the client gateway through the established second IPsec tunnel. Since this second IPsec tunnel, like the first IPsec tunnel, is also an IPsec tunnel between the first and second public IP addresses, the client gateway is always connected to the same public IP address and will not be aware of the hot standby system switchover. It can continue to use the original security association (SA) information for data encryption / decryption, renegotiation, and registration refresh.

[0086] In one embodiment, such as Figure 6 As shown, Figure 6 This is a schematic diagram illustrating a hot standby switching process according to an embodiment of the present invention. Figure 6 The VPN use case shown in the upper part involves the client gateway (i.e., the local gateway) establishing an IPsec encrypted tunnel (i.e., an IPsec TUNNEL) with the VPN gateway. In this embodiment, the VPN gateway is a hot standby system, including VPN1 and VPN2. The VRRP virtual IP of this hot standby system is the IPsec service IP. When the VPN gateway connects with the client gateway, VPN1 is the primary device, and at this time, VPN1 undertakes the IPsec negotiation function. After the client gateway successfully establishes a connection with the primary device VPN1 of the VPN gateway and generates IPsec SA information: SA1 / SA2, VPN1 immediately synchronizes the SA1 / SA2 information, IKE ID information, and IV information to the standby device VPN2 through the HA module via VRRP primary / standby and HA status. At this time, the SA information on VPN1 is used for data encryption and decryption, while VPN2 only stores the SA information.

[0087] When the primary device VPN1 malfunctions, such as Figure 6As shown in the lower part, during VRRP data service switching, the hot standby system switches the IPSEC encrypted tunnel to VPN2. The client gateway is unaware of the hot standby system switch and continues to use the original SA1 / SA2 for data encryption / decryption, renegotiation, and registration refresh. At this time, VPN2 stores all SA information (SA1 / SA2), IKE ID information, and IV information for the IPSEC tunnel. Therefore, VPN2 can normally encrypt and decrypt data services with the client gateway, and can also re-initiate negotiation, reply to negotiation messages, and normally reply to DPD messages. VPN2 then undertakes the IPSEC negotiation function, synchronizing SA information to VPN1 through HA. This achieves a completely delay-free hot standby system switchover.

[0088] in, Figure 6 1.1.1.2 in the text refers to the public IP address of the client gateway IPsec, which is the first public IP address. Figure 6 1.1.1.3 in the URL refers to the public IP address of the VPN gateway, i.e., the second public IP address. The primary and backup devices are single-active; the VRRP protocol is used to determine the primary / backup status, and this second public IP address is configured on the primary device. For example... Figure 6 In the upper part, VPN1 is the primary device. A second public IP address, 1.1.1.3, is configured for VPN1. VPN1 establishes the first IPsec tunnel via IP address 1.1.1.3, and the client gateway establishes the tunnel via IP address 1.1.1.2. If the primary VPN gateway experiences a service failure, VRRP switches to backup within milliseconds, i.e., ... Figure 6 As shown in the lower half, the second public IP address 1.1.1.3 is assigned to the backup device, VPN2. VPN2 is now the primary device. VPN2 establishes a second IPsec tunnel via IP address 1.1.1.3, and the client gateway via IP address 1.1.1.2. Due to the HA function, the new primary device, VPN2, also has the previously successfully negotiated SA information. Therefore, services will be directly sent to the new primary device, VPN2, through the second IPsec tunnel, and service decryption will proceed without error.

[0089] In summary, addressing the shortcomings of existing SDWAN hot standby solutions, the purpose of this invention is to design a latency-free dual-machine hot standby solution for SDWAN based on the linkage of VRRP and STRONSWAN HA functions. This solution utilizes STRONSWAN's HA function to achieve real-time synchronization of negotiation information such as the SA (Service Acquisition) of the IPEC tunnel between the primary and standby systems via a dedicated IKEv2 encrypted tunnel, ensuring that the primary and standby devices have the same protocol SA and other negotiation information. Furthermore, VRRP enables primary-standby synchronization with the HA function, ensuring that the primary device provides normal IPSEC negotiation and ESP (Electronic Security Program) data forwarding functions and can synchronize SA and other negotiation information to the standby device in real time. At this time, the standby device only stores SA information. When the primary device fails and switches to the standby device via VRRP, the standby device provides normal IPSEC data forwarding functions using the existing SA information, completes the new negotiation process, and synchronizes SA information to the original primary device in real time.

[0090] Thus, the present invention has at least the following technical effects: 1. Commonly used IPsec VPN hot standby solutions lack a mature mechanism for synchronizing SA information between hot standby systems. This invention creatively proposes a linkage scheme using the HA plugin of STRONGSWAN and VRRP, which not only ensures zero-latency handover of IPsec data services but also guarantees the normal operation of IPsec connection registration refresh and DPD negotiation processes after the handover. This invention synchronizes the VRRP hot standby scheme with the STRONGSWAN HA primary / standby status, ensuring the synchronization of system handover during hot standby system switching. After VRRP detects and switches the primary / standby system, it ensures that the HA system, assuming the primary role, can quickly and successfully negotiate and synchronize SA information, guaranteeing zero-latency handover of IPsec services.

[0091] 2. Compared to methods such as adding SA synchronization fields using VRRP extension protocol fields, the HA-specific IKEv2 encrypted tunnel for transmitting SA information in this invention offers higher security. Compared to the relatively complex method of achieving SA information hot standby synchronization between systems through VRRP extension negotiation, the HA function of STRONGSWAN itself in this invention, which handles IPsec negotiation, more efficiently ensures the correctness of SA information and zero-delay information synchronization.

[0092] This invention can be applied to hot standby systems that require IPsec VPN support, or to clustered networks where the software framework uses STORNGSWAN for IPsec negotiation, enabling the synchronization of IPsec negotiation information within the cluster. Furthermore, this invention can also be applied to scenarios where multiple devices in a multi-traffic forwarding system need to simultaneously forward IPsec traffic. HA synchronization not only synchronizes negotiation information, but through HA extensions, it can flexibly synchronize a series of information such as device traffic and operational monitoring, while ensuring secure encryption of the information channel and high availability.

[0093] It should be noted that, for the sake of simplicity, the method embodiments are all described as a series of actions. However, those skilled in the art should understand that the embodiments of the present invention are not limited to the described order of actions, because according to the embodiments of the present invention, some steps can be performed in other orders or simultaneously. Furthermore, those skilled in the art should also understand that the embodiments described in the specification are preferred embodiments, and the actions involved are not necessarily essential to the embodiments of the present invention.

[0094] Based on the same inventive concept, one embodiment of the present invention provides a latency-free hot backup system suitable for SDWAN. (Reference) Figure 7 , Figure 7 This is a structural block diagram of a latency-free hot backup system suitable for SDWAN, provided by an embodiment of the present invention. Figure 7 As shown, the system includes at least: a client gateway and a VPN gateway; the VPN gateway includes a first device and a second device; The first device is used for: The first VRRP module sends a first notification message to the first HA module; the first notification message indicates that the first device is the primary device. Establish the first IPsec tunnel with the client gateway; Negotiate Security Association (SA) information with the client gateway, wherein the Security Association (SA) information is used to encrypt and decrypt data exchanged between the client gateway and the first device; The security association (SA) information is synchronized to the second HA module through an encrypted tunnel between the first HA module and the second HA module of the second device, and the second device stores the security association (SA) information. In the event of an abnormality in the first device, a second notification message is sent to the first HA module of the first device via the first VRRP module; the second notification message indicates that the first device is a backup device. The second device is used to establish a second IPSEC tunnel with the client gateway and to interact with the client gateway through the second IPSEC tunnel using the stored Security Association (SA) information.

[0095] Optionally, the method further includes: The first device is also used for: The first negotiation module is used to synchronize the Security Association (SA) information to the first data forwarding module of the first device via the first API; the first negotiation module and the first HA module are deployed at the first layer of the first device; the first data forwarding module and the first VRRP module are deployed at the second layer of the first device. The first data forwarding module uses the security association (SA) information to interact with the client gateway through the first IPSEC tunnel.

[0096] Optionally, the first device has a first host address, and the second device has a second host address; the first device is further configured to: The first host address is configured as a local tunnel address and the second host address is configured as a remote tunnel address through the first HA module. The second device is also used for: The second host address is configured as the local tunnel address and the first host address is configured as the remote tunnel address through the second HA module. The first HA module establishes an encrypted tunnel between itself and the second HA module based on the tunnel address configuration information, through the management port of the first device and the management port of the second device.

[0097] Optionally, the first device is specifically used for: The first HA module uses an encrypted tunnel with the second HA module to send IKE add messages and CHILD add messages to the second HA module, so as to synchronize the security association (SA) information to the second HA module. The first device is further used for: At the end of the renegotiation timeout period, the security association (SA) information is renegotied with the client gateway. Through the first HA module, using an encrypted tunnel with the second HA module, IKE add messages and CHILD add messages are sent to the second HA module to synchronize the renegotiation security association (SA) information to the second HA module, and IKE delete messages and CHILD delete messages are sent to the second HA module to instruct the second HA module to delete the first stored security association (SA) information. If the negotiation of security association (SA) information between the first device and the client gateway times out, the first HA module sends an IKE deletion message and a CHILD deletion message to the second HA module through an encrypted tunnel between the first HA module and the second HA module, instructing the second HA module to delete the stored security association (SA) information.

[0098] Optionally, the first device is further configured to: After the first device negotiates the security association (SA) information with the client gateway, the first HA module sets the status of the security association (SA) information to active. The second device is also used for: After the second device stores the security association (SA) information, the second HA module sets the status of the stored security association (SA) information to a passive state.

[0099] Optionally, the first device is further configured to: After the first VRRP module sends a second notification message to the first HA module of the first device, the first HA module switches the status of the security association SA information from active to passive. The second device is also used for: In the event of an abnormality in the first device, a third notification message is sent to the second HA module of the second device via the second VRRP module. The third notification message indicates that the second device is the primary device. The second HA module switches the status of the stored security association (SA) information from passive to active.

[0100] Optionally, the first device is further configured to: Before the first HA module of the first device synchronizes the security association (SA) information to the second HA module by using an encrypted tunnel between the first HA module of the first device and the second HA module of the second device in the VPN gateway, the first HA module sends a SEGMENT TAKE control message to the second HA module to notify the second HA module that the first HA module is ready to synchronize the security association (SA) information to the second HA module. In the event of an anomaly in the first device, the first HA module sends a SEGMENT DROP control message to the second HA module to notify the second HA module that the first HA module should stop synchronizing the security association (SA) information to the second HA module. When some of the security association SA information in the security association SA information needs to be synchronized, the first HA module sends a RESYNC control message to the second HA module to notify the second HA module that the first HA module will synchronize the partial security association SA information to the second HA module. The first HA module and the second HA module periodically send STATUS control messages to each other to periodically check the HA status of each other.

[0101] Optionally, the client gateway has a first public IP address, and the VPN gateway has a second public IP address; The first device is further used for: After the first VRRP module of the first device in the VPN gateway sends the first notification message to the first HA module of the first device, the second public IP address is configured for the first device through the first VRRP module. The first device is specifically used for: Based on the second public IP address, the client gateway establishes the first IPSEC tunnel based on the first public IP address; The second device is also used for: After the first VRRP module sends the second notification message to the first HA module of the first device, the second VRRP module configures the second public IP address for the second device. The second device is specifically used for: Based on the second public IP address, the client gateway establishes the second IPSEC tunnel based on the first public IP address, and uses the stored security association (SA) information to interact with the client gateway through the second IPSEC tunnel.

[0102] The terms "first," "second," etc., used in the specification and claims of this invention are used to distinguish similar objects and are not used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that embodiments of the invention can be implemented in orders other than those illustrated or described herein. Furthermore, in the specification and claims, "and / or" indicates at least one of the connected objects, and the character " / " generally indicates that the preceding and following objects are in an "or" relationship.

[0103] The latency-free hot backup system for SDWAN in this embodiment of the invention can be a device, or a component, integrated circuit, or chip in a terminal. The device can be a mobile electronic device or a non-mobile electronic device. For example, mobile electronic devices can be mobile phones, tablets, laptops, PDAs, in-vehicle electronic devices, wearable devices, ultra-mobile personal computers (UMPCs), netbooks, or personal digital assistants (PDAs), etc., while non-mobile electronic devices can be servers, network-attached storage (NAS), personal computers (PCs), televisions (TVs), ATMs, or self-service machines, etc. This embodiment of the invention does not impose specific limitations.

[0104] The latency-free hot backup system for SDWAN in this embodiment of the invention can be a device with an operating system. This operating system can be Android, iOS, or other possible operating systems; this embodiment of the invention does not impose specific limitations.

[0105] Based on the same inventive concept, another embodiment of the present invention provides an electronic device, such as... Figure 8 As shown, Figure 8 This is a schematic diagram of an electronic device according to an embodiment of the present invention. The electronic device includes a memory, a processor, and a program or instructions stored in the memory and executable on the processor. When the program or instructions are executed by the processor, they implement the steps in the latency-free hot backup method for SDWAN described in any of the above embodiments of the present invention.

[0106] It should be noted that the electronic devices in the embodiments of the present invention include the mobile electronic devices and non-mobile electronic devices described above.

[0107] As the system implementation is basically similar to the method implementation, it is described in a relatively simple way. For relevant details, please refer to the description of the method implementation.

[0108] It should be noted that, in this document, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes that element. Furthermore, it should be noted that the scope of the methods and apparatuses in the embodiments of the present invention is not limited to performing functions in the order shown or discussed, but may also include performing functions substantially simultaneously or in the reverse order, depending on the functions involved. For example, the described methods may be performed in a different order than described, and various steps may be added, omitted, or combined. Additionally, features described with reference to certain examples may be combined in other examples.

[0109] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods of the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method. Based on this understanding, the technical solution of the present invention, or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product is stored in a storage medium (such as ROM / RAM, magnetic disk, optical disk) and includes several instructions to cause a terminal (which may be a mobile phone, computer, server, air conditioner, or network device, etc.) to execute the methods described in the various embodiments of the present invention.

[0110] The embodiments of the present invention have been described above with reference to the accompanying drawings. However, the present invention is not limited to the specific embodiments described above. The specific embodiments described above are merely illustrative and not restrictive. Those skilled in the art can make many other forms under the guidance of the present invention without departing from the spirit and scope of the claims, and all of these forms are within the protection scope of the present invention.

Claims

1. A latency-free hot backup method suitable for SDWAN, characterized in that, The method includes: The first VRRP module of the first device in the VPN gateway sends a first notification message to the first HA module of the first device; the first notification message indicates that the first device is the primary device. The first device establishes a first IPsec tunnel with the client gateway; The first device negotiates Security Association (SA) information with the client gateway, and the Security Association (SA) information is used to encrypt and decrypt data exchanged between the client gateway and the VPN gateway. The first HA module of the first device uses an encrypted tunnel with the second HA module of the second device in the VPN gateway to synchronize the security association (SA) information to the second HA module, and the second device stores the security association (SA) information. In the event of an anomaly in the first device, the first VRRP module sends a second notification message to the first HA module of the first device; the second notification message indicates that the first device is a backup device. The second device establishes a second IPSEC tunnel with the client gateway and uses the stored Security Association (SA) information to interact with the client gateway through the second IPSEC tunnel.

2. The latency-free hot backup method for SDWAN according to claim 1, characterized in that, The method further includes: The first negotiation module of the first device synchronizes the Security Association (SA) information to the first data forwarding module of the first device via a first API; the first negotiation module and the first HA module are deployed at the first layer of the first device; the first data forwarding module and the first VRRP module are deployed at the second layer of the first device. The first data forwarding module uses the security association (SA) information to interact with the client gateway through the first IPSEC tunnel.

3. The latency-free hot backup method for SDWAN according to claim 1, characterized in that, The first device has a first host address, and the second device has a second host address; the method further includes: The first HA module configures the first host address as the local tunnel address and the second host address as the remote tunnel address; The second HA module configures the second host address as the local tunnel address and the first host address as the remote tunnel address; The first HA module establishes an encrypted tunnel between itself and the second HA module based on the tunnel address configuration information, through the management port of the first device and the management port of the second device.

4. The latency-free hot backup method for SDWAN according to claim 1, characterized in that, The first HA module of the first device uses an encrypted tunnel with the second HA module of the second device in the VPN gateway to synchronize the security association (SA) information to the second HA module, including: The first HA module uses an encrypted tunnel with the second HA module to send IKE add messages and CHILD add messages to the second HA module, so as to synchronize the security association (SA) information to the second HA module. The method further includes: When the renegotiation timeout period ends, the first device and the client gateway renegotiation of the security association (SA) information; The first HA module uses an encrypted tunnel with the second HA module to send IKE add messages and CHILD add messages to the second HA module to synchronize the renegotiation security association (SA) information to the second HA module, and sends IKE delete messages and CHILD delete messages to the second HA module to instruct the second HA module to delete the earliest stored security association (SA) information. If the negotiation of security association (SA) information between the first device and the client gateway times out, the first HA module uses an encrypted tunnel with the second HA module to send IKE deletion messages and CHILD deletion messages to the second HA module, instructing the second HA module to delete the stored security association (SA) information.

5. The latency-free hot backup method for SDWAN according to claim 1, characterized in that, After the first device negotiates the security association (SA) information with the client gateway, the method further includes: The first HA module sets the status of the security association (SA) information to active. After the second device stores the security association (SA) information, the method further includes: The second HA module sets the status of the stored security association (SA) information to passive state.

6. The latency-free hot backup method for SDWAN according to claim 5, characterized in that, After the first VRRP module sends a second notification message to the first HA module of the first device, the method further includes: The first HA module switches the status of the security association SA information from active to passive. The method further includes: In the event of an anomaly in the first device, the second VRRP module of the second device sends a third notification message to the second HA module of the second device, wherein the third notification message indicates that the second device is the primary device; The second HA module switches the status of the stored security association (SA) information from passive to active.

7. The latency-free hot backup method for SDWAN according to claim 1, characterized in that, Before the first HA module of the first device synchronizes the security association (SA) information to the second HA module of the second device in the VPN gateway through an encrypted tunnel, the method further includes: The first HA module sends a SEGMENT TAKE control message to the second HA module to notify the second HA module that the first HA module is ready to synchronize the security association (SA) information to the second HA module. The method further includes: In the event of an anomaly in the first device, the first HA module sends a SEGMENTDROP control message to the second HA module to notify the second HA module that the first HA module should stop synchronizing the security association (SA) information to the second HA module. If some of the Security Association SA information in the Security Association SA information needs to be synchronized, the first HA module sends a RESYNC control message to the second HA module to notify the second HA module that the first HA module will synchronize the partial Security Association SA information to the second HA module. The first HA module and the second HA module periodically send STATUS control messages to each other to periodically check the HA status of each other.

8. The latency-free hot backup method for SDWAN according to claim 1, characterized in that, The client gateway has a first public IP address, and the VPN gateway has a second public IP address; After the first VRRP module of the first device in the VPN gateway sends a first notification message to the first HA module of the first device, the method further includes: The first VRRP module configures the second public IP address for the first device; The first device establishes a first IPsec tunnel with the client gateway, including: The first device establishes the first IPsec tunnel based on the second public IP address, and the client gateway establishes the first public IP address. After the first VRRP module sends a second notification message to the first HA module of the first device, the method further includes: The second VRRP module of the second device configures the second public IP address for the second device; The second device establishes a second IPSEC tunnel with the client gateway and uses the stored Security Association (SA) information to interact with the client gateway through the second IPSEC tunnel, including: The second device establishes a second IPsec tunnel based on the second public IP address, and the client gateway establishes a second IPsec tunnel based on the first public IP address. The second device uses the stored security association (SA) information to interact with the client gateway through the second IPsec tunnel.

9. A latency-free hot backup system suitable for SDWAN, characterized in that, The system includes at least: a client gateway and a VPN gateway; the VPN gateway includes a first device and a second device; The first device is used for: The first VRRP module sends a first notification message to the first HA module; the first notification message indicates that the first device is the primary device. Establish the first IPsec tunnel with the client gateway; Negotiate Security Association (SA) information with the client gateway, wherein the Security Association (SA) information is used to encrypt and decrypt data exchanged between the client gateway and the first device; The security association (SA) information is synchronized to the second HA module through an encrypted tunnel between the first HA module and the second HA module of the second device, and the second device stores the security association (SA) information. In the event of an abnormality in the first device, a second notification message is sent to the first HA module of the first device via the first VRRP module; the second notification message indicates that the first device is a backup device. The second device is used to establish a second IPSEC tunnel with the client gateway and to interact with the client gateway through the second IPSEC tunnel using the stored Security Association (SA) information.

10. An electronic device, characterized in that, It includes a processor, a memory, and a program or instructions stored in the memory and executable on the processor, wherein the program or instructions, when executed by the processor, implement the steps of the delay-free hot standby method for SDWAN as described in any one of claims 1 to 8.

Images