Lightweight internal network interface dynamic routing agent system

Abstract

The invention relates to the technical field of computer network communication, in particular to a lightweight intranet interface dynamic routing agent system which comprises a rule management module, a routing analysis module and a request processing module. The rule management module provides an agent rule configuration interface and performs persistent storage, and comprises a configuration sub-module, a verification sub-module and a storage sub-module; the routing analysis module extracts a rule identifier from a public network request and retrieves a matching rule, and comprises an identifier extraction sub-module and a real-time retrieval sub-module; the request processing module executes preprocessing logic and forwards a request according to an original protocol, and comprises a script execution sub-module and a protocol forwarding sub-module. Dynamic routing is achieved, adaptability and operation and maintenance efficiency are improved, safety is guaranteed through multi-layer protection, deployment flexibility is enhanced through lightweight design, service continuity and communication quality are guaranteed, and the limitation of a traditional proxy technology is effectively solved.

Description

Technical Field

[0001] The present invention relates to the technical field of computer network communications, and in particular to a lightweight intranet interface dynamic routing proxy system. Background Art

[0002] In today's digital office environment, where complex network architectures intersect, enterprises and organizations face numerous challenges in network deployment. Among these challenges is how to efficiently and securely enable communication between public and intranet service interfaces, a key issue that needs to be addressed.

[0003] As businesses continue to expand, the number and variety of intranet services are growing increasingly complex. Many companies have built internal systems based on a microservices architecture, with different business functions handled by numerous independent service interfaces. These service interfaces are often deployed only within the intranet environment and, for security reasons, cannot be directly exposed to the public network. At the same time, external entities such as remote workers and partners need to access these intranet services. For example, remote employees need to access the company's intranet ERP system to process business processes, and partners need to call specific internal data interfaces to obtain collaborative data.

[0004] Traditional intranet penetration and proxy technologies exhibit significant limitations when addressing these scenarios. For example, in a common proxy system based on fixed configurations, changes to intranet service interfaces, such as adjustments to interface addresses or upgrades to service functionality, require extensive manual modification of proxy rules. This process is cumbersome, error-prone, and extremely inefficient. Misconfigurations can easily lead to request routing failures, severely impacting normal business operations.

[0005] Therefore, to address the above problems, a lightweight intranet interface dynamic routing proxy system is proposed. Summary of the Invention

[0006] The purpose of the present invention is to provide a lightweight intranet interface dynamic routing proxy system to solve the problems raised in the above background technology.

[0007] To achieve the above object, the present invention provides the following technical solutions:

[0008] A lightweight intranet interface dynamic routing proxy system, deployed on a jump server connecting the public network and the intranet, including:

[0009] The rule management module is used to provide the configuration interface and persistent storage of proxy rules;

[0010] The routing parsing module is used to extract the rule identifier from the public network request and retrieve the matching proxy rules in real time;

[0011] The request processing module is used to execute the pre-processing logic associated with the proxy rules and forward the request to the intranet service interface according to the original protocol specifications.

[0012] As a preferred solution, the rule management module includes:

[0013] The configuration submodule receives input data including a rule unique identification field, a target interface address field, and an optional pre-processing script field;

[0014] The check submodule verifies the global uniqueness of the rule's unique identifier and the compliance of the target interface address;

[0015] The storage submodule uses the unique identifier of the rule as the index key to persistently store the proxy rules.

[0016] As a preferred solution, the routing parsing module includes:

[0017] The identifier extraction submodule obtains the unique identifier of the rule by parsing the end node value of the request path;

[0018] The real-time retrieval submodule obtains the target interface address and preprocessing script based on the extracted identification query rule management module.

[0019] As a preferred solution, the request processing module includes:

[0020] The script execution submodule runs the preprocessing script in an isolated environment and modifies the original request data;

[0021] The protocol forwarding submodule maintains the HTTP method, header, and body data format of the original request and initiates a proxy request to the target interface address.

[0022] As a preferred solution, the storage submodule further includes:

[0023] Memory cache unit, which stores frequently accessed rules;

[0024] The database unit uses a non-static storage medium that supports real-time updates;

[0025] Cache synchronization unit maintains data consistency between memory cache and database.

[0026] As a preferred solution, the script execution submodule also includes:

[0027] Sandbox isolation unit, which limits the script's access to system resources;

[0028] The fuse control unit forcibly terminates the process when the script execution timeout threshold is reached;

[0029] Audit log unit, records script operation behavior and request data changes.

[0030] As a preferred solution, the identification extraction submodule is specifically configured as follows:

[0031] Identify inbound requests with a path format of {domain name}:{port number} / {rule unique identifier};

[0032] The last path segment is extracted through string splitting operation as the unique identifier of the rule.

[0033] As a preferred solution, the protocol forwarding submodule is further configured as follows:

[0034] Inherits the HTTPS encryption channel properties of the original request;

[0035] Append a tracking field containing the unique identifier of the rule to the request header;

[0036] When forwarding fails, an error message containing the destination interface address is returned.

[0037] It can be seen from the technical solutions provided by the present invention that the lightweight intranet interface dynamic routing proxy system provided by the present invention has the following beneficial effects:

[0038] 1. Dynamic routing improves system adaptability and operation and maintenance efficiency:

[0039] The present invention implements dynamic configuration and updating of proxy rules through a rule management module, allowing the addition, modification, or deletion of rules to be completed without restarting the system. When the intranet service interface address changes or the function is adjusted, only the corresponding rules need to be updated. The routing parsing module can identify and match the new rules in real time, and the request processing module completes request forwarding according to the new rules. This dynamic routing mechanism breaks away from the constraints of static configuration of traditional proxy systems, significantly reduces operation and maintenance costs, and enables the system to quickly adapt to the frequent iterations of intranet services. It is particularly suitable for scenarios that require flexible adjustment, such as microservice architectures.

[0040] 2. Multi-layer protection ensures safe operation of the system:

[0041] Rule verification ensures basic security: The verification submodule of the rule management module strictly verifies the global uniqueness of the rule's unique identifier and the compliance of the target interface address, preventing security risks caused by rule conflicts or pointing to illegal addresses, and ensuring the effectiveness of rules from the source.

[0042] Script execution is secure and controllable: The script execution submodule of the request processing module uses sandbox isolation technology to limit the access of pre-processing scripts to system resources and prevent malicious script attacks. The fuse control unit forcibly terminates the process after the script execution timeout to prevent system resource exhaustion. The audit log unit records script operations, providing a basis for security audits and fault tracing, ensuring script execution security from multiple dimensions.

[0043] Transmission security is maintained: The protocol forwarding submodule inherits the HTTPS encrypted channel properties of the original request, ensuring that data is not stolen or tampered with when the request is transmitted between the public network and the intranet. At the same time, a tracking field containing the unique identifier of the rule is added to make the request traceable throughout the entire process, enhancing the security and manageability of the transmission process.

[0044] 3. Lightweight design enhances system deployment flexibility:

[0045] The system is deployed on a jump server connecting the public and intranet networks. Each module has focused functionality and low coupling. The routing parsing module extracts rule identifiers through simple string segmentation, avoiding the performance loss associated with complex parsing logic. The storage submodule combines memory caching with a database, retrieving frequently accessed rules from memory, improving response speed while reducing storage resource requirements. This lightweight design allows the system to adapt to network environments of varying sizes, enabling stable deployment and operation in both small enterprise intranets and large, complex network architectures, while minimizing server resource usage.

[0046] 4. Reliable mechanisms to ensure service continuity:

[0047] Strong fault response capability: The cache synchronization unit of the storage submodule maintains data consistency between the memory cache and the database, avoiding routing errors caused by data inconsistency. When forwarding fails, the request processing module returns an error message containing the target interface address, facilitating rapid problem location.

[0048] Redundancy and isolation improve stability: The memory cache of the storage submodule forms storage redundancy with the database, reducing the risk of data loss. The sandbox isolation of the script execution submodule isolates script execution from the core functions of the system, preventing script anomalies from affecting the operation of the entire system and ensuring the stability of the core functions of the system.

[0049] 5. Precise routing and protocol maintenance improve communication quality:

[0050] The identifier extraction submodule of the routing parsing module accurately identifies the request path of a specific format, extracts the unique identifier of the rule and quickly retrieves the matching rule to ensure that the request can be accurately routed to the target intranet interface; the protocol forwarding submodule of the request processing module strictly maintains the HTTP method, header and body data format of the original request, so that the intranet service interface can correctly identify and process the request, reducing communication errors caused by protocol conversion or format changes, and improving the accuracy and efficiency of communication between the public network and the intranet service interface. BRIEF DESCRIPTION OF THE DRAWINGS

[0051] Figure 1 This is a schematic diagram of the overall structure of a lightweight intranet interface dynamic routing proxy system of the present invention. DETAILED DESCRIPTION

[0052] In order to make the purpose, technical solutions and advantages of the present invention more clearly understood, the present invention will be 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 the present invention and are not intended to limit the present invention.

[0053] In order to better understand the above technical solution, the above technical solution will be described in detail below with reference to the accompanying drawings and specific implementation methods.

[0054] like Figure 1 As shown, an embodiment of the present invention provides a lightweight intranet interface dynamic routing proxy system, which is deployed on a jump server connecting the public network and the intranet, including:

[0055] The rule management module is used to provide the configuration interface and persistent storage of proxy rules;

[0056] The routing parsing module is used to extract the rule identifier from the public network request and retrieve the matching proxy rules in real time;

[0057] The request processing module is used to execute the pre-processing logic associated with the proxy rules and forward the request to the intranet service interface according to the original protocol specifications.

[0058] In this embodiment, the rule management module includes:

[0059] The configuration submodule receives input data including a rule unique identification field, a target interface address field, and an optional pre-processing script field;

[0060] The check submodule verifies the global uniqueness of the rule's unique identifier and the compliance of the target interface address;

[0061] The storage submodule uses the unique identifier of the rule as the index key to persistently store the proxy rules;

[0062] The storage submodule further includes:

[0063] Memory cache unit, which stores frequently accessed rules;

[0064] The database unit uses a non-static storage medium that supports real-time updates;

[0065] Cache synchronization unit, maintaining data consistency between memory cache and database;

[0066] Furthermore, the rule management module is the "rule center" of the lightweight intranet interface dynamic routing proxy system. It provides a solid rule foundation for the system's dynamic routing function through effective configuration, strict verification, and reliable storage of proxy rules. Whether it is the inclusion of new rules or the maintenance of existing rules, it is efficiently handled by this module, ensuring that the routing parsing module and the request processing module can obtain accurate rule information. The following is a detailed explanation of this module from the overall perspective:

[0067] 1. Overview of overall functions:

[0068] The rule management module is primarily responsible for receiving input data containing the rule unique identifier field, the target interface address field, and the optional pre-processing script field. It then performs strict validation on this data, verifying the global uniqueness of the rule unique identifier and the compliance of the target interface address. Finally, it persistently stores the proxy rules using the rule unique identifier as the index key. At the same time, this module also provides a rule query interface for other modules, such as the routing parsing module, to ensure that during system operation, relevant modules can quickly and accurately obtain the required proxy rules, thereby ensuring the smooth implementation of the dynamic routing proxy function.

[0069] 2. Submodule composition and functions:

[0070] (1) Configuration submodule:

[0071] Data reception: This submodule specifically receives externally input proxy rule-related data, which includes the rule unique identification field, the target interface address field, and an optional pre-processing script field. Whether the rules are manually entered through the system front-end interface or batch imported through other system interfaces, this submodule can accurately receive and perform preliminary processing.

[0072] Data format conversion: Converts received input data in different formats into a unified data format within the system for subsequent processing by the verification submodule and storage submodule. For example, data received in JSON or XML formats is converted into structured data that the system can directly recognize and process.

[0073] (2) Check submodule:

[0074] Rule unique identifier verification: Perform global uniqueness verification on the rule unique identifier passed by the configuration submodule; by querying the unique identifiers of all rules stored in the system, determine whether the currently received identifier already exists; if it does, the rule is determined to be non-compliant, subsequent storage operations are rejected, and the corresponding error message is returned; if it does not exist, the verification passes;

[0075] Target interface address compliance verification: Checks whether the target interface address meets the preset compliance standards. Verification includes whether the address format is correct, such as whether it contains a valid domain name or IP address, and whether the port number is within a reasonable range. At the same time, it checks whether the address falls within the valid address range of the intranet service interface to prevent the rule from being directed to illegal or irrelevant external addresses.

[0076] (3) Storage submodule:

[0077] Memory cache unit: used to store frequently accessed proxy rules. When the routing parsing module frequently queries certain rules, they can be directly obtained from the memory cache, greatly improving the query speed of the rules, reducing the access pressure on the database, and improving the overall response efficiency of the system.

[0078] Database unit: Uses non-static storage media that supports real-time updates, such as relational databases or NoSQL databases, to persistently store all proxy rules. This ensures that rules are not lost due to system restarts or other unexpected situations, providing a stable source of rule data for the system.

[0079] Cache synchronization unit: Responsible for maintaining data consistency between the memory cache and the database. When rules in the database are added, modified, or deleted, the cache synchronization unit promptly synchronizes these changes to the memory cache. Furthermore, when rules in the memory cache need to be updated for some reason (such as cache expiration), the cache synchronization unit retrieves the latest data from the database for synchronization, ensuring that the rule information in the two storage locations remains consistent.

[0080] 3. Key technical principles:

[0081] (1) Configuration input parsing principle:

[0082] The configuration submodule uses a specific parsing algorithm to parse the received input data. This algorithm can identify key fields in different data formats, such as the rule unique identifier, target interface address, and preprocessing script, extract them, and map them to the data structure defined within the system. In this way, no matter how the input data format changes, as long as it contains the required key fields, it can be accurately parsed and processed.

[0083] (2) Verification logic principle:

[0084] Uniqueness verification logic: This system uses a hash table data structure to quickly query and compare rule unique identifiers. All existing rule unique identifiers are stored in the hash table. When a new rule unique identifier is received, its hash value is calculated using a hash function and then searched in the hash table. If the corresponding hash value is found, the identifier already exists; otherwise, it does not. This approach greatly improves the efficiency of uniqueness verification, ensuring rapid verification even with a large number of rules.

[0085] Compliance verification logic: The target interface address is verified using a preset regular expression and rule base. Regular expressions are used to verify the correct format of the address, such as whether the IP address format complies with the IPv4 or IPv6 standard and whether the domain name contains valid characters and structures. The rule base contains information such as the valid address range of the intranet service interface. By comparing the target interface address with the information in the rule base, it is determined whether it is a compliant address.

[0086] (3) Storage architecture principles:

[0087] The storage submodule adopts a two-level storage architecture, combining memory cache with a database. The memory cache uses a key-value pair storage method, with the rule's unique identifier as the key and the proxy rule information as the value, to achieve fast access to the rules. The database uses a structured method to store rules, supporting complex queries and transaction operations, ensuring data persistence and reliability. The cache synchronization unit obtains rule change information in real time by monitoring database change events (such as triggers or log monitoring) and synchronizes it to the memory cache. At the same time, an expiration policy for the memory cache is set. When the rules in the cache expire, the latest data is automatically loaded from the database to ensure data consistency between the two.

[0088] 4. Module workflow:

[0089] (1) Initialization phase:

[0090] After the rule management module is started, it completes the initialization of its related components, including setting parsing parameters of the configuration submodule, loading regular expressions and rule base of the verification submodule, establishing database connection of the storage submodule, and initializing memory cache.

[0091] Load all proxy rules from the database into the memory cache (or load some frequently accessed rules according to the preset cache strategy) to establish an initial rule storage system;

[0092] (2) Configuration input stage:

[0093] The configuration submodule receives externally input proxy rule data, converts its format, and extracts key fields such as the rule unique identifier, target interface address, and preprocessing script;

[0094] Pass the converted structured data to the verification submodule for verification;

[0095] (3) Verification stage:

[0096] The verification submodule first performs global uniqueness verification on the rule unique identifier and uses the hash table for fast query and comparison;

[0097] If the uniqueness check passes, the target interface address is then checked for compliance using regular expressions and a rule base.

[0098] If the verification passes, the rule data is passed to the storage submodule; if the verification fails, an error message is returned to the configuration submodule, which then feeds it back to the input source;

[0099] (IV) Storage stage:

[0100] The storage submodule stores the verified rule data into the database, using the rule's unique identifier as the index key.

[0101] The cache synchronization unit detects new rule additions in the database and synchronizes the rule to the memory cache to ensure data consistency between the memory cache and the database.

[0102] (V) Rule update stage:

[0103] When a stored rule needs to be modified or deleted, the configuration submodule receives the update instruction and related data, converts the format, and passes it to the verification submodule (modification operations require re-verification of uniqueness and compliance, while deletion operations do not require verification);

[0104] After verification is passed (modification operation) or deletion is confirmed, the storage submodule performs corresponding update or deletion operations on the rules in the database;

[0105] The cache synchronization unit synchronizes the changes in the database to the memory cache and updates or deletes the corresponding rules in the memory cache;

[0106] (6) Rule query response phase:

[0107] When other modules such as the routing parsing module initiate a rule query request, the storage submodule first checks whether the corresponding rule exists in the memory cache;

[0108] If the rule exists, it is directly retrieved from the memory cache and returned to the query module; if it does not exist, the rule is retrieved from the database, returned to the query module, and stored in the memory cache so that it can be quickly retrieved in subsequent queries;

[0109] 5. Application value of the module:

[0110] (1) Ensuring the accuracy and effectiveness of the rules:

[0111] The strict verification of the verification submodule ensures that the unique identifier of the rule will not be repeated, avoiding routing confusion caused by identifier conflicts. At the same time, it ensures the compliance of the target interface address, prevents the rule from pointing to the wrong or illegal address, and provides a reliable rule basis for the correct routing of the system.

[0112] (2) Improving the efficiency of rule access:

[0113] The storage submodule adopts an architecture that combines memory cache and database. Frequently accessed rules can be quickly retrieved from the memory cache, greatly shortening the response time of rule queries and improving the overall operating efficiency of the system. The persistent storage of the database ensures the security and integrity of the rules.

[0114] (3) Support dynamic update of rules:

[0115] This module can receive and process new rule configurations, as well as rule modification and deletion operations in real time. The cache synchronization unit ensures consistency between the memory cache and the database, enabling the system to quickly adapt to changes in the intranet service interface. Dynamic rule updates can be achieved without restarting the system, improving system flexibility and maintainability.

[0116] (IV) Providing support for the stable operation of the system:

[0117] As the rule center of the system, the stable operation of the rule management module directly affects the reliability of the entire dynamic routing proxy system; its complete verification mechanism and storage architecture ensure the accuracy, security and efficient access of rule data, providing a solid guarantee for the identity matching of the routing resolution module and the protocol forwarding of the request processing module, and promoting the stable and efficient operation of the entire system.

[0118] In this embodiment, the routing parsing module includes:

[0119] The identifier extraction submodule obtains the unique identifier of the rule by parsing the end node value of the request path;

[0120] The real-time retrieval submodule obtains the target interface address and preprocessing script based on the extracted identification query rule management module;

[0121] The identity extraction submodule is specifically configured as follows:

[0122] Identify inbound requests with a path format of {domain name}:{port number} / {rule unique identifier};

[0123] Extract the last path segment as the unique identifier of the rule through string splitting operation;

[0124] Furthermore, the routing parsing module is the "path navigation core" of the lightweight intranet interface dynamic routing proxy system. It acts as the "eyes" and "brain" of the system. By accurately extracting rule identifiers from public network requests and quickly retrieving matching proxy rules, it indicates the forwarding direction for the request processing module. This is a key step in implementing dynamic routing. The following describes this module in detail:

[0125] 1. Overview of overall functions:

[0126] The routing parsing module is mainly responsible for extracting rule identifiers from public network requests and retrieving matching proxy rules in real time based on the identifiers. It receives requests from the public network, obtains the unique identifier of the rule through a specific parsing method, and then queries the rule management module for the corresponding target interface address and preprocessing script based on this identifier. This provides accurate rule basis for the request processing module to perform subsequent preprocessing and forwarding operations, ensuring that the request can be accurately routed to the corresponding intranet service interface.

[0127] 2. Submodule composition and functions:

[0128] (1) Logo extraction submodule:

[0129] Request path identification: Specialized identification of inbound requests with the path format of {domain name}:{port number} / {rule unique identifier}. It can accurately determine whether incoming public network requests conform to the preset path format. Only requests that conform to the format will be subject to subsequent identifier extraction operations, ensuring the pertinence and effectiveness of the extraction work.

[0130] Rule unique identifier extraction: The last segment of the request path is extracted through string splitting as the rule unique identifier. For example, for a request with the path example.com:8080 / rule123, after string splitting, "rule123" is extracted as the rule unique identifier, providing key information for subsequent rule retrieval.

[0131] (2) Real-time retrieval submodule:

[0132] Initiate a rule query request: Based on the unique rule identifier extracted by the identifier extraction submodule, initiate a rule query request to the rule management module; clearly inform the rule management module of the rule identifier to be queried to ensure the accuracy of the query target;

[0133] Target information acquisition: Obtain the target interface address and pre-processing script corresponding to the unique identifier of the rule from the rule management module; after receiving the information returned by the rule management module, organize and temporarily store it so that it can be passed to the request processing module in a timely manner to ensure the smooth progress of the request processing process;

[0134] 3. Key technical principles:

[0135] (1) Principle of logo extraction technology:

[0136] The identifier extraction submodule uses string processing technology to extract the rule's unique identifier. Its core is to segment the request path using a preset delimiter (usually " / "), breaking the path into multiple path segments. Since the rule's unique identifier is located at the end of the path, the last segment obtained after segmentation is the required rule's unique identifier. This simple and efficient technology can quickly and accurately extract key identifiers from formatted request paths, while consuming minimal system resources, ensuring the module's lightweight nature.

[0137] (2) Principles of real-time retrieval technology:

[0138] The real-time retrieval submodule uses index-based fast query technology. The rule management module stores proxy rules using the rule's unique identifier as the index key. The real-time retrieval submodule uses this index key to search the rule management module's storage structure (memory cache or database) using an efficient query algorithm (such as a hash search algorithm). The hash search algorithm maps the rule's unique identifier to a hash value, allowing it to directly locate the location where the rule may be stored, significantly shortening query time and ensuring real-time retrieval even when a large number of rules exist, meeting the system's response speed requirements.

[0139] 4. Module workflow:

[0140] (1) Initialization phase:

[0141] After the routing parsing module is started, it completes the initialization of its own components, including the setting of path format recognition parameters of the identity extraction submodule, the establishment of communication connection between the real-time retrieval submodule and the rule management module, etc.

[0142] Load the preset request path format standard to prepare for subsequent request identification work;

[0143] (2) Request reception stage:

[0144] Receive inbound requests from the public network and store the request information in the module's temporary buffer;

[0145] Perform a preliminary screening of requests, eliminate invalid requests that clearly do not comply with basic communication protocols, and retain only potentially valid requests for subsequent processing;

[0146] (III) Identification extraction stage:

[0147] The identifier extraction submodule identifies the format of the received request path and determines whether it is in the format of {domain name}:{port number} / {rule unique identifier};

[0148] For request paths that meet the format, string segmentation is used to extract the last path segment as the unique identifier of the rule; for requests that do not meet the format, an error message is returned to inform the request source that the path format is incorrect;

[0149] (IV) Real-time retrieval stage:

[0150] The real-time retrieval submodule obtains the unique rule identifier extracted by the identifier extraction submodule and generates a rule query request;

[0151] Send the query request to the rule management module and wait for it to return the corresponding target interface address and preprocessing script;

[0152] Receive the information returned by the rule management module. If the corresponding rule information is found, it will be passed to the request processing module; if not, an error message indicating that the rule does not exist will be returned.

[0153] 5. Application value of the module:

[0154] 1. Ensuring routing accuracy:

[0155] Through precise identification extraction and real-time retrieval, the routing parsing module can accurately find the corresponding proxy rules for each public network request, thereby ensuring that the request can be accurately forwarded to the target intranet service interface, avoiding the situation where the request fails or is sent to the wrong interface due to routing errors, and improving the accuracy of system routing;

[0156] (2) Improve system response speed:

[0157] The use of efficient string segmentation technology and hash search algorithm makes the identification extraction and rule retrieval process fast and efficient. It can complete the parsing and rule matching of requests in a short time, reducing the time spent on request routing and parsing, improving the response speed of the entire system, and providing users with a smoother user experience.

[0158] (3) Enhance system flexibility:

[0159] Since the routing parsing module performs dynamic routing based on the unique identifier of the rule, when the intranet service interface changes, the corresponding rule information only needs to be updated through the rule management module, and the routing parsing module can automatically route according to the new rule without modifying the module itself, which enhances the system's adaptability and flexibility to changes in the network environment;

[0160] (4) Ensuring the consistency of request processing:

[0161] As the intermediate link connecting public network requests and the rule management module and request processing module, the routing resolution module can transmit rule information in a timely and accurate manner, ensuring that the request processing module can pre-process and forward requests according to the correct rules, thus ensuring the continuity and smoothness of the entire request processing process. It is an indispensable and important component for the stable operation of the system.

[0162] In this embodiment, the request processing module includes:

[0163] The script execution submodule runs the preprocessing script in an isolated environment and modifies the original request data;

[0164] The protocol forwarding submodule maintains the HTTP method, header, and body data format of the original request and initiates a proxy request to the target interface address;

[0165] The script execution submodule also includes:

[0166] Sandbox isolation unit, which limits the script's access to system resources;

[0167] The fuse control unit forcibly terminates the process when the script execution timeout threshold is reached;

[0168] Audit log unit, recording script operation behavior and request data changes;

[0169] The protocol forwarding submodule is further configured as follows:

[0170] Inherits the HTTPS encryption channel properties of the original request;

[0171] Append a tracking field containing the unique identifier of the rule to the request header;

[0172] When forwarding fails, an error message containing the target interface address is returned;

[0173] Furthermore, the request processing module is the "request processing center" of the lightweight intranet interface dynamic routing proxy system. It inherits the rule information passed by the routing parsing module, pre-processes the request, and forwards it according to the specifications. It is the core link to achieve smooth communication between the public network and the intranet service interface. The following is a detailed explanation of this module from the overall perspective:

[0174] 1. Overview of overall functions:

[0175] The request processing module is mainly responsible for executing the pre-processing logic associated with the proxy rules and forwarding the request to the intranet service interface according to the original protocol specifications. It receives the target interface address and pre-processing script provided by the routing resolution module, runs the pre-processing script in an isolated environment to modify the original request data, and then strictly follows the HTTP method, header and body data format of the original request to initiate a proxy request to the target interface address, ensuring that the request can still be correctly identified and responded to by the intranet service interface after processing.

[0176] 2. Submodule composition and functions:

[0177] (1) Script execution submodule:

[0178] Sandbox isolation unit: restricts the access rights of pre-processed scripts to system resources, such as prohibiting scripts from accessing sensitive areas such as the local file system and network resources, to prevent malicious or defective scripts from damaging the system and ensure system security;

[0179] Circuit Breaker Control Unit: Sets a timeout threshold for script execution. When the script execution time exceeds the threshold, the process is automatically terminated. This prevents the entire request processing flow from being blocked due to script execution falling into an infinite loop or taking too long, thus ensuring system efficiency.

[0180] Audit log unit: records the script's operational behavior in detail, including the content and time of the script's modification of the request data, as well as the changes in the request data before and after processing. This log information can be used for subsequent troubleshooting, security audits, and accountability tracing.

[0181] Script execution and request modification: Run pre-processing scripts in a sandbox isolation environment and modify the original request data accordingly based on the script logic, such as adding authentication information and filtering sensitive parameters, to ensure that the request meets the specific requirements of the intranet service interface.

[0182] (2) Protocol forwarding submodule:

[0183] Protocol attribute preservation: Inherits the HTTPS encryption channel attributes of the original request, ensuring the security of the request during transmission and preventing data from being stolen or tampered with during forwarding;

[0184] Tracking field appending: append a tracking field containing the unique identifier of the rule to the request header, making it easier for the intranet service interface and subsequent log analysis to identify the proxy rule corresponding to the request, thus achieving full tracking of the request;

[0185] Proxy request initiation: Strictly maintain the original request's HTTP method (such as GET, POST, etc.), header information, and body data format, and initiate a proxy request to the target interface address to ensure that the intranet service interface can process the request as expected;

[0186] Error handling: When a forwarding request fails, an error message containing the target interface address is returned, allowing the request initiator to clearly understand the relevant information of the request failure and facilitate troubleshooting;

[0187] 3. Key technical principles:

[0188] (1) Script execution technology principle:

[0189] The script execution submodule is implemented based on sandbox technology and process management technology. Sandbox technology creates a restricted operating environment, provides an independent resource space for script execution, isolates it from other parts of the system, and limits the script's resource access rights by setting access control lists. The fuse control unit uses a process monitoring mechanism to monitor the running time of the script execution process in real time. When the preset threshold is reached, it calls the system interface to forcibly terminate the process. The audit log unit uses technologies such as hook functions to capture the script's operation events on the requested data and record the relevant information in a log file or database.

[0190] (2) Principles of protocol forwarding technology:

[0191] The protocol forwarding submodule implements request forwarding based on the HTTP / HTTPS protocol specifications. It first parses the protocol information of the original request, including the HTTP method, header fields, and request body, and strictly maintains the integrity and format correctness of this information during the forwarding process. For HTTPS encrypted channels, it inherits the encryption properties of the original request through session reuse or re-handshake of the SSL / TLS protocol. When appending tracking fields to the request header, it follows the naming conventions and format requirements of the HTTP header fields to ensure that the legitimacy of the request is not affected. When forwarding fails, based on the failure reason (such as connection timeout, target address unreachable, etc.), an error message containing the target interface address is generated and returned according to the HTTP error response specification.

[0192] 4. Module workflow:

[0193] (1) Initialization phase:

[0194] After the request processing module is started, the initialization configuration of the script execution submodule and the protocol forwarding submodule is completed;

[0195] The script execution submodule initializes sandbox environment parameters, sets the timeout threshold for circuit breaker control, and configures the storage path and format of audit logs. The protocol forwarding submodule initializes network connection parameters and loads HTTPS encryption-related certificates and keys.

[0196] Establish a communication connection with the routing parsing module and prepare to receive information such as the target interface address and preprocessing script;

[0197] (2) Script execution and request preprocessing stage:

[0198] Receive the target interface address and pre-processing script passed by the routing parsing module, and pass the pre-processing script to the script execution sub-module;

[0199] The script execution submodule starts the sandbox isolation unit to create an isolated environment for script execution and starts the fuse control unit to start timing;

[0200] Run the preprocessing script in the sandbox environment. The script modifies the original request data according to the preset logic. The audit log unit simultaneously records the script operation and data changes.

[0201] If the script execution completes normally without a timeout, the modified request data is obtained. If a circuit breaker condition (timeout) is triggered, the script execution is terminated and the relevant error log is recorded. The default request processing strategy may be adopted or an error message may be returned.

[0202] (3) Protocol forwarding stage:

[0203] After the script is executed, the script execution submodule passes the modified request data and target interface address to the protocol forwarding submodule;

[0204] The protocol forwarding submodule inherits the HTTPS encrypted channel properties of the original request and appends a tracking field containing the unique identifier of the rule to the request header;

[0205] Initiate a proxy request to the target interface address according to the HTTP method, header, and body data format of the original request;

[0206] If the request is forwarded successfully, wait for the response from the intranet service interface and return the response result to the public network request initiator along the original path; if the forwarding fails, generate an error message containing the target interface address and return it to the request initiator;

[0207] 5. Application value of the module:

[0208] (1) Improving the flexibility and adaptability of request processing:

[0209] The script execution submodule pre-processes the request data and can flexibly adjust the request content according to the needs of different intranet service interfaces. This enables the system to adapt to various intranet service interfaces with special requirements without requiring large-scale modifications to the proxy system itself, thus enhancing the system's versatility.

[0210] (2) Ensuring system security and stable operation:

[0211] The sandbox isolation unit and the fuse control unit provide dual protection for script execution, effectively preventing threats to the system from malicious and abnormal scripts, and reducing the risk of system failures caused by script problems. The audit log unit provides a reliable basis for system security audits and troubleshooting, helping to promptly discover and resolve security risks.

[0212] (3) Ensure the compliance and traceability of request transmission:

[0213] The protocol forwarding submodule strictly adheres to the original protocol specifications when forwarding requests, ensuring compliance during transmission and enabling the intranet service interface to correctly handle requests. The added tracking field enables full traceability of requests, making it easier for administrators to understand the request flow path and processing status, improving system manageability.

[0214] (IV) Optimizing the communication experience between the public network and the intranet:

[0215] The request processing module acts as a bridge between the public network and the intranet service interface. Through efficient preprocessing and forwarding operations, it ensures that requests can reach the intranet service interface quickly and accurately and receive responses, reducing delays and errors in the communication process, improving the overall communication experience, and providing reliable protection for users to use intranet services.

[0216] While embodiments of the present invention have been shown and described, it will be appreciated by those skilled in the art that various changes, modifications, substitutions, and variations may be made to these embodiments without departing from the principles and spirit of the invention, and that the scope of the invention is defined by the appended claims and their equivalents.

Claims

1. A lightweight intranet interface dynamic routing proxy system, deployed on a jump server connecting the public network and the intranet, characterized by: include: The rule management module is used to provide the configuration interface and persistent storage of proxy rules; The routing parsing module is used to extract the rule identifier from the public network request and retrieve the matching proxy rules in real time; The request processing module is used to execute the pre-processing logic associated with the proxy rules and forward the request to the intranet service interface according to the original protocol specifications.

2. A lightweight intranet interface dynamic routing proxy system according to claim 1, characterized in that: The rule management module includes: The configuration submodule receives input data including a rule unique identification field, a target interface address field, and an optional pre-processing script field; The check submodule verifies the global uniqueness of the rule's unique identifier and the compliance of the target interface address; The storage submodule uses the unique identifier of the rule as the index key to persistently store the proxy rules.

3. A lightweight intranet interface dynamic routing proxy system according to claim 1, characterized in that: The routing parsing module includes: The identifier extraction submodule obtains the unique identifier of the rule by parsing the end node value of the request path; The real-time retrieval submodule obtains the target interface address and preprocessing script based on the extracted identification query rule management module.

4. A lightweight intranet interface dynamic routing proxy system according to claim 1, characterized in that: The request processing module includes: The script execution submodule runs the preprocessing script in an isolated environment and modifies the original request data; The protocol forwarding submodule maintains the HTTP method, header, and body data format of the original request and initiates a proxy request to the target interface address.

5. A lightweight intranet interface dynamic routing proxy system according to claim 2, characterized in that: The storage submodule further includes: Memory cache unit, which stores frequently accessed rules; The database unit uses a non-static storage medium that supports real-time updates; Cache synchronization unit maintains data consistency between memory cache and database.

6. A lightweight intranet interface dynamic routing proxy system according to claim 4, characterized in that: The script execution submodule also includes: Sandbox isolation unit, which limits the script's access to system resources; The fuse control unit forcibly terminates the process when the script execution timeout threshold is reached; Audit log unit, records script operation behavior and request data changes.

7. A lightweight intranet interface dynamic routing proxy system according to claim 3, characterized in that: The identification extraction submodule is specifically configured as follows: Identify inbound requests with a path format of {domain name}:{port number} / {rule unique identifier}; The last path segment is extracted through string splitting operation as the unique identifier of the rule.

8. A lightweight intranet interface dynamic routing proxy system according to claim 4, characterized in that: The protocol forwarding submodule is further configured to: Inherits the HTTPS encryption channel properties of the original request; Append a tracking field containing the unique identifier of the rule to the request header; When forwarding fails, an error message containing the destination interface address is returned.

Images