Intranet penetration service agent method, system and device based on trusted tunnel

Abstract

This invention relates to the field of intranet penetration communication technology, specifically to an intranet penetration service proxy method, system, and device based on a trusted tunnel. The method includes: a client initiating a registration request to a server to establish a trusted tunnel based on the TCP protocol; establishing a multiplexed session on the trusted tunnel; the client traversing its local services, constructing and sending a service registration request to the server; the server creating a mapping object to establish a correspondence between the externally exposed entry point, the client, and the local service address; upon receiving an access request, the server determines the target client and the target local service address based on stored mapping data, creates a data flow channel in the corresponding session, sends the target local service address to the target client for verification, and after successful verification, forwards the access request data through the data flow channel and returns response data to the user. This enables high-concurrency transmission and automatic service registration for intranet penetration communication.

Description

Technical Field

[0001] This invention relates to the field of intranet penetration communication technology, specifically to an intranet penetration service proxy method, system, and device based on trusted tunnels. Background Technology

[0002] In the field of intranet penetration technology, enabling users to access intranet services through the external network typically adopts a proxy forwarding architecture: a proxy server is deployed on the public network side, and a proxy client is deployed on the intranet side. The two sides establish a communication link, and external requests, i.e., access request data, are forwarded from the proxy server to the proxy client through this link, and then delivered to the service in the intranet by the proxy client.

[0003] However, the aforementioned existing technologies have the following shortcomings in practical applications:

[0004] First, concurrent processing capabilities are limited. In existing technologies, most implementations employ a serial request processing mechanism, meaning only one request can be processed at a time, and subsequent requests must queue and wait for the current request to complete before receiving service. When a large number of requests arrive in a short period, request backlog leads to a sharp increase in response latency. Some solutions attempt to alleviate this problem by establishing multiple TCP connections, but establishing each connection requires a three-way handshake and a four-way handshake, significantly increasing system overhead. Furthermore, a large number of simultaneous connections consume significant server-side port resources and file descriptors.

[0005] Second, existing solutions typically use static configuration files to define forwarding rules, requiring operations and maintenance personnel to manually edit these files and set the mapping relationship between ports and internal network services. When internal network services change (such as service migration, adding new instances, or changing ports), the configuration file needs to be modified and the proxy service restarted for the changes to take effect, which is cumbersome and can cause service interruptions.

[0006] Therefore, how to improve the concurrent processing capability of the intranet penetration system while maintaining low system overhead, and how to simplify the service configuration process and avoid cumbersome configuration modifications and restart operations when services change, are important issues faced by those skilled in the art. Summary of the Invention

[0007] In view of this, the purpose of this invention is to provide a method, system and device for intranet penetration service proxy based on trusted tunnels, so as to overcome the problems of weak concurrency and cumbersome and inflexible configuration in the current intranet penetration communication technology field.

[0008] To achieve the above objectives, the present invention adopts the following technical solution: In a first aspect, embodiments of this application provide a proxy method for intranet penetration service based on trusted tunnels, applied to an intranet penetration service system based on trusted tunnels. The system includes a server deployed on the public network and a client deployed on the intranet, and the client can communicate with its corresponding local service, including: The client initiates a client registration request based on the HTTP protocol to the server. After authentication, a trusted tunnel based on the TCP protocol is established with the server. Each trusted tunnel corresponds one-to-one with each of the aforementioned clients. The client and server establish a multiplexed session on the trusted tunnel, wherein each session corresponds one-to-one with each local service of the client; The client iterates through its corresponding local services, constructs URL or port mapping registration information for each local service, generates a service registration request based on the URL or port mapping registration information, and sends it to the server. The server receives and verifies the service registration request. After successful verification and confirmation of no conflicts, it creates a mapping object and stores the mapping data. The mapping object is used to establish the correspondence between the server's externally exposed entry point, the client, and the client's local service address. The server's externally exposed entry point includes the URL path corresponding to the URL mapping registration information and the port corresponding to the port mapping registration information. When the server receives access request data from a user targeting the server's exposed entry point, it determines the target client and the target local service address based on the access request data and mapping data; and creates a data stream channel in the corresponding trusted tunnel session to send the target local service address to the target client for the target client to verify whether the target local service is available; and after successful verification, it sends the access request data to the target client through the data stream channel. The target client sends access request data to the target local service and receives response data returned by the target local service; and sends the response data to the server through the data stream channel; The server returns the response data to the user.

[0009] Furthermore, in some embodiments of this application, the client initiates a client registration request based on the HTTP protocol to the server, and after authentication, establishes a trusted tunnel based on the TCP protocol with the server, including: The client reads connection and authentication information from the configuration file, generates a globally unique identifier based on the current device IP address and hostname, generates an HTTP registration request, and sends the HTTP registration request to the server through the server's management port; After verifying the legality and uniqueness of the globally unique identifier, the server upgrades the HTTP connection between the client and the server to a TCP connection through the HTTP protocol upgrade mechanism, and determines the encryption mechanism for tunnel data transmission.

[0010] Furthermore, in some embodiments of this application, the establishment of a multiplexed session between the client and the server on the trusted tunnel includes: The client and server respectively create smux sessions on the TCP connection that correspond one-to-one with the client's local service, configure optimization parameters, and wrap the created smux sessions as managed objects of the corresponding tunnel managers, including the client's tunnel manager and the server's tunnel manager. The server starts a heartbeat detection mechanism through the smux protocol stack, sending probe frames to the client at preset intervals. If no response frame is received from the client within the heartbeat timeout period, the offline processing procedure is triggered. The offline processing procedure includes closing the corresponding smux session and TCP connection, and updating the status of the corresponding client or local service to offline.

[0011] Furthermore, in some embodiments of this application, the server receives and verifies the service registration request, and after successful verification and confirmation of no conflict, creates a mapping object and stores the mapping data, including: After receiving a service registration request from the client, the server verifies the correctness of the client's authentication information carried in the service registration request. If the verification fails, an unauthorized error is returned. If the verification passes, the server checks whether the URL or port mapping registration information carried in the service registration request conflicts with existing mapping data. If there is no conflict, a URL mapping object is created and the mapping data is stored for the URL mapping registration information, and a port mapping object is created and the mapping data is stored for the port mapping registration information; This includes checking whether the URL or port mapping registration information carried in the service registration request conflicts with existing mapping data, including: Check if the URL path or port from the service registration request exists in the current mapping data; If it does not exist, a URL mapping object is created for the client that sent the service registration request, or a port is allocated to create a port mapping object; If it exists, check whether the client occupying the URL path or port in the current mapping data is the same client as the client that sent the service registration request. If yes, return information about the created message or the updated server-side service; if no, check if the client status recorded in the current mapping data that occupies the URL path or port is online. If the client is online, a conflict is determined; if the client is offline, a URL mapping object is created for the client that sent the service registration request, or a port is allocated to create a port mapping object.

[0012] Furthermore, in some embodiments of this application, the step of creating a data stream channel in the session corresponding to the trusted tunnel to send the target local service address to the target client for the target client to verify whether the target local service is available includes: The server determines a trusted tunnel corresponding to the target client, identifies a session corresponding to the target local service address within the dialogue of the trusted tunnel, and creates a data flow channel within that session. The server constructs a request message that includes the target local service address and sends the request message to the target client through the data stream channel; The target client receives and parses the request message to obtain the target local service address; and verifies whether the target local service corresponding to the target local service address is accessible. If it is accessible, it constructs a confirmation response message and sends the confirmation response message to the server through the data stream channel.

[0013] Furthermore, in some embodiments of this application, the target client sends access request data to the target local service, including: The target client and server determine whether to encrypt the access request data and response data based on the pre-configured encryption fields. If necessary, the data transmitted between the target client and server is encrypted based on the tunnel data transmission encryption mechanism.

[0014] Furthermore, in some embodiments of this application, it also includes: The server intercepts the received HTTP access request data and accumulates the HTTP request count value for the current hour in the memory cache area based on key feature information. For non-HTTP access request data, the server creates a monitored connection object corresponding to the original connection, and uses the monitored connection object to count the number of inbound and outbound traffic bytes, and accumulates the total traffic value for the current hour in the memory cache area based on the statistical results. When the hour arrives, the accumulated HTTP request count and total traffic value of the previous hour in the memory cache area are written to the database in batches, and a data merging operation is performed to generate a monitoring report.

[0015] Furthermore, in some embodiments of this application, it also includes: The server records the functional information of each local service. When the server times out when the client sends response data to the server, it determines an emergency local service address based on the access request data and the function information, so as to respond to the access request data through the local service corresponding to the emergency local service address. Alternatively, the server can associate various local services based on their functions; When the client times out sending response data to the server, the server determines an emergency local service address based on the association relationship, and responds to the access request data through the local service corresponding to the emergency local service address.

[0016] Secondly, embodiments of this application provide an intranet penetration service proxy system based on trusted tunnels, used to execute the method described above, including: a client and a server, wherein the client can communicate with its corresponding local service; The client is used to initiate a client registration request to the server to establish a trusted tunnel and a multiplexed session on the trusted tunnel; to traverse the local services corresponding to the client, generate a service registration request to request the server to create a mapping object and store the mapping data; to receive access request data through the data stream channel; to forward the access request data to the local service; and to send the response data returned by the local service to the server through the data stream channel. The server is used to maintain trusted tunnels and multiplexed sessions with each client; receive and verify service registration requests, create mapping objects and store mapping data; receive user access request data, create a data stream channel in the corresponding trusted tunnel session according to the mapping data, send the access request data to the target client through the data stream channel, and forward the response data returned by the target client to the user.

[0017] Thirdly, embodiments of this application provide an intranet penetration service proxy device based on a trusted tunnel, including a processor and a memory, wherein the processor is connected to the memory: The processor is used to call and execute the program stored in the memory; The memory is used to store the program, which is at least used to execute the above-described intranet penetration service proxy method based on trusted tunnels.

[0018] This invention relates to the field of intranet penetration communication technology, specifically to an intranet penetration service proxy method, system, and device based on a trusted tunnel. The method includes: a client initiating a registration request to a server to establish a trusted tunnel based on the TCP protocol; establishing a multiplexed session on the trusted tunnel; the client traversing its local services, constructing and sending a service registration request to the server; the server creating a mapping object to establish a correspondence between the externally exposed entry point, the client, and the local service address; upon receiving an access request, the server determines the target client and the target local service address based on stored mapping data, creates a data flow channel in the corresponding session, sends the target local service address to the target client for verification, and after successful verification, forwards the access request data through the data flow channel and returns response data to the user. This enables high-concurrency transmission and automatic service registration for intranet penetration communication. Attached Figure Description

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

[0020] Figure 1 This is a flowchart illustrating the intranet penetration service proxy method based on trusted tunnels provided in this embodiment of the invention.

[0021] Figure 2 This is a schematic diagram of the intranet penetration service proxy system based on trusted tunnels provided in an embodiment of the present invention.

[0022] Figure 3 This is a schematic diagram of the intranet penetration service proxy device based on trusted tunnels provided in an embodiment of the present invention. Detailed Implementation

[0023] To make the objectives, technical solutions, and advantages of this invention clearer, the technical solutions of this invention will be described in detail below. Obviously, the described embodiments are merely some embodiments of this invention, and not all embodiments. Based on the embodiments of this invention, all other implementation methods obtained by those skilled in the art without creative effort are within the scope of protection of this invention.

[0024] Figure 1 This is a flowchart illustrating the intranet penetration service proxy method based on trusted tunnels provided in an embodiment of the present invention. Please refer to... Figure 1 This embodiment may include the following steps: S101. The client initiates a client registration request based on the HTTP protocol to the server. After authentication, a trusted tunnel based on the TCP protocol is established between the client and the server.

[0025] Each trusted tunnel corresponds one-to-one with each client.

[0026] It is understandable that in this embodiment, the client, as a proxy node in the intranet, first needs to establish a communication link with the server deployed on the public network.

[0027] Specifically, the client proactively sends an HTTP registration request to the server, carrying the client's identity credentials. Upon receiving the registration request, the server verifies the client's identity. If verification is successful, the existing HTTP connection is upgraded to a persistent TCP connection, thus establishing a trusted tunnel between the client and the server. This trusted tunnel is the physical foundation for all subsequent data transmission.

[0028] It should be noted that in this application, each trusted tunnel uniquely corresponds to one client. That is, only one trusted tunnel is maintained between a client and the server (because the server can establish communication links with multiple clients, it can correspond to multiple trusted tunnels for establishing communication links with multiple clients respectively). This provides the foundation for subsequent multiplexing. By establishing a single TCP long connection for a client instead of multiple connections, the system overhead caused by frequently establishing and releasing connections can be effectively avoided.

[0029] S102. The client and server establish a multiplexed session on the trusted tunnel.

[0030] Each session corresponds one-to-one with a local service on the client.

[0031] Specifically, after the trusted tunnel is established, the client and server each create a multiplexed session on the trusted tunnel. In some embodiments of this application, the smux (Simple Multiplexing) protocol can be used to implement the multiplexing function. This session has the ability to virtualize multiple logical channels on a single physical connection, and each logical channel can transmit data independently without interference.

[0032] It should be noted that in this application, each session corresponds to a local service of the client (in practical applications, because the address of each local service is unique, sessions can be directly mapped to local service addresses). That is, the number of sessions created corresponds to the number of local services the client needs to expose, and a single session can be reused for a single local service. Through this multiplexing mechanism, multiple requests can be processed concurrently on the same trusted tunnel, eliminating the need to establish a separate trusted tunnel (such as a TCP connection) for each request, thereby significantly improving the system's concurrency capabilities and resource utilization.

[0033] S103. The client iterates through the corresponding local services, constructs URL or port mapping registration information for each local service, generates a service registration request based on the URL or port mapping registration information, and sends it to the server.

[0034] Specifically, based on the list of local services defined in the configuration file, the client determines the access method for each local service: if the service is an HTTP web service, it constructs URL mapping registration information for the service, such as the expected URL path; if the service is a non-HTTP service, it constructs port mapping registration information for the service, such as the expected port number. The client encapsulates the above information into a service registration request and sends it to the server through the established trusted tunnel (this step can be implemented by deploying an automatic identification mechanism).

[0035] S104. The server receives and verifies the service registration request, and after successful verification and confirmation of no conflict, creates a mapping object and stores the mapping data.

[0036] The mapping object is used to establish the correspondence between the server's externally exposed entry point, the client, and the client's local service address. The server's externally exposed entry point includes the URL path corresponding to the URL mapping registration information and the port corresponding to the port mapping registration information.

[0037] Specifically, after receiving a service registration request, the server first verifies the client information carried in the request to ensure that the registration request comes from a legitimate client.

[0038] After successful verification, the server checks whether the URL path or port number in the request conflicts with existing mapping data. If there is no conflict, the server creates a URL mapping object for URL mapping registration information and a port mapping object for port-type registration requests (i.e., port mapping registration information).

[0039] Then, the server persistently stores the data of the created mapping object (the mapping data) in the database and synchronizes it to the memory cache for fast retrieval. At this point, the client has successfully published its local service to the server. External users can access this intranet service (i.e., the local service) through the server's exposed entry point—the URL path or port. This dynamic registration mechanism eliminates the need for manual editing and restarting of services, greatly simplifying maintenance.

[0040] S105. When the server receives access request data from the user for the server's externally exposed entry point, it determines the target client and the target local service address based on the access request data and mapping data; and creates a data flow channel in the corresponding trusted tunnel session to send the target local service address to the target client for the target client to verify whether the target local service is available; and after successful verification, sends the access request data to the target client through the data flow channel.

[0041] Specifically, when a user (such as an external internet user) accesses a URL path or port exposed by the server, the server first parses the access request, such as extracting the URL path or port number to be accessed. Then, based on the extracted information, the server performs a matching search in the mapping data to determine which client (i.e., the target client) and which local service address on that client (i.e., the target local service address) should be forwarded to.

[0042] Then, the server determines the trusted tunnel corresponding to the target client, and establishes a session on it corresponding to the target's local service address, creating a new data stream channel within that session. In practical applications, this data stream channel is a logical bidirectional communication channel specifically used to transmit the data for this request and response.

[0043] Based on this, the server sends the target local service address to the target client through this data stream channel, informing the target client which local service this request needs to access. After receiving the address information, the target client verifies whether the corresponding local service actually exists and is accessible (e.g., checks whether the service is responding normally). If the verification is successful, it returns the corresponding message to the server.

[0044] After receiving the message, the server sends the original access request data to the target client through the same data stream channel. This "verify before sending" mechanism ensures that the request is not forwarded to an unavailable service, thus improving system reliability.

[0045] S106. The target client sends the access request data to the target local service and receives the response data returned by the target local service; and sends the response data to the server through the data stream channel.

[0046] Specifically, after the target client receives the access request data sent by the server through the data stream channel, it sends the access request data to the corresponding local service, i.e., the target local service, based on the previously verified target local service address.

[0047] The target local service processes the access request data, generates response data, and returns it to the client.

[0048] After receiving the response data, the client returns the response data to the server through the same data stream channel.

[0049] S107. The server returns the response data to the user.

[0050] Specifically, after receiving the response data from the target client through the data stream channel, the server returns the response data to the waiting internet user via the original user TCP connection, completing a full request-response interaction. During this process, depending on the type of access request data, it can be determined whether the data stream channel is closed and released after the interaction, while the underlying trusted tunnel and multiplexed session remain active to handle subsequent requests.

[0051] The intranet penetration service proxy method based on trusted tunnels provided in this application enables concurrent processing of multiple requests on a single trusted tunnel without establishing a separate TCP connection for each request, which significantly reduces system overhead and improves concurrent processing capabilities. At the same time, through the mechanism of client-initiated service mapping registration, the automatic publication and updating of services are realized, avoiding service interruptions caused by manual and tedious parameter configuration and service restart.

[0052] Furthermore, in some embodiments of this application, the client initiates a client registration request based on the HTTP protocol to the server. After authentication, a trusted tunnel based on the TCP protocol is established with the server. This includes: the client reading connection and authentication information from the configuration file, generating a globally unique identifier based on the current device IP address and hostname to generate an HTTP registration request, and sending the HTTP registration request to the server through the server's management port; after verifying the legality and uniqueness of the globally unique identifier, the server upgrades the HTTP connection between the client and the server to a TCP connection through the HTTP protocol upgrade mechanism, and determines the tunnel data transmission encryption mechanism.

[0053] Specifically, in this embodiment, when the client starts, it can first read connection and authentication information from the local configuration file (such as through the configuration reader set inside the client). This information may include: server address, server port, client name, proxy type, group, authentication password, encryption configuration information, local service list, and mapping data related to local services synchronized with the server. After obtaining the above information, it is loaded into the global cache to prepare for subsequent active connection to the server.

[0054] Then, to ensure that each client has unique authentication information, the client can generate a globally unique identifier (UUID) based on the current device IP address and hostname. This UUID will serve as the client's identity credential in all subsequent communications.

[0055] The client encapsulates the connection and authentication information, along with the UUID, into an HTTP request and sends it to the server's management port. Understandably, this request uses the HTTP protocol instead of directly using TCP to facilitate bypassing firewalls and load balancing.

[0056] Upon receiving the registration request, the server first verifies the validity of the UUID format and checks if the UUID has already been registered in the system (i.e., whether the corresponding client has already registered) to prevent duplicate registration by the same client. If the UUID is invalid or already registered, registration is rejected and a corresponding information reminder is returned (in practical applications, it can be stipulated that the client cannot re-initiate a client registration request within a preset waiting time). If the UUID is valid and not registered, the protocol upgrade process begins.

[0057] In practical applications, the protocol upgrade process may specifically include: First, the server can obtain the underlying net.Conn object and bufio.ReadWriter buffer reader / writer through Go's http.Hijacker interface, construct an HTTP 101 Switching Protocols response, and include Upgrade: tcp and Connection:Upgrade in the response header. Then, it can write the response string using methods such as bufrw.WriteString and call the bufrw.Flush method to force flush its buffer to ensure that the response is sent to the client immediately.

[0058] Convert the corresponding connection out of the HTTP protocol scope and into a pure TCP connection.

[0059] It should be noted that, correspondingly, after receiving the above response, the client needs to parse it to determine the protocol switch; subsequent communication will use pure TCP instead of HTTP. At this point, a trusted TCP long connection, or trusted tunnel, is established between the client and the server.

[0060] In addition, in practical applications, to ensure the security of data transmitted in a trusted tunnel, the server can determine the encryption mechanism for tunnel data transmission after the protocol upgrade is completed. This includes issuing a randomly generated encryption key to the client. Both parties can then build a symmetric encryption protocol (such as AES-256-GCM) based on this key, which can encrypt and protect the data transmitted in the trusted tunnel afterward, ensuring the confidentiality and integrity of the communication.

[0061] Furthermore, in some embodiments of this application, the client and server establish a multiplexed session on the trusted tunnel, including: the client and server each creating a smux session corresponding one-to-one with the client's local service on the TCP connection, configuring optimization parameters, and packaging the created smux session into a managed object of the corresponding tunnel manager. The tunnel manager includes the client's tunnel manager and the server's tunnel manager; and the server initiates a heartbeat detection mechanism through the smux protocol stack, sending probe frames to the client at preset intervals. If no response frame is received from the client within the heartbeat timeout period, an offline processing procedure is triggered. The offline processing procedure includes closing the corresponding smux session and TCP connection, and updating the status of the corresponding client or the corresponding local service to offline.

[0062] Specifically, in this embodiment, after the trusted tunnel is established, the client and server each create a smux session on the TCP connection. When creating the smux session, the client and server can configure a series of optimization parameters, including: The client creates a smux session over a TCP connection, configuring optimized smux parameters including maximum receive buffer, maximum stream buffer, heartbeat keep-alive interval, heartbeat timeout, and maximum frame size. The client then encapsulates the created smux session into a global concurrency-safe object and hands it over to the client's tunnel manager. As mentioned above, a client's tunnel manager only manages the session object for that client and is responsible for parsing both incoming and outgoing data.

[0063] Correspondingly, the server creates a smux session on the TCP connection and configures optimized smux parameters, including maximum receive buffer, maximum stream buffer, heartbeat keep-alive interval, heartbeat timeout, and maximum frame size. Then, the server encapsulates the smux session into a global concurrency-safe object and hands it over to the server-side tunnel manager. The server-side tunnel manager manages all the session objects on the server (corresponding to multiple clients) and is also responsible for parsing data in and out.

[0064] Based on this, in order to ensure the activity of the tunnel and the reliability of the connection, the server can initiate connection keep-alive detection through a heartbeat mechanism based on the smux protocol stack.

[0065] Specifically, the server can automatically send probe frames to the client at preset intervals (e.g., 10 seconds) and start a timer to wait for a response frame; after receiving the probe frame, the client automatically replies with a response frame. The entire process can be completed automatically within the protocol stack, while updating the last active timestamp.

[0066] Based on this, the server monitors the heartbeat response: if a response frame is received from the client within the heartbeat timeout period (e.g., 30 seconds), the connection is considered normal, the timer is reset, and the detection continues for the next cycle; if no response frame is received within the timeout period, the client connection is considered offline, and the offline processing procedure is triggered.

[0067] In practical applications, the offline processing flow may include: closing the client's smux session and underlying TCP connection, releasing related resources; deleting the client's record from the server-side tunnel manager, or updating the status of the client or the corresponding local service to offline; and logging and triggering an alarm to indicate that the service provided by the client is unavailable.

[0068] Through this heartbeat keep-alive mechanism, the system (i.e., the trusted tunnel-based intranet penetration service proxy system used to execute the trusted tunnel-based intranet penetration service proxy method) can promptly detect connection anomalies and update its status, preventing requests from being forwarded to offline clients.

[0069] Based on this, the client iterates through its corresponding local services, constructs URL or port mapping registration information for each local service, generates a service registration request based on the URL or port mapping registration information, and sends it to the server.

[0070] Specifically, the client can use its internal service manager to iterate through each of its local services, construct a unique URL path for each local service according to a specified format, or determine the port, and then generate and send a service registration request (such as a POST request) to the server. In practical applications, the request body can include the complete URL path, prefix path, authentication password, whether encryption is enabled, mapping description information, etc.

[0071] Furthermore, in some embodiments of this application, the server receives and verifies the service registration request, and after successful verification and confirmation of no conflict, creates a mapping object and stores the mapping data. This includes: after receiving the service registration request sent by the client, the server verifies the correctness of the client's authentication information carried in the service registration request. If the verification fails, an unauthorized error is returned. If the verification passes, the server checks whether the URL or port mapping registration information carried in the service registration request conflicts with existing mapping data. If there is no conflict, a URL mapping object is created for the URL mapping registration information and the mapping data is stored, and a port mapping object is created for the port mapping registration information and the mapping data is stored. The specific process principle is as follows: S201. The server receives a service registration request (actually, a resource allocation request) initiated by the client.

[0072] Specifically, the server can receive service registration requests from clients through a pre-defined access interface, which is used to establish external access capabilities for the client's local services. In this application, the service registration request can be an HTTP-based URL proxy request (the request includes URL mapping registration information) or a TCP / UDP-based port mapping request (the request includes port mapping registration information).

[0073] S202. The server parses the received service registration request and determines the request type.

[0074] Specifically, the server first verifies the correctness of the client's authentication information carried in the service registration request. If the verification fails, an unauthorized error is returned (e.g., by searching for the corresponding trusted tunnel in the tunnel manager using the UUID, or by comparing the authentication information in the request with the information previously received and stored by the server).

[0075] If the verification is successful, the system continues to identify information carried in the request, such as protocol type, business fields, or function identifiers. Based on the parsing results, the current request is classified as either an HTTP type (i.e., an HTTP-based URL proxy request) or a port type (i.e., a TCP / UDP-based port mapping request), so that it can proceed to different verification and mapping creation processes.

[0076] S203. When the judgment result is an HTTP request, the server extracts the URL mapping registration information in the request (in practical applications, this may include service group, service name, and address information, etc.) as the basis for subsequent construction of mapping relationships and execution of access request data forwarding.

[0077] It should be noted that, in this application, the URL path generated by the client mentioned above is generated according to a preset fixed path generation rule, such as combining and standardizing information fields from the client and the corresponding local service to generate a URL path that can uniquely identify a specific local service. Since the URL path involves server-side resource configuration, relevant information needs to be synchronized between the client and the server beforehand.

[0078] S204. The server checks whether the URL path exists in the current mapping data (i.e., the mapping data that already exists), and determines whether other clients or mappings have already occupied the path, thereby avoiding subsequent access conflicts.

[0079] S205. When the URL path is not in the current mapping data, create a new URL mapping object.

[0080] Specifically, when the URL path is not in the current mapping data, it is confirmed that the URL path has not been occupied. The URL path is then determined to be in an allocatable state, and a new mapping object is created to establish a correspondence between the URL path and the local service address (and the client) in the service registration request sent by the current client.

[0081] S206. When the URL path is already in the current mapping data, determine the information of the client that is currently sending the service registration request, such as the UUID, and check whether the client is the same client as the client that has occupied the URL path stored on the server, so as to determine whether the current service registration request belongs to the duplicate registration or update behavior of the same service subject.

[0082] S207. When the check result indicates that it is not the same client, further check whether the original client that has occupied the URL path is online.

[0083] In practical applications, the heartbeat detection mechanism described above, or the online status table and session persistence information, can be used to determine whether the original client (the client that has occupied the URL path and whose records are stored on the server side) still has the ability to provide services, so as to determine whether the URL path can be taken over by the new client (the client that is currently sending the service registration request).

[0084] S208. When the original client is online, determine that the URL path is already in use, and return an error message indicating that the URL path is already in use to the client that sent the service registration request, and reject the service registration request to prevent multiple different clients from contending for the same URL path, thereby ensuring the consistency of path access and the determinism of resource ownership.

[0085] S209. When the original client is offline, the current requesting client is allowed to overwrite or update the mapping of the URL path, so as to create a URL mapping object for the client that sent the service registration request.

[0086] Understandably, when the server determines that the original client is offline or has lost its service capability, it treats the URL path as a recyclable resource, allowing new clients to reuse the URL path, thereby improving the utilization of path resources and avoiding invalid occupation.

[0087] S210. When the verification result is the same client, the update operation is directly allowed to be performed on the mapping object corresponding to the URL path.

[0088] Specifically, if the server determines that the current client and the original client at the corresponding URL path in the system are the same client, it will directly return the already created information, or allow the information in the original mapping object to be overwritten and updated based on the information in the currently received service registration request, so as to meet the continuous release requirements in scenarios such as changes in client and local service information, restarts and reconnections, or version switching.

[0089] It should be noted that when creating (or updating) a new URL mapping object based on the above checks and judgments, the server can encapsulate the latest URL path, client UUID, local service address, service group, status information, and time information according to a unified data structure, and persist them to the URL mapping table to form queryable and maintainable formal mapping data.

[0090] S211. After the URL mapping data is saved, initialize the corresponding HTTP traffic monitoring module to collect operational data such as the number of requests, response status, access source, request time, and traffic consumption of subsequent Internet users entering through this mapping entry point (i.e., the URL path), providing a data foundation for monitoring, auditing, and billing. Also, perform corresponding resource allocation processing on the server side.

[0091] Similarly, when the result indicates a port-type request, the server processes it based on the same principle described above, which can be understood by referring to the processing of HTTP type requests, and will not be repeated here. The difference is that for port-type mapping requests, the server or client no longer generates a URL path. Instead, it directly allocates a port on the server based on the existing port to create a port mapping object, and starts a listening process on that port. The server's proxy entry manages this port. When subsequent access requests from internet users arrive through the corresponding port, the server forwards the access request data to the corresponding client and local service according to the port mapping object.

[0092] Additionally, it should be noted that for the aforementioned port mapping object, the server can establish a tunnel proxy based on the port mapping object. When the server detects that the port has received external access request data, the access request data is forwarded to the corresponding client through the tunnel proxy, and then forwarded to the corresponding local service address.

[0093] In practical applications, the specific information of the above-mentioned mapping object may include client information such as UUID, local service information such as local service address, and URL path or port.

[0094] Furthermore, in some embodiments of this application, a data flow channel is created in the session corresponding to the trusted tunnel to send the target local service address to the target client for the target client to verify whether the target local service is available. This includes: the server determining a trusted tunnel corresponding to the target client, and determining a session corresponding to the target local service address in the dialogue of the trusted tunnel, and creating a data flow channel in the session; the server constructing a request message including the target local service address, and sending the request message to the target client through the data flow channel; the target client receiving and parsing the request message to obtain the target local service address; and verifying whether the target local service corresponding to the target local service address is accessible. If accessible, the client constructs a confirmation response message and sends the confirmation response message to the server through the data flow channel.

[0095] Specifically, firstly, when an internet user wants to access an intranet service, i.e., the local service of the client mentioned above, they initiate an access request. This access request includes HTTP type access requests and non-HTTP type access requests (such as port type access requests). The server receives the access request data (i.e., the data information contained in the access request) through a proxy entry point, parses it, and determines the client that the user wants to access, i.e., the target client, and the local service address that the user wants to access, i.e., the target local service address, based on the parsing results and stored mapping data.

[0096] Then, the server uses the tunnel manager to determine the trusted tunnel corresponding to the target client, and the smux session within that trusted tunnel corresponding to the target's local service address. Within this smux session, a new data stream channel is created, and a request message is constructed and written to the trusted tunnel through this data stream channel.

[0097] At this point, the target client receives the request message from the trusted tunnel through the data stream channel and parses it to obtain the target local service address. Then, the target client verifies whether the local service corresponding to the target local service address, i.e., the target local service, is accessible through its internal service manager. If it is accessible, the target client constructs an acknowledgment response message indicating that the target local service is accessible and writes the acknowledgment response message to the trusted tunnel through the data stream channel.

[0098] The server receives and decodes the confirmation response message through the data stream channel. It modifies and adjusts HTTP access request data (such as changing the origin field in the header of the original access request data to the target local service address), while non-HTTP access request data, such as port-type access request data, is not modified and is then forwarded to the target client.

[0099] In addition, in other embodiments of this application, besides the data flow channel established by the server when it receives the user's access request data, the state of the tunnel, session, client and local services can also be determined by establishing a data flow channel when a trusted tunnel and session have just been established between the server and the client. This data flow channel is then saved and displayed externally to control which local services the user can access.

[0100] Furthermore, in practical applications, the client can start an independent goroutine to call the AcceptStream method of the smux session in a loop. This method will block and wait for the server to create a new data stream channel. When a user's access request arrives at the server, the server can create a new data stream channel through the OpenStream method. The client's AcceptStream method returns the data stream channel and begins to process the request.

[0101] Furthermore, in some embodiments of this application, the target client sends access request data to the target local service, including: the target client and the server determine whether to encrypt the access request data and response data based on a pre-configured encryption field; if necessary, the data transmitted between the target client and the server is encrypted based on a tunnel data transmission encryption mechanism.

[0102] Specifically, firstly, the server determines whether to encrypt the access request data based on pre-configured encryption fields. If so, it encrypts the access request data and transmits it to the target client. Secondly, the target client determines whether the server has encrypted the access request data based on pre-configured encryption fields. If it has, it decrypts the data and transmits the decrypted data to the target local service. Finally, the target client determines whether to encrypt the response data returned by the target local service based on pre-configured encryption fields. If so, it encrypts the response data and transmits it to the server.

[0103] Furthermore, in some embodiments of this application, the method further includes: the server intercepting received HTTP access request data and accumulating the HTTP request count for the current hour in the memory cache area based on key feature information; for non-HTTP access request data, the server creating a monitored connection object corresponding to the original connection, and using the monitored connection object to count the number of inbound and outbound traffic bytes, and accumulating the total traffic value for the current hour in the memory cache area based on the statistical results; and when the hour arrives, batch writing the accumulated HTTP request count and total traffic value for the previous hour in the memory cache area into the database, and performing data merging operations and generating monitoring reports.

[0104] Specifically, in this application, different methods are used for traffic monitoring of HTTP type access request data and HTTP type access request data.

[0105] The traffic monitoring process for HTTP access request data is as follows: First, when a user initiates a business access, the generated HTTP access request data first reaches the proxy entry point on the server side. As a front-end checkpoint for traffic collection, the proxy entry point is responsible for identifying and intercepting the access request data for subsequent measurement and analysis, without affecting the normal forwarding logic of the request.

[0106] Then, the server calls the HTTP request logging function to parse and mark the intercepted access request data. In practical applications, this function extracts key feature information (such as request timestamps, URL paths, etc.) from the access request data based on preset information, and generates a unique context identifier for the current counting operation to ensure the accuracy of data statistics.

[0107] In the memory cache area, the HTTP request count for the current hour is incremented. In practical applications, to reduce database write pressure and improve real-time response speed, this step does not directly write the data record of each request to persistent storage. Instead, based on the result of the previous step, the request count increment is recorded and atomically added to a high-speed cache object in the server's memory. This cache object can be indexed by time window to maintain and update the request count for the corresponding time period in real time.

[0108] The traffic monitoring process for non-HTTP access request data is as follows: First, as mentioned in the above embodiments, this application creates a monitored connection object corresponding to the original connection for non-HTTP type access requests (such as accessing local services through a port mapping object based on a TCP connection). For example, by using the decorator pattern, a monitored connection object is created that wraps the original connection. This object takes over the read and write interface of the original connection, so that all data streams passing through the connection are in an observable state.

[0109] Based on this, during the execution of the read method of the monitored connection object, the number of bytes read is counted, and during the execution of the write method, the number of bytes written is counted to obtain the number of inbound and outbound traffic bytes. Then, the TCP traffic recording function is called to map the counted bytes to the traffic metric for the current hour (the monitoring principle for HTTP access requests is the same as mentioned above, only the increment of bytes is counted).

[0110] Then, the total traffic value for the current hour is accumulated in the memory cache area. In practical applications, the statistical results can be accumulated into the corresponding counter in the memory cache.

[0111] In addition, the server has a timed scheduling mechanism that continuously monitors the current time. When it detects that the time has crossed the hour boundary (i.e., reached the hour), it determines that the previous statistical period has ended, and then triggers the data persistence process, writing the accumulated HTTP request count value and TCP connection traffic value of the previous hour from the memory cache to the database in batches.

[0112] In practical applications, after the data persistence process is triggered, the server atomically reads the statistical data in the memory cache, encapsulates it into structured record entries, and stores them into a relational database or time-series database through batch insertion.

[0113] Furthermore, after the data persistence process, the counters in memory are reset or archived, starting a new statistical cycle. This effectively avoids database performance bottlenecks caused by high-frequency single-row writes.

[0114] Finally, the server-side correlates and merges traffic monitoring data from different types of access requests within the same time frame. Through aggregation calculations, it generates comprehensive monitoring reports containing multiple dimensions such as request frequency and bandwidth consumption, which are then displayed on the upper-level management interface or used for subsequent billing, auditing, and anomaly detection analysis.

[0115] Furthermore, in some embodiments of this application, to improve the system's fault tolerance and service availability, the server-side also integrates an emergency scheduling mechanism, including: the server-side recording the functional information of each local service; when the client's response data to the server times out, the server-side determining an emergency local service address based on the access request data and functional information, so as to respond to the access request data through the local service corresponding to the emergency local service address. Alternatively, the server-side associating each local service based on its function; when the client's response data to the server times out, the server-side determining an emergency local service address based on the association relationship, so as to respond to the access request data through the local service corresponding to the emergency local service address.

[0116] Specifically, in some embodiments of this application, the server can record functional information of each local service, such as service type, during the service registration phase. When the server sends a request message to the target client or forwards access request data, and does not receive response data within a preset timeout period, it determines that the client or local service may be malfunctioning. At this time, the server matches and searches for the address of other local services that can provide the same or similar functions as the target local service, i.e., the emergency local service address, based on the access request data and the pre-recorded functional information of each local service. The request is then rerouted to the emergency local service address, and a response is awaited.

[0117] In other embodiments of this application, the server can establish associations between multiple local services that are functionally related or can serve as backups for each other. When the target local service times out, the server quickly determines the address of an emergency local service based on the association, routes the access request data to the emergency local service address, and waits for a response.

[0118] This emergency dispatch mechanism ensures that even if a client or local service fails, the system can still respond to requests through other services, avoiding complete service unavailability due to a single point of failure and improving the overall availability and fault tolerance of the system.

[0119] The intranet penetration service proxy method based on trusted tunnels provided by this invention achieves concurrent request processing by establishing multiplexed sessions on a single trusted tunnel and dynamically creating data flow channels within the sessions, avoiding the performance bottlenecks caused by frequent TCP connection establishment or serial processing in traditional solutions. Through a mechanism for clients to actively register service mappings, dynamic service publishing and updates are achieved, eliminating the need for tedious manual editing, simplifying operation and maintenance, and preventing service interruptions. End-to-end encrypted transmission ensures data security, and multi-dimensional traffic monitoring provides data support for operation and maintenance decisions. Furthermore, an emergency scheduling mechanism (i.e., determining an emergency local service address to respond to access request data when a response times out) improves the system's fault tolerance and availability. Compared with existing technologies, this invention significantly improves the concurrent processing capability and service flexibility of the intranet penetration system while maintaining low system overhead.

[0120] Based on the same inventive concept, this application also provides an intranet penetration service proxy system based on trusted tunnels, used to execute the methods described in the above embodiments. Figure 2 This is a schematic diagram of the intranet penetration service proxy system based on trusted tunnels provided in an embodiment of the present invention, as shown below. Figure 2 As shown, the system includes a client 11 and a server 12, and the client can communicate with its corresponding local service.

[0121] The client 11 is used to initiate a client registration request to the server 12 to establish a trusted tunnel with the server 12 and establish a multiplexed session on the trusted tunnel; to traverse the local services corresponding to the client 11, generate a service registration request to request the server 12 to create a mapping object and store the mapping data; to receive access request data through the data flow channel; to forward the access request data to the local service; and to send the response data returned by the local service to the server 12 through the data flow channel.

[0122] In practical applications, client 11 is deployed on the intranet and internally includes: a configuration reader, a service manager, a tunnel manager, and a data forwarder. The configuration reader reads information about the local service from the static configuration file when client 11 starts up, and works with the service manager to register the client and the local service with server 12. The tunnel manager maintains established trusted tunnels and sessions, maintains the heartbeat connection of the unique trusted tunnel, and automatically rebuilds the tunnel if it goes offline. The data forwarder receives access request data from the tunnel manager and forwards it to the corresponding local service, and receives response data from the local service and sends it to server 12.

[0123] Server 12 is used to maintain trusted tunnels and multiplexed sessions with each client 11; receive and verify service registration requests, create mapping objects and store mapping data; receive user access request data, create data stream channels in the corresponding trusted tunnel session according to the mapping data, send access request data to the target client 11 through the data stream channels, and forward the response data returned by the target client 11 to the user.

[0124] In practical applications, server 12 is deployed on the public network and has a tunnel manager and a traffic monitoring module. The tunnel manager provides a global management service entry point for trusted tunnels and can be used to start, stop, deregister, and limit traffic of trusted tunnels. Server 12 also provides a globally unique proxy entry point for access requests to forward access request data from external sources. The traffic monitoring module is used to implement traffic data statistics and query services at multiple time granularities, such as trusted tunnels and local services.

[0125] The present invention also provides an intranet penetration service proxy device based on trusted tunnels, for implementing the above method embodiments. Figure 3 This is a schematic diagram of the intranet penetration service proxy device based on trusted tunnels provided in an embodiment of the present invention, as shown below. Figure 3 As shown, the trusted tunnel-based intranet penetration service proxy device of this embodiment includes a processor 21 and a memory 22, with the processor 21 connected to the memory 22. The processor 21 is used to call and execute the program stored in the memory 22; the memory 22 is used to store the program, which is at least used to execute the trusted tunnel-based intranet penetration service proxy method in the above embodiments.

[0126] The specific implementation scheme of the intranet penetration service proxy device based on trusted tunnel provided in this application embodiment can refer to the implementation scheme of the intranet penetration service proxy method based on trusted tunnel in any of the above embodiments, and will not be repeated here.

[0127] It is understood that the same or similar parts in the above embodiments can be referred to each other, and the contents not described in detail in some embodiments can be referred to the same or similar contents in other embodiments.

[0128] It should be noted that in the description of this invention, the terms "first," "second," etc., are used for descriptive purposes only and should not be construed as indicating or implying relative importance. Furthermore, in the description of this invention, unless otherwise stated, "a plurality of" means at least two.

[0129] Any process or method description in the flowchart or otherwise herein can be understood as representing a module, segment, or portion of code comprising one or more executable instructions for implementing a particular logical function or process, and the scope of the preferred embodiments of the invention includes additional implementations in which functions may be performed not in the order shown or discussed, including substantially simultaneously or in reverse order depending on the functions involved, as will be understood by those skilled in the art to which embodiments of the invention pertain.

[0130] It should be understood that various parts of the present invention can be implemented in hardware, software, firmware, or a combination thereof. In the above embodiments, multiple steps or methods can be implemented in software or firmware stored in memory and executed by a suitable instruction execution system. For example, if implemented in hardware, as in another embodiment, it can be implemented using any one or a combination of the following techniques known in the art: discrete logic circuits having logic gates for implementing logical functions on data signals, application-specific integrated circuits (ASICs) having suitable combinational logic gates, programmable gate arrays (PGAs), field-programmable gate arrays (FPGAs), etc.

[0131] Those skilled in the art will understand that all or part of the steps of the methods in the above embodiments can be implemented by a program instructing related hardware. The program can be stored in a computer-readable storage medium, and when executed, the program includes one or a combination of the steps of the method embodiments.

[0132] Furthermore, the functional units in the various embodiments of the present invention can be integrated into a processing module, or each unit can exist physically separately, or two or more units can be integrated into a module. The integrated module can be implemented in hardware or as a software functional module. If the integrated module is implemented as a software functional module and sold or used as an independent product, it can also be stored in a computer-readable storage medium.

[0133] The storage media mentioned above can be read-only memory, disk, or optical disk, etc.

[0134] In the description of this specification, references to terms such as "one embodiment," "some embodiments," "example," "specific example," or "some examples," etc., indicate that a specific feature, structure, material, or characteristic described in connection with that embodiment or example is included in at least one embodiment or example of the invention. In this specification, the illustrative expressions of the above terms do not necessarily refer to the same embodiment or example. Furthermore, the specific features, structures, materials, or characteristics described may be combined in any suitable manner in one or more embodiments or examples.

[0135] Although embodiments of the present invention have been shown and described above, it is understood that the above embodiments are exemplary and should not be construed as limiting the present invention. Those skilled in the art can make changes, modifications, substitutions and variations to the above embodiments within the scope of the present invention.

Claims

1. A method for proxying intranet penetration services based on trusted tunnels, applied to an intranet penetration service system based on trusted tunnels, the system comprising a server deployed on the public network and a client deployed on the intranet, wherein the client can communicate with its corresponding local service, characterized in that, include: The client initiates a client registration request based on the HTTP protocol to the server. After authentication, a trusted tunnel based on the TCP protocol is established with the server. Each trusted tunnel corresponds one-to-one with each of the aforementioned clients. The client and server establish a multiplexed session on the trusted tunnel, wherein each session corresponds one-to-one with each local service of the client; The client iterates through its corresponding local services, constructs URL or port mapping registration information for each local service, generates a service registration request based on the URL or port mapping registration information, and sends it to the server. The server receives and verifies the service registration request. After successful verification and confirmation of no conflicts, it creates a mapping object and stores the mapping data. The mapping object is used to establish the correspondence between the server's externally exposed entry point, the client, and the client's local service address. The server's externally exposed entry point includes the URL path corresponding to the URL mapping registration information and the port corresponding to the port mapping registration information. When the server receives access request data from a user targeting the server's exposed entry point, it determines the target client and the target local service address based on the access request data and mapping data; and creates a data stream channel in the corresponding trusted tunnel session to send the target local service address to the target client for the target client to verify whether the target local service is available; and after successful verification, it sends the access request data to the target client through the data stream channel. The target client sends access request data to the target local service and receives response data returned by the target local service; and sends the response data to the server through the data stream channel; The server returns the response data to the user.

2. The method according to claim 1, characterized in that, The client initiates a client registration request based on the HTTP protocol to the server, and after authentication, establishes a trusted tunnel based on the TCP protocol with the server, including: The client reads connection and authentication information from the configuration file, generates a globally unique identifier based on the current device IP address and hostname, generates an HTTP registration request, and sends the HTTP registration request to the server through the server's management port; After verifying the legality and uniqueness of the globally unique identifier, the server upgrades the HTTP connection between the client and the server to a TCP connection through the HTTP protocol upgrade mechanism, and determines the encryption mechanism for tunnel data transmission.

3. The method according to claim 2, characterized in that, The client and server establish a multiplexed session on the trusted tunnel, including: The client and server respectively create smux sessions on the TCP connection that correspond one-to-one with the client's local service, configure optimization parameters, and wrap the created smux sessions as managed objects of the corresponding tunnel managers, including the client's tunnel manager and the server's tunnel manager. The server starts a heartbeat detection mechanism through the smux protocol stack, sending probe frames to the client at preset intervals. If no response frame is received from the client within the heartbeat timeout period, the offline processing procedure is triggered. The offline processing procedure includes closing the corresponding smux session and TCP connection, and updating the status of the corresponding client or local service to offline.

4. The method according to claim 3, characterized in that, The server receives and verifies the service registration request, and after successful verification and confirmation of no conflict, creates a mapping object and stores the mapping data, including: After receiving a service registration request from the client, the server verifies the correctness of the client's authentication information carried in the service registration request. If the verification fails, an unauthorized error is returned. If the verification passes, the server checks whether the URL or port mapping registration information carried in the service registration request conflicts with existing mapping data. If there is no conflict, a URL mapping object is created and the mapping data is stored for the URL mapping registration information, and a port mapping object is created and the mapping data is stored for the port mapping registration information; This includes checking whether the URL or port mapping registration information carried in the service registration request conflicts with existing mapping data, including: Check if the URL path or port from the service registration request exists in the current mapping data; If it does not exist, a URL mapping object is created for the client that sent the service registration request, or a port is allocated to create a port mapping object; If it exists, check whether the client occupying the URL path or port in the current mapping data is the same client as the client that sent the service registration request. If yes, return information about the created message or the updated server-side service; if no, check if the client status recorded in the current mapping data that occupies the URL path or port is online. If the client is online, a conflict is determined; if the client is offline, a URL mapping object is created for the client that sent the service registration request, or a port is allocated to create a port mapping object.

5. The method according to claim 1, characterized in that, The step of creating a data stream channel in the corresponding trusted tunnel session to send the target local service address to the target client, allowing the target client to verify whether the target local service is available, includes: The server determines a trusted tunnel corresponding to the target client, identifies a session corresponding to the target local service address within the dialogue of the trusted tunnel, and creates a data flow channel within that session. The server constructs a request message including the target local service address and sends the request message to the target client through the data stream channel; The target client receives and parses the request message to obtain the target local service address; and verifies whether the target local service corresponding to the target local service address is accessible. If it is accessible, it constructs a confirmation response message and sends the confirmation response message to the server through the data stream channel.

6. The method according to claim 2, characterized in that, The target client sends access request data to the target local service, including: The target client and server determine whether to encrypt the access request data and response data based on the pre-configured encryption fields. If necessary, the data transmitted between the target client and server is encrypted based on the tunnel data transmission encryption mechanism.

7. The method according to claim 1, characterized in that, Also includes: The server intercepts the received HTTP access request data and accumulates the HTTP request count value for the current hour in the memory cache area based on key feature information. For non-HTTP access request data, the server creates a monitored connection object corresponding to the original connection, and uses the monitored connection object to count the number of inbound and outbound traffic bytes, and accumulates the total traffic value for the current hour in the memory cache area based on the statistical results. When the hour arrives, the accumulated HTTP request count and total traffic value of the previous hour in the memory cache area are written to the database in batches, and a data merging operation is performed to generate a monitoring report.

8. The method according to claim 1, characterized in that, Also includes: The server records the functional information of each local service. When the server times out when the client sends response data to the server, it determines an emergency local service address based on the access request data and the function information, so as to respond to the access request data through the local service corresponding to the emergency local service address. Alternatively, the server can associate various local services based on their functions; When the client times out sending response data to the server, the server determines an emergency local service address based on the association relationship, and responds to the access request data through the local service corresponding to the emergency local service address.

9. A trusted tunnel-based intranet penetration service proxy system, used to execute the method as described in any one of claims 1-8, characterized in that, include: The client and server sides, and the client can communicate with its corresponding local service; The client is used to initiate a client registration request to the server in order to establish a trusted tunnel with the server and establish a multiplexed session on the trusted tunnel; Iterate through the local services corresponding to the client, generate a service registration request to request the server to create a mapping object and store the mapping data; And receive access request data through the data stream channel; And forwarding access request data to the local service, and sending the response data returned by the local service to the server through the data stream channel; The server is used to maintain trusted tunnels and multiplexed sessions with each client. Receive and verify service registration requests, create mapping objects, and store mapping data; It also receives user access request data, creates a data stream channel in the corresponding trusted tunnel session based on the mapping data, sends the access request data to the target client through the data stream channel, and forwards the response data returned by the target client to the user.

10. An intranet penetration service proxy device based on trusted tunnels, characterized in that, It includes a processor and a memory, wherein the processor is connected to the memory: The processor is used to call and execute the program stored in the memory; The memory is used to store the program, which is at least used to execute the intranet penetration service proxy method based on trusted tunnels as described in any one of claims 1-8.

Images