Cross-protocol interaction system and method

Abstract

The cross-protocol interaction method comprises the steps that if a target DNS request used for analyzing a target domain name into a first IP address based on a first network protocol is intercepted in a kernel mode of a Windows host, a target application program managing and controlling the target DNS request sends a first data packet originally sent to a target server side of the first IP address to a target server side of the first IP address, redirecting to a target port of a local IP address based on a second network protocol in the Windows host; adding a target flow identification head at least comprising the target domain name to a first data packet received by the target port to form a target data packet; the cloud protocol conversion module extracts a target domain name and a first data packet from the target data packet; obtaining a first IP address of the target domain name based on a first network protocol through DNS analysis; and based on the first IP address, converting the first data packet into a second data packet capable of accessing a target server side corresponding to the first IP address so as to access the target server side.

Description

A cross-protocol interaction system and method Technical Field

[0001] This application relates to the field of cross-protocol interaction technology, and in particular to a cross-protocol interaction system and method. Background Technology

[0002] In the existing network communication architecture, the Windows host communicates with the outside world through the configured network protocol stack, while the application server listens and exchanges data based on the network protocol stack it has designed and selected.

[0003] However, when a Windows host is configured with only a single network protocol (such as IPv6), while the server-side application deployed on that Windows host uses a different network protocol (such as IPv4), the network protocols between the two become inconsistent. This inconsistency disrupts network communication between the Windows host and the server, hindering the operations of applications that rely on it.

[0004] Therefore, when the network protocol configured on the Windows host is inconsistent with the network protocol used by the application's server, how to achieve normal interaction between the application and the server has become an urgent problem to be solved. Summary of the Invention

[0005] This application proposes a cross-protocol interaction system and method, the main purpose of which is to enable normal interaction between the application and the server when the network protocol configured on the Windows host is inconsistent with the network protocol used by the application's server.

[0006] To achieve the above objectives, this application mainly provides the following technical solutions: Firstly, this application provides a cross-protocol interaction system. The cross-protocol interaction system provided in this application embodiment may include at least: a kernel filtering module, used to intercept DNS requests initiated by applications in the kernel mode of a Windows host, and, upon intercepting a target DNS request for resolving a target domain name to a first IP address based on a first network protocol, to control the target application corresponding to the target DNS request to redirect the first data packet originally intended for sending to the target server corresponding to the first IP address to the target port corresponding to the local IP address within the Windows host based on a second network protocol; the second network protocol is configured by the Windows host. The local traffic forwarding module is used to add a target traffic identifier header to the first data packet to form a target data packet when the target port receives the first data packet, and then send the target data packet to the cloud protocol conversion module; the target traffic identifier header includes at least the target domain name; the cloud protocol conversion module is used to extract the target domain name and the first data packet from the target data packet; obtain the first IP address based on the first network protocol corresponding to the target domain name through DNS resolution; convert the first data packet into a second data packet that can access the target server corresponding to the first IP address based on the first IP address, and access the target server based on the second data packet.

[0007] Secondly, this application provides a cross-protocol interaction method. An embodiment of this application provides a cross-protocol interaction method that may include at least: intercepting DNS requests initiated by applications in the kernel mode of a Windows host; and, upon intercepting a target DNS request for resolving a target domain name to a first IP address based on a first network protocol, controlling the target application corresponding to the target DNS request to redirect a first data packet originally intended for the target server corresponding to the first IP address to a target port corresponding to a local IP address based on a second network protocol within the Windows host; the second network protocol is a single network protocol configured on the Windows host and is different from the first network protocol; upon detecting that the target port has received a first data packet, adding a target traffic identifier header to the first data packet to form a target data packet, and sending the target data packet to a cloud protocol conversion module; the target traffic identifier header at least includes the target domain name; extracting the target domain name and the first data packet from the target data packet through the cloud protocol conversion module, obtaining the first IP address based on the first network protocol corresponding to the target domain name through DNS resolution, converting the first data packet into a second data packet capable of accessing the target server corresponding to the first IP address based on the first IP address, and accessing the target server based on the second data packet.

[0008] Thirdly, this application provides a computer-readable storage medium including a stored program, wherein, when the program is executed, it controls the device where the storage medium is located to perform the cross-protocol interaction method of the second aspect.

[0009] Fourthly, this application provides an electronic device comprising: a memory for storing a program; and a processor coupled to the memory for running the program to perform the cross-protocol interaction method of the second aspect.

[0010] Fifthly, this application provides a computer program product comprising: a computer program / computer executable instructions, wherein the computer program / computer executable cross-protocol interaction method of the second aspect.

[0011] The cross-protocol interaction system and method provided in this application intercepts DNS requests initiated by applications in the kernel mode of a Windows host. Upon intercepting a target DNS request used to resolve a target domain name to a first IP address based on a first network protocol, the system manages the target application corresponding to the target DNS request to redirect the first data packet originally intended for the target server corresponding to the first IP address to a target port corresponding to a local IP address based on a second network protocol within the Windows host. Then, upon detecting that the target port has received the first data packet, a target traffic identifier header, including at least the target domain name, is added to the first data packet to form a target data packet, which is then sent to a cloud protocol conversion module. Subsequently, the cloud protocol conversion module extracts the target domain name and the first data packet from the target data packet and obtains the first IP address based on the first network protocol corresponding to the target domain name through DNS resolution. Finally, the cloud protocol conversion module converts the first data packet into a second data packet capable of accessing the target server corresponding to the first IP address based on the first IP address, and then accesses the target server based on the second data packet. As can be seen, the solution provided in this application has at least the following two effects: First, when an application initiates a DNS request to resolve a domain name to a first IP address based on the first network protocol, it can directly bypass the data packet sending path based on the second network protocol on the Windows host side. Instead, it uses a cloud-based protocol conversion module compatible with both protocols to complete the protocol adaptation and conversion. This ensures that data packets originally intended for the server based on the first network protocol corresponding to the application can directly establish an effective communication link with the server after being processed by the cloud-based protocol conversion module. This solves the problem of incompatibility between the second network protocol of the Windows host and the first network protocol of the server, and also ensures the stability and accuracy of DNS requests and subsequent data interactions. Smooth cross-protocol access can be achieved without modifying the underlying protocol of the application or server. Second, it eliminates the need to deploy a professional dual-stack hardware gateway device at the network egress point, reducing the equipment cost for cross-protocol interaction. Moreover, the use of the cloud-based protocol conversion module enables cross-protocol conversion to be unrestricted by the fixed network environment governed by the dual-stack hardware gateway device, meeting the needs of mobile office and improving the flexibility of cross-protocol interaction.

[0012] The above description is only an overview of the technical solution of this application. In order to better understand the technical means of this application and to implement it in accordance with the contents of the specification, and to make the above and other objects, features and advantages of this application more obvious and understandable, the following are specific embodiments of this application. Attached Figure Description

[0013] 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 some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0014] Figure 1 shows a schematic diagram of a cross-protocol interaction system provided in one embodiment of this application; Figure 2 shows a schematic diagram of a cross-protocol interaction system provided in another embodiment of this application; Figure 3 shows a flowchart of a cross-protocol interaction method provided in another embodiment of this application. Detailed Implementation

[0015] Exemplary embodiments of this disclosure will now be described in more detail with reference to the accompanying drawings. While exemplary embodiments of this disclosure are shown in the drawings, it should be understood that this disclosure 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 this disclosure and to fully convey the scope of this disclosure to those skilled in the art. Currently, with the continuous advancement of technology and the increasing complexity of application architectures, it is common to encounter situations where Windows hosts are configured with only a single network protocol, while the corresponding servers of applications use a different network protocol. For example, with the large-scale deployment of IPv6 networks (such as operator 5G core networks, next-generation data centers, etc.), many Windows hosts are now configured with only the single network protocol IPv6, while the servers of many applications (such as industrial control interfaces, legacy e-commerce platforms, enterprise legacy APIs, etc.) still use the IPv4 protocol. To address this inconsistency in network protocols between Windows hosts and servers, cross-protocol interaction technologies are employed. Traditional cross-protocol interaction technologies typically include the following two types: First, system-level IPv4 protocol stack deployment. Specifically, in the "Network Connection Properties" of the Windows host, check "Internet Protocol Version 4 (TCP / IPv4)" or assign an IPv4 address through a DHCP server. This technology relies on a network environment that supports IPv4 forwarding (e.g., the router needs to have dual-stack functionality enabled). However, network communication architectures configured only with IPv6 (i.e., IPv6-only architecture) usually have the IPv4 protocol stack and routing module disabled. Forcing deployment will cause anomalies such as "address conflicts" and "routing table disorder," and may even trigger enterprise security policy alerts. In particular, some industries (such as finance and energy) have explicitly prohibited enabling IPv4 in IPv6-only production environments due to compliance requirements, resulting in a low actual success rate for this technology. Secondly, there is hardware gateway protocol conversion. Specifically, at the network boundary, at the network exit connecting the internal network and the external Internet, a professional dual-stack hardware gateway device is deployed to convert internal IPv6 traffic to IPv4 traffic, while simultaneously converting external IPv4 responses to IPv6 backhaul. This technology relies on dual-stack hardware gateway devices, which are very expensive and fixed at the network egress point. Once a mobile device (such as a laptop) is not in the network managed by the dual-stack hardware gateway device and accesses another IPv6-only network (such as hotel WiFi, exhibition network, etc.) that the dual-stack hardware gateway device cannot manage, the conversion cannot be achieved, thus severely lacking conversion flexibility.

[0016] Research revealed that when the application's server uses a first network protocol, and the Windows host is configured with a single second network protocol different from the first, when the application initiates a DNS request targeting an IP address based on the first network protocol (such as IPv4), it can skip the data packet sending process based on the second network protocol (such as IPv6) on the Windows host. Instead, the data packet originally intended for the server using the first network protocol (such as IPv4) is routed to a cloud protocol conversion module that supports both network protocols. The cloud protocol conversion module performs protocol conversion on the data packet, obtaining a data packet that can directly access the server using the first network protocol (such as IPv4), and then sends the protocol-converted data packet to the server, thereby completing the interaction with the server.

[0017] Based on the above findings, this application provides a cross-protocol interaction system, which includes at least: a kernel filtering module, used to intercept DNS requests initiated by applications in the kernel mode of a Windows host, and when intercepting a target DNS request for resolving a target domain name to a first IP address based on a first network protocol, to control the target application corresponding to the target DNS request to redirect the first data packet originally intended for the target server corresponding to the first IP address to a target port corresponding to a local IP address based on a second network protocol within the Windows host; the second network protocol is a single network protocol configured on the Windows host and is different from the first network protocol. A local traffic forwarding module, used to add a target traffic identifier header to the first data packet to form a target data packet when the target port receives the first data packet, and send the target data packet to a cloud protocol conversion module; the target traffic identifier header includes at least the target domain name. A cloud protocol conversion module, used to extract the target domain name and the first data packet from the target data packet; obtain the first IP address based on the first network protocol corresponding to the target domain name through DNS resolution; convert the first data packet into a second data packet that can access the target server corresponding to the first IP address based on the first IP address, and access the target server based on the second data packet. As can be seen, the solution provided in this application has at least the following two effects: First, when an application initiates a DNS request to resolve a domain name to a first IP address based on the first network protocol, it can directly bypass the data packet sending path based on the second network protocol on the Windows host side. Instead, it uses a cloud-based protocol conversion module compatible with dual protocol stacks to complete the protocol adaptation and conversion. This ensures that data packets originally intended for the server based on the first network protocol corresponding to the application can directly establish an effective communication link with the server after being processed by the cloud protocol conversion module. This solves the problem of incompatibility between the second network protocol of the Windows host and the first network protocol of the server, and also ensures the stability and accuracy of DNS requests and subsequent data interactions. Smooth cross-protocol access can be achieved without modifying the underlying protocol of the application or server. Second, it eliminates the need to deploy professional dual-stack hardware gateway devices at the network egress point, reducing the equipment cost for cross-protocol interaction. Moreover, the use of the cloud-based protocol conversion module enables cross-protocol conversion to be unrestricted by the fixed network environment governed by the dual-stack hardware gateway device, meeting the needs of mobile office and improving the flexibility of cross-protocol interaction.

[0018] Based on the aforementioned cross-protocol interaction system, this application also provides a cross-protocol interaction method. The cross-protocol interaction system and method provided in this application are applicable to Windows hosts, where the Windows host is a host deployed with a Windows system. The Windows system can be flexibly selected based on business needs; for example, the Windows system may include, but is not limited to, Windows 10 / 11, Windows Server 2016 / 2019 / 2022, and Windows systems supporting x64 architecture. The specific type of host can also be flexibly selected based on business needs; for example, the host may include, but is not limited to, personal computers, enterprise IPv6-only servers, mobile office devices, etc. The cross-protocol interaction system and method provided in this embodiment will be described in detail below.

[0019] This application provides a cross-protocol interaction system, as shown in Figure 1. The cross-protocol interaction system provided in this application may include at least: a kernel filtering module 11, a local traffic forwarding module 12, and a cloud protocol conversion module 13.

[0020] The kernel filtering module 11 is used to intercept DNS requests initiated by applications in the kernel mode of the Windows host. When it intercepts a target DNS request that resolves a target domain name to a first IP address based on a first network protocol, it controls the target application corresponding to the target DNS request to redirect the first data packet that was originally to be sent to the target server corresponding to the first IP address to the target port corresponding to the local IP address based on a second network protocol in the Windows host. The second network protocol is a single network protocol configured on the Windows host and is different from the first network protocol.

[0021] The local traffic forwarding module 12 is used to add a target traffic identifier header to the first data packet to form a target data packet when the target port receives the first data packet, and then send the target data packet to the cloud protocol conversion module 13; the target traffic identifier header includes at least the target domain name.

[0022] The cloud protocol conversion module 13 is used to extract the target domain name and the first data packet from the target data packet; obtain the first IP address corresponding to the target domain name based on the first network protocol through DNS resolution; convert the first data packet into a second data packet that can access the target server corresponding to the first IP address based on the first IP address, and access the target server based on the second data packet.

[0023] The following section provides a detailed explanation of the components of a cross-protocol interaction system and the interaction logic between them.

[0024] Kernel Filtering Module 11: Kernel filtering module 11 can be a kernel-level filtering driver developed based on the Windows Filtering Platform (WFP) framework of the Windows host. It runs in the kernel mode of the Windows host, thus achieving kernel-level control within the Windows host without relying on third-party drivers. The main functions of kernel filtering module 11 include the following two aspects: First, filtering and intercepting target DNS requests used to resolve target domain names to a first IP address based on a first network protocol; second, controlling the target application corresponding to the target DNS request to redirect the first data packet originally intended for the target server corresponding to the first IP address to the target port corresponding to the local IP address within the Windows host based on a second network protocol. It should be noted that the first network protocol is the network protocol used by the server corresponding to the application, and the second network protocol is a single network protocol configured by the Windows host, which is different from the first network protocol. The first and second network protocols are determined based on specific business needs, and this embodiment does not limit them. For example, the first network protocol is IPv4, and the second network protocol is IPv6. For example, the first network protocol is IPv6, and the second network protocol is IPv4.

[0025] In some embodiments, as shown in FIG2, the kernel filtering module 11 may include a first interception unit 111 and a matching unit 112, so as to filter and intercept target DNS requests for resolving target domain names to first IP addresses based on the first network protocol through the interaction between the first interception unit 111 and the matching unit 112. Specifically, the first interception unit 111 is used to filter and intercept DNS requests entering the kernel mode of the Windows host based on target filtering information, wherein the target filtering information is the information contained in the DNS request. The matching unit 112 is used to match the domain name in the DNS request with a sample domain name set for each intercepted DNS request; if the DNS request successfully matches a sample domain name in the sample domain name set, the DNS request is determined to be a target DNS request for resolving target domain names to first IP addresses based on the first network protocol, wherein the sample domain names in the sample domain name set are mapped to corresponding first IP addresses based on the first network protocol.

[0026] Specifically, after the kernel filtering module 11 is deployed on the Windows host, the WFP filtering engine is invoked and opened, a custom filtering sublayer is created, and filtering conditions, i.e., target filtering information, are set in the filtering sublayer. The priority of the filtering conditions is set to "high" to ensure that their priority is higher than the system default rules of the Windows host. The target filtering information is the information contained in the DNS request. It is the basis for accurately filtering DNS requests from the network requests in the kernel space. Its specific content can be flexibly selected based on business needs, and this embodiment does not limit it. The target filtering information may include, but is not limited to, at least one of the following: UDP / TCP protocol type, target port number, network protocol version, etc. For example, the target filtering information is "protocol=UDP / TCP, target port=53, IP version=IPv6". 53 is the default DNS port.

[0027] Specifically, the first interception unit 111 filters and intercepts DNS requests entering the kernel mode of the Windows host based on target filtering information. The specific implementation process may include the following steps for each network request entering the kernel mode of the Windows host: detect whether the network request has target filtering information (e.g., protocol=UDP / TCP, target port=53, IP version=IPv6). If it does, determine that the network request is a DNS request and intercept it (e.g., intercept it through a pre-registered callback function). If it does not, determine that the network request is not a DNS request and allow the network request to pass through, so as not to interfere with the normal flow of network requests.

[0028] Specifically, a sample domain name set is deployed within the Windows host. Each sample domain name in the set is mapped to a corresponding IP address based on a first network protocol (such as IPv4). It should be noted that the sample domain name set is continuously updated. Matching unit 112 performs the following steps for each intercepted DNS request: It matches the domain name in the DNS request with the sample domain name set. This matching can include, but is not limited to, at least one of the following: exact match, wildcard match (such as *.v4.example.org), and fuzzy string match (such as ignoring case). If the DNS request successfully matches a sample domain name in the sample domain name set, it indicates that the IP address corresponding to the domain name in the DNS request is an IP address based on a first network protocol (such as IPv4). Therefore, the DNS request is determined as a target DNS request used to resolve the target domain name to a first IP address based on a first network protocol (such as IPv4). If the DNS request does not successfully match a sample domain name in the sample domain name set, it indicates that the IP address corresponding to the domain name in the DNS request is an IP address based on a second network protocol (such as IPv6) configured on the Windows host. Therefore, the DNS request is allowed, ensuring normal access is not interfered with.

[0029] In some embodiments, when a target DNS request for resolving a target domain name to a first IP address based on a first network protocol (such as IPv4) is intercepted, in order to enable interaction between the target application initiating the target DNS request and the target server corresponding to the first IP address, it is necessary to skip the packet sending process of the Windows host based on a second network protocol (such as IPv6). Based on this, as shown in Figure 2, the kernel filtering module 11 may include a second interception unit 113 and a redirection unit 114, to control the target application corresponding to the target DNS request to redirect the first data packet originally intended for the target server corresponding to the first IP address to the target port corresponding to the local IP address within the Windows host based on the second network protocol. Specifically, the second interception unit 113 is used to intercept the DNS response packet of the target DNS request, modify the first IP address based on the first network protocol in the DNS response packet to the local IP address based on the second network protocol, and send the modified DNS response packet to the target application corresponding to the target DNS request, so that the target application, based on the modified DNS response packet, changes the destination address of the first data packet originally intended for the target server corresponding to the first IP address from the first IP address to the local IP address. Redirection unit 114 is used to filter and intercept the first data packet whose destination address is the local IP address in the kernel mode of the Windows host based on the local IP address, and redirect the intercepted first data packet to the target port corresponding to the local IP address based on the second network protocol in the Windows host.

[0030] Specifically, to ensure that data packets are not leaked to the public network and only circulate locally within the Windows host, a target port is set in the Windows host, and this target port is bound to a pre-defined local IP address within the Windows host based on a second network protocol. The local IP address within the Windows host based on a second network protocol (such as IPv6) is a non-internet local IP address, belonging to a private address range of the second network protocol (e.g., fc00:: / 7, a locally unique address range) or a loopback address (e.g., ::1 / 128). Such addresses do not participate in public network routing, are only used for local process communication, and will not be resolved or accessed by internet services. For example, the target port is 8888, and the local IP address is fc00::100.

[0031] Specifically, the second interception unit 113 intercepts the DNS response packet of the target DNS request. The DNS response packet includes the first IP address obtained from the DNS resolution of the target domain name based on the first network protocol (such as IPv4). To bypass the Windows host's packet sending process based on the second network protocol (such as IPv6), the first IP address in the DNS response packet based on the first network protocol (such as IPv4) is modified to a local IP address based on the second network protocol (such as IPv6) (such as fc00::100), and the modified DNS response packet is sent to the target application that initiated the target DNS request. Based on the modified DNS response packet, the target application modifies the destination address of the first data packet originally intended for the target server corresponding to the first IP address (such as 192.168.1.100) based on the first network protocol (such as IPv4) to the local IP address (such as fc00::100), and sends the first data packet. The first data packet enters the kernel mode of the Windows host. The redirection unit 114 filters and intercepts data packets entering the kernel mode of the Windows host based on target filtering conditions (such as IP=fc00::100, IP version=IPv6). The first data packet has a destination address of the local IP address (such as fc00::100) and the destination address is based on a second network protocol (such as IPv6 protocol). The first data packet is then redirected to the target port (such as 8888) corresponding to the local IP address (such as fc00::100) based on the second network protocol in the Windows host.

[0032] Local traffic forwarding module 12: Local traffic forwarding module 12 runs in the user space of the Windows host. Its main function is to receive the first data packet redirected to the target port (the destination address of the first data packet received by the target port is the local IP address based on the second network protocol) and forward the first data packet to the cloud protocol conversion module 13.

[0033] In some embodiments, in order to listen to the target port and acquire the first data packet based on the second network protocol, the local traffic forwarding module 12 may perform the following initialization steps before the cross-protocol interaction system is put into operation: by calling Windows Socket... The API (socket function, specifying the AF_INET6 address family and SOCK_STREAM type) creates a TCP socket object dedicated to the second network protocol (such as IPv6), laying the foundation for communication. Next, the bind function binds this socket to the local IP address (e.g., the local IP address "fc00::100" based on the second network protocol "IPv6") and the target port (e.g., 8888). A crucial operation in this binding process is setting the socket option (e.g., the socket option IPv6_V6ONLY) to 1 using the setsockopt function to enable "second network protocol (e.g., IPv6)-only mode." This aims to completely eliminate the possibility of the target port 8888 being used simultaneously for the first network protocol (e.g., IPv4) connection from the initial setup, avoiding subsequent address and port conflicts at the protocol stack level. Only after all the above configurations are complete will the listen function be called to officially put the socket into passive listening mode. At this point, the Windows host kernel's TCP / IP protocol stack begins to formally accept and queue TCP connection request packets from the second network protocol (such as the IPv6 protocol) that may subsequently arrive and be sent to the target port (such as 8888).

[0034] In some embodiments, when the local traffic forwarding module 12 detects that a first data packet has been received on the target port (e.g., 8888), the accept function establishes a connection with the target application using a second network protocol (e.g., IPv6 protocol) and receives the first data packet (e.g., an IPv6 protocol data packet, which may be, but is not limited to, HTTP / HTTPS requests, TCP data payloads, etc.). Then, it generates a target traffic header corresponding to the first data packet. The target traffic header includes at least the target domain name, used to support the cloud protocol conversion module 13 in resolving the target domain name to the first IP address based on the first network protocol (e.g., IPv4 protocol), i.e., the IP address corresponding to the target application.

[0035] In some embodiments, after generating the target data packet, it is necessary to send the target data packet to the cloud protocol conversion module 13. Based on this, as shown in FIG2, the local traffic forwarding module 12 may include a third sending unit 121 to send the target data packet to the cloud protocol conversion module 13. Specifically, the third sending unit 121 is used to establish a third communication connection with the cloud protocol conversion module 13 based on transport layer security protocol encryption and using a second network protocol as the network layer bearer protocol, and to send the target data packet to the cloud protocol conversion module 13 through the third communication connection. Specifically, the system first reads the local configuration file, which explicitly specifies the IP address and port (e.g., [2001:0db8:4567::abcd:ef12:3456]:9999) of the second network protocol (e.g., IPv6) of the cloud protocol conversion module 13. Based on this configuration, a connection request is initiated, routed to the cloud protocol conversion module 13 via the second network protocol (e.g., IPv6). Immediately after the TCP connection is established, a transport layer security protocol (e.g., TLS 1.3) handshake is performed to negotiate the encryption suite (supporting optional SM4 national cryptographic algorithm) and verify the server certificate. This establishes an end-to-end encrypted communication channel, the third communication connection, ensuring the confidentiality and integrity of all subsequent data transmissions. Then, the target data packet is sent to the cloud protocol conversion module 13 via the third communication connection. It should be noted that a "sliding window" mechanism can be used to control the sending rate when sending the target data packet to avoid network congestion.

[0036] Cloud Protocol Conversion Module 13: The cloud protocol conversion module 13 is essentially a dual-stack cloud server located in the cloud (such as supporting Linux or Windows Server operating systems). Its main function is to extract the target domain name and the first data packet from the target data packet, obtain the first IP address corresponding to the target domain name based on the first network protocol through DNS resolution, convert the first data packet of the second network protocol into the second data packet of the first network protocol, and access the target server according to the converted second data packet, thereby realizing the interaction between the target application and the target server.

[0037] In some embodiments, to ensure data security, the target data packet is encrypted. Therefore, the cloud protocol conversion module 13 needs to perform TLS decryption on the target data packet (e.g., using a pre-set SSL certificate and key), and then extract the target domain name and the first data packet from the decrypted target data packet.

[0038] In some embodiments, the cloud protocol conversion module 13 has a local DNS service. Therefore, the cloud protocol conversion module 13 resolves the target domain name to the first IP address based on the first network protocol (such as IPv4) through the local DNS service. For example, DNS resolution of the target domain name "ipv4-only.old-service.com" yields the first IP address "103.23.45.67" based on the first network protocol "IPv4". This first IP address (such as "103.23.45.67") is the IP address of the target server corresponding to the target application.

[0039] In some embodiments, after obtaining the first IP address, the conversion operation can be initiated. Based on this, as shown in FIG2, the cloud protocol conversion module 13 may include a first conversion unit 131 and a first sending unit 132, so as to realize the conversion of a first data packet of the second network protocol into a second data packet of the first network protocol through the interaction between the first conversion unit 131 and the first sending unit 132, and access the target server according to the converted second data packet of the first network protocol. Specifically, the first conversion unit 131 is used to modify the source address in the header of the first data packet from the IP address of the target application based on the second network protocol to the third IP address of the cloud protocol conversion module 13 based on the first network protocol, and to modify the destination address in the header of the first data packet from the local IP address to the first IP address, forming a second data packet that can access the target server corresponding to the first IP address. The first sending unit 132 is used to establish a first communication connection with the target server based on transport layer security protocol encryption and using the first network protocol as the network layer bearer protocol, and send the second data packet to the target server through the first communication connection.

[0040] Specifically, the first conversion unit 131 modifies the source address in the header of the first data packet from the IP address of the target application based on the second network protocol (such as IPv6) to the third IP address (such as 47.98.123.45) based on the first network protocol (such as IPv4) corresponding to the cloud protocol conversion module 13, and modifies the destination address in the header of the first data packet from the local IP address (such as fc00::100) to the first IP address (such as 103.23.45.67), forming a second data packet capable of accessing the target server corresponding to the first IP address (such as 103.23.45.67). Simultaneously, the TCP / UDP port, sequence number, and acknowledgment number in the transport layer information of the first data packet remain unchanged, and the application layer data in the first data packet remains unchanged. It should be noted that the entire conversion process can be implemented in the kernel mode of the cloud protocol conversion module 13 to ensure that the conversion processing latency is less than 1 millisecond.

[0041] Specifically, after the first conversion unit 131 converts the data packet into the second data packet, the first sending unit 132 sends the second data packet to the target server. The sending process may include: firstly, reading the local configuration file, which explicitly specifies the IP address and port of the target server based on a first network protocol (such as IPv4); then, initiating a connection request based on this configuration; routing the data to the target server via the first network protocol (such as IPv4); and immediately performing a transport layer security protocol (such as TLS 1.3) handshake after the TCP connection is established, negotiating the encryption suite (supporting the national cryptographic algorithm SM4, optional), and verifying the server certificate, ultimately establishing an end-to-end encrypted communication channel, i.e., the first communication connection, to ensure the confidentiality and integrity of all subsequent data transmissions. Then, the second data packet is sent to the target server through the communication connection.

[0042] The cross-protocol interaction system provided in this application intercepts DNS requests initiated by applications in the kernel mode of a Windows host. Upon intercepting a target DNS request used to resolve a target domain name to a first IP address based on a first network protocol, the system controls the target application corresponding to the target DNS request to redirect the first data packet, originally intended for the target server corresponding to the first IP address, to a target port corresponding to a local IP address based on a second network protocol within the Windows host. Then, upon detecting that the target port has received the first data packet, a target traffic identifier header, including at least the target domain name, is added to the first data packet to form a target data packet, which is then sent to a cloud protocol conversion module. Subsequently, the cloud protocol conversion module extracts the target domain name and the first data packet from the target data packet and obtains the first IP address based on the first network protocol corresponding to the target domain name through DNS resolution. Finally, the cloud protocol conversion module converts the first data packet into a second data packet capable of accessing the target server corresponding to the first IP address based on the first IP address, and then accesses the target server based on the second data packet. As can be seen, the solution provided in this application has at least the following two effects: First, when an application initiates a DNS request to resolve a domain name to a first IP address based on the first network protocol, it can directly bypass the data packet sending path based on the second network protocol on the Windows host side. Instead, it uses a cloud-based protocol conversion module compatible with both protocols to complete the protocol adaptation and conversion. This ensures that data packets originally intended for the server based on the first network protocol corresponding to the application can directly establish an effective communication link with the server after being processed by the cloud-based protocol conversion module. This solves the problem of incompatibility between the second network protocol of the Windows host and the first network protocol of the server, and also ensures the stability and accuracy of DNS requests and subsequent data interactions. Smooth cross-protocol access can be achieved without modifying the underlying protocol of the application or server. Second, it eliminates the need to deploy a professional dual-stack hardware gateway device at the network egress point, reducing the equipment cost for cross-protocol interaction. Moreover, the use of the cloud-based protocol conversion module enables cross-protocol conversion to be unrestricted by the fixed network environment governed by the dual-stack hardware gateway device, meeting the needs of mobile office and improving the flexibility of cross-protocol interaction.

[0043] In some embodiments of this application, the target traffic identifier header may further include packet verification data for the cloud protocol conversion module 13 to verify the integrity and security of the target data packet. Based on this, the cloud protocol conversion module 13 is further configured to extract packet verification data from the target data packet, verify the first data packet based on the packet verification, and if the verification passes, execute the step of converting the first data packet into a second data packet capable of accessing the target server corresponding to the first IP address based on the first IP address.

[0044] In some embodiments, packet verification data may include, but is not limited to, at least one of the following: request timestamp (e.g., millisecond level) and packet sequence number (e.g., for reordering). Therefore, verifying the integrity of the first packet typically involves two core checks: sequence number continuity and timestamp validity. Sequence number continuity refers to sorting and verifying the sequence numbers of the received first packets to ensure they are continuous or allow for a small amount of reasonable out-of-order (e.g., temporary out-of-order due to network jitter). If sequence number jumps or missing sequences are found, reordering or retransmission is requested. This is to prevent incomplete information caused by packet loss or out-of-order. The timestamp validity check is to defend against replay attacks and expired requests. It requires that the timestamp carried by each packet must be within a certain range before and after the current system time (e.g., within 10 minutes). This means that the cloud protocol conversion module 13 only accepts recently generated packets and rejects packets that arrive too early or too late, thereby ensuring the timeliness and freshness of the request. These two verifications together constitute the basic guarantee for packet integrity and security.

[0045] In some embodiments, when the packet verification data includes a request timestamp and a packet sequence number, the process of verifying the first packet based on packet verification may include: firstly, checking whether the timestamp carried by the first packet is within the window allowed by the current time of the cloud protocol conversion module 13 (e.g., 10 minutes before or after). If it exceeds this range, it is immediately determined to be invalid, the verification fails, and the first packet is discarded. After the timestamp verification passes, the packet sequence number is further checked: for TCP-like ordered communication, the sequence number is verified to be equal to the expected next value; if so, the verification passes. For UDP-like unordered communication, the sequence number is checked to be within an acceptable sliding window; if so, the verification passes. Only when both the timestamp and the sequence number pass their respective rules of verification and are rearranged as needed will the first packet be marked as verified.

[0046] In some embodiments of this application, upon receiving the second data packet, the target server of the target application may send back a corresponding data response packet to the second data packet, so that the target application can perform corresponding business processing based on the data response packet. Based on this, the cloud protocol conversion module 13 is further configured to receive the data response packet sent by the target server in response to the second data packet, convert the data response packet into a target data response packet that can be sent to the target application based on the IP address of the target application using the second network protocol, and send the target data response packet to the local traffic forwarding module 12. The local traffic forwarding module 12 is further configured to forward the target data response packet to the target application upon receiving it.

[0047] In some embodiments, after performing corresponding data processing based on the second data packet, the target server (e.g., 103.23.45.67:80) forms a corresponding data response packet and sends it back to the cloud protocol conversion module 13. The data response packet is a response packet based on a first network protocol (e.g., IPv4 protocol). Based on this, as shown in FIG2, the cloud protocol conversion module 13 may include a second conversion unit 133 and a second sending unit 134 to complete the protocol conversion and sending of the data response packet. Specifically, the second conversion unit 133 is used to modify the source address in the header of the data response packet from the first IP address of the target server based on the first network protocol to the fourth IP address of the cloud protocol conversion module 13 based on the second network protocol, and to modify the destination address in the header of the data response packet from the third IP address of the cloud protocol conversion module 13 based on the first network protocol to the IP address of the target application based on the second network protocol, thereby forming a target data response packet. The second sending unit 134 is used to establish a second communication connection with the local traffic forwarding module 12 based on the transport layer security protocol encryption and using the second network protocol as the network layer bearer protocol, and to send the target data response packet to the local traffic forwarding module 13 through the second communication connection.

[0048] In some embodiments, the second conversion unit 133 modifies the source address in the header of the data response packet from the first IP address of the target server based on the first network protocol (such as IPv4 protocol) (e.g., 103.23.45.67:80) to the fourth IP address of the cloud protocol conversion module 13 based on the second network protocol (such as IPv6 protocol), and modifies the destination address in the header of the data response packet from the third IP address of the cloud protocol conversion module 13 based on the first network protocol (such as IPv4 protocol) to the IP address of the target application based on the second network protocol (such as IPv6 protocol), thus forming a target data response packet. Then, the second sending unit 134 first reads the local configuration file, which explicitly specifies the local IP address and port of the target port based on a second network protocol (such as IPv6). Based on this configuration, it initiates a connection request, routes the request through the network via the second network protocol (such as IPv6) to the local traffic forwarding module 12, and immediately after the TCP connection is established, performs a transport layer security protocol (such as TLS 1.3) handshake, negotiates the encryption suite (supporting the national cryptographic algorithm SM4, optional), and verifies the server certificate. Finally, an end-to-end encrypted communication channel, i.e., the second communication connection, is established to ensure the confidentiality and integrity of all subsequent data transmissions. Then, the target data response packet is sent to the local traffic forwarding module 12 through the communication connection. Subsequently, the local traffic forwarding module 12, based on the destination address in the target data response packet—"the IP address of the target application based on the second network protocol (such as IPv6)"—sends the target data response packet to the target application for use by the target application.

[0049] Furthermore, one embodiment of this application also provides a cross-protocol interaction method, as shown in FIG3. The cross-protocol interaction method provided in this application embodiment may include at least the following steps 201 to 203.

[0050] 201. In the kernel mode of a Windows host, a DNS request initiated by an application is intercepted. If a target DNS request for resolving a target domain name to a first IP address based on a first network protocol is intercepted, the target application corresponding to the target DNS request is controlled to redirect the first data packet originally intended to be sent to the target server corresponding to the first IP address to the target port corresponding to the local IP address based on a second network protocol within the Windows host. The second network protocol is a single network protocol configured on the Windows host and is different from the first network protocol.

[0051] 202. Upon detecting that the target port has received a first data packet, a target traffic identifier header is added to the first data packet to form a target data packet, and the target data packet is sent to the cloud protocol conversion module; the target traffic identifier header includes at least the target domain name.

[0052] 203. Extract the target domain name and the first data packet from the target data packet through the cloud protocol conversion module, obtain the first IP address corresponding to the target domain name based on the first network protocol through DNS resolution, convert the first data packet into a second data packet that can access the target server corresponding to the first IP address based on the first IP address, and access the target server based on the second data packet.

[0053] The cross-protocol interaction method provided in this application provides at least the following two effects: First, when an application initiates a DNS request to resolve a domain name to a first IP address based on a first network protocol, it can directly bypass the data packet sending path based on the second network protocol on the Windows host side. Instead, it uses a cloud-based protocol conversion module compatible with dual protocol stacks to complete the protocol adaptation and conversion. This ensures that data packets originally intended for the server based on the first network protocol corresponding to the application can directly establish an effective communication link with the server after being processed by the cloud protocol conversion module. This solves the incompatibility problem between the second network protocol of the Windows host and the first network protocol of the server, and also ensures the stability and accuracy of DNS requests and subsequent data interactions. Smooth cross-protocol access can be achieved without modifying the underlying protocol of the application or server. Second, it eliminates the need to deploy professional dual-stack hardware gateway devices at the network egress point, reducing the equipment cost of cross-protocol interaction. Moreover, the use of the cloud protocol conversion module enables cross-protocol conversion to be unrestricted by the fixed network environment governed by the dual-stack hardware gateway device, meeting the needs of mobile office and improving the flexibility of cross-protocol interaction.

[0054] In some embodiments of this application, the specific implementation process of intercepting DNS requests initiated by applications in the kernel mode of the Windows host in step 201 above may include: filtering and intercepting DNS requests in the kernel mode of the Windows host based on target filtering information, wherein the target filtering information is the information contained in the DNS request; then, the cross-protocol interaction method provided in this embodiment may further include the following steps: for each intercepted DNS request, the domain name in the DNS request is matched with the sample domain name set; if the DNS request successfully matches a sample domain name in the sample domain name set, the DNS request is determined as a target DNS request for resolving the target domain name to a first IP address based on the first network protocol, wherein the sample domain names in the sample domain name set are mapped to corresponding IP addresses based on the first network protocol.

[0055] In some embodiments of this application, the specific implementation process of controlling the target application corresponding to the target DNS request to redirect the first data packet originally intended to be sent to the target server corresponding to the first IP address to the target port corresponding to the local IP address based on the second network protocol in step 201 above may include: intercepting the DNS response packet of the target DNS request, modifying the first IP address based on the first network protocol in the DNS response packet to the local IP address based on the second network protocol, and sending the modified DNS response packet to the target application corresponding to the target DNS request, so that the target application modifies the destination address of the first data packet originally intended to be sent to the target server corresponding to the first IP address from the first IP address to the local IP address based on the modified DNS response packet; based on the local IP address, filtering and intercepting the first data packet with the destination address of the local IP address in the kernel mode of the Windows host, and redirecting the intercepted first data packet to the target port corresponding to the local IP address based on the second network protocol in the Windows host.

[0056] In some embodiments of this application, the specific implementation process of step 203, which converts the first data packet into a second data packet capable of accessing the target server corresponding to the first IP address based on the first IP address, and accesses the target server based on the second data packet, may include at least the following steps: modifying the source address in the header of the first data packet from the IP address of the target application based on the second network protocol to the third IP address corresponding to the cloud protocol conversion module based on the first network protocol, and modifying the destination address in the header of the first data packet from the local IP address to the first IP address, thereby forming a second data packet capable of accessing the target server corresponding to the first IP address; establishing a first communication connection with the target server based on transport layer security protocol encryption and using the first network protocol as the network layer bearer protocol, and sending the second data packet to the target server through the first communication connection.

[0057] In some embodiments of this application, after step 203 above, the cross-protocol interaction method provided in this application may further include the following steps: receiving a data response packet fed back by the target server in response to the second data packet; converting the data response packet into a target data response packet that can be sent to the target application based on the IP address of the target application based on the second network protocol; and forwarding the target data response packet to the target application.

[0058] In some embodiments of this application, the specific execution process of converting the data response packet into a target data response packet that can be sent to the target application based on the IP address of the target application using the second network protocol may at least include: modifying the source address in the header of the data response packet from the first IP address of the target server based on the first network protocol to the fourth IP address of the cloud protocol conversion module based on the second network protocol, and modifying the destination address in the header of the data response packet from the third IP address of the cloud protocol conversion module based on the first network protocol to the IP address of the target application based on the second network protocol, thereby forming the target data response packet; then, the specific implementation process of forwarding the target data response packet to the target application may include: establishing a second communication connection with the local traffic forwarding module in the Windows host based on transport layer security protocol encryption and using the second network protocol as the network layer bearer protocol, and sending the target data response packet to the local traffic forwarding module through the second communication connection, so that the local traffic forwarding module can forward the target data response packet to the target application.

[0059] In some embodiments of this application, the process of sending the target data packet to the cloud protocol conversion module in step 202 above may include at least: establishing a third communication connection with the cloud protocol conversion module based on transport layer security protocol encryption and using a second network protocol as the network layer bearer protocol, and sending the target data packet to the cloud protocol conversion module through the third communication connection.

[0060] In some embodiments of this application, the target traffic identifier header further includes data packet verification data. Therefore, the cross-protocol interaction method provided in this application embodiment may further include the following steps: extracting the data packet verification data from the target data packet, verifying the first data packet based on the data packet verification data, and if the verification is successful, performing the step 203 above of converting the first data packet into a second data packet that can access the target server corresponding to the first IP address based on the first IP address.

[0061] In some embodiments of this application, the first network protocol is IPv4 and the second network protocol is IPv6; or, the first network protocol is IPv6 and the second network protocol is IPv4.

[0062] For detailed explanations of the cross-protocol interaction method provided in this application embodiment, please refer to the corresponding detailed explanations of the cross-protocol interaction system embodiment described above, which will not be repeated here.

[0063] Furthermore, one embodiment of this application also provides a computer-readable storage medium, the storage medium including a stored program, wherein, when the program is executed, it controls the device where the storage medium is located to perform the above-described cross-protocol interaction method.

[0064] Furthermore, one embodiment of this application also provides an electronic device, the electronic device comprising: a memory for storing a program; and a processor coupled to the memory for running the program to perform the cross-protocol interaction method described above.

[0065] Furthermore, one embodiment of this application also provides a computer program product, the computer program product comprising: a computer program / computer executable instructions, the computer program / computer executable to perform the above-described cross-protocol interaction method.

[0066] In the above embodiments, the descriptions of each embodiment have different focuses. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions in other embodiments.

[0067] It is understood that the relevant features in the above methods and apparatus can be referenced interchangeably. Furthermore, the terms "first," "second," etc., in the above embodiments are used to distinguish between embodiments and do not represent the superiority or inferiority of any particular embodiment.

[0068] Those skilled in the art will clearly 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.

[0069] The algorithms and displays provided herein are not inherently related to any particular computer, virtual system, or other device. Various general-purpose systems can also be used in conjunction with the teachings herein. The required structure for constructing such systems is apparent from the above description. Furthermore, this application is not directed to any particular programming language. It should be understood that the content of this application described herein can be implemented using various programming languages, and the above description of specific languages ​​is for the purpose of disclosing preferred embodiments of this application.

[0070] In addition, the memory may include non-permanent memory in computer-readable media, such as random access memory (RAM) and / or non-volatile memory, such as read-only memory (ROM) or flash RAM, and the memory includes at least one memory chip.

[0071] Those skilled in the art will understand that embodiments of this application can be provided as methods, systems, or computer program products. Therefore, this application can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, this application can take the form of a computer program product embodied on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0072] This application is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this application. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data cutover device to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data cutover device, create means for implementing the functions specified in one or more blocks of the flowchart illustrations and / or one or more blocks of the block diagrams.

[0073] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data cutover device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means that implement the functions specified in one or more flowcharts and / or one or more block diagrams.

[0074] These computer program instructions may also be loaded onto a computer or other programmable data cutover device to cause a series of operational steps to be performed on the computer or other programmable device to produce a computer-implemented process, such that the instructions, which execute on the computer or other programmable device, provide steps for implementing the functions specified in one or more flowcharts and / or one or more block diagrams.

[0075] In a typical configuration, a computing device includes one or more processors (CPU), input / output interfaces, network interfaces, and memory.

[0076] Memory may include non-persistent memory in computer-readable media, such as random access memory (RAM) and / or non-volatile memory, such as read-only memory (ROM) or flash RAM. Memory is an example of computer-readable media.

[0077] Computer-readable media includes both permanent and non-permanent, removable and non-removable media that can store information using any method or technology. Information can be computer-readable instructions, data structures, modules of programs, or other data. Examples of computer storage media include, but are not limited to, phase-change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, CD-ROM, digital versatile optical disc (DVD) or other optical storage, magnetic tape, magnetic magnetic disk storage or other magnetic storage devices, or any other non-transferable medium that can be used to store information accessible by a computing device. As defined herein, computer-readable media does not include transient computer-readable media, such as modulated data signals and carrier waves.

[0078] It should also be noted that the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such process, method, article, or apparatus. Unless otherwise specified, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes that element.

[0079] Those skilled in the art will understand that embodiments of this application can be provided as methods, systems, or computer program products. Therefore, this application can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, this application can take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0080] The above are merely embodiments of this application and are not intended to limit the scope of this application. Various modifications and variations can be made to this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the scope of the claims of this application.

Claims

1. A cross-protocol interaction system, characterized in that, The system includes: a kernel filtering module, used to intercept DNS requests initiated by applications in the kernel mode of a Windows host, and when intercepting a target DNS request for resolving a target domain name to a first IP address based on a first network protocol, controlling the target application corresponding to the target DNS request to redirect the first data packet originally intended for the target server corresponding to the first IP address to a target port corresponding to a local IP address based on a second network protocol within the Windows host; the second network protocol is a single network protocol configured on the Windows host and is different from the first network protocol; a local traffic forwarding module, used to add a target traffic identifier header to the first data packet to form a target data packet when the target port receives the first data packet, and send the target data packet to a cloud protocol conversion module; the target traffic identifier header includes at least the target domain name; the cloud protocol conversion module, used to extract the target domain name and the first data packet from the target data packet; obtain the first IP address based on the first network protocol corresponding to the target domain name through DNS resolution; convert the first data packet into a second data packet that can access the target server corresponding to the first IP address based on the first IP address, and access the target server based on the second data packet.

2. The system according to claim 1, characterized in that, The kernel filtering module includes: a first interception unit, configured to filter and intercept DNS requests entering the kernel mode of the Windows host based on target filtering information, wherein the target filtering information is the information contained in the DNS request; and a matching unit, configured to match the domain name in the DNS request with a sample domain name set for each intercepted DNS request; if the DNS request successfully matches a sample domain name in the sample domain name set, the DNS request is determined as a target DNS request for resolving the target domain name to a first IP address based on a first network protocol, wherein the sample domain names in the sample domain name set are mapped to corresponding IP addresses based on the first network protocol.

3. The system according to claim 1, characterized in that, The kernel filtering module includes: a second interception unit, configured to intercept the DNS response packet of the target DNS request, modify the first IP address based on the first network protocol in the DNS response packet to a local IP address based on the second network protocol, and send the modified DNS response packet to the target application corresponding to the target DNS request, so that the target application, based on the modified DNS response packet, modifies the destination address of the first data packet originally to be sent to the target server corresponding to the first IP address from the first IP address to the local IP address; and a redirection unit, configured to filter and intercept the first data packet with the destination address of the local IP address in the kernel mode of the Windows host based on the local IP address, and redirect the intercepted first data packet to the target port corresponding to the local IP address based on the second network protocol within the Windows host.

4. The system according to claim 1, characterized in that, The cloud protocol conversion module includes: a first conversion unit, configured to modify the source address in the header of the first data packet from the IP address of the target application based on the second network protocol to the third IP address corresponding to the cloud protocol conversion module based on the first network protocol, and to modify the destination address in the header of the first data packet from the local IP address to the first IP address, thereby forming a second data packet capable of accessing the target server corresponding to the first IP address; and a first sending unit, configured to establish a first communication connection with the target server based on transport layer security protocol encryption and using the first network protocol as the network layer bearer protocol, and to send the second data packet to the target server through the first communication connection.

5. The system according to claim 1, characterized in that, The cloud protocol conversion module is further configured to receive a data response packet from the target server in response to the second data packet, convert the data response packet into a target data response packet that can be sent to the target application based on the IP address of the target application based on the second network protocol, and send the target data response packet to the local traffic forwarding module; the local traffic forwarding module is further configured to forward the target data response packet to the target application upon receiving the target data response packet.

6. The system according to claim 5, characterized in that, The cloud protocol conversion module includes: a second conversion unit, configured to modify the source address in the header of the data response packet from the first IP address of the target server based on the first network protocol to the fourth IP address of the cloud protocol conversion module based on the second network protocol, and to modify the destination address in the header of the data response packet from the third IP address of the cloud protocol conversion module based on the first network protocol to the IP address of the target application based on the second network protocol, thereby forming the target data response packet; and a second sending unit, configured to establish a second communication connection with the local traffic forwarding module based on transport layer security protocol encryption and using the second network protocol as the network layer bearer protocol, and to send the target data response packet to the local traffic forwarding module through the second communication connection.

7. The system according to any one of claims 1-6, characterized in that, The local traffic forwarding module includes: a third sending unit, configured to establish a third communication connection with the cloud protocol conversion module based on transport layer security protocol encryption and using a second network protocol as the network layer bearer protocol, and to send the target data packet to the cloud protocol conversion module through the third communication connection; and / or, if the target traffic identifier header further includes data packet verification data, then the cloud protocol conversion module is further configured to extract the data packet verification data from the target data packet, verify the first data packet based on the data packet verification data, and if the verification is successful, execute the step of converting the first data packet into a second data packet that can access the target server corresponding to the first IP address based on the first IP address; and / or, the first network protocol is IPv4 and the second network protocol is IPv6; or, the first network protocol is IPv6 and the second network protocol is IPv4.

8. A cross-protocol interaction method, characterized in that, The method includes: intercepting DNS requests initiated by applications in kernel mode on a Windows host; and, upon intercepting a target DNS request for resolving a target domain name to a first IP address based on a first network protocol, controlling the target application corresponding to the target DNS request to redirect a first data packet originally intended for the target server corresponding to the first IP address to a target port corresponding to a local IP address based on a second network protocol within the Windows host; the second network protocol is a single network protocol configured on the Windows host and is different from the first network protocol; upon detecting that the target port has received a first data packet, adding a target traffic identifier header to the first data packet to form a target data packet, and sending the target data packet to a cloud protocol conversion module; the target traffic identifier header includes at least the target domain name; extracting the target domain name and the first data packet from the target data packet through the cloud protocol conversion module, obtaining the first IP address based on the first network protocol corresponding to the target domain name through DNS resolution, converting the first data packet into a second data packet capable of accessing the target server corresponding to the first IP address based on the first IP address, and accessing the target server based on the second data packet.

9. A computer-readable storage medium, characterized in that, The storage medium includes a stored program, wherein the program, when running, controls the device where the storage medium is located to execute the cross-protocol interaction method of claim 8.

10. An electronic device, characterized in that, The electronic device includes: a memory for storing a program; and a processor coupled to the memory for running the program to perform the cross-protocol interaction method of claim 8.

11. A computer program product, characterized in that, The computer program product includes: a computer program / computer-executable instructions, wherein the computer program / computer-executable instructions are the cross-protocol interaction method of claim 8.

Images