VPN tunnel fault recovery method, apparatus and device, and medium

Abstract

The invention relates to a fault recovery method and device for a VPN tunnel, equipment and a medium. In the scheme, when a VPN module of a data sending end detects a to-be-recovered VPN tunnel in an abnormal state, session information of the to-be-recovered VPN tunnel is deleted, when a first VPN gateway corresponding to the VPN module sends a target message through the to-be-recovered VPN tunnel, the target message is sent to a router of a data receiving end through a random port, and the router of the data receiving end receives the target message through the to-be-recovered VPN tunnel. According to the embodiment of the invention, the target message is sent to the second VPN gateway of the data receiving end through the router, the router generates new target session information based on the random port, and when the reply message sent by the second VPN gateway is forwarded at the router, wrong session information is not matched, but correct target session information is matched. Therefore, under the condition that the VPN tunnel is abnormal due to wrong matching of the session information, the VPN tunnel is quickly recovered to be normal, and normal communication between the data sending end and the data receiving end is recovered.

Description

Technical Field

[0001] This application relates to the field of VPN tunnel fault recovery technology, and in particular to a VPN tunnel fault recovery method, apparatus, device and medium. Background Technology

[0002] Cross-data center network connectivity solutions primarily utilize VPN (Virtual Private Network) solutions. As cross-data center services increase, VPN reliability becomes a crucial consideration. Many factors influence the VPN tunnel status, such as public network quality and the network equipment used in intermediate devices. Because VPN protocols require packet probing to maintain tunnel health, complex intermediate network environments or poor public network quality can cause the VPN tunnel to become abnormal. In off-site disaster recovery scenarios, managed cloud environments, considering cost, security, and versatility, utilize numerous virtual router network resources and configure NAT (Network Address Translation) rules.

[0003] Currently, when there is a virtual router in the intermediate network device of a VPN tunnel, the virtual router has introduced a function of fast session connection matching in order to quickly forward routes. That is, when a packet is transmitted in the virtual router, the router will record the five-tuple of the packet to form a session. When subsequent packets arrive, they will first match the session. If a match is found, the packet will be forwarded according to the matching session mechanism. If no match is found, then a route query and forwarding will be performed. Combining the router's session mechanism with the VPN protocol, current VPN tunnel status monitoring can lead to tunnel anomalies due to incorrect session matching. For example, when there is a virtual router between the VPN gateways of two data centers, the VPN protocol sends probe packets to both the headquarters and branch ends. If a probe packet sent from the branch end is sent to the virtual router at the headquarters and forms session 1 through NAT rules, then the probe packet sent from the branch end can successfully send a response packet if it matches session 1 on the virtual router at the headquarters. However, if the probe packet sent from the headquarters end forms session 2 on the virtual router at the headquarters, and the probe packet sent from the branch end fails to match session 2 on the virtual router, the response packet forwarding will fail. When the probe packet cannot reach the other end, and neither side receives any response after multiple consecutive probes, the VPN tunnel will be flagged as abnormal, resulting in network connectivity issues between the data centers.

[0004] Therefore, how to quickly restore a VPN tunnel to normal when a VPN tunnel malfunctions due to a mismatched session is a problem that needs to be solved by those skilled in the art. Summary of the Invention

[0005] This application provides a method, apparatus, device, and medium for VPN tunnel fault recovery, so as to quickly restore the VPN tunnel to normal when the VPN tunnel is abnormal due to a mismatched session.

[0006] Firstly, a fault recovery method for a VPN tunnel is provided, the fault recovery method being based on the VPN module at the data sending end, the fault recovery method comprising:

[0007] Check for any VPN tunnels in an abnormal state that are awaiting recovery;

[0008] If it exists, delete the session information of the VPN tunnel to be restored;

[0009] When the first VPN gateway corresponding to the VPN module sends a target packet through the VPN tunnel to be restored, it uses a random port as the source port to send the target packet to the router at the data receiving end, and then the router sends the target packet to the second VPN gateway at the data receiving end. The router at the data receiving end generates target session information based on the random port and returns the reply packet sent by the second VPN gateway to the first VPN gateway through the target session information, thereby achieving tunnel fault recovery. The random port is different from the original port used by the first VPN gateway to send the packet.

[0010] Optionally, before checking for the existence of VPN tunnels in an abnormal state that need to be recovered, the method further includes:

[0011] Obtain the configuration information of the first VPN gateway;

[0012] Determine whether the main switch of the first VPN gateway is in the on state based on the configuration information;

[0013] If enabled, the step of checking for any VPN tunnels in an abnormal state that need to be restored is performed.

[0014] Optionally, after sending the target message to the router at the data receiving end, the method further includes:

[0015] The health status of the VPN tunnel to be restored is queried a first predetermined number of times at a first preset time interval.

[0016] If the query results are all abnormal for the first predetermined number of consecutive times, the fault recovery fails, and the VPN tunnel to be recovered is determined to be a failed recovery tunnel, generating a fault reminder message.

[0017] Optionally, deleting the session information of the VPN tunnel to be restored includes:

[0018] Using a connection tracking tool, query the session information of the VPN tunnel to be restored from the first VPN gateway, and delete the session information of the VPN tunnel to be restored from the first VPN gateway using the connection tracking tool.

[0019] Optionally, the check for the existence of VPN tunnels in an abnormal state that need to be recovered includes:

[0020] In each detection cycle, obtain the tunnel list of the first VPN gateway;

[0021] Iterate through each VPN tunnel in the tunnel list to check if there are any abnormal VPN tunnels; the abnormal VPN tunnel refers to a tunnel whose health status is abnormal but is in the started state.

[0022] If an abnormal VPN tunnel exists, determine whether the abnormal VPN tunnel is in the list of failed recovery tunnels;

[0023] If not, the abnormal VPN tunnel will be treated as a VPN tunnel awaiting recovery.

[0024] Optionally, before determining whether the abnormal VPN tunnel is in the list of failed tunnel recovery attempts, the method further includes:

[0025] In each inspection cycle, it is determined whether the number of inspections for each failed recovery tunnel in the list of failed recovery tunnels exceeds a predetermined number;

[0026] If so, the recovery failure tunnel that has been checked more than the predetermined number of times will be removed from the recovery failure tunnel list.

[0027] Optionally, if the abnormal VPN tunnel is not in the list of failed tunnel recovery attempts, the fault recovery method further includes:

[0028] The health status of the abnormal VPN tunnel is queried a second predetermined number of times at a second preset time interval.

[0029] If the query results are all abnormal for the second predetermined number of consecutive times, then the step of treating the abnormal VPN tunnel as a VPN tunnel to be restored is executed.

[0030] Secondly, this application provides a fault recovery device for a VPN tunnel, the fault recovery device being based on a VPN module at the data sending end, the fault recovery device comprising:

[0031] The tunnel inspection module is used to check for the existence of VPN tunnels in an abnormal state that need to be restored; if one exists, the first deletion module is triggered.

[0032] The first deletion module is used to delete the session information of the VPN tunnel to be restored;

[0033] The sending module is used to send the target packet to the router of the data receiving end by using a random port as the source port when the first VPN gateway corresponding to the VPN module sends the target packet through the VPN tunnel to be restored; and then sends the target packet to the second VPN gateway of the data receiving end through the router.

[0034] The router at the data receiving end generates target session information based on the random port and returns the reply message sent by the second VPN gateway to the first VPN gateway through the target session information, thereby realizing tunnel fault recovery; the random port is different from the original port used by the first VPN gateway to send the message.

[0035] Thirdly, this application provides an electronic device, comprising:

[0036] Memory, used to store computer programs;

[0037] A processor is used to implement the steps of the above-described fault recovery method when executing the computer program.

[0038] Fourthly, this application also provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the steps of the above-described fault recovery method.

[0039] Compared with the prior art, the technical solution provided in this application has the following advantages: This application provides a method, apparatus, device, and medium for fault recovery of a VPN tunnel. In this solution, when the VPN module at the data sending end detects a VPN tunnel in an abnormal state that needs to be recovered, it needs to delete the session information of the VPN tunnel to be recovered. This allows the first VPN gateway of the VPN module to send a target packet through the VPN tunnel to be recovered, using a random port to send the target packet to the router at the data receiving end, and then the router to send the target packet to the second VPN gateway at the data receiving end. The router can then generate new target session information based on the random port. When the reply packet sent by the second VPN gateway is forwarded at the router, it will not match the incorrect session information, but will match the correct target session information. Thus, in the case of VPN tunnel abnormality caused by matching incorrect session information, the VPN tunnel can be quickly restored to normal, and normal communication between the data sending end and the data receiving end can be restored. Attached Figure Description

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

[0041] Figure 1 This application provides a schematic diagram of a message matching anomaly.

[0042] Figure 2 This application provides a schematic diagram of a VPN tunnel fault recovery system structure.

[0043] Figure 3 A schematic flowchart of a VPN tunnel fault recovery method provided in an embodiment of this application;

[0044] Figure 4 This is a schematic diagram of the tunnel monitoring process provided in an embodiment of this application;

[0045] Figure 5 A timing diagram for VPN monitoring and management provided in an embodiment of this application;

[0046] Figure 6 A VPN tunnel fault recovery device is provided as an embodiment of this application;

[0047] Figure 7 This is a schematic diagram of an electronic device structure provided in an embodiment of this application. Detailed Implementation

[0048] This specific embodiment is merely an explanation of this application and is not intended to limit it. After reading this specification, those skilled in the art can make modifications to this embodiment without contributing any inventive step, but such modifications are protected by patent law as long as they are within the scope of this application.

[0049] It should be noted that, in the optional embodiments of this application, the data related to object information, when applied to specific products or technologies, requires the permission or consent of the object. Furthermore, the collection, use, and processing of this data must comply with the relevant laws, regulations, and standards of the relevant countries and regions. In other words, if the embodiments of this application involve data related to an object, it must be obtained with the object's authorization and consent, the authorization and consent of relevant departments, and in accordance with the relevant laws, regulations, and standards of the country and region. If the embodiments involve personal information, the acquisition of all personal information requires the individual's consent. If sensitive information is involved, the separate consent of the information subject is required. The embodiments also need to be implemented with the object's authorization and consent.

[0050] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0051] Furthermore, the term "and / or" in this document is merely a description of the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, and B existing alone. Additionally, the character " / " in this document, unless otherwise specified, generally indicates that the preceding and following related objects have an "or" relationship. To better understand and illustrate the solutions of the embodiments of this application, some technical terms involved in the embodiments of this application are briefly explained below.

[0052] NAT (Network Address Translation) is used to implement the mapping and reverse mapping between internal network IP (Internet Protocol) addresses and external network IP addresses.

[0053] VPN (Virtual Private Network) establishes a private network on a public network for encrypted communication.

[0054] VPN Gateway: Sangfor's network product that enables cross-data center connectivity by creating VPN tunnels.

[0055] Session: A long-lived connection formed by the data forwarding plane when forwarding packets, which can increase the packet's five-tuple information for faster packet forwarding.

[0056] In the existing solution, the VPN protocol itself occupies ports 500 and 4500 to send messages. Port 500 is used to send probe messages to detect the health status of the entire VPN tunnel. If the probe messages can be sent and received normally, it means that the entire link is normal, so the VPN tunnel is normal. The messages on port 4500 are used to encapsulate the transmitted data packets.

[0057] When probe packets fail to reach the other end, and both parties receive no response after multiple consecutive probes, the VPN tunnel will be flagged as faulty. When the VPN tunnel is faulty, it will send probe packets periodically, waiting for the intermediate link to recover. When both the server's and client's probe packets reach their respective gateway routers, a session is generated on the router. Subsequent packets will then be quickly matched to this session for forwarding. However, this session generated by the probe packets can cause incorrect data packet matching.

[0058] See Figure 1 This figure illustrates a message matching anomaly according to an embodiment of this application. It includes data center 1 and data center 2, each containing a VPN gateway. Virtual routers in data centers 1 and 2 send probe messages via the Internet. The probe messages from data center 1, when sent to the virtual router in data center 2, undergo dNAT (Destination Network Address Translation), creating session 1 on the virtual router. The content of session 1 is:

[0059] flow0 (data flow direction: virtual router in data center 1 - virtual router in data center 2):

[0060] srcip:10.128.137.100;sport:4500;

[0061] dstip:10.129.137.100; dport:4500;

[0062] flow1 (configured with dNAT, data flow direction: virtual router in data center 2 - VPN gateway in data center 2):

[0063] srcip:10.129.137.100;sport:4500;

[0064] dstip:8.8.8.8 dport:;4500;

[0065] flow2 (data flow direction: VPN gateway of data center 2 - virtual router of data center 2):

[0066] srcip:8.8.8.8; sport:4500;

[0067] dstip:10.129.137.100; dport:4500;

[0068] Wherein, flow represents a data flow, srcip (Source IP Address) is the source IP address, dstip (Destination IP Address) is the destination IP address, sport (Source Port) is the source port, and dport (Destination Port) is the destination port. The source port of each flow is the port through which the VPN gateway in data center 1 sends packets, and the destination port of each flow is the port through which the VPN gateway in data center 2 receives packets.

[0069] Therefore, after Data Center 1 sends a probe packet to the VPN gateway of Data Center 2, the VPN gateway of Data Center 2 sends a reply packet to the virtual router of Data Center 2. This reply packet will match flow2 in session1 of the virtual router and then send the reply packet to the VPN gateway of Data Center 1 through flow1 of session1.

[0070] However, since the VPN gateway in data center 2 also sends probe packets, it will create a session 2 on the data center's exit virtual router, as shown in the figure. Session 2 is:

[0071] flow0 (Data flow direction: VPN gateway of data center 2 - virtual router of data center 2):

[0072] srcip:8.8.8.8; sport:4500;

[0073] dstip:10.129.137.100; dport:500;

[0074] flow1 (Data flow direction: Virtual router in data center 2 - VPN gateway in data center 2):

[0075] src:10.129.137.100; src port:4500;

[0076] dst:8.8.8.8 dst;port:4500;

[0077] By comparing session1 and session2, it can be seen that in the virtual router, the five-tuples of flow2 in session1 and flow0 in session2 are the same. Therefore, when the probe packet from data center1 is sent to the VPN gateway in data center2, the VPN gateway sends a normal response packet. The response packet in the virtual router of data center2 will incorrectly match flow0 of session2, but cannot match flow2 of session1, resulting in the failure to replace the source IP and other content, causing network failure.

[0078] Therefore, this application proposes a method, apparatus, device, and medium for VPN tunnel fault recovery, so as to quickly restore the VPN tunnel to normal when the VPN tunnel is abnormal due to a mismatched session.

[0079] To clearly explain this solution, the fault recovery system will first be described. This system includes a data transmitter and a data receiver. The data transmitter includes a VPN module, a first VPN gateway, and a router. The data receiver includes a VPN module, a second VPN gateway, and a router. The VPN module's product form includes, but is not limited to:

[0080] 1) A VPN software service, which is decoupled from VPN hardware devices, for scheduling VPN hardware devices deployed on data sending ends.

[0081] 2) A VPN software service that provides a pure software VPN service through virtualization technology, requiring no hardware support, and is deployed on the data sending and receiving ends.

[0082] 3) A VPN hardware device, wherein VPN software services are integrated into the VPN hardware device, and the VPN hardware device is deployed at the data sending end.

[0083] It is understood that if the VPN module is the scheme described in 2) and 3) above, then the VPN module at the data sending end includes a first VPN gateway; if the VPN module is the scheme in 1) above, then the data sending end includes a decoupled VPN module (software module) and a first VPN gateway (hardware device), and the VPN module can schedule the first VPN gateway to work. This application embodiment does not impose any restrictions on the VPN module architecture at the data receiving end.

[0084] In this embodiment, the structure of the fault recovery system is described only in the case of decoupling the VPN software service from the VPN hardware device. See [link to documentation]. Figure 2This figure shows a schematic diagram of a VPN tunnel fault recovery system provided in this application. The system includes a data sending end and a data receiving end. The data sending end includes a VPN module and a router. The VPN module of the data sending end includes a first VPN gateway. The data receiving end includes a VPN module and a router. The VPN module of the data receiving end includes a second VPN gateway. The data sending end and data receiving end can be data centers, and the router can be a virtual router. It should be noted that this embodiment only uses the example of the data sending end and data receiving end including a VPN gateway and a router to illustrate the VPN tunnel fault recovery process. In practical applications, the network element devices implementing network relay within this system are not limited to this, and are not specifically limited here.

[0085] The fault recovery method described in this application can run on various software units of the VPN module, including but not limited to software units driving the VPN client and software units driving the VPN gateway. That is, in the fault recovery method described in this application, except for the sending of the target packet which needs to be implemented through the first VPN gateway, other operations unrelated to packet sending, such as determining the VPN tunnel to be recovered, deleting session information, and determining a random port, can all be implemented through the software unit driving the VPN client or the software unit driving the VPN gateway. When the VPN module detects a VPN tunnel to be recovered in an abnormal state, it deletes the session information of the VPN tunnel to be recovered. When the first VPN gateway sends the target packet through the VPN tunnel to be recovered, it uses a random port to send the target packet to the router at the data receiving end, and then the router sends the target packet to the second VPN gateway at the data receiving end. The router at the data receiving end generates target session information based on the random port and returns the reply packet sent by the second VPN gateway to the first VPN gateway through the target session information, thereby achieving tunnel fault recovery. The random port is different from the original port used by the first VPN gateway to send the packet.

[0086] See Figure 3 This is a schematic flowchart of a VPN tunnel fault recovery method provided in an embodiment of this application. The fault recovery method is based on the VPN module at the data sending end and includes:

[0087] S101. Check if there are any VPN tunnels in an abnormal state that need to be restored;

[0088] If yes, then execute S102; otherwise, continue executing S101.

[0089] In this application, when performing VPN tunnel fault recovery operations, it is first necessary to check whether there are any VPN tunnels in an abnormal state awaiting recovery. Specifically, this application can obtain the health status of each tunnel from the status field in the tunnel information. If there are tunnels in an abnormal state, they are referred to as VPN tunnels awaiting recovery. The health status recorded in the status field of the tunnel information is controlled by probe packets. If no reply packet is received after sending probe packets multiple times through a tunnel, the health status of that tunnel is determined to be abnormal.

[0090] It should be noted that the S101-S103 process described in this application refers to the operation performed in any detection cycle. That is, in each detection cycle, the S101-S103 process is executed to check whether there is an abnormal VPN tunnel to be restored. If there is, the subsequent tunnel restoration operation continues. If there is no abnormal VPN tunnel to be restored, the process ends and waits for the next detection cycle to continue executing S101-S103. S102: Delete the session information of the VPN tunnel to be restored; S103: When the first VPN gateway corresponding to the VPN module sends the target packet through the VPN tunnel to be restored, it uses a random port as the source port to send the target packet to the router at the data receiving end, and the router sends the target packet to the second VPN gateway at the data receiving end. The router at the data receiving end generates target session information based on the random port and returns the reply packet sent by the second VPN gateway to the first VPN gateway through the target session information, thereby realizing the tunnel fault recovery. The random port is different from the original port used by the first VPN gateway to send the packet.

[0091] Understandably, if a VPN tunnel malfunctions due to a router at the data receiving end matching incorrect session information, this application requires that the router at the data receiving end match the correct session information when sending a reply message. To achieve this, this application adds a NAT rule to the VPN gateway or VPN module. This NAT rule is used to randomize the source port when the VPN gateway sends a message to the VPN tunnel to be restored. That is, when this application sends a target message through the VPN tunnel to be restored, the source port does not use the original port of the first VPN gateway, but a random port different from the original port of the first VPN gateway. In this way, the router at the data receiving end will generate new target session information based on the random port. When the second VPN gateway at the data receiving end sends a reply message to the router, the router will not match the incorrect session information, but will match the newly generated target session information. Thus, the reply message can be returned to the first VPN gateway through the target session information, thereby realizing the tunnel fault recovery.

[0092] Specifically, the router's session information matching mechanism is based on the five-tuple. Since the VPN protocol stipulates that the source IP, destination IP, and destination port cannot be changed, only the source port can be changed. Therefore, in case of an anomaly, this application can perform a random source port operation to change the source port of the packet sent by the first VPN gateway. As a result, at the router of the second VPN gateway, there is no need to match the original session information, but a new target session information will be formed, thus causing the network to return packets normally. For example, in the above embodiment, after the VPN gateway / VPN module of data center 1 discovers a VPN tunnel in an abnormal state that needs to be restored, the VPN gateway / VPN module of data center 1 performs source port randomization and uses the new random port as the source port to send a probe packet to data center 2. Since the source port has changed, after the probe packet is sent to the virtual router of data center 2, a new target session information will be generated, such as session 3. The source port in session 3 is the random port. Therefore, after the VPN gateway of data center 2 sends the reply packet to the virtual router of data center 2 with the random port, even if the virtual router of data center 2 has session 2, it will not match session 2 because the new random port is used. Instead, it will match the newly generated session 3.

[0093] The VPN gateway / VPN module that adds NAT rules in this application is a gateway / VPN module designed to resolve VPN tunnel anomalies caused by incorrect session matching. For example, in the above embodiment, the headquarters refers to the VPN gateway of data center 2, and the branch refers to the VPN gateway of data center 1. NAT rules need to be added to the VPN gateway at the branch. When implementing NAT rules, source port randomization can be achieved through iptables (user space configuration tool). Furthermore, the target packets sent in this application refer to probe packets and data packets; that is, this application only performs source port randomization when sending probe packets and transmitting data packets (destination ports are 500 and 4500).

[0094] In another embodiment of this application, deleting the session information of the VPN tunnel to be restored includes: querying the session information of the VPN tunnel to be restored from the first VPN gateway using a connection tracking tool, and deleting the session information of the VPN tunnel to be restored from the first VPN gateway using the connection tracking tool.

[0095] Specifically, the connection tracking tool is conntrack. This application uses conntrack to query session information corresponding to the VPN tunnel to be restored within the first VPN gateway and delete the queried session information so that the first VPN gateway can perform random source port operations through NAT rules.

[0096] It's important to note that, based on the router's session management mechanism, session information within the router has its own aging time, so older session information will be deleted after the timeout period. However, the kernel session management mechanism of the first VPN gateway means that session information will not be cleared for a period of time. That is, if the first VPN gateway has matching session information, it will prioritize sending packets through the matching session information. Therefore, after detecting the VPN tunnel to be restored, if the session information matching the VPN tunnel to be restored has not been cleared in time, the packets sent will still be sent according to the matching session information, and the operation of sending target packets using random ports cannot be achieved.

[0097] Therefore, in this application, in order to implement the operation of sending target packets using a random port, it is necessary to query whether the first VPN gateway has session information corresponding to the VPN tunnel to be restored. If so, the session information of the VPN tunnel to be restored needs to be deleted so that the target packets can be sent to the data receiving end using a random port.

[0098] In summary, in this application, when the VPN module at the data sending end detects a VPN tunnel in an abnormal state that needs to be restored, it needs to delete the session information of the VPN tunnel to be restored. This allows the target packet to be sent to the router at the data receiving end via a random port when sending the target packet through the VPN tunnel to be restored. The router then sends the target packet to the second VPN gateway at the data receiving end. The router can then generate new target session information based on the random port. When the reply packet sent by the second VPN gateway is forwarded at the router, it will not match the incorrect session information, but will match the correct target session information. This allows the VPN tunnel to quickly recover to normal and restore normal communication between the data sending end and the data receiving end in the event of a VPN tunnel abnormality caused by matching incorrect session information.

[0099] In another embodiment of this application, before checking whether there is a VPN tunnel in an abnormal state that needs to be restored, the method further includes: obtaining configuration information of a first VPN gateway; determining whether the main switch of the first VPN gateway is in an on state based on the configuration information; if it is in an on state, then performing the step of checking whether there is a VPN tunnel in an abnormal state that needs to be restored.

[0100] In this application, the first VPN gateway has a master switch. If the user configures the master switch of the first VPN gateway to be in the "on" state, then each VPN tunnel should not be in an abnormal state under normal circumstances. However, if the user configures the master switch of the first VPN gateway to be in the "off" state, then each VPN tunnel should be in an abnormal state under normal circumstances. Therefore, in this application, the configuration information of the first VPN gateway can be obtained to check the status of the master switch of the first VPN gateway. If it is in the "on" state, then fault recovery can be performed. If it is in the "off" state, it means that the user expects all tunnels to be abnormal. In this case, no recovery is required, and the user can be reminded to go to the master switch configuration page on the tunnel page and click to turn it on.

[0101] Furthermore, the process of checking whether the main switch of the first VPN gateway is on can also be performed after detecting any VPN tunnels in an abnormal state that need to be recovered. That is, firstly, the health status of each tunnel is queried to determine whether the tunnel is in an abnormal state. If it is in an abnormal state, it is added to the list of tunnels to be monitored. Then, it is determined whether the abnormal state of the tunnel is caused by configuration (e.g., the main switch is off). If it is caused by configuration, the abnormal state of the tunnel is considered normal. If it is not caused by tunnel configuration, subsequent operations are performed. However, in this application, in order to reduce the resource consumption of detecting abnormal tunnels, it can be set to be performed before checking whether there are any VPN tunnels in an abnormal state that need to be recovered. If it is on, then the step of checking whether there are any VPN tunnels in an abnormal state that need to be recovered is performed. If it is off, then the subsequent check process does not need to be performed, thereby reducing the consumption of check resources.

[0102] In another embodiment of this application, checking for the existence of a VPN tunnel in an abnormal state that needs to be recovered includes:

[0103] During each detection cycle, obtain the tunnel list of the first VPN gateway; traverse each VPN tunnel in the tunnel list to check if there is an abnormal VPN tunnel; the abnormal VPN tunnel refers to a tunnel whose health status is abnormal and is in the started state; if there is an abnormal VPN tunnel, determine whether the abnormal VPN tunnel is in the list of failed recovery tunnels; if not, the abnormal VPN tunnel is regarded as a VPN tunnel to be recovered.

[0104] In this application, a monitoring task can be added to the management service of the first VPN gateway. This monitoring task is a periodic task, and the period duration can be customized according to the needs. For example, the period duration can be set to 10 seconds, that is, the interval between different detection periods is 10 seconds. Each detection period needs to check whether there are any VPN tunnels in an abnormal state that need to be recovered, so as to perform fault recovery.

[0105] Specifically, if a VPN gateway has multiple VPN tunnels, the difficulty of troubleshooting can increase if some tunnels malfunction, especially when the number of tunnels is large. Therefore, in this application, a tunnel list of the first VPN gateway needs to be obtained during each detection cycle. This list contains all VPN tunnels of the VPN gateway. To improve the accuracy of troubleshooting, each VPN tunnel in the tunnel list can be traversed to check if there are any abnormal VPN tunnels. An abnormal VPN tunnel refers to a tunnel whose health status is abnormal but is still active. The health status can be determined by the `status` field in the tunnel information, and the active status can be determined by whether `enabled` is `True`. If `True`, the tunnel is active and requires fault recovery; if `enabled` is not `True`, the tunnel is not in use, its health status is abnormal, and no recovery is needed.

[0106] In another embodiment of this application, after sending the target message to the router at the data receiving end, the method further includes:

[0107] The health status of the VPN tunnel to be restored is queried a first predetermined number of times at a first preset time interval.

[0108] If the query results are all abnormal for the first predetermined number of consecutive times, the fault recovery fails, and the VPN tunnel to be recovered is determined to be a failed recovery tunnel, generating a fault reminder message.

[0109] In this application, after sending the target packet to the router at the data receiving end, it is also necessary to query the health status of the VPN tunnel to be restored for a first predetermined number of times at a first preset time interval. Here, the first preset time interval is the time interval between two consecutive health status queries, and the first predetermined number of queries is the total number of queries. The specific values ​​of the first preset time interval and the first predetermined number of queries can be customized as needed. For example, if the first preset time interval is set to 10 seconds and the first predetermined number of queries is 3, then the health status of the VPN tunnel to be restored is queried every 10 seconds, for a total of 3 consecutive queries, yielding 3 query results.

[0110] If the VPN tunnel failure was caused by matching incorrect session information after the recovery operation is performed, the VPN tunnel should return to normal. At least one of the first predetermined number of query results should be in a normal state to indicate that it has returned to normal. If all of the first predetermined number of query results are in an abnormal state, it means that the recovery has failed and the VPN tunnel failure was not caused by matching incorrect session information. In this case, the VPN tunnel to be recovered should be added to the recovery failure tunnel list as a recovery failure tunnel, and a failure reminder message can also be generated to remind the user.

[0111] Therefore, in this application, if an abnormal VPN tunnel is determined to exist, it is also necessary to determine whether the abnormal VPN tunnel is in the list of failed recovery tunnels. If the abnormal VPN tunnel is in the list of failed recovery tunnels, it means that the abnormality of the abnormal VPN tunnel is not due to the matching of incorrect session information, and it does not need to be treated as a VPN tunnel to be recovered. If the abnormal VPN tunnel is not in the list of failed recovery tunnels, it is then treated as a VPN tunnel to be recovered.

[0112] In summary, this application, by traversing the tunnel list, can check each VPN tunnel one by one when there are multiple VPN tunnels in the VPN gateway, avoiding missing faulty tunnels and improving the accuracy of fault diagnosis. Furthermore, by matching the VPN tunnel to be recovered with the failed recovery tunnel, this application can avoid restoring the VPN tunnel to be recovered if the failure is not caused by matching incorrect session information, thus saving recovery resources.

[0113] In another embodiment of this application, before determining whether an abnormal VPN tunnel is in the list of failed recovery tunnels, the method further includes: in each inspection cycle, determining whether the number of inspections of each failed recovery tunnel in the list of failed recovery tunnels exceeds a predetermined number; if so, deleting the failed recovery tunnels whose number of inspections exceeds the predetermined number from the list of failed recovery tunnels.

[0114] In this application, each failed recovery tunnel is not permanently stored in the failed recovery tunnel list. The failed recovery tunnels in the list only represent tunnels that do not require recovery via random source port for a certain period. If this period expires, it indicates that the tunnels in the list may have already recovered from their failures, and there may also be anomalies due to mismatched session information. Therefore, this application sets a check count for each failed recovery tunnel in the list. This check count is updated with each check cycle. For example, after adding a failed recovery tunnel to the list, its check count is 1 after one check cycle, 2 after two check cycles, and so on. This application also sets a predetermined number of checks per cycle. If the number of checks for a failed recovery tunnel in the failed recovery tunnel list exceeds this predetermined number, it means that the failed recovery tunnel has not been recovered by this solution within the predetermined number of check cycles. At this time, the tunnel may have already repaired the fault, or it may have caused an anomaly due to matching incorrect session information. Therefore, in each detection cycle, if the number of checks for a failed recovery tunnel exceeds the predetermined number, this application will delete the failed recovery tunnel from the failed recovery tunnel list. In this way, if the tunnel fails, it will not be ignored because it matches a tunnel in the failed recovery tunnel list.

[0115] As can be seen, by adding the number of checks to each failed tunnel in the list of failed tunnels, this application can remove the failed tunnel from the list of failed tunnels after a period of time after a tunnel recovery failure, so that the fault can be recovered in a timely manner in the event of a tunnel failure.

[0116] In another embodiment of this application, if the abnormal VPN tunnel is not in the list of failed recovery tunnels, the fault recovery method further includes: querying the health status of the abnormal VPN tunnel a second predetermined number of times at a second preset time interval; if the query results for the second predetermined number of times are all abnormal, then performing the step of treating the abnormal VPN tunnel as a VPN tunnel to be recovered.

[0117] In this application, if an abnormal VPN tunnel is detected but not in the list of failed recovery tunnels, it indicates that the abnormal tunnel did not fail to recover within a certain period. In this case, before adding the abnormal VPN tunnel as a VPN tunnel to be recovered, the cause of the abnormality can be determined by repeatedly checking its health status, such as whether it is due to mismatched session information. Therefore, this application allows setting a list of tunnels to be monitored. If an abnormal VPN tunnel is not in the list of failed recovery tunnels, it is added to the list, and monitoring begins. If a tunnel is already in the list of tunnels to be monitored, it does not need to be monitored again in the next periodic monitoring task.

[0118] For each abnormal VPN tunnel in the list of tunnels to be monitored, the health status of the abnormal VPN tunnel is queried a second predetermined number of times at a second preset time interval. The second preset time interval is the time interval between two consecutive health status checks, and the second predetermined number of queries is the total number of queries. The specific values ​​of the second preset time interval and the second predetermined number of queries can be customized as needed; they can be the same as or different from the first preset time interval and the first predetermined number of queries. For example, if the second preset time interval is set to 10 seconds and the second predetermined number of queries is 3, then the health status of the abnormal VPN tunnel will be queried every 10 seconds, for a total of 3 consecutive queries, yielding 3 query results.

[0119] If at least one query result in the second predetermined number of queries is in a normal state, it indicates that the abnormal VPN tunnel is not abnormal due to mismatched session information, and there is no need to list the abnormal VPN tunnel as a VPN tunnel to be restored. If the tunnel status in the query results is consistently abnormal, it indicates that the abnormal VPN tunnel is more likely to be abnormal due to mismatched session information. In this case, the abnormal VPN tunnel can be listed as a VPN tunnel to be restored and added to the list of tunnels to be restored. In the monitoring list of tunnels to be restored, the session of the VPN tunnel to be restored needs to be disconnected and residual session information needs to be cleared using the conntrack tool in the VPN gateway kernel. This will cause the target packets sent by the VPN gateway tunnel to be resent. Since NAT rules are configured in the VPN gateway / VPN module, the source port of the target packets sent through the VPN tunnel to be restored will be replaced by a random port. The router at the data receiving end will generate a new session without further matching the residual session in the router, and the tunnel will eventually be restored.

[0120] As can be seen, this application adds a monitoring process for VPN tunnels within the VPN gateway / VPN module. When a tunnel becomes abnormal, the VPN gateway / VPN module uses a mechanism to monitor VPN tunnels in real time, utilizing VPN tunnel health status, configuration information, etc., to add the detected abnormal VPN tunnels to the list of those to be monitored and those to be recovered. For VPN tunnels to be recovered, the conntrace tool is used to quickly clean up the session to form a new session with a random source port, thereby achieving tunnel fault recovery.

[0121] See Figure 4 The figure shows a schematic diagram of the tunnel monitoring process provided in an embodiment of this application. The tunnel monitoring process specifically includes the following:

[0122] S1: Periodic tasks need to initialize the following variables: need_monitor_tunnel_ids (list of tunnels to be monitored), check_times (number of checks), restore_failed_tunnel_ids (list of tunnels that failed to be restored).

[0123] When the periodic task executes the tunnel monitoring process for the first time, it needs to initialize the list of tunnels to be monitored, the number of checks, and the list of tunnels that failed to recover, so that they can be used in subsequent processes.

[0124] S2: Periodic task begins execution, running once every 10 seconds;

[0125] S3: Determine if check_times is 36;

[0126] If yes, continue with S4; otherwise, increment check_times and continue with S5.

[0127] S4: Set check_times to 0 and check if restore_failed_tunnel_ids is not empty; if it is not empty, clear the contents of restore_failed_tunnel_ids and execute S5; if it is empty, execute S5.

[0128] In this embodiment, the recovery failure tunnels stored in `restore_failed_tunnel_ids` are tunnels that cannot be successfully repaired using this solution. Therefore, in the subsequent S8, if the abnormal tunnel is in `restore_failed_tunnel_ids`, it does not need to be restored. This application sets a predetermined number of checks to 35. At the 36th check when `check_times` exceeds 35, the recovery failure tunnel in the recovery failure tunnel list needs to be deleted, and `check_times` should be set to 0. If it does not exceed 35, i.e., when `check_times` is between 0 and 35, there is no need to clear the recovery failure tunnel list; instead, the check count `check_times` needs to be incremented by one. It should be noted that in this embodiment, only a single recovery failure tunnel in the recovery failure tunnel list is used as an example. If the check counts of each recovery failure tunnel in the recovery failure tunnel list are different, then S3-S4 need to be executed separately for each recovery failure tunnel's check count. When clearing `restore_failed_tunnel_ids`, only the tunnel with a check count of 36 is deleted.

[0129] S5: Check the main switch of the VPN gateway; if it is off, end the process and no further steps are required; if it is not off, proceed to S6.

[0130] S6: Query the list of tunnels in the current VPN gateway, traverse the tunnels, if there are any untraversed tunnels, then execute S7; if all tunnels have been traversed, then execute S11.

[0131] S7: Check if the enabled value of the traversed tunnel is True and if its status is abnormal; if not, proceed to S6; if yes, determine it as an abnormal tunnel and proceed to S8.

[0132] S8: Check if the abnormal tunnel is in need_monitor_tunnel_ids or restore_failed_tunnel_ids; if it is in one of the lists, execute S6; if it is not in either list, execute S9.

[0133] S9: Add the ID of the abnormal tunnel to need_monitor_tunnel_ids; start the monitoring task with need_monitor_tunnel_ids as the input parameter; iterate through the tunnel information every 10 seconds, count the tunnels, and check the tunnel status;

[0134] S10: Check if the tunnel status of the monitored abnormal tunnel is abnormal for three consecutive times; if not, remove the restored tunnel ID from need_monitor_tunnel_ids; if so, add the abnormal tunnel to need_restore_tunnel_ids (the list of tunnels that need to be restored).

[0135] S11: After the traversal is complete, check if need_restore_tunnel_ids is empty; if it is, end the process and wait for the next cycle task; if not, execute S12.

[0136] S12: Start executing the tunnel restoration task, with the input parameters being each tunnel in need_restore_tunnel_ids; query the tunnel session using the conntrack tool, and delete the tunnel session using the conntrack tool;

[0137] S13: Traverse each tunnel in need_restore_tunnel_id, check if the health status of each tunnel is normal, retry three times, with an interval of 10 seconds each time; if all three times are abnormal, execute S14; otherwise, execute S15.

[0138] S14: Add the failed tunnels to restore_failed_tunnel_ids;

[0139] S15: Remove the restored tunnel from need_monitor_tunnel_id and remove the restored tunnel from need_restore_tunnel_ids;

[0140] S16. If all tunnels in need_restore_tunnel_id have been traversed, the process ends; otherwise, S13 is executed.

[0141] See Figure 5 The figure shows a VPN monitoring and management timing diagram provided in this embodiment of the application. The execution entities of this process include monitoring tasks within the VPN network management system, the VPN configuration database, and the VPN gateway kernel. The process includes the following:

[0142] Initialization process: Initialize the monitoring task, check whether the tunnel needs to be monitored, and if so, initialize the environment. Among them, environment initialization is a key step to build the basic operating conditions for subsequent tunnel status query, anomaly handling and other operations. Its core function is to complete the necessary configuration and resource preparation before the monitoring task starts, and ensure that the subsequent process can be executed stably and efficiently.

[0143] Tunnel status query process: Call the interface to query all VPN tunnels from the VPN configuration database, and the VPN configuration database returns the VPN tunnels; Call the interface to query whether the VPN tunnel status is normal from the VPN gateway kernel; The VPN gateway kernel returns the VPN tunnel status.

[0144] Tunnel monitoring process: Filter abnormal VPN tunnels and add them to the monitoring list; continuously monitor abnormal VPN tunnels and obtain real-time tunnel information. This process requires calling an interface to query the VPN gateway kernel to check if the VPN tunnel status is normal; the VPN gateway kernel returns the VPN tunnel status; filter out persistently abnormal VPN tunnels and add them to the list to be restored.

[0145] Fault recovery process: Call the contract to attempt to restore the VPN tunnel state; the VPN gateway kernel returns the VPN tunnel state. If it is restored to normal, record the VPN tunnel state as normal, call the interface to update the restored VPN tunnel state, and return the VPN tunnel.

[0146] In summary, when a VPN gateway establishes network connectivity across data centers via a VPN tunnel, the presence of numerous network elements across these data centers increases the likelihood of VPN tunnel anomalies. To address this, this application, after analyzing the principles of the VPN protocol, proposes a method to monitor the health status of VPN tunnels. Upon discovering a VPN tunnel in an abnormal state awaiting recovery, the application resets the session of the tunnel and drives it to resend packets via random operations on the source port. This enables self-recovery of VPN tunnel anomalies in the managed cloud environment, improving the reliability of the platform's VPN gateway without impacting business operations and enhancing the overall reliability of the VPN tunnel.

[0147] The fault recovery device provided in the embodiments of this application is described below. The fault recovery device described below and the fault recovery method described above can be referred to each other.

[0148] See Figure 6 , Figure 6 A fault recovery device for a VPN tunnel provided in this application embodiment, the fault recovery device is based on the VPN module of the data sending end, and the fault recovery device includes:

[0149] Tunnel inspection module 11 is used to check whether there are any VPN tunnels in an abnormal state that need to be restored; if so, the first deletion module is triggered.

[0150] The first deletion module 12 is used to delete the session information of the VPN tunnel to be restored;

[0151] The sending module 13 is used to send the target packet to the router of the data receiving end by using a random port as the source port when the first VPN gateway corresponding to the VPN module sends the target packet through the VPN tunnel to be restored, and then sends the target packet to the second VPN gateway of the data receiving end through the router.

[0152] The router at the data receiving end generates target session information based on the random port and returns the reply message sent by the second VPN gateway to the first VPN gateway through the target session information, thereby realizing tunnel fault recovery; the random port is different from the original port used by the first VPN gateway to send the message.

[0153] As an optional embodiment, the device further includes:

[0154] The configuration acquisition module is used to acquire the configuration information of the first VPN gateway before checking whether there is an abnormal VPN tunnel to be recovered;

[0155] The configuration check module is used to determine whether the main switch of the first VPN gateway is in the on state based on the configuration information; if it is in the on state, the tunnel check module is triggered.

[0156] As an optional embodiment, the device further includes:

[0157] The first query module is used to query the health status of the VPN tunnel to be restored a first predetermined number of times at a first preset time interval after the sending module sends the target message to the router of the data receiving end.

[0158] The determination module is used to determine that the VPN tunnel to be restored is a failed recovery tunnel if the query results are all abnormal for a first predetermined number of consecutive times and the fault recovery fails.

[0159] The information generation module is used to generate fault reminder information when fault recovery fails.

[0160] As an optional embodiment, the first deletion module is specifically used to: query the session information of the VPN tunnel to be restored from the first VPN gateway through a connection tracking tool, and delete the session information of the VPN tunnel to be restored from the first VPN gateway through the connection tracking tool.

[0161] As an optional embodiment, the tunnel inspection module includes:

[0162] The acquisition unit is used to acquire the tunnel list of the first VPN gateway in each detection cycle;

[0163] The query unit is used to traverse each VPN tunnel in the tunnel list and query whether there is an abnormal VPN tunnel; the abnormal VPN tunnel refers to a tunnel whose health status is abnormal and is in the started state.

[0164] The judgment unit is used to determine whether the abnormal VPN tunnel is in the list of failed recovery tunnels when an abnormal VPN tunnel exists; if not, the abnormal VPN tunnel is regarded as a VPN tunnel to be recovered.

[0165] As an optional embodiment, the device further includes:

[0166] The judgment module is used to determine, in each inspection cycle, whether the number of inspections of each failed recovery tunnel in the list of failed recovery tunnels exceeds a predetermined number; if so, the second deletion module is triggered.

[0167] The second deletion module is used to delete recovery failure tunnels that have been checked more than a predetermined number of times from the recovery failure tunnel list.

[0168] As an optional embodiment, the device further includes:

[0169] The second query module is used to query the health status of the abnormal VPN tunnel a second predetermined number of times at a second preset time interval when the abnormal VPN tunnel is not in the list of failed recovery tunnels; if the query results for the second predetermined number of times are all abnormal, then the abnormal VPN tunnel is regarded as a VPN tunnel to be recovered.

[0170] Figure 7 A structural diagram of an electronic device provided in an embodiment of the present invention is shown in the figure, comprising:

[0171] Memory 20 is used to store computer programs;

[0172] The processor 21 is used to execute a computer program to implement the steps of the fault recovery method as described in the above embodiments.

[0173] The electronic devices provided in this embodiment may include, but are not limited to, smartphones, tablets, laptops, or desktop computers.

[0174] The processor 21 may include one or more processing cores, such as a quad-core processor or an octa-core processor. The processor 21 may be implemented using at least one hardware form selected from Digital Signal Processing (DSP), Field-Programmable Gate Array (FPGA), and Programmable Logic Array (PLA). The processor 21 may also include a main processor and a coprocessor. The main processor, also known as the Central Processing Unit (CPU), is used to process data in the wake-up state; the coprocessor is a low-power processor used to process data in the standby state. In some embodiments, the processor 21 may integrate a Graphics Processing Unit (GPU), which is responsible for rendering and drawing the content to be displayed on the screen. In some embodiments, the processor 21 may also include an Artificial Intelligence (AI) processor, which handles computational operations related to machine learning.

[0175] The memory 20 may include one or more computer-readable storage media, which may be non-transitory. The memory 20 may also include high-speed random access memory and non-volatile memory, such as one or more disk storage devices or flash memory devices. In this embodiment, the memory 20 is used to store at least the following computer program 201, which, after being loaded and executed by the processor 21, is capable of implementing the relevant steps of the fault recovery method disclosed in any of the foregoing embodiments. In addition, the resources stored in the memory 20 may also include an operating system 202 and data 203, and the storage method may be temporary storage or permanent storage. The operating system 202 may include Windows, Unix, Linux, etc.

[0176] In some embodiments, the electronic device may further include a display screen 22, an input / output interface 23, a communication interface 24, a power supply 25, and a communication bus 26.

[0177] Those skilled in the art will understand that Figure 7 The structures shown do not constitute a limitation on electronic devices and may include more or fewer components than those shown.

[0178] In another exemplary embodiment, a computer storage medium is also provided, wherein the program instructions, when executed by a processor, implement the steps of the data deduplication method described in any of the above method embodiments.

[0179] It is understood that if the fault recovery method in the above embodiments is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present invention, in essence, or the part that contributes to the current technology, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and executes all or part of the steps of the methods in the various embodiments of the present invention. The aforementioned storage medium includes: USB flash drive, mobile hard drive, read-only memory (ROM), random access memory (RAM), electrically erasable programmable ROM, register, hard disk, removable disk, CD-ROM, magnetic disk or optical disk, and other media capable of storing program code.

[0180] The various embodiments described in this specification are presented in a progressive manner, with each embodiment focusing on its differences from other embodiments. Similar or identical parts between embodiments can be referred to interchangeably. It should be understood that the terminology used herein is for the purpose of describing particular exemplary embodiments only and is not intended to be limiting. Unless the context clearly indicates otherwise, the singular forms “a,” “an,” and “described” used herein may also mean the plural forms. The terms “comprising,” “including,” “containing,” and “having” are inclusive and therefore indicate the presence of the stated features, steps, operations, elements, and / or components, but do not exclude the presence or addition of one or more other features, steps, operations, elements, components, and / or combinations thereof. The method steps, processes, and operations described herein are not construed as requiring them to be performed in a specific order described or illustrated, unless the order of performance is explicitly indicated. It should also be understood that additional or alternative steps may be used.

[0181] It should be understood that although the steps in the flowcharts of the accompanying figures are shown sequentially as indicated by the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless explicitly stated herein, there is no strict order restriction on the execution of these steps, and they can be executed in other orders. Moreover, at least some steps in the flowcharts of the accompanying figures may include multiple sub-steps or multiple stages. These sub-steps or stages are not necessarily completed at the same time, but can be executed at different times, and their execution order is not necessarily sequential, but can be performed alternately or in turn with other steps or at least some of the sub-steps or stages of other steps.

[0182] The above are only some embodiments of this application. It should be noted that for those skilled in the art, several improvements and modifications can be made without departing from the principle of this application, and these improvements and modifications should also be considered within the scope of protection of this application.

Claims

1. A method for fault recovery of a VPN tunnel, characterized in that, The fault recovery method is based on the VPN module at the data sending end, and includes: Check for any VPN tunnels in an abnormal state that are awaiting recovery; If it exists, delete the session information of the VPN tunnel to be restored; When the first VPN gateway corresponding to the VPN module sends a target packet through the VPN tunnel to be restored, it uses a random port as the source port to send the target packet to the router at the data receiving end, and then the router sends the target packet to the second VPN gateway at the data receiving end. The router at the data receiving end generates target session information based on the random port and returns the reply packet sent by the second VPN gateway to the first VPN gateway through the target session information, thereby achieving tunnel fault recovery. The random port is different from the original port used by the first VPN gateway to send the packet.

2. The fault recovery method according to claim 1, characterized in that, Before checking for the existence of VPN tunnels in an abnormal state that need to be restored, the following steps are also included: Obtain the configuration information of the first VPN gateway; Determine whether the main switch of the first VPN gateway is in the on state based on the configuration information; If enabled, the step of checking for any VPN tunnels in an abnormal state that need to be restored is performed.

3. The fault recovery method according to claim 1, characterized in that, After sending the target message to the router at the data receiving end, the process also includes: The health status of the VPN tunnel to be restored is queried a first predetermined number of times at a first preset time interval. If the query results are all abnormal for the first predetermined number of consecutive times, the fault recovery fails, and the VPN tunnel to be recovered is determined to be a failed recovery tunnel, generating a fault reminder message.

4. The fault recovery method according to claim 1, characterized in that, Deleting the session information of the VPN tunnel to be restored includes: Using a connection tracking tool, query the session information of the VPN tunnel to be restored from the first VPN gateway, and delete the session information of the VPN tunnel to be restored from the first VPN gateway using the connection tracking tool.

5. The fault recovery method according to any one of claims 1 to 4, characterized in that, The check for the existence of VPN tunnels in an abnormal state that need to be restored includes: In each detection cycle, obtain the tunnel list of the first VPN gateway; Iterate through each VPN tunnel in the tunnel list to check if there are any abnormal VPN tunnels; the abnormal VPN tunnel refers to a tunnel whose health status is abnormal but is in the started state. If an abnormal VPN tunnel exists, determine whether the abnormal VPN tunnel is in the list of failed recovery tunnels; If not, the abnormal VPN tunnel will be treated as a VPN tunnel awaiting recovery.

6. The fault recovery method according to claim 5, characterized in that, Before determining whether the abnormal VPN tunnel is in the list of failed tunnel recovery, the process also includes: In each inspection cycle, it is determined whether the number of inspections for each failed recovery tunnel in the list of failed recovery tunnels exceeds a predetermined number; If so, the recovery failure tunnel that has been checked more than the predetermined number of times will be removed from the recovery failure tunnel list.

7. The fault recovery method according to claim 5, characterized in that, If the abnormal VPN tunnel is not in the list of failed tunnel recovery attempts, the fault recovery method further includes: The health status of the abnormal VPN tunnel is queried a second predetermined number of times at a second preset time interval. If the query results are all abnormal for the second predetermined number of consecutive times, then the step of treating the abnormal VPN tunnel as a VPN tunnel to be restored is executed.

8. A VPN tunnel fault recovery device, characterized in that, The fault recovery device is based on the VPN module of the data sending end, and the fault recovery device includes: The tunnel inspection module is used to check for the existence of VPN tunnels in an abnormal state that need to be restored; if one exists, the first deletion module is triggered. The first deletion module is used to delete the session information of the VPN tunnel to be restored; The sending module is used to send the target packet to the router of the data receiving end by using a random port as the source port when the first VPN gateway corresponding to the VPN module sends the target packet through the VPN tunnel to be restored; and then sends the target packet to the second VPN gateway of the data receiving end through the router. The router at the data receiving end generates target session information based on the random port and returns the reply message sent by the second VPN gateway to the first VPN gateway through the target session information, thereby realizing tunnel fault recovery; the random port is different from the original port used by the first VPN gateway to send the message.

9. An electronic device, characterized in that, include: Memory, used to store computer programs; A processor, configured to implement the steps of the fault recovery method as described in any one of claims 1 to 7 when executing the computer program.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that, when executed by a processor, implements the steps of the fault recovery method as described in any one of claims 1 to 7.

Images