Method, device and equipment for automatically identifying and accessing CPE (Customer Premise Equipment) based on reverse tunnel

Abstract

The invention relates to a method, a device and equipment for realizing automatic identification and access to CPE (Customer Premise Equipment) based on a reverse tunnel, and the method comprises the steps: based on a reverse tunnel protocol, actively initiating TCP (Transmission Control Protocol) connection and carrying out three-time handshake through the CPE, realizing the establishment of an initial communication link, and according to the established TCP connection, reporting equipment identification and structured equipment information through the CPE along the path, and realizing automatic identification and access to the CPE. Automatic equipment identification and port mapping management of the controller are realized, and active access to any service of the CPE equipment is realized by querying mapping through the controller and utilizing the logic connection according to the binding relationship between the equipment identification and the logic connection. According to the method, the device identifier and the structured information are reported in advance by using the TCP connection, the controller actively queries the mapping relationship between the device identifier and the logic connection, and the device discovery, the tunnel establishment and the service agent process are integrated into a single continuous session, so that the connection establishment efficiency and the system expandability are improved.

Description

Technical Field

[0001] This application relates to the field of computer network technology, and in particular to a method, apparatus and device for automatically identifying and accessing CPE devices based on reverse tunneling. Background Technology

[0002] In Software-Defined Wide Area Network (SD-WAN) systems, the number of Customer Premises Equipment (CPEs) is large, and they are typically deployed within the enterprise's private network, lacking directly accessible public IP addresses. To achieve centralized management, the CPE devices need to proactively initiate connections to the control unit located on the public network and establish reverse communication tunnels, enabling the controller to manage and configure these internal network devices.

[0003] like Figure 2 As shown, traditional technologies commonly use the SSH protocol to build such reverse tunnels. Specifically, the CPE device needs to actively create an SSH connection to the controller. By performing port reverse mapping on the controller side, the controller can connect to the internal CPE via the mapped port and issue command-line instructions to it. However, this traditional method has several significant drawbacks: First, the CPE and controller need to negotiate the mapped port number assigned by the controller in advance through additional means, increasing the complexity of system configuration and maintenance costs; second, because the established connection is an SSH connection, the controller is limited to issuing text-based shell-like commands, and cannot efficiently and flexibly access or call the diverse services deployed on the CPE device (such as gRPC services, RESTful APIs, or other application protocols based on specific ports), severely limiting the scalability and applicability of management functions; third, to achieve an SSH connection, all CPE devices need to pre-configure the controller's SSH authentication credentials (such as username and password), which poses obvious security risks. Once the credentials are leaked, the entire network of devices may be vulnerable to security threats.

[0004] To address the aforementioned pain points and challenges, this solution proposes an automatic identification and transparent access method based on a Socks5 reverse tunnel and a device information pre-registration mechanism. This method reports device identification and metadata after establishing a transport layer connection but before the proxy handshake, achieving automatic device identification and seamless reverse proxying. This effectively overcomes the limitations of traditional SSH reverse tunnels in terms of flexibility, security, and functionality. Summary of the Invention

[0005] This application provides a method for automatically identifying and accessing CPE devices based on reverse tunneling, characterized by comprising: Based on the reverse tunneling protocol, the initial communication link is established by the CPE device actively initiating a TCP connection and performing a three-way handshake. Based on the established TCP connection, the CPE device reports the device identifier and structured device information along with the road, enabling the controller to automatically identify devices and manage port mapping. Based on the binding relationship between device identifier and logical connection, the controller queries the mapping and utilizes the logical connection to enable proactive access to any service of the CPE device.

[0006] Optionally, the establishment of the initial communication link based on the reverse tunneling protocol, whereby the CPE device actively initiates a TCP connection and performs a three-way handshake, includes: Based on the requirement to establish a reverse tunnel of Socks5 or similar Socks5, the CPE device actively initiates a connection request to the TCP port specified by the controller to realize the three-way handshake of the transport layer TCP. By successfully completing the three-way handshake, an initial TCP communication link is established from the CPE device to the controller.

[0007] Optionally, the step of automatically identifying devices and managing port mapping for the controller by reporting device identifiers and structured device information via the CPE device along with the established TCP connection includes: Based on the established TCP connection, data is sent on this link through the CPE device to report the device identifier and other device information to the controller; Based on the reported data received by the controller, the controller parses and extracts the device identifier, automatically allocates a local port for the TCP connection, and establishes a mapping relationship between the port and the device identifier; By continuing the protocol handshake and authentication process on this TCP connection, a logical connection with a device identifier and proxy functionality is established.

[0008] Optionally, the step of querying the mapping through the controller and utilizing the logical connection based on the binding relationship between the device identifier and the logical connection to achieve proactive access to any service of the CPE device includes: Based on the service requirements accessing the CPE device, the corresponding logical connection can be queried through the device identifier via external commands or the controller's own logic. By querying the specific logical connection, the controller sends an access target request to that logical connection, thereby forwarding the request data to the CPE device. This logical connection enables seamless access to services within the CPE device by transmitting data over the established TCP link.

[0009] Optionally, the step of sending data on this link via the CPE device based on the established TCP connection to report the device identifier and other device information to the controller includes: After the TCP connection is established but before the protocol handshake begins, the CPE device prioritizes sending pre-prepared data packets on this link to report the device's unique identifier and other device information; The pre-prepared data packets are encapsulated and serialized using a lightweight structured data format to generate device information messages with a uniform format that are easy to parse.

[0010] Optionally, the step of automatically allocating a local port for the TCP connection and establishing a mapping relationship between the port and the device identifier by parsing and extracting the device identifier from the reported data received by the controller includes: Based on the received reported data, the controller's listening service parses its format and obtains the device identifier field. Based on the obtained device identifier, an idle local listening port is automatically allocated to the device identifier, and the correspondence between the device identifier and the allocated local port is stored in the controller mapping management table to form a mapping relationship that can be used for querying and routing.

[0011] Optionally, the step of obtaining a specific logical connection through querying, and then using the controller to send an access target request to that logical connection to forward the request data to the CPE device, includes: Based on the instructions to access services on the CPE device, the local port number bound to it and the corresponding logical connection are obtained by querying the port mapping table with the device identifier as the key; The controller initiates a TCP connection to the local port and sends the target service address and port as a request to the logical connection, thereby encapsulating the access intent into a protocol request packet. Based on the established reverse tunnel, the protocol request packet is transmitted to the remote CPE device through the initial TCP link via this logical connection, so that the CPE device can parse the request locally and establish a connection to the service port to complete the data forwarding.

[0012] This application also provides a device for automatically identifying and accessing CPE devices based on reverse tunneling, characterized in that the device comprises: The automatic identification module is used to initiate a TCP connection and perform a three-way handshake through the CPE device based on the reverse tunneling protocol to establish the initial communication link; The connection and identification binding module is used to report device identification and structured device information via the CPE device along with the established TCP connection, so as to realize the controller's automatic device identification and port mapping management. The access module is used to actively access any service of the CPE device by querying the mapping through the controller and utilizing the logical connection based on the binding relationship between the device identifier and the logical connection.

[0013] Optionally, the connection and identifier binding module further includes: The data reporting and receiving module is used to obtain device identification and structured device information by intercepting and receiving the first data packet sent by the CPE device before the protocol handshake begins, based on the established TCP connection. The mapping management module is used to automatically allocate a local port for the TCP connection based on the received reported data by parsing its data structure and extracting the device identifier field, and to establish a mapping relationship between the device identifier and the local port, storing it in the controller's mapping table; The logical connection establishment module is used to establish a usable reverse proxy logical connection bound to the mapping relationship by continuing the protocol handshake and authentication process with the CPE device on the same TCP connection after the data reporting and reception is completed.

[0014] This application also provides an electronic device, characterized in that it includes a method for automatically identifying and accessing a CPE device based on reverse tunneling, comprising: The controller listens for TCP connections from CPE devices, receives and parses device identifiers and structured device information reported by CPE devices, automatically allocates local ports and establishes a mapping relationship between ports and device identifiers, completes the protocol handshake to establish a logical connection, and accesses the internal services of CPE devices through the specified logical connection according to the query request. The CPE device is used to proactively initiate a TCP connection to the controller and immediately report the device's identifier and structured device information after the connection is established. It then continues to complete the protocol handshake to establish a logical connection with the controller and acts as a server to respond to and process all access requests forwarded through this logical connection.

[0015] The beneficial effects of this application are as follows: by using a Socks5 or Socks5-like reverse tunnel and pre-reporting device identifiers and structured information using the same TCP connection before establishing a logical connection, the controller can automatically identify and bind a large number of CPE devices, eliminating the maintenance overhead of manually configuring port mapping; by having the controller actively query the mapping relationship between device identifiers and logical connections, it can directly access the CPE device's intranet services through the reverse tunnel, achieving seamless, centralized, and secure access to device services in the heterogeneous network environment of the enterprise; and by integrating the device discovery, tunnel establishment, and service proxy processes into a single continuous session, it significantly reduces the number of links and communication rounds in traditional solutions, and significantly improves connection establishment efficiency and system scalability. Attached Figure Description

[0016] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the accompanying drawings required in the description of the embodiments or the prior art are briefly introduced below. Obviously, the accompanying drawings described below are only embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on the provided drawings without creative effort.

[0017] Figure 1 A flowchart illustrating a specific embodiment of this application shows a method for automatically identifying and accessing CPE devices based on reverse tunneling; Figure 2 This diagram illustrates a prior art method for automatically identifying and accessing CPE devices based on a reverse tunnel, according to a specific embodiment of this application. Figure 3 This diagram illustrates the architecture of a method for automatically identifying and accessing CPE devices based on reverse tunneling, according to a specific embodiment of this application. Figure 4 This illustration shows a data exchange diagram of a method for automatically identifying and accessing CPE devices based on a reverse tunnel according to a specific embodiment of this application. Figure 5 This diagram illustrates a device block diagram for automatically identifying and accessing CPE devices based on a specific embodiment of this application using reverse tunneling. Detailed Implementation

[0018] Various exemplary embodiments, features, and aspects of this application will now be described in detail with reference to the accompanying drawings. The same reference numerals in the drawings denote elements that have the same or similar functions. Although various aspects of the embodiments are shown in the drawings, they are not necessarily drawn to scale unless specifically indicated otherwise.

[0019] The terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of technical features indicated. Therefore, a feature defined as "first" or "second" may explicitly or implicitly include one or more of that feature. In the description of this application, "multiple" means two or more, unless otherwise explicitly specified.

[0020] The term “exemplary” as used herein means “serving as an example, embodiment, or illustration.” Any embodiment illustrated herein as “exemplary” is not necessarily to be construed as superior to or better than other embodiments.

[0021] Furthermore, to better illustrate this application, numerous specific details are provided in the following detailed embodiments. Those skilled in the art should understand that this application can be implemented without certain specific details. In some instances, methods, means, components, and circuits well-known to those skilled in the art have not been described in detail in order to highlight the main points of this application.

[0022] This invention proposes a method for automatically identifying and accessing CPE devices based on reverse tunneling, addressing challenges such as difficult device discovery, cumbersome manual configuration, and complex network penetration when remotely maintaining a large number of distributed CPE devices. Based on Socks5 or a Socks5-like reverse tunneling protocol, this method innovatively utilizes device-initiated TCP connections to pre-report device identifiers and other structured information before the tunneling protocol handshake, enabling the controller to simultaneously complete device authentication and logical channel establishment on the same connection. Accordingly, this invention designs a device information pre-reporting mechanism, an automatic identifier and port mapping mechanism, and a service proxy mechanism based on logical connections, respectively enabling zero-configuration device identification by the controller, dynamic binding of reverse tunnel links, and seamless transparent access to CPE internal services. Application results show that the method described in this invention can automatically access and manage devices without any pre-configuration, significantly reducing operational complexity while ensuring efficient and secure remote access to various internal network services such as SSH, gRPC, and Web.

[0023] Example 1 like Figure 1 The diagram shown is a flowchart of a method for automatically identifying and accessing a CPE device based on a reverse tunnel, according to an embodiment of this application. The method specifically includes the following: The S100, based on the reverse tunneling protocol, initiates a TCP connection and performs a three-way handshake through the CPE device to establish the initial communication link.

[0024] Specifically, based on the communication framework defined by Socks5 or a Socks5-like reverse tunneling protocol, an initial transmission control channel is established between the CPE device and the controller. The CPE device, as the communication initiator, actively initiates a transmission control protocol connection request to the controller's preset listening port. The controller, as the receiver, responds to this request. The two parties exchange sequence numbers and acknowledgment numbers through a standard three-way handshake process, negotiate the initial sequence window size, thereby verifying the bidirectional reachability of the communication link and synchronizing the connection status.

[0025] Based on the established TCP connection, the S200 uses the CPE device to report device identifiers and structured device information along with the road, enabling the controller to automatically identify devices and manage port mapping.

[0026] Specifically, based on the successfully established Transmission Control Protocol (TCP) connection, before any Socks5 or Socks5-like protocol interaction, the existing channel is immediately used to transmit device metadata. The CPE device, as the information provider, serializes and encapsulates its unique identifier and other attribute information according to a predefined structured data organization format to form payload data and sends it. The controller, as the receiver and parser, listens for and reads this initial data, extracts the key device identification field, and then dynamically allocates a local logical port resource. A strong mapping relationship is created and maintained between this port and the obtained device identifier. Afterward, both parties continue to complete the subsequent interaction processes, such as authentication and method negotiation, as specified by the Socks5 or Socks5-like protocol, on the same TCP connection. Finally, based on the above mapping relationship, a logical connection tunnel bound to a specific device and possessing proxy forwarding capabilities is successfully constructed.

[0027] S300, based on the binding relationship between device identifier and logical connection, queries the mapping through the controller and utilizes the logical connection to enable proactive access to any service of the CPE device.

[0028] Specifically, based on the pre-stored mapping between device identifiers and logical connection ports, the controller enables on-demand reverse access to services within the CPE device. When there is a need to access a specific CPE device service, the requesting party provides the controller with the identifier of the target device. The controller, acting as an access proxy hub, uses the received device identifier as the lookup key to retrieve the logical connection channel bound to that device from its internal mapping table. Subsequently, following the Socks5 or Socks5-like proxy protocol specification, the controller re-encapsulates the external access request into a forwarding data packet conforming to the protocol format and forwards the request data stream to the corresponding remote CPE device through the established logical connection tunnel. The CPE device receives and decapsulates this data stream at the tunnel end, restores it to a standard service request, and submits it to the corresponding local service process for processing. This ultimately achieves seamless, transparent, and controlled proactive access to the services of CPE devices in a private network environment.

[0029] In summary, this application breaks through the traditional reverse tunneling model that requires establishing a proxy connection before additional device registration, innovatively integrating device identity reporting with the tunnel establishment process. By pre-transmitting device identifiers and structured metadata through the same channel after the TCP connection is established but before the Socks5 or Socks5-like protocol handshake, the controller achieves automatic device identification and discovery with zero configuration. This eliminates the operational burden of manually configuring port mappings for each device, significantly reducing the overhead and complexity of link establishment, and providing an efficient and automated access solution for the centralized management of large-scale distributed CPE devices. Secondly, addressing the pain point of difficulty in unified access to device services in heterogeneous network environments, a dynamic binding and mapping mechanism for logical connections based on device identifiers is designed. The controller automatically allocates local ports and establishes a strong association mapping with the device identifier by parsing the reported information, and then completes tunnel establishment on the same connection, forming a dedicated proxy channel for the device. This mechanism makes the logical connections between massive devices and the controller globally addressable and manageable. Administrators only need to provide the device identifier to accurately locate the tunnel link, laying a solid foundation for subsequent service access. Finally, a seamless service proxy access system based on reverse tunnels is constructed. By querying the mapping relationship between device identifiers and logical connections, the controller can dynamically encapsulate externally initiated access requests into a Socks5 proxy protocol format and accurately forward them to the target CPE device through the established tunnel. This system effectively overcomes the access barriers caused by Network Address Translation (NAT) and firewalls, enabling transparent, secure, and centralized access to various services such as SSH, gRPC, and Web on CPE devices located within a private network, greatly improving the efficiency and reliability of remote operation and maintenance.

[0030] As an optional implementation of this application, optionally, in step S100, based on the reverse tunneling protocol, the CPE device actively initiates a TCP connection and performs a three-way handshake to establish the initial communication link, including: S101, based on the requirement of establishing a Socks5 or Socks5-like reverse tunnel, actively initiates a connection request to the TCP port specified by the controller through the CPE device, thereby realizing the three-way handshake of the transport layer TCP.

[0031] Specifically, such as Figure 3As shown, the CPE device, based on pre-configured network parameters and controller endpoint information, actively initiates a connection establishment request to the specific Transmission Control Protocol (TCP) port that the controller is listening on. The CPE device constructs a synchronization sequence number packet, sets an initial sequence number, and sets the synchronization flag to indicate the connection request intent. The controller, as the connection receiver, upon receiving this request packet, if the target port is in a normal listening state, constructs a synchronization acknowledgment packet in response. This acknowledgment packet contains both a field confirming the received initial sequence number and a field carrying the controller's own generated initial sequence number to achieve bidirectional sequence number synchronization. After receiving this acknowledgment, the CPE device sends a final acknowledgment packet to confirm the controller's sequence number, thus completing the three-way handshake process. Through the interaction of these three data packets, the communicating parties successfully exchange and confirm each other's initial sequence number windows, negotiating and determining the starting sequence number and window size parameters for subsequent data transmission, laying the foundation for subsequent reliable byte stream-based data transmission.

[0032] S102, by successfully completing the three-way handshake, an initial TCP communication link is obtained from the CPE device to the controller.

[0033] Specifically, such as Figure 3 As shown, after successfully completing the three-way handshake of the Transmission Control Protocol (TCP), a bidirectional, reliable, and ordered initial communication link is established between the CPE device and the controller. The state of this link is marked as established in the system kernels of both communicating parties, and both parties can send and receive data on this link. This link provides a byte-stream-based transmission service, ensuring that data packets transmitted through it arrive in order, and guarantees data reliability through acknowledgment and retransmission mechanisms. The establishment of this link provides a fundamental network communication capability guarantee for subsequent data exchange of any application layer protocol (including Socks5 or Socks5-like protocols).

[0034] As an optional implementation of this application, optionally, in step S200, based on the established TCP connection, the CPE device reports the device identifier and structured device information along with the device to realize the controller's automatic device identification and port mapping management, including: S201, based on the established TCP connection, data is sent on this link through the CPE device to realize the reporting of the device identifier and other device information to the controller.

[0035] Specifically, after the Transmission Control Protocol (TCP) connection is successfully established, and before any handshake interaction as defined by Socks5 or Socks5-like protocols, the CPE device immediately uses this established reliable channel to prioritize sending device metadata information. The CPE device serializes and encapsulates its unique identifier and other relevant attribute information (which may include device model, hardware version, software version, etc.) according to a predefined, structured data organization format (e.g., TLV / LV / V, JSON, or XML) to form an application layer data payload. This data payload is then encapsulated in a TCP segment and sent to the controller through the established connection. The controller, as the receiver, continuously listens for data arrivals on this connection, reads, and receives this initial data packet.

[0036] Among them, such as Figure 4 As shown, the CPE device actively initiates a TCP connection. After a successful TCP handshake, the CPE device immediately uses this TCP connection to report its device identifier and other optional information, including but not limited to the device name, operating system, and version. The reported data can be formatted data, including but not limited to TLV / LV / V, JSON, XML, etc. The controller allocates a local port and records the mapping relationship between this port and the device identifier.

[0037] S202, based on the reported data received by the controller, the controller parses and extracts the device identifier, automatically allocates a local port for the TCP connection, and establishes a mapping relationship between the port and the device identifier.

[0038] Specifically, after receiving reported data from the CPE device, the controller calls the corresponding parsing module to process the data payload. Based on the known data format specifications, the parsing module deserializes the received structured data, precisely extracting the device identifier as a key field. Subsequently, the controller's connection management module is triggered, dynamically selecting an unoccupied local transmission control protocol port from the available port resource pool and associating this port number with the extracted device identifier. This association, a mapping pair between the device identifier and the local port number, is created and persistently stored in the controller's mapping management table.

[0039] Among them, such as Figure 4 As shown, the CPE device and controller continue with the subsequent processes of the SOCKS5 or SOCKS5-like protocol to establish a logical connection. The controller can then locate the logical connection via the CPE device identifier and access any service of the CPE device through that connection, based on external instructions or its own needs. This includes, but is not limited to, SSH, GPRC, and web services.

[0040] S203, by continuing the protocol handshake and authentication process on the TCP connection, establish a logical connection that is bound to the device identifier and has proxy functionality.

[0041] Specifically, after the device information is reported and the mapping relationship is established, the two communicating parties continue to use the existing same Transmission Control Protocol (TCP) connection to conduct subsequent interaction processes defined by the Socks5 or Socks5-like protocol. This typically includes version and authentication method negotiation, optional identity authentication, and final command request and method confirmation. The CPE device and controller exchange corresponding instructions and response messages according to the protocol specifications, gradually completing the protocol handshake phase. After successfully completing all necessary interactions, a logical connection tunnel based on the Socks5 protocol standard and possessing proxy forwarding capabilities is considered successfully established over the TCP connection.

[0042] As an optional implementation of this application, optionally, in step S300, based on the binding relationship between the device identifier and the logical connection, the controller queries the mapping and utilizes the logical connection to achieve active access to any service of the CPE device, including: S301, based on the service requirements of accessing the CPE device, uses external commands or the controller's own logic to query the corresponding logical connection through the device identifier.

[0043] Specifically, when there is a need to access services on a specific CPE device (this need may originate from external user commands or internal controller timed tasks), the requesting party must provide the controller with the device identifier of the target CPE device. Upon receiving the access request and the target device identifier, the controller's mapping query module is activated. Using the received device identifier as the query key, it searches the internally maintained mapping management table to find the local transmission control protocol port number associated with that device identifier. Successfully finding the target port number means locating the local access point of the logical connection tunnel bound to the target CPE device.

[0044] S302, by querying the specific logical connection, the controller sends an access target request to the logical connection, thereby forwarding the request data to the CPE device.

[0045] Specifically, after successfully retrieving the corresponding local port number using the device identifier, the controller, acting as an access proxy hub, begins operation. Access requests are received and processed by the controller. Following the specifications of the Socks5 proxy protocol or a Socks5-like protocol, the controller re-encapsulates the original access request (e.g., an attempt to access an SSH or web service within the CPE device) into one or more data frames conforming to the Socks5 protocol format. These data frames contain the address and port information of the target service. The encapsulated protocol data units are then sent through the operating system's network stack to the specific local port previously retrieved. Since this port is associated with the logical connection tunnel to the target CPE device, data is injected into this reverse tunnel.

[0046] S303 transmits data over the established TCP link through this logical connection, enabling seamless access to services within the CPE device.

[0047] Specifically, the data stream injected into the reverse tunnel is transmitted to the remote CPE device via a reliable underlying transmission control protocol connection. The data frames received by the CPE device's network stack have the controller itself as the destination IP and port, but the payload is the original request encapsulated in the Socks5 protocol. The Socks5 proxy client (or server) program on the CPE device decapsulates the received data, strips the Socks5 protocol header, and restores the original access request data packet. The restored request data packet is then submitted to the CPE device's local operating system and, based on its destination address and port information, is routed to the corresponding local service process on the device (such as the SSHD daemon, HTTP server, etc.) for processing. The response data generated by the service process is then returned along the original path, ultimately reaching the original request initiator, thus completing a full, transparent access to the CPE device's services located within the private network.

[0048] Example 2 Based on the same principle as the aforementioned method, a device for automatically identifying and accessing CPE devices based on reverse tunneling is also proposed, see [link to relevant documentation]. Figure 5 An apparatus 100 for automatically identifying and accessing CPE devices based on reverse tunneling, according to an embodiment of this disclosure, includes: The automatic identification module 110 is used to initiate a TCP connection and perform a three-way handshake through the CPE device based on the reverse tunneling protocol to establish the initial communication link. The connection and identification binding module 120 is used to report device identification and structured device information via the CPE device along with the established TCP connection, so as to realize the controller's automatic device identification and port mapping management. Access module 130 is used to actively access any service of CPE device by querying the mapping through the controller and utilizing the logical connection based on the binding relationship between device identifier and logical connection.

[0049] As an optional implementation of this application, the connection and identifier binding module 120 may further include: The data reporting and receiving module 121 is used to obtain device identification and structured device information by intercepting and receiving the first data packet sent by the CPE device before the protocol handshake begins, based on the established TCP connection. The mapping management module 122 is used to automatically allocate a local port for the TCP connection based on the received reported data by parsing its data structure and extracting the device identifier field, and to establish a mapping relationship between the device identifier and the local port and store it in the controller's mapping table. The logical connection establishment module 123 is used to establish a usable reverse proxy logical connection bound to the mapping relationship by continuing the protocol handshake and authentication process with the CPE device on the same TCP connection after the data reporting and reception is completed.

[0050] Obviously, those skilled in the art should understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. The program can be stored in a computer-readable storage medium, and when executed, it can include the processes of the embodiments of the control methods described above. The modules or steps of this application described above can be implemented using general-purpose computing devices. They can be centralized on a single computing device or distributed across a network of multiple computing devices. Optionally, they can be implemented using computer-executable program code, and thus can be stored in a storage device for execution by a computing device, or they can be fabricated as separate integrated circuit modules, or multiple modules or steps can be fabricated as a single integrated circuit module. Therefore, this application is not limited to any specific hardware and software combination.

[0051] Those skilled in the art will understand that all or part of the processes in the above embodiments can be implemented by a computer program instructing related hardware. The program can be stored in a computer-readable storage medium, and when executed, it can include the processes of the embodiments of the control methods described above. The storage medium can be a magnetic disk, optical disk, read-only memory (ROM), random access memory (RAM), flash memory, hard disk drive (HDD), or solid-state drive (SSD), etc.; the storage medium can also include combinations of the above types of memory.

[0052] Example 3 Furthermore, this application proposes an electronic device characterized by comprising the following methods for implementing any of the aforementioned methods for automatically identifying and accessing CPE devices based on reverse tunneling: The controller listens for TCP connections from CPE devices, receives and parses device identifiers and structured device information reported by CPE devices, automatically allocates local ports and establishes a mapping relationship between ports and device identifiers, completes the protocol handshake to establish a logical connection, and accesses the internal services of CPE devices through the specified logical connection according to the query request. The CPE device is used to proactively initiate a TCP connection to the controller and immediately report the device's identifier and structured device information after the connection is established. It then continues to complete the protocol handshake to establish a logical connection with the controller and acts as a server to respond to and process all access requests forwarded through this logical connection.

[0053] An embodiment of the network control system disclosed herein includes the aforementioned controller and one or more of the aforementioned CPE devices. The controller and CPE devices communicate via a network. The CPE devices are configured to actively establish connections with the controller and report information. The controller is configured to automatically manage device connections and provide proxy access functionality based on the received information.

[0054] It should be noted that the number of controllers deployed can be one or more, and the number of CPE devices can be multiple. Furthermore, not only CPE devices can be selected, but other computers requiring centralized management or terminals with computer functions can also be used. Additionally, in the network control system of this embodiment, the controller may also include input interfaces and output interfaces. The internal components of the controller can be connected via an internal bus or other methods, which are not specifically limited here.

[0055] The controller's memory can serve as a computer-readable storage medium, used to store software programs, computer-executable programs, and various modules that implement automatic device identification and access functions, such as: device connection management modules, information parsing modules, mapping maintenance modules, logical connection processing modules, and service proxy modules. The controller executes the automatic identification, connection management, and service access functions for CPE devices by running the relevant software programs or modules stored in its memory.

[0056] The input interface can be used to receive user commands or access requests from external systems, while the output interface can be used to output system status, access results, or warning information. A CPE device may include a network interface unit, a device information storage unit, and a service processing unit, used for network communication, storing device identification and configuration information, and operating and providing internal services, respectively.

[0057] The various embodiments of this application have been described above. These descriptions are exemplary and not exhaustive, nor are they limited to the disclosed embodiments. Many modifications and variations will be apparent to those skilled in the art without departing from the scope and spirit of the described embodiments. The terminology used herein is chosen to best explain the principles, practical application, or improvement of the technology in the market, or to enable others skilled in the art to understand the embodiments disclosed herein.

Claims

1. A method for automatically identifying and accessing CPE devices based on reverse tunneling, characterized in that, include: Based on the reverse tunneling protocol, the initial communication link is established by the CPE device actively initiating a TCP connection and performing a three-way handshake. Based on the established TCP connection, the controller can automatically identify devices and manage port mapping by reporting device identifiers and structured device information along with the CPE device. Based on the binding relationship between device identifiers and logical connections, the controller can query the mapping and utilize the logical connection to enable active access to any service of the CPE device.

2. The method for automatically identifying and accessing CPE devices based on reverse tunneling as described in claim 1, characterized in that, The method of establishing an initial communication link based on the reverse tunneling protocol, whereby the CPE device actively initiates a TCP connection and performs a three-way handshake, includes: Based on the requirement to establish a reverse tunnel of Socks5 or similar Socks5, the CPE device actively initiates a connection request to the TCP port specified by the controller to realize the three-way handshake of the transport layer TCP. By successfully completing the three-way handshake, an initial TCP communication link is established from the CPE device to the controller.

3. The method for automatically identifying and accessing CPE devices based on reverse tunneling as described in claim 1, characterized in that, The process of automatically identifying devices and managing port mapping for the controller by reporting device identifiers and structured device information via the CPE device along with the established TCP connection includes: Based on the established TCP connection, data is sent on this link through the CPE device to report the device identifier and other device information to the controller; Based on the reported data received by the controller, the controller parses and extracts the device identifier, automatically allocates a local port for the TCP connection, and establishes a mapping relationship between the port and the device identifier; By continuing the protocol handshake and authentication process on this TCP connection, a logical connection with a device identifier and proxy functionality is established.

4. The method for automatically identifying and accessing CPE devices based on reverse tunneling as described in claim 1, characterized in that, The process of leveraging the binding relationship between device identifiers and logical connections, querying the mapping through the controller, and utilizing the logical connections to enable proactive access to any service of the CPE device includes: Based on the service requirements accessing the CPE device, the corresponding logical connection can be queried through the device identifier via external commands or the controller's own logic. By querying the specific logical connection, the controller sends an access target request to that logical connection, thereby forwarding the request data to the CPE device. This logical connection enables seamless access to services within the CPE device by transmitting data over the established TCP link.

5. The method for automatically identifying and accessing CPE devices based on reverse tunneling as described in claim 3, characterized in that, The step of sending data over this link via the CPE device based on the established TCP connection to report the device identifier and other device information to the controller includes: After the TCP connection is established but before the protocol handshake begins, the CPE device prioritizes sending pre-prepared data packets on this link to report the device's unique identifier and other device information; The pre-prepared data packets are encapsulated and serialized using a lightweight structured data format to generate device information messages with a uniform format that are easy to parse.

6. The method for automatically identifying and accessing CPE devices based on reverse tunneling as described in claim 3, characterized in that, The step of automatically allocating a local port for the TCP connection and establishing a mapping relationship between the port and the device identifier based on the reported data received by the controller includes: Based on the received reported data, the controller's listening service parses its format and obtains the device identifier field. Based on the obtained device identifier, an idle local listening port is automatically allocated to the device identifier, and the correspondence between the device identifier and the allocated local port is stored in the controller mapping management table to form a mapping relationship that can be used for querying and routing.

7. The method for automatically identifying and accessing CPE devices based on reverse tunneling as described in claim 4, characterized in that, The specific logical connection obtained through querying, and the controller sending an access target request to that logical connection to forward the request data to the CPE device, include: Based on the instructions to access services on the CPE device, the local port number bound to it and the corresponding logical connection are obtained by querying the port mapping table with the device identifier as the key; The controller initiates a TCP connection to the local port and sends the target service address and port as a request to the logical connection, thereby encapsulating the access intent into a protocol request packet. Based on the established reverse tunnel, the protocol request packet is transmitted to the remote CPE device through the initial TCP link via this logical connection, so that the CPE device can parse the request locally and establish a connection to the service port to complete the data forwarding.

8. A device for automatically identifying and accessing CPE devices based on reverse tunneling, characterized in that, The device includes: The automatic identification module is used to initiate a TCP connection and perform a three-way handshake through the CPE device based on the reverse tunneling protocol to establish the initial communication link; The connection and identification binding module is used to report device identification and structured device information via the CPE device along with the established TCP connection, so as to realize the controller's automatic device identification and port mapping management. The access module is used to actively access any service of the CPE device by querying the mapping through the controller and utilizing the logical connection based on the binding relationship between the device identifier and the logical connection.

9. The apparatus for automatically identifying and accessing CPE devices based on reverse tunneling according to claim 8, wherein the connection and identification binding module further comprises: The data reporting and receiving module is used to obtain device identification and structured device information by intercepting and receiving the first data packet sent by the CPE device before the protocol handshake begins, based on the established TCP connection. The mapping management module is used to automatically allocate a local port for the TCP connection based on the received reported data by parsing its data structure and extracting the device identifier field, and to establish a mapping relationship between the device identifier and the local port, storing it in the controller's mapping table; The logical connection establishment module is used to establish a usable reverse proxy logical connection bound to the mapping relationship by continuing the protocol handshake and authentication process with the CPE device on the same TCP connection after the data reporting and reception is completed.

10. An electronic device, characterized in that, The method for automatically identifying and accessing CPE devices based on reverse tunneling as described in any one of claims 1 to 7 includes: The controller listens for TCP connections from CPE devices, receives and parses device identifiers and structured device information reported by CPE devices, automatically allocates local ports and establishes a mapping relationship between ports and device identifiers, completes the protocol handshake to establish a logical connection, and accesses the internal services of CPE devices through the specified logical connection according to the query request. The CPE device is used to proactively initiate a TCP connection to the controller and immediately report the device's identifier and structured device information after the connection is established. It then continues to complete the protocol handshake to establish a logical connection with the controller and acts as a server to respond to and process all access requests forwarded through this logical connection.

Images