A data transmission method, device, apparatus and readable storage medium

Abstract

This application discloses a data transmission method, apparatus, device, and readable storage medium in the field of computer technology. This application utilizes data transmission rules negotiated between a first forwarding end and a second forwarding end to encapsulate a second message. These data transmission rules include session mapping relationships. When applied to VPN access scenarios, multiple sessions within the tunnel do not need to transmit to the external network through the same public network session, thus solving the traffic blocking problem during remote access. Simultaneously, the transmission protocol and data processing requirements in the data transmission rules enable the second forwarding end and the first forwarding end to process the data transmitted between them according to the agreed-upon requirements, facilitating the expansion of data transmission between the second and first forwarding ends and improving data transmission efficiency.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to a data transmission method, apparatus, device, and readable storage medium. Background Technology

[0002] Currently, network congestion is prone to occur during VPN remote access. For example, there are many UDP sessions within the tunnel, and these UDP sessions need to be transmitted to the external network through the same public network session, resulting in traffic blocking. Similarly, TCP (Transmission Control Protocol) long connections are also prone to traffic blocking.

[0003] Therefore, how to solve the problem of traffic blocking during remote access is a problem that needs to be solved by those skilled in the art. Summary of the Invention

[0004] In view of this, the purpose of this application is to provide a data transmission method, apparatus, device, and readable storage medium to enable a one-to-one connection between one session and another, thereby resolving traffic blocking during remote access. The specific solution is as follows:

[0005] In a first aspect, this application provides a data transmission method applied at a first forwarding end, comprising:

[0006] Obtain the first message; the destination of the first message is the second forwarding end;

[0007] Determine the data transmission rules negotiated with the second forwarding end; the data transmission rules include: the session formed between the first forwarding end and the sender of the first message, and the mapping relationship between the session formed between the first forwarding end and the second forwarding end;

[0008] The first message is encapsulated according to the data transmission rules to obtain the second message;

[0009] Send the second message to the second forwarding end.

[0010] Optionally, determining the data transmission rules negotiated with the second forwarding end includes:

[0011] Using the identification information of the second forwarding end as the query keyword, the data transmission rules are queried in the preset database;

[0012] The data transmission rules corresponding to the identification information are determined as the data transmission rules negotiated between the first forwarding end and the second forwarding end.

[0013] Optionally, it also includes:

[0014] If the data transmission rule does not exist, then negotiate with the second forwarding end to determine the data transmission rule.

[0015] Optionally, negotiating and determining the data transmission rules with the second forwarding end includes:

[0016] Add the first requirement of the first forwarding end to the original communication message to obtain a new communication message; the first requirement includes: the terminal IP address and terminal port number in the local area network where the first forwarding end is located, and the internal network IP address and internal network port number of the first forwarding end;

[0017] The new communication message is sent to the second forwarding end so that the second forwarding end can parse the new communication message to obtain the first requirement. If it is confirmed that the first requirement can be met, the data transmission rule is generated and recorded based on the first requirement and the second end confirmation requirement, and the second end confirmation requirement is added to the original confirmation message to obtain a new confirmation message. The second end confirmation requirement includes: the public IP address and public port number of the second forwarding end.

[0018] Receive the new confirmation message sent by the second forwarding end, and parse the new confirmation message to obtain the confirmation request from the second end;

[0019] The data transmission rules are generated and recorded based on the first requirement and the second end confirmation requirement.

[0020] Optionally, the original communication message is a handshake message; correspondingly, adding the first requirement of the first forwarding end to the original communication message includes: adding the first requirement to the extended options and / or emergency information options of the handshake message;

[0021] The original confirmation message is the handshake confirmation message of the handshake message; correspondingly, adding the second end confirmation requirement to the original confirmation message includes: adding the second end confirmation requirement to the extended options and / or emergency information options of the handshake confirmation message.

[0022] Optionally, the original communication message is a preset information negotiation message before data transmission; correspondingly, adding the first requirement of the first forwarding end to the original communication message includes: adding the first requirement to the payload option of the information negotiation message;

[0023] The original confirmation message is the negotiation confirmation message of the information negotiation message; correspondingly, adding the second end confirmation requirement to the original confirmation message includes: adding the second end confirmation requirement to the payload option of the negotiation confirmation message.

[0024] Optionally, it also includes:

[0025] The data transmission rules also include: a transmission protocol applicable to both the second forwarding end and the first forwarding end, and data processing requirements applicable to both the second forwarding end and the first forwarding end;

[0026] Accordingly, the first requirement also includes: at least one transmission protocol applicable to the first forwarding end and at least one data processing requirement;

[0027] Accordingly, the second end confirmation requirements also include: a transmission protocol applicable to both the second forwarding end and the first forwarding end, and data processing requirements applicable to both the second forwarding end and the first forwarding end;

[0028] If an error message is received, and it is confirmed that there are other transmission protocols and other data processing requirements applicable to the first forwarding end that are not in the first requirement, then the transmission protocol and data processing requirements in the first requirement are replaced with other transmission protocols and other data processing requirements, and the first requirement of adding the first forwarding end to the original communication message and subsequent steps are executed.

[0029] If the second forwarding terminal confirms that the first requirement cannot be met, it generates the error message and sends the error message to the first forwarding terminal.

[0030] Optionally, it also includes:

[0031] If the error message is received, and it is confirmed that there are no other transmission protocols or other data processing requirements applicable to the first forwarding end that are not included in the first requirement, then an error notification message is returned to the sending end of the first message.

[0032] Optionally, the mapping relationship is a 5-tuple mapping relationship; the transmission protocols applicable to both the second forwarding end and the first forwarding end include: HTTPS, UDP, and IPSEC; the data processing requirements applicable to both the second forwarding end and the first forwarding end include: encryption requirements, data integrity detection requirements, and identity authentication requirements.

[0033] Optionally, the public network source port number of the second forwarding end and the public network destination port number of the first forwarding end in the five-tuple mapping relationship are not duplicated.

[0034] Secondly, this application provides a data transmission apparatus applied at a first forwarding end, comprising:

[0035] The acquisition module is used to acquire the first message; the destination of the first message is the second forwarding end.

[0036] The determining module is used to determine the data transmission rules negotiated with the second forwarding end; the data transmission rules include: the session formed between the first forwarding end and the sender of the first message, and the mapping relationship between the session formed between the first forwarding end and the second forwarding end;

[0037] The encapsulation module is used to encapsulate the first message according to the data transmission rules to obtain the second message;

[0038] The sending module is used to send the second message to the second forwarding end.

[0039] Thirdly, this application provides an electronic device, comprising:

[0040] Memory, used to store computer programs;

[0041] A processor is configured to execute the computer program to implement the aforementioned disclosed data transmission method.

[0042] Fourthly, this application provides a readable storage medium for storing a computer program, wherein the computer program, when executed by a processor, implements the aforementioned disclosed data transmission method.

[0043] As can be seen from the above scheme, this application provides a data transmission method applied to a first forwarding end, including: obtaining a first message; determining data transmission rules negotiated with a second forwarding end; the data transmission rules include: a mapping relationship between the session formed by the first forwarding end and the sender of the first message, and the session formed by the first forwarding end and the second forwarding end; encapsulating the first message according to the data transmission rules to obtain a second message; and sending the second message to the second forwarding end.

[0044] As can be seen, this application uses the data transmission rules negotiated between the first forwarding end and the second forwarding end to encapsulate the second message. Since the data transmission rules include the session mapping information between the first forwarding end and the sender of the first message and the session between the first forwarding end and the second forwarding end, the two sessions have a unique one-to-one mapping relationship. When applied to VPN access scenarios, multiple sessions in the tunnel do not need to be transmitted to the external network through the same public network session, thus solving the traffic blocking phenomenon in the remote access process.

[0045] Correspondingly, the data transmission apparatus, device, and readable storage medium provided in this application also have the above-mentioned technical effects. Attached Figure Description

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

[0047] Figure 1 This is a flowchart of a data transmission method disclosed in this application;

[0048] Figure 2 This is a schematic diagram of a data transmission rule negotiation process disclosed in this application;

[0049] Figure 3 This is a schematic diagram of the packet sending process between a second forwarding terminal and a first forwarding terminal as disclosed in this application;

[0050] Figure 4 This is a schematic diagram of the packet receiving process between a second forwarding terminal and a first forwarding terminal as disclosed in this application;

[0051] Figure 5 This is a schematic diagram of a data transmission device disclosed in this application;

[0052] Figure 6 This is a schematic diagram of an electronic device disclosed in this application;

[0053] Figure 7 This is a schematic diagram of another electronic device disclosed in this application. Detailed Implementation

[0054] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0055] Currently, network congestion is prone to occur during VPN remote access. For example, there are many UDP sessions within the tunnel, and these UDP sessions need to be transmitted to the external network through the same public network session, resulting in traffic blockage. Similarly, TCP long connections are also prone to traffic blockage. To address this, this application provides a data transmission scheme that enables a one-to-one mapping between tunnel sessions and public network sessions, resolving traffic blockage during remote access. Furthermore, the transmission protocol and data processing requirements in the data transmission rules allow the second forwarding end and the first forwarding end to process the transmitted data according to mutually agreed-upon requirements, such as encrypting and decrypting the transmitted data using agreed-upon cryptographic algorithms and performing data integrity checks using agreed-upon detection methods. This facilitates the expansion of data transmission between the second and first forwarding ends.

[0056] The following is a description of the technical terms used in this application:

[0057] VPN (Virtual Private Network): A communication method used to connect private networks between medium and large enterprises or groups. It uses tunneling protocols to achieve security effects for private messages, such as confidentiality, sender authentication, and message accuracy.

[0058] NAT (Network Address Translation): In computer networks, it's a technique that rewrites the source or destination IP address of IP packets as they pass through routers or firewalls. This application's network address translation includes port mapping, which can be viewed as PAT (Port Address Translations). A VPN implemented using NAT rules is called a NATVPN.

[0059] TCP SYN: The first message in a TCP handshake.

[0060] TCP SYN+ACK: The second message in the TCP handshake.

[0061] TCP+ACK: The third message in the TCP handshake.

[0062] IP OPT / IP opt: Extension options in the IP header, including well-known extension information and private extension information. This application can choose to use well-known extension headers, such as SR, or private extension headers to carry private data.

[0063] TCP OPT / tcp opt: Extension options in the TCP protocol header, including well-known extension information and private extension information. This application can choose well-known extension options and private extension options to carry private data.

[0064] A session is a quintuple that corresponds to a session during network transmission.

[0065] QUIC (Quick UDP Internet Connection) is a reliable and secure transport protocol based on UDP, proposed by Google.

[0066] See Figure 1 As shown in the figure, this application discloses a data transmission method applied to a first forwarding end, including:

[0067] S101. Obtain the first message to be sent to the second forwarding end.

[0068] In this embodiment, the second forwarding end and the first forwarding end can be two gateways, each implementing VPN functionality. For example, the gateway acting as the first forwarding end is deployed in LAN 1, and the gateway acting as the second forwarding end is deployed in LAN 2. Alternatively, the gateway acting as the second forwarding end can be deployed as a server in the intranet of a company headquarters located in region A, and the gateway acting as the first forwarding end can be deployed as a client in the intranet of a company branch located in region B. Of course, the second forwarding end and the first forwarding end can also be host servers located in the same network or in different networks; or VPN devices located in different networks. Specifically, the second forwarding end and the first forwarding end are equipped with software modules or hardware modules that provide the packet encapsulation function provided in this embodiment.

[0069] Therefore, this embodiment is applicable to scenarios where VPN devices on a branch network of an enterprise access VPN devices on the headquarters network of an enterprise, VPN devices on the headquarters network access VPN devices on a branch network of an enterprise, access scenarios between different devices within the same network, and access scenarios between different hosts on different networks. That is, the first forwarding end and the second forwarding end can be gateways to two networks; they can also be two hosts, and these two hosts are not limited to being on the same network or different networks.

[0070] S102. Determine the data transmission rules negotiated with the second forwarding end.

[0071] It should be noted that the transmission protocols and data processing requirements applicable to and supported by the first and second forwarding ends can be flexibly configured, and there can be more than one type of transmission protocol and data processing requirement. However, the data transmitted between the first and second forwarding ends must follow the same transmission protocol and the same data processing requirements. Therefore, the first and second forwarding ends need to negotiate the data transmission rules.

[0072] The data transmission rules include: session mapping information between the first forwarding end and the sending end of the first message (such as an intranet session in a VPN access scenario), and the session between the first forwarding end and the second forwarding end (such as a public network session in a VPN access scenario); the transmission protocol applicable to both the second forwarding end and the first forwarding end; and the data processing requirements applicable to both the second forwarding end and the first forwarding end. In a VPN access scenario, an intranet session is the session between the terminal sending the first message and the first forwarding end, where the terminal sending the first message and the first forwarding end are located within the same local area network; a public network session is the session between the second forwarding end and the first forwarding end.

[0073] In one implementation, the mapping relationship is a five-tuple mapping relationship, where the five-tuple includes: source IP address, source port number, destination IP address, destination port number, and the name of the transport protocol. These five elements of the intranet session between the terminal sending the first message and the first forwarding end, and the five elements of the public network session between the second forwarding end and the first forwarding end, form a mapping relationship, thus obtaining the five-tuple mapping relationship. The transport protocols applicable to both the second and first forwarding ends include: HTTPS (Hypertext Transfer Protocol over Secure Socket Layer), UDP, and IPSEC (Internet Protocol Security, an open standard framework). The data processing requirements applicable to both the second and first forwarding ends include: encryption requirements, data integrity detection requirements, and authentication requirements. Notably, the public network source port number of the second forwarding end and the public network destination port number of the first forwarding end in the five-tuple mapping relationship are not duplicated.

[0074] The first and second forwarding ends can negotiate data transmission rules using the messages they would normally transmit (such as handshake messages), or they can specifically set up messages for negotiating data transmission rules, such as setting up an information negotiation message before transmitting data to negotiate data transmission rules. After successful negotiation, the first and second forwarding ends each record the data transmission rules. For example, the first forwarding end can use a preset database to record the data transmission rules for use in subsequent data transmissions.

[0075] When data needs to be transmitted, the first forwarding end immediately determines the data transmission rules negotiated with the second forwarding end, including: the first forwarding end uses the identification information of the second forwarding end as the query keyword to query the data transmission rules in the preset database; and determines the data transmission rules corresponding to the identification information as the data transmission rules negotiated between the first forwarding end and the second forwarding end.

[0076] If the first forwarding end cannot find the data transmission rules when it needs to transmit data, then the first forwarding end and the second forwarding end will negotiate in real time to determine the data transmission rules. In one implementation, the first forwarding end and the second forwarding end negotiate and determine data transmission rules, including: adding a first requirement from the first forwarding end to the original communication message to obtain a new communication message; the first requirement includes: the terminal IP address and terminal port number in the local area network where the first forwarding end is located, the internal network IP address and internal network port number of the first forwarding end, at least one transmission protocol applicable to the first forwarding end, and at least one data processing requirement; sending the new communication message to the second forwarding end, so that the second forwarding end parses the new communication message to obtain the first requirement; if it is confirmed that the first requirement can be met, the data transmission rules are generated and recorded based on the first requirement and the second end confirmation requirement, and the second end confirmation requirement is added to the original confirmation message to obtain a new confirmation message; the second end confirmation requirement includes: the public network IP address and public network port number of the second forwarding end, the transmission protocol applicable to both the second forwarding end and the first forwarding end, and the data processing requirement applicable to both the second forwarding end and the first forwarding end; receiving the new confirmation message sent by the second forwarding end, parsing the new confirmation message to obtain the second end confirmation requirement; and generating and recording the data transmission rules based on the first requirement and the second end confirmation requirement.

[0077] As mentioned above, the first forwarding end and the second forwarding end can negotiate data transmission rules using the messages that would normally be transmitted between them, or they can specifically set up messages dedicated to negotiating data transmission rules. Therefore, in one embodiment, the original communication message is a handshake message; correspondingly, a first requirement of the first forwarding end is added to the original communication message, including: adding a first requirement to the extended options and / or emergency information options of the handshake message; the original confirmation message is a handshake confirmation message of the handshake message; correspondingly, a second confirmation requirement is added to the original confirmation message, including: adding a second confirmation requirement to the extended options and / or emergency information options of the handshake confirmation message.

[0078] In one implementation, the original communication message is a pre-set information negotiation message before data transmission; correspondingly, a first requirement of the first forwarding end is added to the original communication message, including: adding a first requirement to the payload option of the information negotiation message; the original acknowledgment message is a negotiation acknowledgment message of the information negotiation message; correspondingly, a second end acknowledgment requirement is added to the original acknowledgment message, including: adding a second end acknowledgment requirement to the payload option of the negotiation acknowledgment message.

[0079] If the second forwarding end confirms that it cannot meet the first requirement (e.g., the second forwarding end does not support the transmission protocol and / or data processing requirements in the first requirement), it generates an error message and sends the error message to the first forwarding end. In one embodiment, if the first forwarding end receives the error message and confirms that there are other transmission protocols and other data processing requirements applicable to the first forwarding end but not in the first requirement, it replaces the transmission protocol and data processing requirements in the first requirement with the other transmission protocols and other data processing requirements, and executes the first requirement of the first forwarding end to be added to the original communication message and subsequent steps. The first forwarding end thereby changes the transmission protocol and data processing requirements and negotiates the data transmission rules with the second forwarding end again.

[0080] In one implementation, if the first forwarding end receives an error message and confirms that there are no other transmission protocols or data processing requirements applicable to the first forwarding end that are not included in the first requirement, it returns an error notification message to the sender of the first message. That is, after negotiation between the first and second forwarding ends, it is found that they do not support the same transmission protocol and the same data processing requirements; in this case, the first forwarding end informs the sender of the first message. The sender of the first message can be a terminal device located on the same local area network as the first forwarding end.

[0081] S103. Encapsulate the first message according to the data transmission rules to obtain the second message.

[0082] S104. Send the second message to the second forwarding end.

[0083] As can be seen, this embodiment utilizes the data transmission rules negotiated between the first and second forwarding ends to encapsulate the second message. In the VPN access scenario, the first and second forwarding ends are VPN devices set up at the exits of two networks. The data transmission rules include the mapping relationship between intranet sessions and public network sessions. Therefore, the intra-tunnel session and the public network session are mapped one-to-one, so multiple sessions within the tunnel do not need to be transmitted to the external network through the same public network session, thus solving the traffic blocking phenomenon during remote access. At the same time, the transmission protocol and data processing requirements in the data transmission rules enable the second and first forwarding ends to process the data transmitted between them according to the requirements negotiated by both parties. For example, the transmitted data can be encrypted and decrypted using the negotiated cryptographic algorithm, and the data integrity can be checked using the negotiated detection method. This facilitates the expansion of data transmission between the second and first forwarding ends and also improves data transmission efficiency.

[0084] The following example illustrates the solution using VPN gateways configured as the exit points of two different networks, with the first and second forwarding ends being the gateways for those networks.

[0085] If the first and second forwarding endpoints transmit data via TCP, then they need to exchange configuration characteristics between the two gateways before negotiating NAT rules. TCP is used to ensure the reliability of data exchange; please refer to [link to relevant documentation]. Figure 2 The configuration features to be exchanged include: Security Flags: such as whether encryption, integrity, and compression are supported, and other overlay features. Security Parameters: encryption algorithm, integrity algorithm, key material (DH group, etc.). Ext-option List: including IP header options, TCP header options, etc. Auth Info: used for authentication.

[0086] Please see Figure 2During the TCP handshake phase, NatVPN CLIENT (first forwarding end) and NatVPN SERVER (second forwarding end) negotiate data transmission rules. The specific process includes: NatVPN CLIENT adding private data to the IP layer ipopt in the TCP SYN packet or adding private data to the TCP header tcp opt. The private data includes: the transmission protocols supported by NatVPN CLIENT, the encryption algorithm used for the data, the terminal IP address and terminal port number in the local area network where NatVPN CLIENT is located, and the internal IP address and internal port of NatVPN CLIENT, which is the first requirement. If the NATVPN server receives this SYN packet, it means that the client can use either IP opt or TCP opt to carry private data to the server. The NATVPN server then uses the private data in the packet to confirm whether it supports the same transport protocol, encryption algorithm, and other requirements. If it does, the NATVPN server includes its support for the same transport protocol and encryption algorithm, along with its public IP address and port, as private data (the second-end confirmation requirement), in the SYN+ACK packet and sends it out in the same way. Simultaneously, the NAT server learns and records the NAT rules (i.e., data transmission rules). If the TCP handshake is successful, it means that the server and client can use either IP opt or TCP opt to carry private data, and the negotiation has been successfully completed. If the handshake fails, a different transport protocol or encryption algorithm needs to be used to try negotiating again. Other transport protocols include ESP (Encapsulating Secure Payload Protocol) and UDP (User Datagram Protocol). ESP and UDP do not have a handshake process and do not have an extension in the Layer 4 header, but they can use IP opt to carry private data for negotiation.

[0087] It is evident that for protocols with a handshake process, private data is loaded into the IP layer (ip opt) or TCP header (tcp opt) of the handshake message for negotiation. For protocols without a handshake process, private data is loaded into the ip opt for negotiation.

[0088] After the NatVPN CLIENT and NatVPN SERVER have negotiated the rules, the data transfer process between them can be found in [link to relevant documentation]. Figure 3 and Figure 4 .like Figure 3As shown, when a NatVPN CLIENT or NatVPN SERVER sends packets to the public network, it first determines whether the destination of the data being sent corresponds to a NAT rule. If so, it encapsulates the data packet based on this rule, performs address translation, and then sends the data packet to the public network. If not, it immediately generates a NAT rule, encapsulates the data packet based on the generated rule, performs address translation, and then sends the data packet to the public network. Figure 4 As shown, after receiving a data packet, the NatVPN CLIENT or NatVPNSERVER first performs a routine security check. If the check passes, it determines whether the sender of the current data has a corresponding NAT rule. If so, it restores the data packet to tunnel data based on this rule, performs address translation, and then sends the data packet to the internal network. If not, it immediately generates a NAT rule, restores the data packet to tunnel data based on the generated rule, performs address translation, and then sends the data packet to the internal network. NAT records are the basic information for forming NAT rules and can be considered as the set of the aforementioned first requirement and subsequent client confirmation requirements.

[0089] The NAT rules include the mapping between the original 5-tuple of the session within the tunnel and the public network 5-tuple. When sending packets within the tunnel, the corresponding session outside the tunnel is queried based on the 5-tuple, and the packet is sent accordingly. After learning through these NAT rules, the receiving end will query the 5-tuple information inside the tunnel based on the external 5-tuple and then reconstruct the data. Different NAT rules need to be conflict-checked, and only generated when there is no conflict. In other words, one session inside the tunnel cannot correspond to multiple sessions outside the tunnel, and one session outside the tunnel cannot correspond to multiple sessions inside the tunnel; there must be a one-to-one mapping between sessions inside and outside the tunnel. The mapping rules generated locally can easily avoid conflicts, but it is also necessary to avoid conflicts between the rules learned from the other end and the local rules. This problem can be avoided by using conventions, such as: the source port of a session initiated by the NATVPN server uses an odd-numbered port, and the source port of a session initiated by the NATVPN client uses an even-numbered port as the destination port. In extreme cases, sessions are initiated by only one end. Excluding well-known ports, with a port allocation range of 20,000, there are at least 20,000 × 20,000 / 2, totaling approximately 200 million sessions, which is more than sufficient. Generally, when deploying the gateway, the NATVPN client is deployed on the branch intranet, while the NATVPN server is deployed on the headquarters intranet.

[0090] This embodiment stores NAT rules in either IP opt or TCP opt. Generally, these rules are only added to IP opt or TCP opt during the learning phase, and the learning phase varies depending on the protocol. For example, TCP learns NAT rules during the handshake phase, and subsequent packets do not carry NAT rules. However, UDP learns NAT rules in its first packet. To avoid packet loss, NAT rules are carried in the preceding packets. Since UDP has no connection, these NAT rules have a certain validity period; if no UDP packets are sent for a long time, the NAT rules need to be carried to prevent discrepancies caused by non-existent rules. Since UDP is an unreliable transport protocol, it can be mapped to QUIC for reliable UDP transmission. Within a tunnel, a UDP session is mapped to a QUIC session for transmission.

[0091] Specifically, NAT rules can specify data processing requirements such as privacy, integrity, data source authentication, and key protection. Privacy: Secure encryption algorithms such as AES, Chacha20, 3DES, RSA, SM3, and SM4 can be selected to encrypt the Layer 4 payload; the key is negotiated during the configuration feature negotiation phase, for example, using a DH group. Integrity and Data Source Authentication: Algorithms such as HMAC-SHA and HMAC-SHA2 can be selected to protect the integrity of the Layer 4 payload and private extension data; the key is negotiated during the configuration feature negotiation phase. Key Protection: The negotiated key is the base key, named skey_d. The session key is derived from skey_d and can be generated using skey_s = HMAC_SHA256(skey_d, NAT rule | key type), which uses the HMAC_SHA256 algorithm with skey_d as the key to encrypt packets. There are two key types: encryption and integrity protection, and corresponding keys will be generated accordingly.

[0092] Current VPN tunneling protocols are fixed and singular, making them susceptible to blocking by intermediate networks. This application enables tunnel sessions to be directly mapped to the public network one-to-one via NAT rules, breaking the fixed and singular nature of VPN tunnel and public network transmission, improving network penetration, and reducing bandwidth consumption. Key features include: mapping tunnel sessions one-to-one to the public network via NAT rules, allowing multiple sessions to run on the public network, avoiding intermediate network blocking, and significantly improving network penetration; learning NAT rules to avoid the hassle of manual NAT rule configuration, reducing the management difficulty of NAT rules; using the private fields of IP opt and TCP opt to transmit NAT rules, avoiding the corruption of sequence numbers caused by TCP packet length corruption, and preserving the high reliability of TCP; and using IP opt and TCP opt probes to test the network's penetration of private extension information, ensuring successful NAT rule learning. Adding security features on top of NAT enhances security compared to the original gateway NAT solution, protecting the security of data transmission between gateways. This embodiment also allows the use of different protocols for reliability overlay, including but not limited to QUIC, RUDP (Reliable User Datagram Protocol), RTP (Real-Time Transport Protocol), UDT (UDP-based Data Transmission Protocol), etc.

[0093] This embodiment coordinates NAT rules through data packets, mapping sessions inside and outside the tunnel one-to-one. This enables multiple sessions to run in the public network environment and within the tunnel, resolving the blocking issues caused by single sessions on the public network. Negotiation only needs to be performed during the NAT rule learning phase. Sessions with security requirements carry security parameters, while sessions without security requirements do not, thus not adding extra data. In other words, data processing requirements are optional depending on actual transmission needs.

[0094] The following describes a data transmission device provided in an embodiment of this application. The data transmission device described below and the data transmission method described above can be referred to each other.

[0095] See Figure 5 As shown in the figure, this application discloses a data transmission device applied to a first forwarding end, comprising:

[0096] The acquisition module 501 is used to acquire the first message that needs to be sent to the second forwarding end;

[0097] The determination module 502 is used to determine the data transmission rules negotiated with the second forwarding end; the data transmission rules include: the mapping relationship between intranet sessions and public network sessions, the transmission protocol applicable to both the second forwarding end and the first forwarding end, and the data processing requirements applicable to both the second forwarding end and the first forwarding end;

[0098] Encapsulation module 503 is used to encapsulate the first message according to data transmission rules to obtain the second message;

[0099] The sending module 504 is used to send the second message to the second forwarding end.

[0100] In one implementation, the determining module is specifically used for:

[0101] Using the identification information of the second forwarding end as the query keyword, query the data transmission rules in the preset database;

[0102] The data transmission rules corresponding to the identification information are determined as the data transmission rules negotiated between the first forwarding end and the second forwarding end.

[0103] In one implementation, the determining module is further configured to:

[0104] If no data transmission rules exist, negotiate and determine the data transmission rules with the second forwarding end.

[0105] In one implementation, the determining module is further configured to:

[0106] A new communication message is obtained by adding the first requirement of the first forwarding end to the original communication message; the first requirement includes: the terminal IP address and terminal port number in the local area network where the first forwarding end is located, the internal network IP address and internal network port number of the first forwarding end, at least one transmission protocol applicable to the first forwarding end, and at least one data processing requirement.

[0107] The new communication message is sent to the second forwarding end, so that the second forwarding end can parse the new communication message to obtain the first requirement. If it is confirmed that the first requirement can be met, the data transmission rule is generated and recorded based on the first requirement and the second end confirmation requirement, and the second end confirmation requirement is added to the original confirmation message to obtain a new confirmation message. The second end confirmation requirement includes: the public IP address of the second forwarding end, the public port number, the transmission protocol applicable to both the second forwarding end and the first forwarding end, and the data processing requirements applicable to both the second forwarding end and the first forwarding end.

[0108] Receive the new confirmation message sent by the second forwarding end, and parse the new confirmation message to obtain the confirmation request from the second end;

[0109] The data transmission rules are generated and recorded based on the first requirement and the second end confirmation requirement.

[0110] In one implementation, the original communication message is a handshake message; accordingly, the determining module is also used to: add a first requirement to the extended options and / or emergency information options of the handshake message;

[0111] The original confirmation message is a handshake confirmation message; correspondingly, the determination module is also used to: add a second-end confirmation requirement in the extended options and / or emergency information options of the handshake confirmation message.

[0112] In one implementation, the original communication message is a pre-defined information negotiation message before data transmission; the determining module is further configured to: add a first requirement to the payload options of the information negotiation message;

[0113] The original confirmation message is a negotiation confirmation message for the information negotiation message; the determination module is also used to add a second-end confirmation requirement to the payload options of the negotiation confirmation message.

[0114] In one implementation, the determining module is further configured to:

[0115] If an error message is received, and it is confirmed that there are other transmission protocols and other data processing requirements applicable to the first forwarding end that are not in the first requirement, then the transmission protocol and data processing requirements in the first requirement are replaced with other transmission protocols and other data processing requirements, and the first requirement of adding the first forwarding end to the original communication message and subsequent steps are executed.

[0116] If the second forwarding end confirms that the first requirement cannot be met, it generates an error message and sends the error message to the first forwarding end.

[0117] In one implementation, it further includes:

[0118] The error reporting module is used to return error notification information to the sender of the first message if it receives an error message and confirms that there are no other transmission protocols or other data processing requirements applicable to the first forwarding end that are not in the first requirements.

[0119] In one implementation, the transport protocols applicable to both the second forwarding end and the first forwarding end include HTTPS, UDP, and IPsec; the data processing requirements applicable to both the second forwarding end and the first forwarding end include encryption requirements, data integrity detection requirements, and authentication requirements.

[0120] For more detailed information on the working process of each module and unit in this embodiment, please refer to the relevant content disclosed in the foregoing embodiments, which will not be repeated here.

[0121] As can be seen, this embodiment provides a data transmission device that enables a one-to-one connection between tunnel sessions and public network sessions, thus resolving traffic blocking issues during remote access.

[0122] The following describes an electronic device provided by an embodiment of this application. The electronic device described below can be referred to in conjunction with the data transmission method and apparatus described above.

[0123] See Figure 6 As shown in the figure, an embodiment of this application discloses an electronic device, including:

[0124] Memory 601 is used to store computer programs;

[0125] Processor 602 is configured to execute the computer program to implement the method disclosed in any of the above embodiments.

[0126] Please refer to Figure 7 , Figure 7 This is a schematic diagram of another electronic device provided in this embodiment. This electronic device can vary significantly due to differences in configuration or performance. It may include one or more central processing units (CPUs) 322 (e.g., one or more processors) and a memory 332, and one or more storage media 330 (e.g., one or more mass storage devices) for storing application programs 342 or data 344. The memory 332 and storage media 330 can be temporary or persistent storage. The program stored in the storage media 330 may include one or more modules (not shown in the diagram), each module including a series of instruction operations on the data processing device. Furthermore, the central processing unit 322 may be configured to communicate with the storage media 330 and execute the series of instruction operations in the storage media 330 on the electronic device 301.

[0127] Electronic device 301 may also include one or more power supplies 326, one or more wired or wireless network interfaces 350, one or more input / output interfaces 358, and / or one or more operating systems 341. Examples include Windows Server™, Mac OS X™, Unix™, Linux™, FreeBSD™, etc.

[0128] exist Figure 7 In this context, application 342 can be a program that executes the data transmission method, and data 344 can be data required or generated for executing the data transmission method.

[0129] The steps in the data transmission method described above can be implemented by the structure of an electronic device.

[0130] The following describes a readable storage medium provided in an embodiment of this application. The readable storage medium described below can be referred to in conjunction with the data transmission method, apparatus and device described above.

[0131] A readable storage medium is provided for storing a computer program, wherein the computer program, when executed by a processor, implements the data transmission method disclosed in the foregoing embodiments. Specific steps of this method can be found in the corresponding content disclosed in the foregoing embodiments, and will not be repeated here.

[0132] The terms “first,” “second,” “third,” “fourth,” etc., used in this application (if applicable) are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms “comprising” and “having,” and any variations thereof, are intended to cover non-exclusive inclusion; for example, a process, method, or apparatus that includes a series of steps or units is not necessarily limited to those explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, or apparatus.

[0133] It should be noted that the use of terms such as "first" and "second" in this application is for descriptive purposes only and should not be construed as indicating or implying their relative importance or implicitly specifying the number of technical features indicated. Therefore, a feature defined as "first" or "second" may explicitly or implicitly include at least one of those features. Furthermore, the technical solutions of the various embodiments can be combined with each other, but this must be based on the ability of those skilled in the art to implement them. If the combination of technical solutions is contradictory or impossible to implement, such a combination of technical solutions should be considered non-existent and not within the scope of protection claimed in this application.

[0134] The various embodiments in this specification are described in a progressive manner. Each embodiment focuses on the differences from other embodiments. The same or similar parts between the various embodiments can be referred to each other.

[0135] The steps of the methods or algorithms described in conjunction with the embodiments disclosed herein can be implemented directly by hardware, a software module executed by a processor, or a combination of both. The software module can be located in random access memory (RAM), main memory, read-only memory (ROM), electrically programmable ROM, electrically erasable programmable ROM, registers, hard disk, removable disk, CD-ROM, or any other form of readable storage medium known in the art.

[0136] This document uses specific examples to illustrate the principles and implementation methods of this application. The descriptions of the above embodiments are only for the purpose of helping to understand the methods and core ideas of this application. At the same time, for those skilled in the art, there will be changes in the specific implementation methods and application scope based on the ideas of this application. Therefore, the content of this specification should not be construed as a limitation of this application.

Claims

1. A data transmission method, characterized in that, Applied to the first forwarding end, including: Obtain the first message; the destination of the first message is the second forwarding end; Determine the data transmission rules negotiated with the second forwarding end; the data transmission rules include: the session formed between the first forwarding end and the sender of the first message, and the mapping relationship between the session formed between the first forwarding end and the second forwarding end; The first message is encapsulated according to the data transmission rules to obtain the second message; Send the second message to the second forwarding terminal; If the data transmission rule does not exist, then negotiate with the second forwarding end to determine the data transmission rule; The step of negotiating and determining the data transmission rules with the second forwarding end includes: Add the first requirement of the first forwarding end to the original communication message to obtain a new communication message; the first requirement includes: the terminal IP address and terminal port number in the local area network where the first forwarding end is located, and the internal network IP address and internal network port number of the first forwarding end; The new communication message is sent to the second forwarding end so that the second forwarding end can parse the new communication message to obtain the first requirement. If it is confirmed that the first requirement can be met, the data transmission rule is generated and recorded based on the first requirement and the second end confirmation requirement, and the second end confirmation requirement is added to the original confirmation message to obtain a new confirmation message. The second end confirmation requirement includes: the public IP address and public port number of the second forwarding end. Receive the new confirmation message sent by the second forwarding end, and parse the new confirmation message to obtain the confirmation request from the second end; The data transmission rules are generated and recorded based on the first requirement and the second end confirmation requirement.

2. The data transmission method according to claim 1, characterized in that, The determination of the data transmission rules negotiated with the second forwarding end includes: Using the identification information of the second forwarding end as the query keyword, the data transmission rules are queried in the preset database; The data transmission rules corresponding to the identification information are determined as the data transmission rules negotiated between the first forwarding end and the second forwarding end.

3. The data transmission method according to claim 1, characterized in that, The original communication message is a handshake message; correspondingly, adding the first requirement of the first forwarding end to the original communication message includes: adding the first requirement to the extended options and / or emergency information options of the handshake message; The original confirmation message is the handshake confirmation message of the handshake message; correspondingly, adding the second end confirmation requirement to the original confirmation message includes: adding the second end confirmation requirement to the extended options and / or emergency information options of the handshake confirmation message; The original communication message is a preset information negotiation message before data transmission; correspondingly, adding the first requirement of the first forwarding end to the original communication message includes: adding the first requirement to the payload option of the information negotiation message; The original confirmation message is the negotiation confirmation message of the information negotiation message; correspondingly, adding the second end confirmation requirement to the original confirmation message includes: adding the second end confirmation requirement to the payload option of the negotiation confirmation message.

4. The data transmission method according to claim 1, characterized in that, The data transmission rules also include: a transmission protocol applicable to both the second forwarding end and the first forwarding end, and data processing requirements applicable to both the second forwarding end and the first forwarding end; Accordingly, the first requirement also includes: at least one transmission protocol applicable to the first forwarding end and at least one data processing requirement; Accordingly, the second end confirmation requirements also include: a transmission protocol applicable to both the second forwarding end and the first forwarding end, and data processing requirements applicable to both the second forwarding end and the first forwarding end; Correspondingly, it also includes: If an error message is received, and it is confirmed that there are other transmission protocols and other data processing requirements applicable to the first forwarding end that are not in the first requirement, then the transmission protocol and data processing requirements in the first requirement are replaced with other transmission protocols and other data processing requirements, and the first requirement of the first forwarding end and subsequent steps are executed in the original communication message; wherein, if the second forwarding end confirms that the first requirement cannot be met, then the error message is generated and sent to the first forwarding end.

5. The data transmission method according to claim 4, characterized in that, Also includes: If the error message is received, and it is confirmed that there are no other transmission protocols or other data processing requirements applicable to the first forwarding end that are not included in the first requirement, then an error notification message is returned to the sending end of the first message.

6. A data transmission device, characterized in that, Applied to the first forwarding end, including: The acquisition module is used to acquire the first message; the destination of the first message is the second forwarding end. The determining module is used to determine the data transmission rules negotiated with the second forwarding end; the data transmission rules include: the session formed between the first forwarding end and the sender of the first message, and the mapping relationship between the session formed between the first forwarding end and the second forwarding end; The encapsulation module is used to encapsulate the first message according to the data transmission rules to obtain the second message; The sending module is used to send the second message to the second forwarding end; The determining module is further configured to negotiate and determine the data transmission rule with the second forwarding end if the data transmission rule does not exist. The determining module is further configured to add a first requirement from the first forwarding end to the original communication message to obtain a new communication message; the first requirement includes: the terminal IP address and terminal port number in the local area network where the first forwarding end is located, and the internal network IP address and internal network port number of the first forwarding end; send the new communication message to the second forwarding end so that the second forwarding end can parse the new communication message to obtain the first requirement; if it is confirmed that the first requirement can be met, generate and record the data transmission rules based on the first requirement and the second end confirmation requirement, and add the second end confirmation requirement to the original confirmation message to obtain a new confirmation message; the second end confirmation requirement includes: the public network IP address and public network port number of the second forwarding end; receive the new confirmation message sent by the second forwarding end, parse the new confirmation message to obtain the second end confirmation requirement; generate and record the data transmission rules based on the first requirement and the second end confirmation requirement.

7. An electronic device, characterized in that, include: Memory, used to store computer programs; A processor for executing the computer program to implement the data transmission method as described in any one of claims 1 to 5.

8. A readable storage medium, characterized in that, Used to store a computer program, wherein the computer program, when executed by a processor, implements the data transmission method as described in any one of claims 1 to 5.

Images