Network tunnel creation method and device, computer equipment and readable storage medium

Abstract

The embodiment of the invention provides a network tunnel creation method and device, computer equipment and a readable storage medium. The method comprises the following steps: acquiring a tunnel configuration file, wherein the tunnel configuration file at least comprises a tunnel creation type, a plurality of tunnel creation steps and constraint information; converting the tunnel configuration file into target configuration information; analyzing constraint information in the target configuration information according to a preset constraint meta statement to obtain a logic constraint parameter, and generating a logic object according to the target configuration information and the logic constraint parameter; a task queue is generated based on each tunnel creation step in the logic object and the corresponding logic constraint parameter through a target reflection mechanism, the task queue comprises a plurality of creation sub-tasks with a sorting relationship, and each creation sub-task corresponds to one tunnel creation step; and sequentially executing each creation sub-task in the task queue to create the network tunnel of the tunnel creation type. Therefore, the configuration efficiency in the network tunnel creation process can be improved.

Description

Technical Field

[0001] The present application relates to the field of network communication technology, and in particular to a method, apparatus, computer device, and readable storage medium for establishing a network tunnel. Background Art

[0002] Tunneling technology is a technique used to create and manage virtual channels within a network, designed to securely transmit data over public networks such as the internet. It establishes an encrypted tunnel between two ends, encapsulating data packets for transmission and ensuring the privacy and integrity of data during transmission. Tunneling technology is commonly used in scenarios such as virtual private networks (VPNs), data center interconnections, and remote access. It effectively hides users' real Internet Protocol addresses, protects sensitive information, and bypasses geographic restrictions, providing a more secure and flexible network connection solution.

[0003] In the related art, network tunnel configuration typically relies on traditional manual configuration solutions or semi-automated secure tunnel configuration software. Specifically, these methods require administrators to manually define the detailed configuration of each tunnel, including port numbers, and when multiple related tunnels and their complex inter-constraints are involved, these configurations must also be manually adjusted to ensure consistency, which reduces configuration efficiency. Summary of the Invention

[0004] The embodiments of the present application provide a network tunnel creation method, apparatus, computer equipment, and readable storage medium, which can improve the configuration efficiency during the network tunnel creation process.

[0005] Obtain a tunnel configuration file, where the tunnel configuration file includes at least a tunnel creation type, multiple tunnel creation steps, and constraint information;

[0006] Converting the tunnel configuration file into target configuration information corresponding to the target format;

[0007] Parsing the constraint information in the target configuration information according to the preset constraint meta-statement to obtain logical constraint parameters, and generating a logical object according to the target configuration information and the logical constraint parameters;

[0008] Generate a task queue based on each tunnel creation step in the logic object and the corresponding logic constraint parameters through a target reflection mechanism, wherein the task queue includes a plurality of creation subtasks having an ordering relationship, and each creation subtask corresponds to a tunnel creation step;

[0009] Each creation subtask in the task queue is executed in sequence to create a network tunnel of the tunnel creation type.

[0010] Accordingly, a second aspect of an embodiment of the present application provides a network tunnel creation device, the device comprising:

[0011] An acquisition module, configured to acquire a tunnel configuration file, wherein the tunnel configuration file includes at least a tunnel creation type, multiple tunnel creation steps, and constraint information;

[0012] A conversion module, configured to convert the tunnel configuration file into target configuration information corresponding to a target format;

[0013] a parsing module, configured to parse the constraint information in the target configuration information according to a preset constraint meta-statement, obtain logical constraint parameters, and generate a logical object according to the target configuration information and the logical constraint parameters;

[0014] a generation module, configured to generate a task queue based on each tunnel creation step in the logic object and the corresponding logical constraint parameters through a target reflection mechanism, wherein the task queue includes a plurality of creation subtasks having an ordered relationship, and each creation subtask corresponds to a tunnel creation step;

[0015] The creation module is used to execute each creation subtask in the task queue in sequence to create a network tunnel of the tunnel creation type.

[0016] In some embodiments, the generating module is further configured to:

[0017] Mapping each tunnel creation step in the logic object through a target reflection mechanism to determine a target execution function for executing each tunnel creation step;

[0018] Determining target logical object parameters corresponding to each tunnel creation step from the logical object, and generating a creation subtask for each tunnel creation step according to the target execution function and the target logical object parameters;

[0019] Based on the multiple creation subtasks corresponding to the multiple tunnel creation steps included in the tunnel creation type, a corresponding task queue is generated.

[0020] In some embodiments, the generating module is further configured to:

[0021] Based on each creation subtask corresponding to each tunnel creation step included in the tunnel creation type, labeling the corresponding subtask identifier, the queue identifier of the corresponding task queue, the position code in the corresponding task queue, and the subtask status, to obtain the labeled creation subtask;

[0022] The corresponding task queue is constructed according to multiple creation subtasks in sequence.

[0023] In some embodiments, the creation module is further configured to:

[0024] Determine multiple corresponding candidate devices by sequentially performing tunnel creation steps corresponding to each creation subtask;

[0025] Determine a target device from the plurality of candidate devices based on the target logical object parameters included in each creation subtask;

[0026] generating a corresponding execution instruction according to each creation subtask, and sending the execution instruction to the target device, so that the target device executes the corresponding creation subtask based on the execution instruction;

[0027] When the last creation subtask in the task queue is completed, a network tunnel of the tunnel creation type is created.

[0028] In some embodiments, the creation module is further configured to:

[0029] receiving a callback function triggered by a device interface of a target device, wherein the callback function is triggered by the target device after completing execution of each created subtask according to the execution instruction, and the callback function includes the execution result of the target device for each created subtask;

[0030] When the execution result indicates that the target device fails to execute the creation subtask, updating the creation subtask based on the constraint information to obtain a target creation subtask;

[0031] Based on the target creation subtask, the task queue is updated, and the task queue is rolled back to execute the remaining task of the target creation subtask.

[0032] In some embodiments, the parsing module is further configured to:

[0033] Parsing the constraint information in the target configuration information according to the preset constraint meta-statement to obtain the logical parameter name and constraint parsing information corresponding to each constraint item contained in the constraint information;

[0034] Perform parameter polling and allocation based on the constraint parsing information corresponding to each logical parameter name to obtain a configuration parameter value;

[0035] A logical object parameter is generated based on the combination of the logical parameter name and the configuration parameter value.

[0036] In some embodiments, the parsing module is further configured to:

[0037] Create initial logical objects;

[0038] According to the target configuration information, at least one tunnel creation step corresponding to each tunnel creation type is read, and based on the tunnel creation type, the at least one tunnel creation step, and the logical object parameters contained in each tunnel creation step, the initial logical object is filled to generate a generated logical object corresponding to each tunnel creation type.

[0039] Correspondingly, the third aspect of the embodiments of the present application proposes a computer device, which includes a memory and a processor, the memory stores a computer program, and when the processor executes the computer program, it implements the network tunnel creation method of any one of the embodiments of the first aspect of the present application.

[0040] Correspondingly, the fourth aspect of the embodiments of the present application proposes a computer-readable storage medium, which stores a computer program. When the computer program is executed by a processor, it implements the network tunnel creation method of any one of the embodiments of the first aspect of the present application.

[0041] The embodiment of the present application obtains a tunnel configuration file, which includes at least a tunnel creation type, multiple tunnel creation steps, and constraint information; converts the tunnel configuration file into target configuration information corresponding to a target format; parses the constraint information in the target configuration information according to preset constraint metastatements to obtain logical constraint parameters, and generates a logical object based on the target configuration information and the logical constraint parameters; generates a task queue based on each tunnel creation step and the corresponding logical constraint parameters in the logical object through a target reflection mechanism, the task queue containing multiple creation subtasks with an ordered relationship, each creation subtask corresponding to a tunnel creation step; and sequentially executes each creation subtask in the task queue to create a network tunnel of the tunnel creation type. In this way, the user-provided tunnel configuration file can be automatically constrained and parsed, effectively solving the problem of manually coordinating complex constraint relationships between multiple tunnels. At the same time, the reflection mechanism dynamically generates an ordered task queue, converting discrete creation steps into atomic operations that can be serialized and executed. This not only avoids configuration conflicts that may be caused by manually defining parameters such as port numbers, but also eliminates the workload of manually adjusting the configuration order through the automatic sorting mechanism of the task queue, thereby significantly improving the configuration efficiency of the network tunnel creation process while ensuring configuration consistency. BRIEF DESCRIPTION OF THE DRAWINGS

[0042] Figure 1 This is a schematic diagram of the architecture of the network tunnel creation system provided in an embodiment of the present application;

[0043] Figure 2 This is a flow chart of a method for establishing a network tunnel provided by an embodiment of the present application;

[0044] Figure 3 This is a flowchart of generating a logical object provided by an embodiment of the present application;

[0045] Figure 4 This is a general flow chart of generating a task queue provided by an embodiment of the present application;

[0046] Figure 5 This is a flowchart of the execution task queue provided by an embodiment of the present application;

[0047] Figure 6 This is a schematic diagram of the functional modules of the network tunnel creation device provided in an embodiment of the present application;

[0048] Figure 7 This is a schematic diagram of the hardware structure of the computer device provided in the embodiment of the present application. DETAILED DESCRIPTION

[0049] In order to make the purpose, technical solutions and advantages of this application more clearly understood, the present application is further described in detail below with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are only used to explain this application and are not intended to limit this application.

[0050] It should be noted that although the device schematics illustrate functional module divisions and the flowcharts illustrate logical sequences, in certain circumstances, the steps shown or described may be performed in a sequence that differs from the module divisions in the device or the sequence in the flowcharts. The terms "first," "second," and so on, in the specification, claims, and drawings, are used to distinguish similar items and are not necessarily used to describe a specific sequence or precedence.

[0051] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by those skilled in the art to which this application pertains. The terms used herein are for the purpose of describing the embodiments of this application only and are not intended to limit this application.

[0052] Tunneling technology is a technique used to create and manage virtual channels within a network, designed to securely transmit data over public networks such as the internet. It establishes an encrypted tunnel between two ends, encapsulating data packets for transmission and ensuring the privacy and integrity of data during transmission. Tunneling technology is commonly used in scenarios such as virtual private networks (VPNs), data center interconnections, and remote access. It effectively hides users' real Internet Protocol addresses, protects sensitive information, and bypasses geographic restrictions, providing a more secure and flexible network connection solution.

[0053] In the related art, network tunnel configuration typically relies on traditional manual configuration solutions or semi-automated secure tunnel configuration software. Specifically, these methods require administrators to manually define the detailed configuration of each tunnel, including port numbers, and when multiple related tunnels and their complex inter-constraints are involved, these configurations must also be manually adjusted to ensure consistency, which reduces configuration efficiency.

[0054] Based on this, the embodiments of the present application provide a network tunnel creation method, apparatus, computer equipment and readable storage medium, which can improve the configuration efficiency during the network tunnel creation process.

[0055] The network tunnel creation method, apparatus, computer device, and readable storage medium provided in the embodiments of the present application are specifically illustrated through the following embodiments. First, the network tunnel creation system in the embodiments of the present application is described.

[0056] Please refer to Figure 1 In some implementations, an embodiment of the present application provides a network tunnel creation system.

[0057] Exemplarily, the network tunnel creation system adopts a layered design, which is divided into an application layer 11, an implementation layer 12, and an infrastructure layer 13. The modules at each layer work together to implement the network tunnel creation method. The following is a detailed description of the network tunnel creation system:

[0058] Exemplarily, the application layer 11 serves as a user interaction portal and provides tunnel full lifecycle management functions. It includes a tunnel creation module 111, a tunnel status management module 112, and a tunnel replay module 113. Among them, the tunnel creation module 111 supports one-click creation of single-range, multi-range, and multi-type tunnels. Users can define the tunnel creation type, tunnel creation steps, and constraint information through the tunnel configuration file. Furthermore, the tunnel status management module 112 can be used to implement batch query of tunnel status and locate the cause of failure during the tunnel creation process. Furthermore, the tunnel replay module 113 can provide failed task retry and tunnel reconstruction functions based on the callback function mechanism, and implement error rollback and process recovery by updating the task queue.

[0059] Specifically, the implementation layer 12 can be the core logic processing layer of the system, including a configuration parsing module 121, a task queue generation module 122, and an execution module 123. Exemplarily, the configuration parsing module 121 can parse the tunnel configuration file provided by the user into a JSON object (that is, the target configuration information corresponding to the target format), and parse the parameter constraints according to the preset constraint meta-statements (such as Param, Team, ALL, etc.) to generate a logical object. The configuration parsing module 121 can bind cross-tunnel dependent parameters (such as bridgeId) to the Params field of the logical object through parameter mapping rules to ensure that the constraint information takes effect in subsequent processes.

[0060] Furthermore, the task queue generation module 122 of the implementation layer 12 can use the Java reflection mechanism (i.e., the target reflection mechanism) to map each tunnel creation step in the logical object into a creation subtask (AtomicTask), and generate a task queue based on the step sequence. Each creation subtask is annotated with a subtask identifier, a queue identifier, and a position code, and is bound to a specific execution function of the device interface (e.g., create_wireguard_tunnel()), forming a persistent task queue.

[0061] For example, the execution module 123 of the implementation layer 12 can sequentially execute the creation subtasks in the task queue and send instructions (such as WireGuard / VXLAN configuration commands) to the target device through the southbound interface. The instruction execution results are fed back through a callback function. If a failure occurs, the task update and queue rollback are triggered, ultimately completing the tunnel creation and updating the pipeline status.

[0062] For example, infrastructure layer 13 can be a bottom-level support system, including device interface 131 and storage system 132. Specifically, device interface 131 can uniformly encapsulate southbound commands (such as WireGuard and VLAN configuration commands) from different manufacturers to achieve multi-device compatibility. Furthermore, storage system 132 can use MySQL and message queues (MQ) to persistently store logical objects, task queues, and pipeline status data to support task status management and error retry mechanisms for creating subtasks.

[0063] In some implementations, each layer is connected to a southbound interface via a northbound interface. Specifically, the implementation layer 12 provides a templated interface to the application layer 11 and invokes device commands via a unified southbound interface, forming a complete configuration-parsing-execution closed loop. The network tunnel creation system of this application utilizes layered decoupling and modular design to achieve dynamic generation of multi-configuration tunnels, automated constraint management, and task replayability, thereby improving configuration efficiency during the network tunnel creation process.

[0064] The network tunnel creation method in the embodiment of the present application can be illustrated by the following embodiment.

[0065] It should be noted that in each specific embodiment of the present application, when it comes to the need to perform relevant processing based on data related to user identity or characteristics such as user information, user behavior data, user historical data, and user location information, the user's permission or consent will be obtained first. Moreover, the collection, use, and processing of these data will comply with relevant laws, regulations, and standards. In addition, when the embodiment of the present application needs to obtain the user's sensitive personal information, the user's separate permission or consent will be obtained through a pop-up window or by jumping to a confirmation page. After clearly obtaining the user's separate permission or consent, the necessary user-related data for the normal operation of the embodiment of the present application will be obtained.

[0066] In the embodiment of the present application, the network tunnel creation device will be described from the perspective of the network tunnel creation device, which can be integrated into a computer device. Figure 2 , Figure 2 This is a flowchart of the steps of the network tunnel creation method provided in an embodiment of the present application. In this embodiment of the present application, the network tunnel creation device is specifically integrated into a terminal or server as an example. When the processor on the terminal or server executes the program instructions corresponding to the network tunnel creation method, the specific process is as follows:

[0067] Step 101: Obtain a tunnel configuration file, which at least includes a tunnel creation type, multiple tunnel creation steps, and constraint information.

[0068] In some implementations, in order to provide an initialization data basis for the subsequent automatic generation of multiple types of tunnels, a structured tunnel configuration file may be obtained to accurately capture user requirements.

[0069] Among them, the tunnel configuration file can be a technical document containing tunnel generation logic defined in a structured data format, which at least includes the tunnel creation type to be created, the tunnel creation steps and constraint information corresponding to each tunnel creation type, and is used to guide the system to generate dynamic tunnel configuration solutions that meet the needs of multiple scenarios.

[0070] Tunnel creation types can be classified based on network protocols or application scenarios. Each tunnel creation type corresponds to a specific set of configuration parameters and device interface calling rules. For example, tunnel creation types can be gatewayTunnel and userTunnel, corresponding to different network security levels and device interface combinations.

[0071] The tunnel creation step may be a sequence of operation units required to complete a specific type of tunnel configuration.

[0072] The constraint information may be a set of rules that control parameter generation and the order of step execution, including parameter range restrictions, cross-device parameter associations, and dependencies between steps.

[0073] In some implementations, the format of the tunnel configuration file may be as shown in Table 1 below:

[0074]

[0075] The following is an example of a tunnel configuration file formed according to the format of Table 1:

[0076] tunnelTypes:

[0077] gatewayTunnel:

[0078] GATETUNNELWIREGUARD:port:[1000,4000];

[0079] GATETUNNELVLAN:

[0080] GATETUNNELLOOPBACK:

[0081] GATETUNNELVXLAN:

[0082] userTunnel:

[0083] STUTUNNELWIREGUARD:

[0084] STUTUNNELVXLAN:

[0085] Constraints:

[0086] Team:gatewayTunnel.GATETUNNELVLAN.bridgeId=gatewayTunnel.GATETUNNELVXLAN.bridgeId=userTunnel.STUTUNNELVXLAN.bridgeId

[0087] Specifically, the above tunnel configuration file defines two tunnel creation types: gatewayTunnel and userTunnel. For example, when creating a gatewayTunnel, it can include four tunnel creation steps: GATETUNNELWIREGUARD and GATETUNNELVLAN. These tunnel creation steps correspond to device interface names in the infrastructure layer and are used to determine the execution function for the corresponding tunnel creation step. Specifically, in the GATETUNNELWIREGUARD tunnel creation step, the user specifies a constraint for the port parameter, specifying a range between 1000 and 4000. Furthermore, in the GATETUNNELVLAN and GATETUNNELVLAN tunnel creation steps, the user also defines a constraint for the bridgeId (bridge identifier). Furthermore, these constraints specify that when creating both gatewayTunnel and userTunnel tunnel types, the GATETUNNELVLAN and GATETUNNELVLAN of the gatewayTunnel must match the bridgeId in the STUTUNNELVXLAN of the userTunnel.

[0088] By obtaining the tunnel configuration file, the basic data for creating the tunnel can be obtained. The user only needs to fill in the file according to the preset tunnel configuration file format. This can facilitate the subsequent direct conversion of the basic data into a format that the system can recognize, thereby achieving efficient and accurate creation of the tunnel.

[0089] Step 102: Convert the tunnel configuration file into target configuration information corresponding to the target format.

[0090] In some embodiments, in order to achieve dynamic adaptation and zero-error deployment of multi-scenario tunnels without manual intervention and solve the problem of configuration semantic ambiguity in heterogeneous network environments, the tunnel configuration file can be converted into programmable and traceable data, such as JSON objects, to achieve standardized conversion from high-level business requirements to underlying device instructions.

[0091] The target format may be a standardized data structure format defined within the system, that is, a structured data format that can be recognized and processed by the system.

[0092] Among them, the target configuration information can be a set of device executable parameters after constraint parsing, including but not limited to tunnel creation type, tunnel creation steps (such as GATETUNNELWIREGUARD, etc.), parameter-level constraints (such as port range 1000 to 4000) and cross-step or team-level constraint information (such as bridgeId consistency requirements).

[0093] In some implementations, a user-defined tunnel configuration file can be structured and parsed to convert its abstract description into target configuration information corresponding to a target format executable by the system. This process semantically maps the configuration content based on a predefined data model, identifies the tunnel type, creation steps, and parameter constraints, and organizes this information into a unified format (such as a JSON object), thereby achieving the conversion from manual configuration intent to machine-processable data and providing standardized input for the subsequent dynamic generation of tunnels.

[0094] For example, following the example of the tunnel configuration file above, the tunnel configuration file is converted into target configuration information corresponding to the target format, and the following information can be obtained:

[0095]

[0096] l.GATETUNNELVLAN.bridgeId=gatewayTunnel.GATETUNNELVXLAN.bridgeId=use rTunel.STUTUNNELVXLAN.bridgeId"] / / Global parameter consistency rule;

[0097] }

[0098] }

[0099] In some implementations, a declarative configuration parsing engine can convert user-written, unstructured tunnel configuration files (such as the example in the image) into standardized, programmable target configuration information, specifically into a JSON object. First, the tunnel configuration file can be parsed to obtain tunnel creation types (tunnelTypes), such as "gatewayTunnel" and "userTunnel," and then the unique identifier (typeName) corresponding to each tunnel creation type can be obtained. The tunnel configuration file can then be parsed to obtain a series of tunnel creation steps (steps) for each tunnel creation type, thereby guiding the specific tunnel creation operation.

[0100] Furthermore, parameter-level constraints (param) and global parameter consistency rules (team) can be parsed from the tunnel configuration file. Specifically, "param" can be used to define specific constraint information for the tunnel creation steps recorded in the tunnel configuration file, such as constraining the port (port) range in the "GATETUNNELWIREGUARD" step of the "gatewayTunnel" type to be between 1000 and 4000. Furthermore, the "team" section can be used to define parameter consistency rules across multiple tunnel creation steps or tunnel creation types, ensuring that certain key parameters (such as bridgeId) remain consistent across the entire team or all related tunnels. For example, constraining the bridgeId values in the "GATETUNNELVLAN" and "GATETUNNELVXLAN" steps of the "gatewayTunnel" and "STUTUNNELVXLAN" steps to be the same. Once all contents in the tunnel configuration file have been converted to the target format, the target configuration information can be obtained.

[0101] Through structured data representation, the original tunnel configuration file is converted into target configuration information that can be understood and executed by computer programs. This not only improves configuration flexibility and efficiency, but also reduces the potential for errors during manual configuration. Furthermore, this approach allows the system to dynamically adapt to network requirements in different scenarios, simplifying the tunnel creation process and meeting the real-time configuration update requirements in mixed networking scenarios with multi-vendor devices.

[0102] Step 103: Parse the constraint information in the target configuration information according to the preset constraint meta-statement to obtain logical constraint parameters, and generate a logical object according to the target configuration information and the logical constraint parameters.

[0103] In some embodiments, in order to effectively solve the technical problems of dynamic parameter allocation and conflict avoidance in multi-tunnel collaborative configuration, the abstract parameter constraints described in the target configuration information can be converted into specific usable parameter values, and based on this, logical objects that can drive the automatic creation of tunnels can be constructed to achieve dynamic, standardized and controllable tunnel deployment, thereby improving the efficiency and reliability of configuration.

[0104] The preset constraint meta-statement may be a constraint expression paradigm (such as Param, Team, Noduplicate, etc.) predefined in a configuration file, and is used to describe the constraint logic of the constraint information.

[0105] The logical constraint parameter may be a parameter allocation rule set generated during the constraint resolution process, and its data structure includes a logical parameter name and a configuration parameter value, such as "port":4001.

[0106] The logical object may be standardized intermediate data generated by binding target configuration information with logical constraint parameters, including a tunnel creation type, a step sequence consisting of multiple tunnel creation steps, and parsed logical constraint parameters.

[0107] In some embodiments, by parsing the constraint meta-statements defined in the user configuration file (such as Param, Team, etc.), the user-defined parameter range, uniqueness, cross-tunnel parameter association and other constraints can be converted into specific logical constraint parameters (such as incremental allocation of unique port numbers, unified cross-tunnel bridge IDs), and these logical constraint parameters can be bound to the corresponding tunnel creation type and tunnel creation steps to form a structured logical object.

[0108] In some implementations, a table consisting of preset constraint meta-statements is shown in Table 2 below:

[0109]

[0110] For example, for parameter-level constraints, such as Param class constraints (such as GATETUNNELWIREGUARD.port = [1000, 4000]), the system can automatically generate a configuration parameter value that meets the conditions (such as 4001) from the user-defined range and bind it to the params field of the corresponding parameter; if there is a noduplicate constraint, it ensures that the global or device parameter is unique.

[0111] Furthermore, for combination-level constraints, such as Team or ALL class constraints (such as bridgeId consistency across tunnels), the system can generate unified configuration parameter values (such as 121) for associated parameters, and ensure that multiple tunnel creation steps or tunnel creation types share the same configuration parameter values through global parameter mapping.

[0112] Furthermore, after generating the configuration parameter values corresponding to the logical parameter names, constraint conflict checking is required. Specifically, the system can verify whether the configuration parameter values meet all constraint information (such as range, uniqueness, and cross-parameter associations) to avoid logical contradictions, thereby ensuring the accuracy and usability of the generated configuration parameter values. Ultimately, the parsed logical parameter names (such as port and bridgeId) and configuration parameter values (such as 4001 and 121) are structured and bound to the logical objects, ultimately ensuring that they are consistent with the device interface parameter names and meet the user-defined multi-level constraint rules.

[0113] In some implementations, the parameter table corresponding to the logical object is shown in Table 3 below:

[0114]

[0115] In some implementations, after parsing the target configuration information to obtain the logical constraint parameters, the system can perform structured binding of the logical constraint parameters according to the structural requirements of the logical object (such as Table 3). Specifically, the generated parameter values (such as {"port":4001, "bridgeId":121}) can be added to the steps list of the logical object to form a complete structure of tunnel creation types and tunnel creation steps. For example, taking the user-defined gatewayTunnel constraint as an example, the generated logical object can be as follows:

[0116]

[0117]

[0118] It should be noted that all configuration parameter values meet the user-defined constraint information, and the structure of the logical object conforms to the definition in Table 3 (such as name matches the device interface, and params key name is consistent with the interface parameter), so as to provide standardized input for the generation of subsequent task queues.

[0119] Please refer to Figure 3 In some embodiments, the combination Figure 3The process of generating logical objects is summarized. For example, configuration file parsing is performed first. A structured configuration file (e.g., in YAML / text format) containing the tunnel creation type, a sequence of multiple tunnel creation steps, and constraint information is read. The file structure is then parsed and converted into standardized target configuration information (e.g., in JSON format). The configuration constraint parsing phase then begins, extracting parameter-level independent constraints (e.g., port range validation) and cross-tunnel combined constraints (e.g., bridge ID consistency). The constraint type is determined: if it is an independent constraint, logical constraint parameter operations are performed directly within the current tunnel creation process (e.g., generating a dynamic port number based on a Param metastatement) to obtain the corresponding logical constraint parameters. If it is a combined constraint, team-level parameter synchronization rules are set (e.g., maintaining bridge IDs in a global hash table) to generate logical constraint parameters corresponding to the combined constraint for multiple tunnel creation processes. Finally, based on the parsed logical constraint parameters and target configuration information, a logical object containing dynamic parameters is generated, completing automated configuration preparation and achieving unified logical object construction for multi-level tunnel configuration. It should be noted that after generating the logical object corresponding to the current tunnel creation type, the logical object generation process for the current tunnel creation type ends and the next processing step is entered. Through the above approach, the multi-tunnel parameter coordination problem, which originally relied on manual experience, can be transformed into a deterministic calculation process, greatly reducing configuration time. Furthermore, this application supports real-time hot update of constraint rules, such as expanding the maximum transmission unit (MTU) value range when adding new vendor equipment, without interrupting service, ensuring zero-conflict deployment of multi-configuration tunnels in heterogeneous network environments.

[0120] In some implementations, to address dynamic parameter generation, conflict avoidance, and cross-step parameter synchronization issues in multi-tunnel collaborative configuration, user-declared abstract constraint rules can be converted into device-executable configuration parameter values by deconstructing constraint semantics, dynamically assigning parameter values, and combining parameter binding. This provides standardized input data for subsequent task queue generation. For example, step 103, "parsing the constraint information in the target configuration information according to the preset constraint metastatements to obtain logical constraint parameters," may include:

[0121] (103.a1) Parsing the constraint information in the target configuration information according to the preset constraint meta-statement to obtain the logical parameter name and constraint parsing information corresponding to each constraint item contained in the constraint information;

[0122] (103.a2) Perform parameter polling and allocation based on the constraint parsing information corresponding to each logical parameter name to obtain the configuration parameter value;

[0123] (103.a3) Generate logical object parameters based on the combination of logical parameter name and configuration parameter value.

[0124] The constraint item may be an instance of a constraint rule defined in a configuration file, such as port=[1000,4000], which is used to limit parameter generation logic.

[0125] Among them, the logical parameter name can be the target parameter identifier of the constraint item (such as port, bridgeId, etc. in Table 3). The logical parameter name corresponds to the input parameter name of the device interface function and is used to establish a mapping relationship between configuration parameters and device instructions.

[0126] The constraint resolution information may be a constraint range extracted from the constraint item, such as [1000, 4000].

[0127] The configuration parameter value may be a parameter instance value (eg, port=3501, bridgeId=121) dynamically generated based on the constraint resolution information.

[0128] In some implementations, the system can parse the constraint rules in the target configuration information based on pre-defined constraint meta-statements (e.g., Param, Team, [], etc.), extracting the logical parameter name corresponding to each constraint item and its constraint resolution information. For example, if the user defines GATETUNNELWIREGUARD.port = [1000,4000], the system can parse the constraint item to find that the logical parameter name corresponding to this constraint item is port, and the constraint resolution information is "between 1000 and 4000."

[0129] Furthermore, the system may generate configuration parameter values that satisfy the constraint resolution information through parameter polling allocation according to the constraint resolution information.

[0130] Exemplarily, the system can maintain an allocated port set. If the allocated port set is {1000, 1001, 1005}, and the constraint item is Param.device+[1000, 4000]+noduplicate (ports in the same device are not repeated, ranging from 1000 to 4000), then polling can start from 1000, skipping the allocated value, and selecting the first available port. If it is detected that 1000 is occupied, continue polling, and 1001 is also occupied, continue polling, and get 1002. Then, 1002 can be allocated and added to the allocated port set, and the set is updated to {1000, 1001, 1002, 1005}.

[0131] In some implementations, values can also be randomly generated within the constraints. If they conflict with assigned values, they are regenerated. This application does not limit the specific process of generating configuration parameter values, as long as the generated values satisfy the constraint resolution information and do not cause conflicts.

[0132] Generating logical object parameters in the above manner not only solves the dependency issues of complex configurations between multiple tunnels (such as cross-tunnel parameter consistency), but also avoids the inefficiency and error risks of manual configuration, effectively reduces adaptation complexity, and significantly improves tunnel deployment efficiency in federal range scenarios.

[0133] In some implementations, to ensure that the generation logic for all tunnel creation types follows a unified data model (as shown in Table 3), the parsed configuration parameters can be dynamically bound to the tunnel creation steps to construct a standardized logical structure. This solves the discretization problem of parameters and operation steps in the multi-type tunnel configuration process, eliminates the need to adjust the underlying code, and reduces operational complexity. For example, the "generating a logical object based on the target configuration information and logical constraint parameters" in step 103 may include:

[0134] (103.b1) Create initial logic objects;

[0135] (103.b2) According to the target configuration information, read at least one tunnel creation step corresponding to each tunnel creation type, and based on the tunnel creation type, at least one tunnel creation step, and the logical object parameters contained in each tunnel creation step, fill in the initial logical object to generate a generated logical object corresponding to each tunnel creation type.

[0136] Among them, the initial logical object can be a blank data structure template predefined by the system according to the tunnel configuration file, which includes fields such as tunnel type (typeName), step set (Steps) and parameter placeholder (Params), which are used to fill in the parsed parameter values and step dependencies as needed.

[0137] In some implementations, the tunnel creation type, tunnel creation steps, and parameter values of each network tunnel to be created may be filled into an initial logical object for structural binding to form a logical object for creating the network tunnel.

[0138] Exemplarily, the initial logical object may be an empty logical object frame. For example, the format of the initial logical object may be as follows:

[0139] {

[0140] "tunnelTypes":[

[0141] {

[0142] "typeName":"", / / The name of the tunnel creation type to be filled (such as gatewayTunnel);

[0143] "steps":[], / / Multiple tunnel creation steps to be filled;

[0144] "params":{} / / Logical constraint parameters to be filled;

[0145] } ]

[0147] }

[0148] In some implementations, the form of the initial logical object can be adjusted according to actual conditions, and the embodiments of the present application do not impose excessive restrictions on this.

[0149] For example, the pre-generated tunnel creation type, at least one tunnel creation step, and the logical object parameters included in each tunnel creation step can be injected into the initial logical object to obtain the object's logical object. The above data acquisition formula has been expanded above and will not be repeated here.

[0150] By injecting the pre-generated tunnel creation type, at least one tunnel creation step, and the logical object parameters contained in each tunnel creation step into the initial logical object, the complex logic of multi-tunnel configuration (such as cross-manufacturer device collaboration) can be converted into programmable operations, significantly reducing the complexity of manual configuration.

[0151] Step 104: Generate a task queue based on each tunnel creation step and corresponding logical constraint parameters in the logical object through the target reflection mechanism. The task queue contains multiple creation subtasks with an ordering relationship, and each creation subtask corresponds to a tunnel creation step.

[0152] In some implementations, in order to ensure the timing correctness of the collaborative configuration of multiple devices and to quickly locate the specific timing link for hot repair when a fault occurs, the device interface implementation class can be dynamically bound through the reflection mechanism, and the abstract configuration steps in the logical object can be converted into an executable creation sub-task sequence to solve the configuration process fragmentation problem caused by the differentiation of heterogeneous device instructions, realize the unified pipeline orchestration of multi-vendor device tunnels, and thereby improve the reliability and operation and maintenance efficiency of multi-constraint multi-tunnel configuration.

[0153] Among them, the target reflection mechanism can be a dynamic interface binding method based on Java reflection technology. By parsing the step name in the logical object (such as GATETUNNEL_WIREGUARD), the implementation class of the corresponding device interface can be dynamically loaded at runtime, that is, the execution function (such as WireGuardHandler.class), and a call instruction carrying the logical object parameters (such as port=3501) can be generated to realize the automatic mapping of the configuration tunnel creation steps to the execution instructions.

[0154] The task queue may be an ordered set of creation subtasks generated in the order of steps in the logic object, and is used to characterize the operation dependency and execution priority in the multi-tunnel creation process.

[0155] The creation subtask can be an atomic operation unit bound to a single tunnel creation step in the task queue. Its execution result is independent of other creation subtasks and supports failure retry and status rollback.

[0156] In some embodiments, the step name of the tunnel creation step in the logical object (such as GATETUNNELWIREGUARD) can be dynamically parsed through the reflection mechanism, mapped to the device interface implementation class of the specific device (such as WireGuardHandler), and combined with the constraint parameters (such as port = 3501, bridgeId = 121) to generate an atomic creation subtask (such as generating a CLI command for a Cisco device or a Huawei NETCONF message). The task queue sorts the multiple creation subtasks for creating the current network tunnel (such as num = 0, 1, 2...) according to the dependencies between the steps (such as allocating the port first and then starting the tunnel), and marks the globally unique identifier (such as jobId) and status mark, thereby converting the abstract configuration into a serializable and traceable atomic operation chain, realizing the automatic generation and zero-conflict scheduling of multi-vendor device instructions, and supporting dynamic rollback and parameter reallocation of abnormal tasks (such as automatically increasing the attempt 3501 to 3502 when there is a port conflict).

[0157] Through the above method, the step name in the logical object (such as STUTUNNEL_VXLAN) can be dynamically bound to the manufacturer's device interface through reflection, so that the same configuration logic can automatically adapt to multi-vendor devices, greatly improving the efficiency and accuracy of tunnel creation; at the same time, each creation subtask independently carries execution instructions and parameters, supports distributed parallel execution, and further improves execution efficiency.

[0158] In some implementations, to achieve automated orchestration and standardized execution of complex tunnel creation processes, device interface functions and parameters can be dynamically bound through a reflection mechanism, converting abstract configurations in logical objects into a sequence of creation subtasks executable by the device. This eliminates the ambiguity and complexity of manual parameter mapping, addresses configuration fragmentation caused by differences in device instructions from multiple vendors, and enables timing control and fault-tolerant scheduling of complex configurations. For example, step 104 may include:

[0159] (104.1) Map each tunnel creation step in the logical object through the target reflection mechanism and determine the target execution function for executing each tunnel creation step;

[0160] (104.2) Determine the target logical object parameters corresponding to each tunnel creation step from the logical object, and generate a creation subtask for each tunnel creation step based on the target execution function and the target logical object parameters;

[0161] (104.3) Generate a corresponding task queue based on multiple creation subtasks corresponding to the multiple tunnel creation steps included in the tunnel creation type.

[0162] The target execution function may be a specific implementation function of the device interface corresponding to each tunnel creation step determined by the reflection mechanism (eg, create_wireguard_tunnel()), which is used to convert the logical object parameters (eg, port=3501) into execution instructions.

[0163] Among them, the target logical object parameter can be a deterministic parameter key-value pair (i.e., logical object parameter) bound to the tunnel creation step in the logical object, such as {"port":3501, "bridgeId":121} in the Params field). The logical parameter name of the target logical object parameter is consistent with the input parameter definition of the target execution function, and is used to generate execution instructions that can be recognized by the target device.

[0164] In some embodiments, the step names of the user-configured tunnel creation steps (such as GATETUNNELWIREGUARD) can be dynamically parsed through the target reflection mechanism, and the abstract steps can be converted into executable code through dynamic mapping of the tunnel creation steps with specific execution functions (for example, matching to the WireGuardHandler.createTunnel() function), thereby eliminating the need for hard-coding to adapt different tunnel creation types to specific device interfaces.

[0165] Furthermore, the target logical object parameters (e.g., port=4001) of the current tunnel creation step can be extracted from the logical object and injected into the target execution function to generate an atomic creation subtask. For example, by calling the device interface create_wireguard_tunnel(port=4001), the target logical object parameters of each tunnel creation step can be ensured to accurately match the device's execution instructions.

[0166] Furthermore, based on the dependencies and execution order of the tunnel creation steps in the configuration (such as configuring VLAN first and then binding VXLAN), the creation subtasks can be arranged in sequence into a task queue, and the task execution process can be managed through a state machine to ensure coordination and fault tolerance between multiple tunnel creation steps.

[0167] For example, taking the user-configured tunnel creation step, GATETUNNELWIREGUARD step as an example, the system can locate the predefined WireGuardHandler class and its execution function executeTunnelCreation() through Java reflection based on the step name GATETUNNELWIREGUARD, and bind it as the target execution function of the tunnel creation step.

[0168] Furthermore, the parsed target logical object parameters (such as port = 4001, etc.) of the tunnel creation step can be read from the logical object and filled into the parameter list of the executeTunnelCreation(port, peer_ip) method to generate the creation subtask corresponding to the GATETUNNELWIREGUARD step. Afterwards, if the GATETUNNELWIREGUARD and GATETUNNELVLAN steps need to be executed in sequence during the creation of the network tunnel, the system will generate two creation subtasks in the configuration order, calling the interface methods of WireGuardHandler and VLANHandler respectively, forming a task queue [Task1: WireGuard port configuration, Task2: VLAN bridge binding] to facilitate subsequent sequential execution and status detection.

[0169] Please refer to Figure 4 , combined with Figure 4 This section introduces the overall process of generating the corresponding task queue. Figure 4 As shown, the system first reads the logical object, traverses the multiple tunnel creation steps it contains (such as GATETUNNELWIREGUARD, GATETUNNELVXLAN, etc.), and resolves the name of each tunnel creation step through the target reflection mechanism, dynamically mapping it to the preset target execution function (for example, mapping GATETUNNELWIREGUARD to WireGuardHandler.create() method). Subsequently, the system extracts the target logical object parameters corresponding to the tunnel creation step from the logical object (such as port=4001, bridgeId=121), and injects the target logical object parameters into the function interface corresponding to the target execution function obtained by reflection, generates a creation subtask corresponding to the current tunnel creation step, and adds the creation subtask to the task queue.

[0170] Furthermore, after generating each creation subtask and adding it to the task queue, it can be determined whether all tunnel creation steps for creating the current network tunnel have been traversed and completed. If not, continue to create the creation subtask of the next tunnel creation step, and add the newly created creation subtask to the task queue in sequence; if so, end the process, obtain the generated task queue, and save the queue status through information persistence operations (such as storing it in a database) to ensure task traceability and breakpoint resumption capabilities.

[0171] By mapping the step names of the tunnel creation steps in the logical object to the manufacturer's device interface function through reflection, generating structured subtasks based on the corresponding parameters, and organizing them into task queues according to the tunnel type, on the one hand, the same configuration logic can be adapted to devices from multiple manufacturers, eliminating the risk of parameter misalignment in manual configuration and greatly improving the efficiency and accuracy of configuration; on the other hand, the modularization, automation and dynamic scheduling of the tunnel creation process can be achieved, significantly improving the flexibility and execution efficiency of tunnel deployment.

[0172] In some implementations, to address the task dependency management and status tracking challenges in concurrent multi-tunnel creation scenarios, structured annotation and queue construction can be used to transform atomic creation subtasks into traceable and choreographed task sequences, enabling standardized scheduling and dynamic monitoring of complex configuration processes. For example, (104.3) can include:

[0173] (104.3.1) Based on each creation subtask corresponding to each tunnel creation step included in the tunnel creation type, label the corresponding subtask identifier, the queue identifier of the corresponding task queue, the location code in the corresponding task queue, and the subtask status to obtain the labeled creation subtask;

[0174] (104.3.2) Build a corresponding task queue based on multiple creation subtasks in sequence.

[0175] Among them, the subtask identifier can be a unique identifier assigned to each created subtask (such as the jobId field), which is used to track the execution status and log association of the created subtask (such as port allocation, VLAN configuration) in the distributed system. Its encoding rule can be "task queue ID_step number" (such as TUN001_JOB002).

[0176] Among them, the queue identifier can be a unique identifier assigned to each task queue (such as the taskId field), which is used to associate multiple creation subtasks under the same tunnel creation type (such as the VXLAN and WireGuard configuration of the same Team), and its encoding is associated with the tunnel creation type in the logical object (such as GATEWAY_TUNNEL_QUEUE_001).

[0177] Among them, the position code can be the sequential number of the created subtask in the task queue (such as the num field), which starts from 0 and increases incrementally. It is used to force the execution order of the device interface call (such as first executing the port allocation num=0, and then executing the tunnel startup num=1) to avoid configuration errors caused by out-of-order steps.

[0178] Among them, the subtask status can be a real-time execution status mark of the created subtask (such as the status field), which can include states such as "to be executed", "executing", "success", and "failure", which is used to trigger the task retry mechanism, such as automatic rollback of failed tasks.

[0179] In some implementations, the configuration table for creating a subtask may be as shown in Table 4 below:

[0180] Field illustrate tunnelId The task queue id jobId Create subtask id conf Task Configuration DeviceId Valid device ID type Task Type num The position in the task queue, starting from 0 and increasing status Create subtask status

[0181] In some implementations, the configuration table of the task queue may be as shown in Table 5 below:

[0182] Field illustrate taskId Task id. A task may contain multiple network tunnels. tunnelId The task queue id status Task queue status UUID The device ID of one end of the network tunnel PeerUuid The device ID of the other end of the network tunnel

[0183] The following is a detailed description with reference to Table 4 and Table 5.

[0184] For example, if a tunnel creation type named "gatewayTunnel" is currently being processed, the tunnel creation type includes four tunnel creation steps: GATETUNNELWIREGUARD, GATETUNNELVLAN, GATETUNNELOOPBACK, and GATETUNNELVXLAN, and each tunnel creation step corresponds to a creation subtask.

[0185] First, you can mark the relevant information for each creation subtask according to the content in Table 4:

[0186] JobId: This is a unique identifier for each created subtask. For example, you could assign jobIds 1, 2, 3, and 4 to these four steps, respectively.

[0187] The task queue's queue ID (tunnelId): This is the identifier of the task queue corresponding to the entire tunnel creation type. For example, the identifier of the task queue corresponding to the "gatewayTunnel" type is 1001.

[0188] Position code (num) in the corresponding task queue: Indicates the sequential position of each created subtask in the task queue. According to the order of steps, the num of GATETUNNELWIREGUARD is 0, the num of GATETUNNELVLAN is 1, and so on.

[0189] Creation subtask status (status): indicates the current execution status of the creation subtask, such as "pending", "executing", "completed", "failed to execute", etc.

[0190] Taking the GATETUNNELWIREGUARD subtask as an example, its annotation information is as follows: jobId: 1; tunnelId: 1001; num: 0; status: pending. The other three creation subtasks can be annotated in the same way, which is not listed here one by one.

[0191] Furthermore, all marked creation subtasks can be sorted according to their position codes (num) in the task queue to form an ordered task queue. The configuration information of the task queue can be recorded in the format shown in Table 5, for example:

[0192] taskld: Task id, which can be the overall task identifier corresponding to the tunnel configuration file provided by the current user. All tunnel creation types required to be created in the tunnel configuration file can share one taskld, for example, it can be set to 001.

[0193] tunnelId: The id of the task queue to which it belongs, for example, 1001.

[0194] status: The task queue status, for example, it can be initially set to "pending".

[0195] UUID: This is the unique identifier of the device on the local (currently operating) end of the tunnel. It is used to locate and manage the tunnel interface on the current device during configuration. For example, if you want to create a WireGuard tunnel on device HW_001, UUID = HW_001.

[0196] PeerUuid: The unique identifier of the device at the other end of the tunnel (the target side of the communication). It is used to specify the device connected to the other end of the tunnel. For example, when HW_001 establishes a tunnel with HW_002, PeerUuid = HW_002 must be declared in the configuration of HW_001, and vice versa.

[0197] In some implementations, the task queue and each created subtask can be configured with labels according to Tables 4 and 5, and the corresponding labels can be appropriately modified or added or subtracted without departing from the concept of the present application. The present application does not impose any specific restrictions on this.

[0198] Through the above method, the system can clearly obtain the execution order and status of each creation subtask, and achieve accurate status positioning of concurrent tunnel creation tasks through the global uniqueness of subtask identifiers, thereby efficiently managing and scheduling the tunnel creation process.

[0199] Step 105 , sequentially executing each creation subtask in the task queue to create a network tunnel of the tunnel creation type.

[0200] In some implementations, to ensure that the tunnel configuration process under multi-step dependencies is strictly executed according to the orchestration of logical objects, atomic creation subtasks in the task queue can be executed sequentially to resolve configuration conflicts and resource allocation anomalies caused by the disorder of step sequence in traditional manual operations, thereby realizing automated and highly reliable deployment of network tunnels in a federal range environment.

[0201] A network tunnel can be a logical communication channel established within a federal range based on encryption protocols (such as WireGuard and VXLAN) or network virtualization technologies. Both ends of a network tunnel are bound to designated network devices (such as routers and gateways), and secure data transmission and isolation across network domains are achieved through dynamically generated configuration parameters (such as port numbers, encryption keys, and VLAN identifiers). For example, a network tunnel can be a gateway tunnel (an encrypted tunnel between gateways) and a user tunnel (a tunnel between user terminals).

[0202] In some embodiments, for each task queue, each creation subtask (such as port allocation, protocol configuration, tunnel activation, etc.) can be executed sequentially, and the corresponding target execution function (such as CiscoHandler.createTunnel()) can be called strictly in accordance with the order of steps to convert the logical configuration into executable instructions for the target device (such as generating CLI commands or NETCONF messages), and the task status of the creation subtask is updated in real time during the execution process to ensure the timing of multi-step operations (such as allocating ports first and then binding tunnels) and the atomicity of the configuration (failure of a single creation subtask triggers queue rollback), ultimately achieving reliable creation of cross-device network tunnels.

[0203] In some implementations, the system can execute multiple tunnel creation task queues in parallel to create multiple network tunnels. Tests have shown that using the approach outlined in this application, the system can support the parallel execution of over 2,000 creation subtasks per second (e.g., batch creation of WireGuard port allocations for 50 network tunnels). In a multi-team collaborative scenario at a federal range, the fully automated creation of 50 heterogeneous network tunnels was reduced from eight hours to just three minutes, a 160-fold increase in efficiency. This provides standardized, highly concurrent tunnel deployment capabilities for the complex network topologies of the federal range.

[0204] The embodiment of the present application obtains a tunnel configuration file, which includes at least a tunnel creation type, multiple tunnel creation steps, and constraint information; converts the tunnel configuration file into target configuration information corresponding to a target format; parses the constraint information in the target configuration information according to preset constraint metastatements to obtain logical constraint parameters, and generates a logical object based on the target configuration information and the logical constraint parameters; generates a task queue based on each tunnel creation step and the corresponding logical constraint parameters in the logical object through a target reflection mechanism, the task queue containing multiple creation subtasks with an ordered relationship, each creation subtask corresponding to a tunnel creation step; and sequentially executes each creation subtask in the task queue to create a network tunnel of the tunnel creation type. In this way, the user-provided tunnel configuration file can be automatically constrained and parsed, effectively solving the problem of manually coordinating complex constraint relationships between multiple tunnels. At the same time, the reflection mechanism dynamically generates an ordered task queue, converting discrete creation steps into atomic operations that can be serialized and executed. This not only avoids configuration conflicts that may be caused by manually defining parameters such as port numbers, but also eliminates the workload of manually adjusting the configuration order through the automatic sorting mechanism of the task queue, thereby significantly improving the configuration efficiency of the network tunnel creation process while ensuring configuration consistency.

[0205] In some implementations, to ensure the automated creation and end-to-end executability of network tunnels in the federated range, dynamic device selection and instruction generation can be used to accurately map subtasks to physical devices and issue instructions. This effectively resolves configuration instruction differences and resource allocation conflicts in a multi-device heterogeneous environment, improving the efficiency and accuracy of network tunnel creation. For example, step 105 may include:

[0206] (105.1) Determine multiple corresponding candidate devices by sequentially performing tunnel creation steps corresponding to each creation subtask;

[0207] (105.2) determining a target device from a plurality of candidate devices based on the target logical object parameters included in each creation subtask;

[0208] (105.3) Generate a corresponding execution instruction for each creation subtask, and send the execution instruction to the target device so that the target device executes the corresponding creation subtask based on the execution instruction;

[0209] (105.4) When the last creation subtask in the task queue is executed, a network tunnel of the tunnel creation type is created.

[0210] The candidate devices may be all network devices that meet the interface specifications required by the corresponding tunnel creation step.

[0211] Among them, the target device can be a network device instance further specified from multiple candidate devices based on the target logical object parameters contained in the creation subtask (such as port = 3501, etc.), and its device type (such as manufacturer, model) strictly matches the tunnel creation type corresponding to the creation subtask (such as WireGuard tunnel creation) and meets parameter constraints (such as port availability, bandwidth limitation).

[0212] Among them, the execution instruction can be a device executable instruction generated based on the tunnel creation type (such as the type field) of the creation subtask and the manufacturer specification of the target device. Its content is filled with logical object parameters (such as port = 3501) and is sent to the target device through the device southbound interface.

[0213] In some embodiments, each creation subtask in each task queue can be executed sequentially, and multiple candidate devices can be determined based on the tunnel creation steps in each creation subtask. For example, when processing a creation subtask of type "GATETUNNEL_WIREGUARD", the system can filter out all gateway devices with a WireGuard module installed and normal interface status, resulting in multiple candidate devices.

[0214] Furthermore, the system can further locate the target device from multiple candidate devices by parsing the target logical object parameters (such as port, bridge ID, etc.) in the creation subtask. For example, if the creation subtask requires port = 4001 and bridgeId = 121, devices that do not support the port range or cannot be configured with the bridge ID will be excluded.

[0215] Furthermore, the system can predefine a library of instruction templates based on device vendor type, mapping target logical object parameters (such as port, bridge ID, etc.) to device-specific instruction templates. For example, the instruction template for WireGuard port configuration can be interface{interface_name}port{port}, and the instruction template for bridge ID binding can be bridge-domain{bridgeId}. The target logical object parameters of the subtask creation can then be injected into the corresponding instruction template to obtain the final execution instruction, such as interface WireGuard1 port 4001 and bridge-domain121.

[0216] Furthermore, an execution instruction can be encapsulated according to a communication protocol supported by the target device and sent to a device interface of the target device. Upon receiving the execution instruction, the target device parses the instruction and executes the corresponding creation subtask based on the parsed instruction parameters. For example, the target device may execute operations such as modifying a device configuration file, enabling a corresponding network interface, or starting a related service.

[0217] Through the above approach, not only the flexibility and automation of configuration are improved, but also the need for manual intervention is significantly reduced, the risk of configuration errors is lowered, and efficient collaborative work in a multi-device environment is ensured.

[0218] In some implementations, to address the self-healing and continuity issues of task execution anomalies in a distributed environment, a callback mechanism can be used to capture the execution status of the target device in real time, dynamically update failed tasks, and trigger queue rollbacks, thereby achieving fault-tolerant scheduling and adaptive recovery of the multi-tunnel creation process in the federated target range. For example, after (105.3), that is, after "generating a corresponding execution instruction for each creation subtask and sending the execution instruction to the target device so that the target device executes the corresponding creation subtask based on the execution instruction," the following may be included:

[0219] (A.1) receiving a callback function triggered by a device interface of a target device, wherein the callback function is triggered by the target device after completing execution of each created subtask according to the execution instruction, and the callback function includes the execution result of each created subtask by the target device;

[0220] (A.2) When the execution result indicates that the target device fails to execute the creation subtask, the creation subtask is updated based on the constraint information to obtain the target creation subtask;

[0221] (A.3) Create subtasks based on the target, update the task queue, and roll back to the target creation subtask to execute the remaining task queue.

[0222] The device interface may be a standardized communication interface between the system and a target device (such as a router, switch, or other physical network device).

[0223] Among them, the callback function can be an asynchronous notification function triggered by the target device after the creation of the subtask is completed. Its input parameters include the execution result (such as success or failure status code, error log, etc.), which is used to feedback the task execution status to the system and trigger subsequent processing logic (such as retry on failure).

[0224] Among them, the execution result can be the status data returned by the target device after executing the creation subtask, including the task identifier (jobId), device response code (such as CLI return code 0 indicates success), error details (such as "port is occupied") and other information, which is used to determine whether the creation subtask needs to be retried or the parameters adjusted.

[0225] Among them, the target creation subtask can be an instance of a creation subtask that is dynamically updated based on the failure information in the execution result (such as port conflict) and the original constraint information (such as port∈[1000,4000]). Its parameter value is regenerated according to the constraint strategy (such as incremental allocation) and marked as a state to be retried.

[0226] For example, please refer to Figure 5 After obtaining the information of the task queue (for example, task queue 1), it starts to execute each creation subtask in the task queue in sequence, and according to the generated corresponding execution instruction, according to the target device corresponding to the creation subtask, calls the target device interface to complete the issuance of the execution instruction. When the target device completes the creation subtask (such as interface configuration), it triggers the callback function through the southbound interface, and returns the execution result (success / failure) and error code (such as port conflict, insufficient authority) to the network tunnel creation system. The system updates the status of the creation subtask according to the execution result of the callback. If the execution result indicates that the configuration for the current creation subtask is successful, then continue to execute the next creation subtask of the current task queue in sequence until all creation subtasks in the task queue are traversed. This indicates that the entire task queue has been completed, and the status of the task queue is updated to run successfully, and the network tunnel corresponding to the task queue is created.

[0227] Furthermore, if the execution result indicates that the configuration for the current creation subtask (e.g., creation subtask A) has failed, then the cause of the error is recorded based on the information contained in the returned execution result (e.g., error code, execution log, etc.). Thereafter, the logical constraint parameters of the tunnel creation step a corresponding to the creation subtask A are updated based on the tunnel configuration file. For example, if the original port for creation subtask A is 51820, and the constraint information corresponding to the original prot is that the port range of port is [51820, 51830], the system can update the new port to 51821 accordingly. Port = 51821 is the updated logical constraint parameter.

[0228] Furthermore, after updating the logical constraint parameters corresponding to the corresponding tunnel creation step a, the logical object can be updated. Finally, the target creation subtask corresponding to creation subtask A is updated. It should be noted that the process of updating the target creation subtask is the same as the process of generating the creation subtask described above. For details, please refer to the above embodiment and will not be repeated here.

[0229] Furthermore, based on the target creation subtask, the current task queue 1 can be updated, and the target creation subtask can be rolled back to continue executing the target creation subtask and its subsequent creation subtasks until all creation subtasks in task queue 1 are traversed, and the network tunnel can be created.

[0230] In some embodiments, a preset number of rollbacks can be set. For example, if the preset number of rollbacks is set to 3, and the creation of subtask B still fails after retrying 3 times, the retry mechanism can be stopped and the execution results returned by multiple retries can be collected to facilitate subsequent analysis of the cause of failure. In this way, resource waste caused by infinite retries can be prevented, and a complete basis for subsequent fault analysis can be provided, further enhancing the maintainability and reliability of the system.

[0231] Through the above methods, the system can achieve accurate perception and dynamic response to the task execution status. When a task fails, it can automatically adjust parameters based on the original constraint information and generate a new target creation subtask to avoid process interruptions due to configuration conflicts or device anomalies. By updating the task queue and rolling back to the failed subtask to continue execution, the continuity and success rate of the tunnel creation process are guaranteed, significantly improving the robustness and intelligence level of automated network tunnel deployment.

[0232] See also Figure 6 The embodiment of the present application further provides a network tunnel creation device that can implement the above-mentioned network tunnel creation method. The network tunnel creation device includes:

[0233] An acquisition module 61 is configured to acquire a tunnel configuration file, where the tunnel configuration file includes at least a tunnel creation type, multiple tunnel creation steps, and constraint information;

[0234] A conversion module 62, configured to convert the tunnel configuration file into target configuration information corresponding to a target format;

[0235] The parsing module 63 is used to parse the constraint information in the target configuration information according to the preset constraint meta-statement to obtain the logical constraint parameters, and generate the logical object according to the target configuration information and the logical constraint parameters;

[0236] A generation module 64 is configured to generate a task queue based on each tunnel creation step and corresponding logical constraint parameters in the logical object through a target reflection mechanism, wherein the task queue includes multiple creation subtasks in an ordered relationship, each creation subtask corresponding to a tunnel creation step;

[0237] The creation module 65 is configured to execute each creation subtask in the task queue in sequence to create a network tunnel of the tunnel creation type.

[0238] The specific implementation of the network tunnel creation device is basically the same as the specific embodiment of the network tunnel creation method described above, and will not be repeated here. Under the premise of meeting the requirements of the embodiment of this application, the network tunnel creation device can also be provided with other functional modules to implement the network tunnel creation method described above.

[0239] The present application also provides a computer device comprising a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the above-mentioned network tunnel establishment method. The computer device can be any intelligent terminal including a tablet computer, an in-vehicle computer, or the like.

[0240] See also Figure 7 , Figure 7 The hardware structure of a computer device according to another embodiment is shown. The computer device includes:

[0241] The processor 71 may be implemented as a general-purpose CPU (Central Processing Unit), a microprocessor, an application-specific integrated circuit (ASIC), or one or more integrated circuits, and is used to execute relevant programs to implement the technical solutions provided in the embodiments of the present application.

[0242] The memory 72 can be implemented in the form of a read-only memory (ROM), a static storage device, a dynamic storage device, or a random access memory (RAM). The memory 72 can store an operating system and other application programs. When the technical solutions provided in the embodiments of this specification are implemented through software or firmware, the relevant program code is stored in the memory 72 and is called by the processor 71 to execute the network tunnel creation method of the embodiments of this application.

[0243] Input / output interface 73, used for information input and output;

[0244] Communication interface 74, used to implement communication interaction between this device and other devices, which can be achieved through wired means (such as USB, network cable, etc.) or wireless means (such as mobile network, WiFi, Bluetooth, etc.);

[0245] bus 75 , which transmits information between the various components of the device (e.g., processor 71 , memory 72 , input / output interface 73 , and communication interface 74 );

[0246] The processor 71 , the memory 72 , the input / output interface 73 and the communication interface 74 are connected to each other in communication within the device via a bus 75 .

[0247] An embodiment of the present application further provides a computer-readable storage medium, which stores a computer program. When the computer program is executed by a processor, the above-mentioned network tunnel creation method is implemented.

[0248] The memory, as a non-transient computer-readable storage medium, can be used to store non-transient software programs and non-transient computer executable programs. In addition, the memory may include a high-speed random access memory and may also include a non-transient memory, such as at least one disk storage device, a flash memory device, or other non-transient solid-state storage device. In some embodiments, the memory may optionally include a memory remotely arranged relative to the processor, and these remote memories may be connected to the processor via a network. Examples of the above-mentioned network include, but are not limited to, the Internet, an intranet, a local area network, a mobile communication network, and combinations thereof.

[0249] The embodiments described in the embodiments of this application are intended to more clearly illustrate the technical solutions of the embodiments of this application and do not constitute a limitation on the technical solutions provided by the embodiments of this application. Those skilled in the art will appreciate that with the evolution of technology and the emergence of new application scenarios, the technical solutions provided in the embodiments of this application are also applicable to similar technical problems.

[0250] Those skilled in the art will understand that the technical solutions shown in the figures do not constitute a limitation on the embodiments of the present application, and may include more or fewer steps than shown in the figures, or a combination of certain steps, or different steps.

[0251] The device embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate, i.e., they may be located in one place or distributed across multiple network units. Some or all of the modules may be selected based on actual needs to achieve the objectives of this embodiment.

[0252] Those skilled in the art will appreciate that all or some of the steps in the methods, systems, and functional modules / units in the devices disclosed above may be implemented as software, firmware, hardware, or appropriate combinations thereof.

[0253] The terms "first", "second", "third", "fourth", etc. (if any) in the specification of the present application and the above-mentioned drawings are used to distinguish similar objects and are not necessarily used to describe a specific order or sequential order. It should be understood that the data used in this way can be interchangeable where appropriate, so that the embodiments of the present application described herein can be implemented in an order other than those illustrated or described herein. In addition, the terms "including" and "having" and any variations thereof are intended to cover non-exclusive inclusions, for example, a process, method, system, product or device that includes a series of steps or units is not necessarily limited to those steps or units clearly listed, but may include other steps or units that are not clearly listed or inherent to these processes, methods, products or devices.

[0254] It should be understood that in the present application, "at least one (item)" and "several" are one or more, and "multiple" is two or more. "And / or" is used to describe the association relationship of associated objects, indicating that there can be three relationships. For example, "A and / or B" can mean: only A exists, only B exists, and A and B exist at the same time, where A and B can be singular or plural. The character " / " generally indicates that the previous and next associated objects are in an "or" relationship. "At least one of the following items" or similar expressions is any combination of these items, including any combination of single items or plural items. For example, at least one of a, b or c can mean: a, b, c, "a and b", "a and c", "b and c", or "a and b and c", where a, b, c can be single or multiple.

[0255] In the several embodiments provided in this application, it should be understood that the disclosed systems and methods can be implemented in other ways. For example, the system embodiments described above are merely illustrative. For example, the division of the above units is merely a logical function division. In actual implementation, there may be other division methods, such as multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be an indirect coupling or communication connection through some interfaces, devices or units, which can be electrical, mechanical or other forms.

[0256] The units described above as separate components may or may not be physically separate, and the components shown as units may or may not be physical units, that is, they may be located in one place or distributed across multiple network units. Some or all of these units may be selected according to actual needs to achieve the purpose of the solution of this embodiment.

[0257] In addition, the functional units in the various embodiments of the present application may be integrated into a single processing unit, or each unit may exist physically separately, or two or more units may be integrated into a single unit. The aforementioned integrated units may be implemented in the form of hardware or software functional units.

[0258] If the integrated unit is implemented in the form of 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 application is essentially or the part that contributes to the prior art or all or part of the technical solution can be embodied in the form of a software product. The computer software product is stored in a storage medium and includes multiple instructions for enabling a computer device (which can be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods of various embodiments of the present application. The aforementioned storage medium includes: U disk, mobile hard disk, read-only memory (ROM), random access memory (RAM), disk or optical disk, and other media that can store programs.

[0259] The preferred embodiments of the present invention are described above with reference to the accompanying drawings, but are not intended to limit the scope of the present invention. Any modifications, equivalent substitutions, and improvements made by those skilled in the art without departing from the scope and essence of the present invention should be within the scope of the present invention.

Claims

1. A method for establishing a network tunnel, characterized in that: The method comprises: Obtain a tunnel configuration file, where the tunnel configuration file includes at least a tunnel creation type, multiple tunnel creation steps, and constraint information; Converting the tunnel configuration file into target configuration information corresponding to the target format; Parsing the constraint information in the target configuration information according to the preset constraint meta-statement to obtain logical constraint parameters, and generating a logical object according to the target configuration information and the logical constraint parameters; Generate a task queue based on each tunnel creation step in the logic object and the corresponding logic constraint parameters through a target reflection mechanism, wherein the task queue includes a plurality of creation subtasks having an ordering relationship, and each creation subtask corresponds to a tunnel creation step; Each creation subtask in the task queue is executed in sequence to create a network tunnel of the tunnel creation type.

2. The network tunnel creation method according to claim 1, wherein: The generating of a task queue based on each tunnel creation step in the logical object and the corresponding logical constraint parameters by a target reflection mechanism includes: Mapping each tunnel creation step in the logic object through a target reflection mechanism to determine a target execution function for executing each tunnel creation step; Determining target logical object parameters corresponding to each tunnel creation step from the logical object, and generating a creation subtask for each tunnel creation step according to the target execution function and the target logical object parameters; Based on the multiple creation subtasks corresponding to the multiple tunnel creation steps included in the tunnel creation type, a corresponding task queue is generated.

3. The network tunnel creation method according to claim 2, characterized in that: The generating of a corresponding task queue based on the multiple creation subtasks corresponding to the multiple tunnel creation steps included in the tunnel creation type includes: Based on each creation subtask corresponding to each tunnel creation step included in the tunnel creation type, labeling the corresponding subtask identifier, the queue identifier of the corresponding task queue, the position code in the corresponding task queue, and the subtask status, to obtain the labeled creation subtask; The corresponding task queue is constructed according to multiple creation subtasks in sequence.

4. The network tunnel creation method according to claim 1, wherein: The sequentially executing each creation subtask in the task queue to create a network tunnel of the tunnel creation type includes: Determine multiple corresponding candidate devices by sequentially performing tunnel creation steps corresponding to each creation subtask; Determine a target device from the plurality of candidate devices based on the target logical object parameters included in each creation subtask; generating a corresponding execution instruction according to each creation subtask, and sending the execution instruction to the target device, so that the target device executes the corresponding creation subtask based on the execution instruction; When the last creation subtask in the task queue is completed, a network tunnel of the tunnel creation type is created.

5. The network tunnel creation method according to claim 4, characterized in that: After generating a corresponding execution instruction according to each creation subtask and sending the execution instruction to the target device so that the target device executes the corresponding creation subtask based on the execution instruction, the method further includes: receiving a callback function triggered by a device interface of a target device, wherein the callback function is triggered by the target device after completing execution of each created subtask according to the execution instruction, and the callback function includes the execution result of the target device for each created subtask; When the execution result indicates that the target device fails to execute the creation subtask, updating the creation subtask based on the constraint information to obtain a target creation subtask; Based on the target creation subtask, the task queue is updated, and the task queue is rolled back to execute the remaining task of the target creation subtask.

6. The network tunnel creation method according to claim 1, characterized in that: The step of parsing the constraint information in the target configuration information according to the preset constraint meta-statement to obtain the logical constraint parameters includes: Parsing the constraint information in the target configuration information according to the preset constraint meta-statement to obtain the logical parameter name and constraint parsing information corresponding to each constraint item contained in the constraint information; Perform parameter polling and allocation based on the constraint parsing information corresponding to each logical parameter name to obtain a configuration parameter value; A logical object parameter is generated based on the combination of the logical parameter name and the configuration parameter value.

7. The network tunnel creation method according to claim 6, characterized in that: Generating a logical object according to the target configuration information and the logical constraint parameters includes: Create initial logical objects; According to the target configuration information, at least one tunnel creation step corresponding to each tunnel creation type is read, and based on the tunnel creation type, the at least one tunnel creation step, and the logical object parameters contained in each tunnel creation step, the initial logical object is filled to generate a generated logical object corresponding to each tunnel creation type.

8. A network tunnel creation device, characterized in that: The device comprises: An acquisition module, configured to acquire a tunnel configuration file, wherein the tunnel configuration file includes at least a tunnel creation type, multiple tunnel creation steps, and constraint information; A conversion module, configured to convert the tunnel configuration file into target configuration information corresponding to a target format; a parsing module, configured to parse the constraint information in the target configuration information according to a preset constraint meta-statement, obtain logical constraint parameters, and generate a logical object according to the target configuration information and the logical constraint parameters; a generation module, configured to generate a task queue based on each tunnel creation step in the logic object and the corresponding logical constraint parameters through a target reflection mechanism, wherein the task queue includes a plurality of creation subtasks having an ordered relationship, and each creation subtask corresponds to a tunnel creation step; The creation module is used to execute each creation subtask in the task queue in sequence to create a network tunnel of the tunnel creation type.

9. A computer device, characterized in that: The computer device includes a memory and a processor, the memory stores a computer program, and the processor implements the network tunnel creation method according to any one of claims 1 to 7 when executing the computer program.

10. A computer-readable storage medium storing a computer program, characterized in that: When the computer program is executed by a processor, the network tunnel creation method according to any one of claims 1 to 7 is implemented.

Images