A data transmission method, device and equipment for multiple local area networks based on dynamic addressing

Abstract

The application provides a data transmission method, device and equipment based on multiple local area networks with dynamic addressing. The method comprises the following steps: receiving a duplex connection request encapsulated based on a preset proxy protocol sent by a multi-level beacon client in multiple local area networks; establishing an encrypted tunnel with the beacon client according to the duplex connection request and registering to a dynamic routing table; receiving an access request for a target device in a target local area network sent by a data collection client corresponding to a target device; determining the address of a target encrypted tunnel in the dynamic routing table according to the account information of the target beacon client and the beacon level; pushing the access request to the target beacon client corresponding to the target local area network through the target encrypted tunnel corresponding to the address; receiving the service data of the target device sent by the target beacon client through the target encrypted tunnel and sending the service data to the data collection client. The scheme can realize instant access to multi-level NAT environment resources, and significantly reduces the operation and maintenance cost.

Description

Technical Field

[0001] This invention relates to the field of network communication technology, and in particular to a data transmission method, apparatus and equipment for multiple local area networks based on dynamic addressing. Background Technology

[0002] With the complete depletion of the global IPv4 address pool and the widespread deployment of Carrier-Grade Network Address Translation (CGNAT) technology, network topologies have generally evolved into multi-level Network Address Translation (NAT) environments, leaving enterprise branches, home gateways, and IoT terminals isolated within closed local area networks. Under this architecture, traditional data acquisition methods based on direct connections via public network protocols (Internet Protocol, IP) have become essentially ineffective due to the loss of end-to-end connectivity.

[0003] While existing LAN penetration and networking solutions restore connectivity to some extent, their underlying design still follows the static mapping paradigm of port mapping or virtual IP allocation. This requires pre-configuring fixed forwarding policies on gateway devices or assigning independent virtual network addresses to each service instance. This "one-to-one" static mapping mechanism exposes the following structural defects: Scalability bottleneck: Configuration policies are tightly coupled with business instances. New services must explicitly add forwarding rules, which causes the complexity of operation and maintenance to increase linearly with the scale of the business, making it difficult to support elastic scaling requirements.

[0004] Lack of dynamic addressing capability: Traffic forwarding paths are fixed to preset rules, lacking addressing capabilities based on user identity, session context or dynamic service characteristics. It is unable to achieve real-time access to temporary port services within the local area network and dynamically generated collection tasks, and it is also difficult to adapt to stateless or sudden communication scenarios.

[0005] Insufficient protocol evolution compatibility: Traditional device protocol stacks generally do not natively support network protocol version 6 (IPv6), resulting in a compatibility gap under dual-stack evolution, which hinders seamless integration with future network infrastructure.

[0006] Weak security protection mechanisms: Static mapping mode directly exposes internal network service ports to the public network, significantly expanding the attack surface and making it vulnerable to port scanning, vulnerability detection and targeted attacks. At the same time, it lacks identity authentication and access control, making it difficult to prevent unauthorized access and lateral movement risks. Summary of the Invention

[0007] This invention provides a data transmission method, apparatus, and device for multiple local area networks based on dynamic addressing, which solves the problems of high operation and maintenance costs and inability to obtain resources in real time.

[0008] To solve the above-mentioned technical problems, the technical solution of the present invention is as follows: This invention provides a data transmission method for multiple local area networks based on dynamic addressing, applied to a server on a public network. The method includes: The system receives a full-duplex connection request encapsulated based on a preset proxy protocol from a multi-level beacon client that corresponds to at least one of multiple local area networks (LANs) and is deployed hierarchically. The LAN is the LAN to which the target device belongs in a multi-level network address translation environment. The full-duplex connection request carries the device identifier of the target device. Based on the duplex connection request, an encrypted tunnel is established with the beacon client and registered to the dynamic routing table; Receive an access request for the target device in the target local area network sent by the data acquisition client corresponding to the target device; the access request carries: the account information of the target beacon client, the beacon level, and the device identifier of the target device; Based on the target beacon client's account information and beacon level, the address of the target encrypted tunnel is determined in the dynamic routing table; The access request is pushed to the target beacon client corresponding to the target local area network through the target encrypted tunnel corresponding to the address; The system receives service data from the target device sent by the target beacon client through the target encrypted tunnel, and then sends the service data to the data acquisition client.

[0009] Optionally, receiving a full-duplex connection request encapsulated based on a preset proxy protocol from a multi-level beacon client corresponding to at least one of multiple local area networks (LANs) and deployed hierarchically, including: The system receives a full-duplex connection request from a multi-level beacon client, which is deployed hierarchically and corresponds to at least one of multiple local area networks (LANs), and encapsulates the device identifier of the target device based on a preset proxy protocol.

[0010] Optionally, based on the full-duplex connection request, an encrypted tunnel is established with the beacon client and registered to the dynamic routing table, including: Based on the full-duplex connection request, an encrypted tunnel is established with the beacon client; the encrypted tunnel includes a control encrypted tunnel and a data encrypted tunnel. Temporary account information is allocated to the beacon client through the control encryption tunnel, and the temporary account information is sent to the beacon client. The registration request sent by the beacon client is received through the control encryption tunnel. The registration request includes a temporary identity and a beacon level. The temporary identity is generated by the beacon client based on the temporary account information, timestamp, and device identifier. Verify the temporary identity identifier in the registration request; After successful verification, the temporary account information corresponding to the beacon client is updated to the account information, and the account information is bound to the corresponding encrypted tunnel and beacon level to generate a mapping relationship and register it to the dynamic routing table; The information in the dynamic routing table includes account information, control encryption tunnel identifier, data encryption tunnel identifier, and beacon level.

[0011] Optionally, the temporary identity in the registration request is verified, including: Based on the temporary account information, device identifier, and multiple timestamps within the sliding time window in the registration request, multiple reference hash values ​​are obtained respectively; If any of the reference hash values ​​matches the temporary identity identifier in the registration request, the temporary identity identifier is deemed to have been verified.

[0012] Optionally, based on the account information and beacon level of the access request, the target encrypted tunnel is determined in the dynamic routing table, including: Based on the account information and beacon level, the mapping relationship in the dynamic routing table is queried to determine the target encrypted tunnel; the target encrypted tunnel includes the target control encrypted tunnel and the target data encrypted tunnel.

[0013] Optionally, the access request is pushed to the target beacon client corresponding to the target local area network through the target encrypted tunnel, including: The target beacon client is sent an addressing command through the target control encrypted tunnel; the addressing command carries the device identifier and is used to instruct the target beacon client to find the corresponding target device within the local area network; The access request is pushed to the target beacon client through the target data encryption tunnel, so that the target beacon client can obtain business data based on the target device found.

[0014] Optionally, the method further includes: The validity of the encrypted tunnel and the account information is monitored in real time to obtain the monitoring status; When the monitoring status is disconnected or the information is invalid, the corresponding mapping relationship in the dynamic routing table is automatically cleared.

[0015] This invention also provides a data transmission device for multiple local area networks based on dynamic addressing, comprising: The acquisition module is used to receive a full-duplex connection request based on a preset proxy protocol sent by a multi-level beacon client corresponding to at least one of multiple local area networks (LANs) and deployed hierarchically; the LAN is the LAN to which the target device belongs in the multi-level network address translation environment, and the full-duplex connection request carries: the device identifier of the target device; The processing module is configured to: establish an encrypted tunnel with the beacon client based on the full-duplex connection request and register it in the dynamic routing table; receive an access request for a target device in the target local area network sent by the data acquisition client corresponding to the target device; the access request carries: the account information of the target beacon client, the beacon level, and the device identifier of the target device; determine the address of the target encrypted tunnel in the dynamic routing table based on the account information and beacon level of the target beacon client; push the access request to the target beacon client corresponding to the target local area network through the target encrypted tunnel corresponding to the address; receive the service data of the target device sent by the target beacon client through the target encrypted tunnel, and send the service data to the data acquisition client.

[0016] This invention also provides a computing device, including: a processor and a memory storing a computer program, wherein the computer program, when run by the processor, executes the above-described method.

[0017] This invention also provides a computer-readable storage medium storing instructions that, when executed on a computer, cause the computer to perform the above-described method.

[0018] The technical solution of the present invention has at least the following effects: The above-described solution of the present invention receives a full-duplex connection request encapsulated based on a preset proxy protocol from a multi-level beacon client corresponding to at least one of multiple local area networks (LANs) and deployed hierarchically. The LAN is the LAN to which the target device belongs in a multi-level network address translation environment. The full-duplex connection request carries the device identifier of the target device. Based on the full-duplex connection request, an encrypted tunnel is established with the beacon client and registered in a dynamic routing table. The solution also receives an access request from a data acquisition client corresponding to the target device in the target LAN. The access request carries the account information of the target beacon client, the beacon level, and the device identifier of the target device. Based on the account information and beacon level of the target beacon client, the address of the target encrypted tunnel is determined in the dynamic routing table. The access request is pushed to the target beacon client corresponding to the target LAN through the target encrypted tunnel corresponding to the address. Finally, the solution receives the target device's service data sent by the target beacon client through the target encrypted tunnel and sends the service data to the data acquisition client. By using multi-level beacon clients and dynamic routing tables with hierarchical deployment, precise addressing based on account information and beacon level can be achieved. This enables real-time secure access to any LAN resource in a multi-level NAT environment without relying on fixed port mapping, significantly reducing operation and maintenance costs and improving the flexibility and reliability of cross-network communication. Attached Figure Description

[0019] Figure 1 This is a flowchart of a data transmission method for multiple local area networks based on dynamic addressing, provided in an embodiment of the present invention. Figure 2 This is a schematic diagram of an example structure of a data transmission method for multiple local area networks based on dynamic addressing provided in an embodiment of the present invention; Figure 3 This is a structural diagram of a data transmission device for multiple local area networks based on dynamic addressing provided in an embodiment of the present invention; Figure 4 This is a schematic diagram of the structure of the computing device provided in an embodiment of the present invention. Detailed Implementation

[0020] Exemplary embodiments of the invention will now be described in more detail with reference to the accompanying drawings. While exemplary embodiments of the invention are shown in the drawings, it should be understood that the invention may be implemented in various forms and should not be limited to the embodiments set forth herein. Rather, these embodiments are provided to enable a more thorough understanding of the invention and to fully convey the scope of the invention to those skilled in the art.

[0021] like Figure 1As shown, an embodiment of the present invention proposes a data transmission method for multiple local area networks based on dynamic addressing, applied to a server in a public network, comprising: Step 11: Receive a full-duplex connection request encapsulated based on a preset proxy protocol from a multi-level beacon client corresponding to at least one of multiple local area networks (LANs) and deployed hierarchically. The LAN is the LAN to which the target device belongs in a multi-level network address translation environment. The full-duplex connection request carries the device identifier of the target device. Hierarchical deployment refers to the beacon client being set up in multiple levels according to the network structure of the LAN, forming a cascading proxy architecture, with each level corresponding to different subnets or different levels of device access points. By hierarchically deploying multi-level beacon clients, it is possible to adapt to complex multi-level LAN environments, thereby ensuring stable access for subsequent requests in cross-NAT environments.

[0022] Step 12: Based on the full-duplex connection request, establish an encrypted tunnel with the beacon client and register it to the dynamic routing table. Establishing an encrypted tunnel enables secure communication between the public network server and multi-level LAN beacon clients, ensuring the confidentiality and integrity of data transmission and preventing attacks and data eavesdropping. Registration allows for the management of the communication link. After registration in the dynamic routing table, account information, beacon level, and device identifier are also synchronized with the data acquisition client.

[0023] Step 13: Receive an access request from the data acquisition client corresponding to the target device in the target local area network. The access request carries: the account information and beacon level of the target beacon client, and the device identifier of the target device. The data acquisition client initiates the access request, carrying the account information and beacon level of the target beacon client to be accessed. This achieves accurate positioning of specific devices in a multi-level network, avoids address confusion, and improves the accuracy and security of access.

[0024] Step 14: Based on the account information and beacon level of the target beacon client, determine the address of the target encrypted tunnel in the dynamic routing table; use the account information and beacon level as a combined index for querying, thereby quickly and accurately locating the encrypted tunnel, significantly improving dynamic addressing efficiency, reducing operation and maintenance costs, and thus supporting real-time routing decisions in large-scale and multi-level network environments.

[0025] Step 15: Through the target encrypted tunnel corresponding to the address, the access request is pushed to the target beacon client corresponding to the target local area network; by forwarding the request using the encrypted tunnel, there is no need to open the inbound port of the local area network, which fundamentally solves the problem of multi-layer NAT being unable to penetrate, reduces deployment costs and improves access immediacy.

[0026] Step 16: Receive the service data of the target device sent by the target beacon client through the target encrypted tunnel, and send the service data to the data acquisition client. By multiplexing the reception of service data through the tunnel, data acquisition from the public network to LAN devices in a multi-level NAT environment is achieved. This ensures data security while reducing overall communication latency and improving the stability and real-time performance of cross-network data transmission.

[0027] The solution described in this embodiment achieves dynamic addressing based on account information and beacon levels by deploying multi-level beacon clients and dynamic routing tables in a multi-LAN environment. This saves the process of pre-configuring port mapping and significantly reduces operation and maintenance costs. At the same time, by using an encrypted tunnel reverse push mechanism, it enables data acquisition clients in a multi-level NAT environment to access resources in any LAN (each LAN) instantly, greatly improving the flexibility and security of cross-network communication.

[0028] In an optional embodiment of the present invention, in step 11, the duplex connection request is obtained by encapsulating the device identifiers of multiple target devices in the local area network corresponding to the beacon client according to a preset proxy protocol.

[0029] In this embodiment, in step 111, the full-duplex connection request is a connection request initiated by the beacon client to the public network server and supports bidirectional communication. It is typically implemented based on the Transmission Control Protocol (TCP) and can be encrypted using security protocols. Specifically, it includes: the client resolving the server's domain name using DNS to obtain the public IP address; the client initiating a TCP connection through the NAT exit, then performing a TCP three-way handshake to establish reliable transmission, followed by a TLS handshake to establish an encrypted channel, application layer negotiation (such as proxy authentication, heartbeat protocol), and entering the TLS long connection maintenance phase; the target device can be a data-generating device such as a surveillance camera, and the device identifier is used to identify the target device, which can be the device's Media Access Control (MAC) address, hostname, disk serial number, or other unique encoded hash. This step, by obtaining the device identifier in advance and encapsulating it using a unified proxy protocol, provides data for subsequent establishment of an encrypted tunnel, completion of authentication, and dynamic route registration, thereby improving the security of the connection.

[0030] In an optional embodiment of the present invention, step 12, establishing an encrypted tunnel with the beacon client according to the full-duplex connection request and registering it to the dynamic routing table, may include: Step 121: Based on the full-duplex connection request, establish a control encryption tunnel and a data encryption tunnel with the beacon client; Step 122: Through the control encryption tunnel, allocate temporary account information to the beacon client and send the temporary account information to the beacon client; Step 123: Receive a registration request sent by the beacon client through the control encryption tunnel. The registration request includes a temporary identity and a beacon level. The temporary identity is generated by the beacon client based on the temporary account information, timestamp, and device identifier. Step 124: Verify the temporary identity identifier in the registration request; Step 125: After successful verification, update the temporary account information corresponding to the beacon client to the account information, and bind the account information with the corresponding encrypted tunnel and beacon level to generate a mapping relationship and register it to the dynamic routing table; The information in the dynamic routing table includes account information, control encryption tunnel identifier, data encryption tunnel identifier, and beacon level.

[0031] In this embodiment, in step 121, the control encryption tunnel is used to transmit control information such as signaling and authentication, while the data encryption tunnel is used to transmit service data. Through the dual-tunnel separation design, physical isolation of control signaling and service data transmission is achieved, thereby improving the system's security, stability, and concurrent processing capabilities. Establishing a control encryption tunnel with the beacon client based on the full-duplex connection request may include: The beacon client sends the first handshake information, including: TLS version (TLS 1.2 / 1.3), supported cipher suites, random number client_random, extensions: ALPN (http / 1.1, ws, h2), SNI (multi-domain); The server responds with the second handshake information, including: selecting the TLS version, selecting the cipher suite, a random number server_random, and selecting the ALPN protocol; The server sends certificates, including: the server sends an SSL certificate chain; Client-side certificate verification: validity period, domain name matching, root certificate trust, and signature validity; Key negotiation (generating session keys), including: RSA method (TLS 1.2): The client encrypts the pre-master key PMS with the server's public key → the server decrypts it; Ultimately, both parties use client_random + server_random + pre-master key to calculate the session master key MasterSecret, and then derive the client encryption key, server encryption key, and MAC / verification key. The encrypted handshake is complete, including: both parties sending a Finished message (encrypted) and verifying that the handshake process has not been tampered with; at this point, the control encryption tunnel for the TLS connection is established.

[0032] After the TLS connection's control encryption tunnel is established, it uses the application layer proxy protocol SOCKS5. Specifically, this includes: the client sending authentication information (token / device-id), the server verifying it and returning a success response; agreeing on a heartbeat (e.g., a heartbeat every 30 seconds); and entering the proxy data forwarding state.

[0033] Establishing a data encryption tunnel with the beacon client based on the duplex connection request includes: Based on the control encryption tunnel of the TLS connection, N data encryption tunnels are established with the beacon client, where N is the number of target devices in the local area network to which the beacon client belongs. That is, a data encryption tunnel is established for each target device to transmit the service data of that target device.

[0034] The process of establishing a data encryption tunnel is as follows: Based on the beacon client encryption key, server encryption key, and MAC / verification key determined when the encrypted tunnel is established, a data encryption tunnel for the TLS connection is established using the handshake information between the beacon client and the server.

[0035] In step 122, temporary account information is allocated to the beacon client through the control encryption tunnel. This means that identity credentials are issued within a secure channel, avoiding the security risks associated with plaintext transmission. The temporary account information has a short lifespan and is used for subsequent authentication, preventing replay attacks. However, it cannot transmit regular business data, thus protecting business data and preventing data leakage.

[0036] In step 123, the temporary identity is generated by the beacon client based on the temporary account information, timestamp, and device identifier to ensure that the identity information is unique and cannot be forged. The lifespan of the temporary identity is 5 minutes by default (which can be set as needed), represented as: Token=HMAC SHA256(SecretKey, username|password|timestamp|flag); where Token represents a temporary identity identifier; HMAC SHA256 represents the encryption algorithm; SecretKey represents the symmetric key agreed upon by the server and the beacon client; username and password represent temporary account information (username and password in the code); timestamp represents the timestamp; and flag represents the device identifier. The beacon level is used to locate the network layer where the target device resides, facilitating subsequent addressing of the target device by the target beacon client.

[0037] In step 124, the obtained temporary identity is verified. The verification process includes: the server calculates multiple reference hash values ​​corresponding to multiple sliding time windows based on the stored temporary account information, device identifier and multiple timestamps in the lifespan of the temporary identity (e.g., 5 minutes by default). If any reference hash value matches the temporary identity, the temporary identity is deemed to have been verified, thereby ensuring the unforgeability of the beacon client's identity and the timeliness of the request.

[0038] The specific verification process includes: the server pre-stores the temporary account information (username / password) and target device identifier (flag) corresponding to the beacon client, and presets the lifespan T of the temporary identity (this lifespan is consistent with the lifespan bound when the beacon client generates the temporary identity, for example, T=5 minutes by default); the sliding time window is the server's verification mechanism, and its division rule is: from the current moment when the server receives the registration request, trace back one lifespan T as the total time range, and then divide the total time range into N consecutive and non-overlapping fixed time periods, setting the step size of the sliding time window. (For example =10 seconds), the number of sliding windows N is determined based on the survival period and step size, and the calculation formula is: (with T=5 minutes) For example, if the time is 10 seconds, then N = 30 sliding time windows.

[0039] Within a sliding time window, the server uses the same encryption algorithm as the beacon client to generate the temporary identity, with a pre-agreed symmetric key, SecretKey, as the encryption key. The server uses the temporary account information, device identifier, and the timestamp corresponding to each sliding time window as the plaintext to be encrypted. It then calculates the reference hash value for each moment within each sliding time window using the formula: Token_p_q = HMAC. SHA256(SecretKey,username|password|timestamp_p_q|flag), where timestamp_p_q is the q-th timestamp corresponding to the p-th sliding time window (accurate to the second, covering all time nodes within the sliding time window).

[0040] Calculated within a sliding time window Each reference hash value (Token_p_1, Token_p_2, ..., Token_p_q) is matched one by one with the temporary identity token sent by the beacon client. If any reference hash value completely matches the temporary identity token, the temporary identity token is considered verified. The verification process continues from the sliding time window closest to the current time until verification is successful, or until no matching data is found in the furthest sliding time window. If no match is found, the verification is considered failed, and the beacon client's registration request is rejected.

[0041] In this verification process, the lifespan is the valid duration of the temporary identity assigned by the beacon client, and the sliding window is a server-specific verification mechanism. By tracing back one lifespan from the moment the request is received to divide the window, and combining it with an encryption algorithm, the base timestamp of each window is used in the calculation. This ensures that the temporary identity is unforgeable (only the server and the beacon client know the SecretKey, and it cannot be forged by a third party), and also accurately covers the valid range of the token through the time window, ensuring the timeliness of the request and effectively resisting replay attacks. At the same time, the sliding window setting takes into account both verification flexibility and security, and avoids misjudgment of legitimate tokens due to network latency.

[0042] In step 125, successful verification indicates compliance with security standards. At this point, official account information is sent to the beacon client. The beacon client stores this account information to verify the identity of the server sending the message and registers it, along with the control encryption tunnel identifier, data encryption tunnel identifier, and the beacon client's hierarchy, in the dynamic routing table. The specific process includes: The server extracts the tunnel address information (including the tunnel source address and tunnel destination address, where the source address is the server-side tunnel interface address and the destination address is the beacon client tunnel interface address, both of which are logically addressable within the local area network) corresponding to the currently established target control encrypted tunnel and target data encrypted tunnel. It then combines the account information, control encrypted tunnel identifier (bound to the tunnel address to uniquely identify the control tunnel), data encrypted tunnel identifier (bound to the corresponding tunnel address to uniquely identify the data tunnel), beacon level, and the network segment address of the local area network to which the beacon client belongs, to construct a complete routing entry. Specifically, the server creates a control tunnel interface (Tunnel0 / 1), binds an IPsec encryption policy, and uses it as the "tunnel carrier" for the routing table. This allows the control tunnel to map to N cameras of a single beacon client, creating independent routing tables (Table 100 = Beacon Client A, Table 200 = Beacon Client B). This enables client-level mapping and configuration of policy routing, directing traffic from different cameras to their corresponding routing tables and tunnels. The data encryption tunnel mapping uses OSPF to publish camera network segment routes to the corresponding tunnels, automatically generating dynamic routing tables, which may include: Step 1: Create and enable the control encryption tunnel Create tunnel interfaces Tunnel0 (for client A) and Tunnel1 (for client B); Tunnel0 is bound to the network segment 172.16.0.0 / 24; Tunnel1 is bound to the network segment 172.17.0.0 / 24; Tunnel0 is associated with routing table 100, and Tunnel1 is associated with routing table 200; First, an encrypted control tunnel is built, which only transmits heartbeats, registration, commands, and routing information, and does not transmit video streams; then, through tunnel and routing table binding, network isolation at the client level is achieved to avoid traffic confusion between different clients.

[0043] Step 2: Enable the OSPF protocol and advertise routes through the controlled encrypted tunnel. Client OSPF configuration data: Client A: ospf 100 vpn-instance CAM_GROUP_A area 0, declaring network segments: 10.0.0.00.0.0.255 (camera), 172.16.0.0 0.0.0.255 (control tunnel) Client B: ospf 200 vpn-instance CAM_GROUP_B area 0, declaring network segments: 10.0.1.00.0.0.255 (camera), 172.17.0.0 0.0.0.255 (control tunnel) Server-side reverse OSPF configuration data: Server-side (connecting to Tunnel0): ospf 100 area 0, declared network segments: 172.16.0.0 0.0.0.255 (tunnel), 192.168.0.0 0.0.0.255 (server network segment) In other words, the OSPF protocol relies on the control encrypted tunnel to achieve automatic synchronization of routing information between the two ends; the server obtains the routes of the camera network segment and the tunnel network segment through OSPF and automatically generates a dynamic routing table.

[0044] Step 3: Create a data encryption tunnel Configuration data: A one-to-one encrypted data tunnel is established based on the unique IP address of each camera (e.g., 10.0.0.2 corresponds to Data-Tunnel-A1, 10.0.0.3 corresponds to Data-Tunnel-A2, and so on). The data tunnel is bound to the corresponding client routing table (100 / 200). This involves establishing a dedicated business transmission channel to handle high volumes of data, such as real-time video, recordings, and audio from cameras; each camera corresponds to a single data tunnel, achieving traffic isolation and preventing interference between multiple camera streams.

[0045] Step 4: Configure policy routing for precise traffic redirection Configuration data: Policy matching based on camera source IP: Traffic from the 10.0.0.0 / 24 network segment → redirected to the data tunnel corresponding to route table 100+; Traffic from the 10.0.1.0 / 24 network segment → redirected to the data tunnel corresponding to route table 200+. Server-side reverse traffic: Traffic accessing the camera → OSPF routing → corresponding data tunnel → target camera This involves combining dynamic routes generated by OSPF with policy-based routing to achieve precise mapping of "camera IP → routing table → data tunnel"; the control tunnel is only responsible for finding the corresponding camera, while the data tunnel is only responsible for data transmission, with clear division of labor and end-to-end encryption.

[0046] Step 5: Two-way Interoperability Verification Data verification: The server can ping a single camera IP (10.0.0.2 / 10.0.1.3), the OSPF neighbor status is Full, and the routing table contains both the camera network segment and the tunnel network segment. Specifically, the control tunnel ensures stable signaling and routing, while the data tunnel ensures encrypted transmission of video streams; OSPF guides traffic, and independent routing tables achieve isolation, ultimately enabling secure two-way communication between the server and each camera.

[0047] Register the route entry to the dynamic routing table and establish an association mapping of "account + tunnel address + tunnel identifier + beacon level + LAN segment" to ensure the core address association attributes of the routing table.

[0048] The control encryption tunnel is responsible for transmitting camera IP address information, OSPF is responsible for generating location and navigation routes, policy routing is responsible for sorting traffic by IP, and the data encryption tunnel is responsible for dedicated data transmission. These four components work together to enable the server to accurately locate the data from each camera throughout the entire process, thus achieving precise mapping between the camera and the server. This step completes the formal registration of the beacon client, establishing a persistent association between the client's identity and the dual tunnels, and providing a clear address addressing basis for the dynamic routing table. This provides a dynamic routing basis for on-demand access by data acquisition clients, thereby improving routing efficiency and access security.

[0049] In an optional embodiment of the present invention, step 13, receiving an access request for the target device in the target local area network sent by the data acquisition client corresponding to the target device, may include: Step 131: Receive an access request sent by the data acquisition client corresponding to the target device, targeting the target device within the local area network under a multi-level NAT environment; Step 132: Parse the access request to obtain the target beacon client's account information, the beacon level to which the target device belongs, and the device identifier.

[0050] In this embodiment, in step 131, the data acquisition client is an application that needs to access local area network (LAN) resources. It can be video viewing software or data capture services from a monitoring center. It initiates an access request to the server by configuring a SOCKS 5 proxy, requesting to obtain business data from a specific device within the specified LAN. This step enables unified management of external applications' access points to LAN resources in a multi-level NAT environment. It eliminates the need to open public ports separately for each LAN service, reducing the possibility of network exposure and improving system security.

[0051] In step 132, the account information received by the server is used to uniquely identify the beacon client corresponding to the target local area network. For example, the account information is encoded into the hostname prefix of the field and transmitted through domain name hijacking using the SOCKS5 protocol. The received beacon level is used to locate the network level (specific location) of the target device in a multi-level network, such as a first-level client or a second-level client. By parsing multi-dimensional access identifiers, the server can accurately locate the network level of the target device and the corresponding beacon client, providing accurate input information for subsequent dynamic routing and addressing, thus improving the accuracy and efficiency of access.

[0052] In an optional embodiment of the present invention, step 14, determining the target encrypted tunnel in the dynamic routing table based on the account information and beacon level of the access request, may include: Step 141: Based on the account information and beacon level, query the mapping relationship in the dynamic routing table to determine the address of the target encrypted tunnel; the target encrypted tunnel includes the target control encrypted tunnel and the target data encrypted tunnel.

[0053] In this embodiment, in step 141, the account information and beacon level are used as the joint query key to retrieve the corresponding matching mapping entry in the dynamic routing table. This allows for the rapid location of the control encryption tunnel and data encryption tunnel corresponding to the target beacon client. This step implements dynamic addressing based on identity and level, ensuring unique and accurate addressing. It eliminates the need for pre-configured fixed routing rules, enabling precise finding of the communication path to the target device in a multi-level NAT environment. This significantly reduces operational complexity and improves the immediacy and efficiency of routing decisions.

[0054] The specific process of tunnel query includes: The server first parses the camera access request parameters, extracts the account permission information and the beacon client level to which the target camera belongs, and combines the two as a joint query key to ensure the uniqueness of the query and avoid camera addressing errors caused by matching a single field.

[0055] The dynamic routing table retrieval mechanism is activated (the routing table is dynamically generated by the server based on the beacon client registration information, carrying navigation information such as beacon client affiliation, tunnel binding, and camera IP mapping relationship with the tunnel). Using the account information in the joint query key as the first-level retrieval condition, all route entries matching the account permissions are first filtered in the dynamic routing table to lock the routing range of the corresponding beacon client.

[0056] Then, using the beacon client level as a secondary verification condition, a second precise match is performed on the selected candidate route entries to confirm that the beacon level bound to the entry is completely consistent with the level extracted from the access request. This completes the double verification, ensuring that the retrieved route entries accurately correspond to the target beacon client and preventing cross-client route confusion.

[0057] After retrieving a matching route entry, the server extracts the bound tunnel address information from that entry in situ: on one hand, it extracts the control encrypted tunnel identifier, the server-side tunnel source address, and the beacon client tunnel interface destination address. The control tunnel is specifically used for transmitting signaling, authentication, route synchronization, and camera addressing commands. On the other hand, it extracts the data encrypted tunnel identifier, the server-side tunnel source address, and the beacon client data interface destination address. The data tunnel is forwarded by the beacon client to the target camera on the internal network and is specifically used to carry service traffic such as camera video streams. Both types of tunnels use the same internal network addressable logical address range, but the tunnel identifier and interface are independent of each other, both being logical addresses addressable within the local area network.

[0058] The server will associate and bind the control encryption tunnel and the data encryption tunnel separately, clarify the tunnel type corresponding to the address, and combine the policy routing rules to sort traffic according to the source IP of the camera, so as to achieve accurate addressing and dedicated transmission of the target camera.

[0059] In an optional embodiment of the present invention, step 15, pushing the access request to the target beacon client corresponding to the target local area network through the target encrypted tunnel, may include: Step 151: Send an addressing command to the target beacon client through the target control encrypted tunnel; the addressing command carries the device identifier and is used to instruct the target beacon client to find the corresponding target device within the local area network; Step 152: Through the target data encryption tunnel, the access request is pushed to the target beacon client so that the target beacon client can obtain business data based on the found target device.

[0060] In this embodiment, in step 151, the encrypted tunnel is controlled as a signaling channel specifically for transmitting control commands, ensuring that addressing commands can be delivered to the target beacon client quickly and accurately. After receiving the addressing command, the client obtains the device's specific address within the local area network based on the device identifier. For example, it queries the IP address corresponding to the MAC address using the Address Resolution Protocol (ARP) or finds the device's communication endpoint through the device registry. This step enables precise control of the local area network client by the public network server, delegating the device search task to the beacon client closest to the target device. This fully utilizes the beacon client's awareness of the local network, improving the efficiency and accuracy of device search.

[0061] In step 152, the data encryption tunnel serves as a service transmission channel, specifically designed to carry the actual service data stream. After the beacon client completes device lookup, it accesses and retrieves the target device's service data based on the received complete access request, and then returns it to the server along the same path. By separating the control tunnel and data tunnel, signaling interaction and data transmission are decoupled, avoiding mutual interference, improving the system's concurrent processing capabilities and overall data transmission and acquisition efficiency, while simultaneously ensuring the real-time nature of control commands and the security of service data.

[0062] In an optional embodiment of the present invention, step 16, receiving service data of the target device sent by the target beacon client through the target encrypted tunnel, and sending the service data to the data acquisition client, may include: Step 161: Receive service data sent by the target beacon client through the target data encryption tunnel; Step 162: Send the business data to the data acquisition client.

[0063] In this embodiment, in step 161, the business data (such as monitoring video streams, sensor data, etc.) generated by the target device is transmitted from the client to the server through the target data encryption tunnel. The established encryption channel is used to ensure the integrity and security of the received business data during the data transmission process, and to prevent the data from being eavesdropped or tampered with.

[0064] In step 162, after receiving the business data, the server determines the data acquisition client that initiated the access request based on the previously recorded corresponding received data, and forwards the business data to that client through the established communication connection. This ensures that the data acquisition client can securely and in real-time obtain the required business data without directly connecting to LAN devices. The entire process is transparent to the data acquisition end, achieving efficient and secure access to LAN resources in a multi-level NAT environment, and improving the immediacy and reliability of cross-network data acquisition.

[0065] In an optional embodiment of the present invention, step 17 further includes: Step 171: Monitor the validity of the encrypted tunnel and the account information in real time to obtain the monitoring status; Step 172: When the monitoring status is disconnected or information is invalid, the corresponding mapping relationship in the dynamic routing table is automatically cleared.

[0066] In this embodiment, in step 171, the server continuously tracks the connection status of the control encryption tunnel and data encryption tunnel of each beacon client through heartbeat mechanisms and timeout detection, while verifying whether the account information is still valid or has not been cancelled. For example, the server can periodically send heartbeat packets to the beacon client; if no response is received multiple times consecutively, the connection is determined to be broken. For account information, an expiration period can be set; if the expiration period is exceeded, the account is deemed invalid. This step ensures that the server always has a grasp of the real-time status of each beacon client and its tunnel, providing a basis for the accurate maintenance of the dynamic routing table.

[0067] In step 172, once a beacon client's encrypted tunnel is detected to be disconnected or its account information to be invalid, the mapping entry related to that beacon client is immediately deleted from the dynamic routing table. This includes account information, control encrypted tunnel identifier, data encrypted tunnel identifier, and beacon level. This dynamic maintenance mechanism prevents invalid entries from interfering with subsequent routing decisions, avoids incorrectly pushing access requests to unreachable clients, and frees up system resources. This allows the system to adaptively respond to network fluctuations and device status changes, ensuring service continuity and reliability.

[0068] A specific embodiment of the data transmission method for multiple local area networks based on dynamic addressing provided in this invention is as follows: like Figure 2 As shown, this case is a typical application of video surveillance from multiple construction sites converging to the group company: based on the SOCKS5 standard, it natively supports TCP, User Datagram Protocol (UDP) and Domain Name System (DNS) resolution, and can carry any application layer protocol such as Hypertext Transfer Protocol (HTTP), Remote Desktop Protocol (RDP), Secure Shell Protocol (SSH), video stream, and Modbus.

[0069] This case study uses video streaming as an example. The monitoring client and the monitoring cameras are not on the same local area network. To ensure the security objective of preventing the leakage of monitored content, a server registration port is opened on the group company's public IP address. This port allows SOCKS5 proxy clients (beacon clients) to register their own information with the SOCKS5 server and supports long-term encrypted connection maintenance. When the client supports the SOCKS5 protocol, opening the proxy service port on the group's internal network allows SOCKS5 clients to directly configure the SOCKS5 server's IP address, port number, and corresponding username and password. This enables the monitoring client within the group company to collect video data from all cameras at construction site A (proxy client group 1).

[0070] In this case, this method can effectively achieve secure transmission of video streams across networks. Its core lies in ensuring the privacy and integrity of monitoring data in environments that are not on the same local area network by using encrypted tunnels.

[0071] In this case, the SOCKS5 server was deployed on a public IP address server of the group company, with an open registration port to receive connection requests from the camera group (agent client group 1) at construction site A. The cameras, as the lower-level devices of the SOCKS5 clients, actively registered with the server and established a long-connection encrypted channel, thereby penetrating local network restrictions. The monitoring clients then accessed the SOCKS5 service in the group company's internal network and obtained video stream data through the established channel, avoiding the risk of directly exposing the cameras to the public network.

[0072] The main advantage of this method is: (1) Can easily penetrate NAT / firewalls Cameras are typically located on a local area network (such as a home or business LAN) and do not have a public IP address or can not be directly port-mapped.

[0073] The SOCKS5 client actively connects to the SOCKS5 server on the external network (establishing a long connection through a secret channel), forming an encrypted tunnel.

[0074] The monitoring software only needs to connect to a SOCKS5 server on the public network to access the LAN cameras through this tunnel, without needing to open any inbound ports on the firewall, which greatly simplifies network configuration.

[0075] (2) Protocol independence, adaptable to multiple protocols SOCKS5 operates at the session layer and is not concerned with the upper-layer application protocols.

[0076] Cameras may use web-based management or even proprietary protocols, but SOCKS5 can transparently forward TCP / UDP packets without requiring the development of separate penetration modules for each protocol.

[0077] It especially supports UDP (a significant improvement of SOCKS5 over SOCKS4), which is crucial for real-time video streaming that relies on UDP.

[0078] (3) Built-in authentication and access control SOCKS5 supports username / password authentication, which can authenticate monitoring software on the server side to prevent unauthorized access.

[0079] The encrypted channel is encrypted, so even if SOCKS5 itself is not encrypted, the combination can ensure the confidentiality and integrity of data transmitted over the public network, preventing eavesdropping or tampering.

[0080] (4) Unified entry point, simplified management All cameras (distributed across multiple local area networks) can access the same SOCKS5 server through their respective SOCKS5 clients.

[0081] The monitoring software only needs to be configured with a SOCKS5 proxy address (server public IP + port) and can access the corresponding camera through different user authentications.

[0082] This centralized entry point makes it very convenient for future expansion and policy adjustments (adding a new LAN camera only requires deploying the client in the new LAN).

[0083] (5) Hide the local area network topology to enhance security The monitoring software can only see the SOCKS5 server and cannot directly access the local area network where the camera is located.

[0084] The camera's actual IP address and network structure are not visible to the outside world, reducing the risk of direct attacks.

[0085] Even if the secret channel is intercepted, attackers cannot obtain more network details because SOCKS5 itself does not expose local area network information.

[0086] (6) Lightweight and efficient with low resource consumption The SOCKS protocol is very simple, only responsible for establishing connections and forwarding data, without parsing application layer content, so it consumes very little CPU and memory.

[0087] Secret channels can be designed on demand, and compared to the global virtual network card solution of Virtual Private Network (VPN), they only forward camera-related traffic, making them more flexible and lightweight.

[0088] (7) Supports remote DNS resolution SOCKS5 allows clients to delegate domain name resolution tasks to either the server or the client. It can be configured to allow SOCKS5 clients to resolve camera domain names on the local area network, avoiding the problems of monitoring software being polluted by public DNS or unable to resolve private domain names, and can also further protect the local area network topology.

[0089] The data transmission method for multiple local area networks based on dynamic addressing proposed in this invention, through hierarchical deployment of beacon clients, establishment of double-encrypted tunnels, and combined account information with beacon-level joint addressing and dynamic routing table management, can reduce operation and maintenance costs without the need for preset port mapping and virtual IP allocation. It can prevent the risks of identity forgery and data tampering, realize secure, efficient and real-time data collection of devices in multi-level NAT environments, and improve the stability and flexibility of cross-network data transmission.

[0090] like Figure 3 As shown, this embodiment of the invention also provides a data transmission device 30 for multiple local area networks based on dynamic addressing, comprising: The acquisition module 31 is used to receive a full-duplex connection request based on a preset proxy protocol sent by a multi-level beacon client corresponding to at least one of the multiple local area networks and deployed hierarchically; the local area network is the local area network to which the target device belongs in the multi-level network address translation environment, and the full-duplex connection request carries: the device identifier of the target device; Processing module 32 is configured to: establish an encrypted tunnel with the beacon client according to the full-duplex connection request and register it in the dynamic routing table; receive an access request for a target device in the target local area network sent by the data acquisition client corresponding to the target device; the access request carries: the account information of the target beacon client, the beacon level, and the device identifier of the target device; determine the address of the target encrypted tunnel in the dynamic routing table according to the account information and beacon level of the target beacon client; push the access request to the target beacon client corresponding to the target local area network through the target encrypted tunnel corresponding to the address; receive the service data of the target device sent by the target beacon client through the target encrypted tunnel, and send the service data to the data acquisition client.

[0091] Optionally, module 31 is specifically used for: The system receives a full-duplex connection request from a multi-level beacon client, which is deployed hierarchically and corresponds to at least one of multiple local area networks (LANs), and encapsulates the device identifier of the target device based on a preset proxy protocol.

[0092] Optionally, processing module 32 is specifically used for: Based on the full-duplex connection request, an encrypted tunnel is established with the beacon client; the encrypted tunnel includes a control encrypted tunnel and a data encrypted tunnel. Temporary account information is allocated to the beacon client through the control encryption tunnel, and the temporary account information is sent to the beacon client. The registration request sent by the beacon client is received through the control encryption tunnel. The registration request includes a temporary identity and a beacon level. The temporary identity is generated by the beacon client based on the temporary account information, timestamp, and device identifier. Verify the temporary identity identifier in the registration request; After successful verification, the temporary account information corresponding to the beacon client is updated to the account information, and the account information is bound to the corresponding encrypted tunnel and beacon level to generate a mapping relationship and register it to the dynamic routing table; The information in the dynamic routing table includes account information, control encryption tunnel identifier, data encryption tunnel identifier, and beacon level.

[0093] Optionally, the temporary identity in the registration request is verified, including: Based on the temporary account information, device identifier, and multiple timestamps within the sliding time window in the registration request, multiple reference hash values ​​are obtained respectively; If any of the reference hash values ​​matches the temporary identity identifier in the registration request, the temporary identity identifier is deemed to have been verified.

[0094] Optionally, processing module 32 is specifically used for: Based on the account information and beacon level, the mapping relationship in the dynamic routing table is queried to determine the target encrypted tunnel; the target encrypted tunnel includes the target control encrypted tunnel and the target data encrypted tunnel.

[0095] Optionally, processing module 32 is specifically used for: The target beacon client is sent an addressing command through the target control encrypted tunnel; the addressing command carries the device identifier and is used to instruct the target beacon client to find the corresponding target device within the local area network; The access request is pushed to the target beacon client through the target data encryption tunnel, so that the target beacon client can obtain business data based on the target device found.

[0096] Optionally, the processing module 32 is also specifically used for: The validity of the encrypted tunnel and the account information is monitored in real time to obtain the monitoring status; When the monitoring status is disconnected or the information is invalid, the corresponding mapping relationship in the dynamic routing table is automatically cleared.

[0097] It should be noted that this device is a device corresponding to the above method. All implementation methods in the above method embodiments are applicable to this embodiment and can achieve the same technical effect.

[0098] like Figure 4 As shown, this embodiment of the invention also provides a computing device 40, including a processor 41, a memory 42, and a program or instructions stored in the memory 42 and executable on the processor 41. When executed by the processor 41, the program or instructions implement the various processes of the above-described embodiments of the data transmission method for multiple local area networks based on dynamic addressing, and achieve the same technical effects. To avoid repetition, further details are omitted here. It should be noted that the computing device in this embodiment includes the aforementioned mobile electronic devices and non-mobile electronic devices.

[0099] Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementations should not be considered beyond the scope of this invention.

[0100] Those skilled in the art will understand that, for the sake of convenience and brevity, the specific working processes of the systems, devices, and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here.

[0101] In the embodiments provided by this invention, it should be understood that the disclosed apparatus and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between apparatuses or units may be electrical, mechanical, or other forms.

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

[0103] In addition, the functional units in the various embodiments of the present invention can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.

[0104] If the aforementioned functions are implemented as software functional units and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this invention, or the part that contributes to the prior art, or a portion of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods of the various embodiments of this invention. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, ROM, RAM, magnetic disks, or optical disks.

[0105] Furthermore, it should be noted that in the apparatus and method of the present invention, it is obvious that the components or steps can be decomposed and / or recombined. These decompositions and / or recombinations should be considered equivalent solutions of the present invention. Moreover, the steps performing the above series of processes can naturally be executed in the order described, but are not necessarily required to be executed in chronological order; some steps can be executed in parallel or independently of each other. Those skilled in the art will understand that all or any step or component of the method and apparatus of the present invention can be implemented in any computing device (including processors, storage media, etc.) or network of computing devices, in hardware, firmware, software, or a combination thereof. This is something that those skilled in the art can achieve by using their basic programming skills after reading the description of the present invention.

[0106] Therefore, the object of the present invention can also be achieved by running a program or a set of programs on any computing device. The computing device can be a known general-purpose device. Therefore, the object of the present invention can also be achieved simply by providing a program product containing program code for implementing the method or apparatus. That is, such a program product also constitutes the present invention, and the storage medium storing such a program product also constitutes the present invention. Obviously, the storage medium can be any known storage medium or any storage medium developed in the future. It should also be noted that in the apparatus and method of the present invention, it is obvious that the components or steps can be decomposed and / or recombined. These decompositions and / or recombinations should be considered equivalent to the present invention. Furthermore, the steps for performing the above series of processes can naturally be performed in the order described, but are not necessarily required to be performed in chronological order. Some steps can be performed in parallel or independently of each other.

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

Claims

1. A data transmission method for multiple local area networks based on dynamic addressing, characterized in that, The method, applied to servers on the public network, includes: The system receives a full-duplex connection request encapsulated based on a preset proxy protocol from a multi-level beacon client that corresponds to at least one of multiple local area networks (LANs) and is deployed hierarchically. The LAN is the LAN to which the target device belongs in a multi-level network address translation environment. The full-duplex connection request carries the device identifier of the target device. Based on the duplex connection request, an encrypted tunnel is established with the beacon client and registered to the dynamic routing table; Receive an access request for the target device in the target local area network sent by the data acquisition client corresponding to the target device; the access request carries: the account information of the target beacon client, the beacon level, and the device identifier of the target device; Based on the target beacon client's account information and beacon level, the address of the target encrypted tunnel is determined in the dynamic routing table; The access request is pushed to the target beacon client corresponding to the target local area network through the target encrypted tunnel corresponding to the address; The system receives service data from the target device sent by the target beacon client through the target encrypted tunnel, and then sends the service data to the data acquisition client.

2. The data transmission method for multiple local area networks based on dynamic addressing according to claim 1, characterized in that, Receiving a full-duplex connection request based on a preset proxy protocol from a multi-level beacon client corresponding to at least one of multiple local area networks (LANs) and deployed hierarchically, including: The system receives a full-duplex connection request from a multi-level beacon client, which is deployed hierarchically and corresponds to at least one of multiple local area networks (LANs), and encapsulates the device identifier of the target device based on a preset proxy protocol.

3. The data transmission method for multiple local area networks based on dynamic addressing according to claim 2, characterized in that, Based on the full-duplex connection request, an encrypted tunnel is established with the beacon client and registered to the dynamic routing table, including: Based on the full-duplex connection request, an encrypted tunnel is established with the beacon client; the encrypted tunnel includes a control encrypted tunnel and a data encrypted tunnel. Temporary account information is allocated to the beacon client through the control encryption tunnel, and the temporary account information is sent to the beacon client. The registration request sent by the beacon client is received through the control encryption tunnel. The registration request includes a temporary identity and a beacon level. The temporary identity is generated by the beacon client based on the temporary account information, timestamp, and device identifier. Verify the temporary identity identifier in the registration request; After successful verification, the temporary account information corresponding to the beacon client is updated to the account information, and the account information is bound to the corresponding encrypted tunnel and beacon level to generate a mapping relationship and register it to the dynamic routing table; The information in the dynamic routing table includes account information, control encryption tunnel identifier, data encryption tunnel identifier, and beacon level.

4. The data transmission method for multiple local area networks based on dynamic addressing according to claim 3, characterized in that, Verification of the temporary identity in the registration request includes: Based on the temporary account information, device identifier, and multiple timestamps within the sliding time window in the registration request, multiple reference hash values ​​are obtained respectively; If any of the reference hash values ​​matches the temporary identity identifier in the registration request, the temporary identity identifier is deemed to have been verified.

5. The data transmission method for multiple local area networks based on dynamic addressing according to claim 1, characterized in that, Based on the account information and beacon level of the access request, the target encrypted tunnel is determined in the dynamic routing table, including: Based on the account information and beacon level, the mapping relationship in the dynamic routing table is queried to determine the target encrypted tunnel; the target encrypted tunnel includes the target control encrypted tunnel and the target data encrypted tunnel.

6. The data transmission method for multiple local area networks based on dynamic addressing according to claim 1, characterized in that, Through the target encrypted tunnel, the access request is pushed to the target beacon client corresponding to the target local area network, including: The target beacon client is sent an addressing command through the target control encrypted tunnel; the addressing command carries the device identifier and is used to instruct the target beacon client to find the corresponding target device within the local area network; The access request is pushed to the target beacon client through the target data encryption tunnel, so that the target beacon client can obtain business data based on the target device found.

7. The data transmission method for multiple local area networks based on dynamic addressing according to claim 1, characterized in that, Also includes: The validity of the encrypted tunnel and the account information is monitored in real time to obtain the monitoring status; When the monitoring status is disconnected or the information is invalid, the corresponding mapping relationship in the dynamic routing table is automatically cleared.

8. A data transmission device for multiple local area networks based on dynamic addressing, characterized in that, include: The acquisition module is used to receive a full-duplex connection request based on a preset proxy protocol sent by a multi-level beacon client that is deployed hierarchically and corresponds to at least one of the multiple local area networks. The local area network is the local area network to which the target device belongs in a multi-level network address translation environment, and the full-duplex connection request carries: the device identifier of the target device; The processing module is used to establish an encrypted tunnel with the beacon client based on the full-duplex connection request and register it to the dynamic routing table; Receive access requests for the target device in the target local area network sent by the data acquisition client corresponding to the target device; The access request carries: the target beacon client's account information, beacon level, and the target device's device identifier; Based on the target beacon client's account information and beacon level, the address of the target encrypted tunnel is determined in the dynamic routing table; The access request is pushed to the target beacon client corresponding to the target local area network through the target encrypted tunnel corresponding to the address; The system receives service data from the target device sent by the target beacon client through the target encrypted tunnel, and then sends the service data to the data acquisition client.

9. A computing device, characterized in that, include: A processor, a memory storing a computer program, wherein the computer program, when executed by the processor, performs the method as described in any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that, The system stores instructions that, when executed on a computer, cause the computer to perform the method as described in any one of claims 1 to 7.

Images