Private cloud access method and device without firewall penetration

Abstract

The invention discloses a private cloud access method and device without firewall penetration, in an operator mobile network, a relay gateway device is established, the mobile network and a home private cloud network are configured with respective ip / didr addresses, and the mobile device of a user and the home private cloud network are connected through a relay gateway. In a relay gateway, a private communication protocol and a DPDK technology are used, and communication connection between mobile equipment and a home private cloud is directly processed in a user mode, so that efficient communication is realized. And meanwhile, client software is installed on the home private cloud to process a private communication protocol message, and a TUN virtual network card is created to process an original IP data packet, so that the functions of packing, unpacking, forwarding and the like are realized. The relay gateway is directly established in the mobile network of the operator, and all requests of the user do not need to pass through a third-party network, so that the whole communication process has higher credibility, stability and safety, and the privacy of the user is effectively protected.

Description

Technical Field

[0001] The present invention relates to the field of network communication technologies, and specifically to a method and device for accessing a private cloud without firewall penetration. Background Art

[0002] Compared with public clouds, due to the characteristics of better security, privacy, and pertinence of private clouds, more and more users choose to build their own home private clouds. Family members hope to seamlessly access the home private cloud through the mobile network of their mobile phones regardless of their location. However, the user's mobile devices such as mobile phones are located in the mobile network, while the private cloud is located in the home network. On the one hand, due to the NAT (Network Address Translation) + firewall mechanism, the services listening on the IP in the home private cloud network cannot be accessed by the external network, that is, there is no mapping from the internal IP + internal listening port to the external IP + external port, and the mobile network cannot directly access the home network. On the other hand, the network IP addresses of mobile terminals such as mobile phones are dynamically allocated by the operator network, and it is difficult for the home network to maintain a connection with the mobile phone through a fixed IP address.

[0003] In order to solve the problem that it is difficult for user mobile devices to directly access the home private cloud through the mobile network, it is necessary to rely on the intranet penetration technology to enable external network devices to communicate with devices located behind the NAT. Most existing methods, such as the patent "An Intranet Penetration Method and System Based on TCP Socket and Improved Heartbeat Mechanism", in order to achieve intranet penetration, need to rely on a server with a public IP address as a relay, and both communication devices need to install corresponding clients to establish an end-to-end TCP connection to communicate with devices located behind the NAT. However, since the entire communication process needs to pass through a third-party public network relay server, the security of user privacy cannot be guaranteed, so it is not applicable to the scenario where mobile devices access the home private cloud through the mobile network.

[0004] Therefore, there is a need for a method and device for accessing a private cloud without firewall penetration. Summary of the Invention

[0005] The present invention aims to solve the problem of efficient and secure communication between mobile devices and home private clouds, and proposes an efficient access method based on UDP without firewall penetration. By building a dedicated relay gateway and home router in the operator's mobile network and home private cloud, the communication efficiency between mobile devices and home private clouds is improved and the security of user privacy is protected.

[0006] According to one aspect of the present application, a method for accessing a private cloud without firewall penetration is provided, which includes: S1. Establish an operator relay gateway for connecting the operator's mobile network and the home private cloud network; S2. Create a private protocol format to enable communication between the relay gateway and the home router; S3. The relay gateway receives an access request from a mobile device to access the home private cloud network through the IP address of the home local area network and processes the request message; S4. Install client software on the home router to receive messages sent from the relay gateway or devices in the home private cloud local area network, process them, and forward them to devices in the local area network or the relay gateway; S5. The third network card of the relay gateway receives the message sent from the home router, and the relay gateway unpacks the original message.

[0007] Preferably, the step S1 includes: configuring the forwarding policy of the user plane function in the operator's mobile network to forward all messages accessing the home private cloud network to the relay gateway, and the user plane function copies the radius message containing the mobile device's IP address to the relay gateway in real time.

[0008] Preferably, the step S2 includes: S21. Define a private protocol format fmfp, where the first byte in its message represents the protocol version for compatibility management of fmfp to ensure that both parties follow the same set of rules for communication; S22. The second to seventh bytes are protocol identifiers, and their values are fixed as fmfpv1 to distinguish different communication protocol categories; S23. The eighth byte is the packet type, used to identify different packet types in the fmfp protocol format, where "F" represents a proxy protocol packet sent from the client to the mobile device side, "C" represents a proxy protocol packet sent from the mobile device side to the client, and "H" represents a heartbeat packet sent from the client to the relay gateway; S24. The protocol formats corresponding to different packet types are not exactly the same. If the packet type is "F" or "C", it is used for communication between the mobile device and the client software; if the packet type is "H", it is used for the client software to send a heartbeat to the relay gateway.

[0009] Preferably, step S3 includes: S31. The first network card of the relay gateway receives an IP request from the mobile device, sends the request message to the message encapsulation module, and starts to process the request message; S32. The message encapsulation module of the relay gateway decodes the received data packet, extracts the destination address field in the IPv4 header, compares the extracted destination address with the preset home private cloud local area network segment. If the destination address does not belong to the home private cloud local area network segment, the data packet is discarded; S33. The relay gateway analyzes the header information of the received data packet, extracts the source IP address, queries the device registry maintained by the message encapsulation module using the extracted source IP, finds the matching entry, and retrieves the corresponding device ID and client ID; S34. The relay gateway uses the information of the client ID matching the client's IP and port to communicate with the target client; S35. Write the retrieved device ID and client ID into the corresponding fields of the private protocol fmfp, set the data packet type field to "C", and encapsulate the processed fmfp into a UDP data packet; S36. After the UDP data packet is encapsulated, process the IP layer, set the destination IP address to the client IP, the destination port to the client software listening port, the source IP address to the relay gateway's IP address, and the source port to the corresponding port of the message encapsulation module; S37. Calculate the checksum of UDP and IP to ensure the reliability of communication, and encapsulate the data packet into an Ethernet frame and send it to the third network card, which is sent by the third network card to the home private cloud.

[0010] Preferably, step S4 includes: S41. The client software in the home router creates and starts a TUN virtual network card and assigns an IP address to it; S42. The heartbeat sending module is installed in the client software. The data packet type of the heartbeat packet in the private protocol fmfp is "H". Write information such as the client ID and listening port into the fmfp. Set the target IP to the relay gateway's IP address, the source IP to the wan port address of the home router, and use a timer to trigger the task of sending heartbeat packets every two minutes, responsible for constructing heartbeat packets and sending them to the relay gateway to ensure that the client software and the relay gateway maintain a connected state; S43. The home router receives IP packets from the relay gateway and devices in the local area network. If the home router's wan port receives a packet, call the local area network forwarding process; if the home router's lan port receives a packet, call the relay gateway forwarding process.

[0011] Preferably, in step S43, when the WAN port of the home router receives a packet, the local area network forwarding process is invoked, including: the packet disassembling module of the client software parses and processes the received original packet; the packet disassembling module disassembles the original packet into an IP packet, and determines whether the packet protocol type is fmfpv1 according to the format of the private protocol. If not, the packet is discarded; at the same time, the position and length of the client ID field are determined. If the obtained client ID does not match the local client ID, the packet is discarded; according to the format of the private protocol, the position and length of the device ID field in the packet are extracted, and in the client software, the mapping relationship between the source IP address and the device ID is saved in the form of a table, named the device query table; it is checked whether the source IP address already exists in the device query table. If the source IP arrives at the home router for the first time, a routing entry for this source address is added to the TUN virtual network card; the local area network forwarding module of the home router creates a raw socket using the RAW Socket interface. The socket allows the application to directly interact with the network layer, send and receive IP data packets, and the IP data packets are sent to the local area network device through the RAW Socket; the local area network forwarding module first checks the destination IP address to determine whether an Address Resolution Protocol request needs to be made. If the destination IP address is within the same local area network, the local area network forwarding module will send an Address Resolution Protocol request to obtain the destination MAC address; after obtaining the MAC address of the destination IP, the local area network forwarding module fills the MAC address into the header of the Ethernet frame to ensure that the data packet can be correctly routed in the local area network, determines the next-hop address of the data packet according to the routing table, and sends the data packet to the corresponding network interface.

[0012] Preferably, in step S43, when the LAN port of the home router receives a packet, the relay gateway forwarding process is invoked, including: the packet encapsulating module of the client software parses and processes the received original packet; the packet encapsulating module parses out the destination IP address from the packet, searches the device query table, matches the parsed destination IP with the IP in the device query table, and obtains the matching device ID; the packet encapsulating module encapsulates the original IP data packet into a UDP data packet using the private protocol fmfp, writes the device ID into the device ID field of the fmfp, writes the local client ID of the client software into the client ID field of the fmfp, sets the data packet type field of the fmfp to "F", and finally sends out the data packet.

[0013] Preferably, step S5 includes: S51. The third network card of the relay gateway receives an IP request from the home router, sends the request message to the message disassembling module of the relay gateway, and starts to respond to the processing of the original message; S52. The message disassembling module locates the position and length of the device ID field in the message according to the format of the private protocol, extracts the device ID information, and looks up the device registry saved in the relay gateway according to the device ID to obtain the client ID and the device IP address; S53. Compare the obtained client ID with the data in the client ID field in the message. If the two are different, discard the message; S54. The message disassembling module disassembles the received message to obtain the original IP packet sent by the IoT terminal device; S55. After disassembling to obtain the original IP data packet, the message disassembling module sets the destination IP address in the IP packet to the device IP address obtained in S52; S56. Calculate the checksum of the IP to ensure the reliability of communication, and look up the mobile device MAC address cache. If the mobile device MAC address cannot be found through the destination IP, send it to the default gateway, and finally send it to the mobile device in the mobile network by the first network card.

[0014] According to another aspect of the present application, there is also provided a private cloud access device without firewall penetration, which is characterized by including: a relay gateway establishment module for establishing an operator relay gateway to connect the operator mobile network and the home private cloud network; a protocol format creation module for creating a private protocol format to realize communication between the relay gateway and the home router; a relay gateway request message processing module for the relay gateway to receive an access request from a mobile device to access the home private cloud network through the IP address of the home local area network and process the request message; a client software processing module for installing client software on the home router to receive messages sent from the relay gateway or devices in the home private cloud local area network, process them, and forward them to devices in the local area network or the relay gateway; a relay gateway unpacking module for the relay gateway to unpack the original message sent from the home router.

[0015] The following technical effects can be achieved by using the present invention:

[0016] The present invention uses DPDK network technology to take over the first network card and the second network card through DPDK on the relay gateway. The UDP request packets received by the relay gateway will be directly sent to the packet encapsulation module and the packet deconstruction module for processing, improving the communication efficiency and supporting a large number of users to be online simultaneously. Meanwhile, the established relay gateway and home router enable mobile devices to access the home private cloud without penetrating the firewall, and can maintain the real-time IP addresses of the mobile devices and the home private cloud devices. Mobile devices do not need to install any client software, realizing the seamless access of users. The relay gateway is established in the operator's mobile network, and the client software is installed on the home router of the user's private cloud. The entire communication process does not need to go through any other third party. Therefore, the present invention can improve the security of user privacy. BRIEF DESCRIPTION OF THE DRAWINGS

[0017] By describing the embodiments of the present application in more detail in conjunction with the drawings, the above and other objects, features, and advantages of the present application will become more obvious. The drawings are used to provide a further understanding of the embodiments of the present application, and constitute a part of the specification. Together with the embodiments of the present application, they are used to explain the present application, and do not constitute a limitation to the present application. In the drawings, the same reference numerals generally represent the same components or steps.

[0018] Figure 1 It is a flowchart of a method for accessing a private cloud without firewall penetration according to an embodiment of the present application.

[0019] Figure 2 It is a flowchart of the client software in the method for accessing a private cloud without firewall penetration according to an embodiment of the present application.

[0020] Figure 3 It is a diagram of the private protocol format (packet type is "F" or "C") of the method for accessing a private cloud without firewall penetration according to an embodiment of the present application.

[0021] Figure 4 It is a diagram of the private protocol format (packet type is "H") of the method for accessing a private cloud without firewall penetration according to an embodiment of the present application.

[0022] Figure 5 It is a system structure diagram of the method for accessing a private cloud without firewall penetration according to an embodiment of the present application. DETAILED DESCRIPTION OF THE EMBODIMENTS

[0023] The following will detail various exemplary embodiments, features, and aspects of the present application with reference to the drawings. The same reference numerals in the drawings represent elements with the same or similar functions. Although various aspects of the embodiments are shown in the drawings, unless otherwise specified, the drawings do not have to be drawn to scale.

[0024] The word “exemplary” is used exclusively herein to mean “serving as an example, example, or illustration.” Any embodiment described herein as “exemplary” is not necessarily to be construed as preferred or advantageous over other embodiments.

[0025] In addition, in order to better illustrate the present application, numerous specific details are given in the following specific embodiments. It should be understood by those skilled in the art that the present application can also be implemented without certain specific details. In some examples, methods, means, components and circuits well known to those skilled in the art are not described in detail in order to highlight the subject matter of the present application.

[0026] In addition, the terms "first" and "second" are used for descriptive purposes only and should not be understood as indicating or implying relative importance or implicitly indicating the number of the indicated technical features. Thus, a feature defined as "first" or "second" may explicitly or implicitly include one or more of the features. In the description of this application, the meaning of "plurality" is two or more, unless otherwise clearly and specifically defined.

[0027] In order to solve the problem that it is difficult for users' mobile devices to directly access the home private cloud through the mobile network, it is necessary to use the intranet penetration technology to enable external network devices to communicate with devices behind NAT. Use Data Plane Development Kit (DPDK) and TUN virtual network device technology to build gateways and routers for home private cloud access without penetrating firewalls. Make the entire communication process more reliable, stable and secure, thereby effectively protecting user privacy.

[0028] Based on this, a private cloud access method and device without firewall penetration is proposed. Using Data Plane Development Kit (DPDK) and TUN virtual network device technology, a gateway and router for home private cloud access are built without firewall penetration. DPDK is a data plane development kit that can reduce multiple copies of messages in user space and application space, thereby improving the performance and efficiency of gateway devices. TUN is a virtual network device that allows applications to directly process raw IP packets and is suitable for home routers.

[0029] Based on this, a private cloud access method and device without firewall penetration is proposed. Using Data Plane Development Kit (DPDK) and TUN virtual network device technology, a gateway and router for home private cloud access are built without firewall penetration. DPDK is a data plane development kit that can reduce multiple copies of messages in user space and application space, thereby improving the performance and efficiency of gateway devices. TUN is a virtual network device that allows applications to directly process raw IP packets and is suitable for home routers.

[0030] Therefore, a private cloud access method without firewall penetration, such as Figure 1 shown, has the following basic process. The private cloud access method without firewall penetration according to the embodiments of the present application includes: S1. Establish an operator relay gateway for connecting the operator's mobile network and the home private cloud network; S2. Create a private protocol format to enable communication between the relay gateway and the home router; S3. The relay gateway receives an access request from a mobile device to access the home private cloud network through the IP address of the home local area network and processes the request message; S4. Install client software on the home router to receive messages sent from the relay gateway or devices in the home private cloud local area network, process them, and forward them to devices in the local area network or the relay gateway; S5. The third network card of the relay gateway receives the message sent from the home router, and the relay gateway unpacks the original message.

[0031] In the embodiments of the present application, in step S1, an operator relay gateway is established for connecting the operator's mobile network and the home private cloud network. It should be understood that the relay gateway can convert data of different protocols. The mobile network and the home private cloud network may use different communication protocols. The relay gateway enables smooth communication between the two by converting protocols, thereby realizing data transmission and exchange. The relay gateway can forward data according to the network traffic situation. In the case of large network traffic, the relay gateway can cache and optimize data packets and then forward them to avoid network congestion and improve network performance and stability. The present application is applicable to mobile networks such as 4G, 5G, and future 6G of operators;

[0032] Specifically, the user plane function (UPF) is a component of the operator's mobile core network infrastructure system. The network traffic accessed by the user's mobile device through the base station will first be sent to the UPF and then forwarded by the UPF. Configure the forwarding policy of the UPF in the operator's mobile network to forward all messages accessing the home private cloud network to the relay gateway, and the UPF copies the radius message containing the mobile device's IP address to the relay gateway in real time.

[0033] A message encapsulation module, a message deconstruction module, and a device registration module are installed on the relay gateway; three physical network cards are equipped on the relay gateway. The DPDK is used to take over the first network card and the third network card of the relay gateway. Among them, the first network card accesses the operator's mobile network and provides data forwarding services for mobile devices. The first network card is connected to the message encapsulation module on the relay gateway and is responsible for processing the IP request messages of mobile devices so that they can be forwarded to the home private cloud; the third network card accesses the operator's intercity network and provides data forwarding services for the home private cloud network. The third network card is connected to the message deconstruction module on the relay gateway and is responsible for processing the response messages sent by the home router so that they can be forwarded to the mobile devices in the mobile network; the second network card of the relay gateway is a management network card and uses the Linux default driver and kernel protocol stack for device registration services. The relay gateway is connected to the authentication server through the second network card. The HTTP service listens on the 8000 port of the second network card and is connected to the device registration module on the relay gateway.

[0034] Client software is installed on the home router of the private cloud. The client software is used to process the messages received from the relay gateway, encapsulate the messages sent from the home private cloud to mobile devices, and send heartbeat packets to the relay gateway, etc. When a new user joins, the binding relationship between the mobile device of the user and the home private cloud is registered through the authentication server. The client software on each mobile device and home router maintains a uniquely identified ID. The authentication server registers the device ID and client ID of the user into the mapping table stored in the relay gateway, called the device registration table. The matching relationship is represented in the form of a triple (device IP, device ID, client ID) and is maintained by the message encapsulation module on the relay gateway.

[0035] In the embodiment of the present application, in step S2, a private protocol format is created to implement communication between the relay gateway and the home router. It should be understood that the private protocol can integrate encryption and authentication mechanisms, encrypt the transmitted data, and authenticate both communication parties. This can effectively prevent the data from being eavesdropped, tampered with, or forged during transmission, ensuring the security and integrity of the data. If a standard public protocol is used, complex protocol conversions may be required between the relay gateway and the home router. The private protocol can unify the protocol standards of both communication parties, reduce the complexity and overhead of protocol conversion, and simplify the communication process.

[0036] Specifically, the step S2 includes: S21. Define a private protocol format fmfp. The first byte in its packet represents the protocol version, which is used for the compatibility management of fmfp to ensure that both parties follow the same set of rules for communication; S22. The second to the seventh bytes are protocol identifiers, and their values are fixed as fmfpv1, which is used to distinguish different communication protocol categories; S23. The eighth byte is the packet type, which is used to identify different packet types in the fmfp protocol format. Among them, "F" represents a proxy protocol packet sent from the client to the mobile device side, "C" represents a proxy protocol packet sent from the mobile device side to the client, and "H" represents a heartbeat packet sent from the client to the relay gateway; S24. The protocol formats corresponding to different packet types are not exactly the same. If the packet type is "F" or "C", it is used for the communication between the mobile device and the client software; if the packet type is "H", it is used for the client software to send a heartbeat to the relay gateway.

[0037] Further, if the packet type is "F" or "C", it is used for the communication between the mobile device and the client software. Figure 3 FIG. is a diagram of the private protocol format of the private cloud access method without firewall penetration according to an embodiment of the present application (packet type is "F" or "C"). As Figure 3 shown, its packet format is as follows: The ninth to the sixteenth bytes are the client ID, which is used to uniquely identify the client software on a home router; the seventeenth to the twenty-fourth bytes are the device ID, which is used to uniquely identify a mobile device in the operator network; starting from the twenty-fifth byte to the end of the entire packet is the original IP packet. Go to step S3

[0038] Furthermore, if the packet type is "H", it is used for the client software to send a heartbeat to the relay gateway. Figure 4 FIG. is a diagram of the private protocol format of the private cloud access method without firewall penetration according to an embodiment of the present application (packet type is "H"). As Figure 4As shown, the format of the data packet is as follows: the 9th to 16th bytes are the client ID, which is used to uniquely identify the client software on a home router; if the data packet is actively sent by the client software to the relay gateway, the 17th to 24th bytes are the heartbeat instruction code, and its value is 0; if the data packet is a heartbeat response of the relay gateway to the client software, the 17th to 24th bytes are the response code, and if the response is successful, its value is 200, otherwise its value is 400; the 25th to 26th bytes are the client listening port, which is used to identify the specific port where the client software receives the heartbeat response; the 27th to 28th bytes are the compatible protocol version, which is used for the relay gateway to identify the protocol version in use, so as to correctly parse and process the heartbeat data packet; the 29th to 30th bytes are the heartbeat sequence number, which is used to track and manage the sending and receiving status of the heartbeat message. If the heartbeat sequence number does not arrive as expected, the heartbeat connection may have been disconnected; starting from the 31st byte is the custom content, which is used for future expansion and custom authentication, and then go to step S3.

[0039] In an embodiment of the present application, in step S3, the relay gateway receives an access request from a mobile device to access a home private cloud network through the IP address of a home LAN, and processes the request message. It should be understood that the relay gateway is located at the edge access layer of different networks and can connect the home LAN with the home private cloud network. The mobile device initiates an access request through the home LAN, and the relay gateway is responsible for forwarding the request from the home LAN to the home private cloud network to achieve data transmission and communication between different networks. The home LAN and the home private cloud network may use different communication protocols. The relay gateway can convert the IP protocol data of the home LAN into a protocol format that can be recognized and processed by the home private cloud network, thereby ensuring that data can be smoothly transmitted between the two networks.

[0040] Specifically, step S3 includes: S31. The first network card of the relay gateway receives an IP request from the mobile device, sends the request message to the message encapsulation module, and starts to respond to and process the request message; S32. The message encapsulation module of the relay gateway decodes the received data packet, extracts the destination address field in the IPv4 header, compares the extracted destination address with the preset home private cloud local area network segment. If the destination address does not belong to the home private cloud local area network segment, the data packet is discarded; S33. The relay gateway parses the header information of the received data packet, extracts the source IP address, uses the extracted source IP to query in the device registry maintained by the message encapsulation module, finds the matching entry, and retrieves the corresponding device ID and client ID; S34. The relay gateway uses the information of the client ID to match the IP and port of the client to communicate with the target client; S35. Write the retrieved device ID and client ID into the corresponding fields of the private protocol fmfp, set the data packet type field to "C", and encapsulate the processed fmfp into a UDP data packet; S36. After the UDP data packet is encapsulated, process the IP layer, set the destination IP address to the client IP, the destination port to the client software listening port, the source IP address to the relay gateway IP address, and the source port to the corresponding port of the message encapsulation module; S37. Calculate the checksum of UDP and IP to ensure the reliability of communication, and encapsulate the data packet into an Ethernet frame and send it to the third network card, which is sent by the third network card to the home private cloud.

[0041] In the embodiment of the present application, in step S4, a client software is installed on the home router, which is used to receive the messages sent by the devices in the relay gateway or the home private cloud local area network, and after processing, forward them to the devices or the relay gateway in the local area network. It should be understood that the client software on the home router can receive the data messages from the relay gateway. These data messages may be the requests for the mobile device to access the home private cloud network forwarded by the relay gateway, or the data obtained by the relay gateway from the home private cloud network. After receiving these data, the client software can pass them to the target devices in the home local area network, such as NAS, smart TV, etc., to achieve data reception. The client software can also receive the messages sent by the devices in the home private cloud local area network. These devices may need to send data to the relay gateway for further transmission to the mobile device or other networks. After processing these messages, the client software forwards them to the relay gateway, thereby realizing data forwarding and transmission. The client software can perform encapsulation and decapsulation operations on the data. During data transmission, the client software can encapsulate the original data into a packet format suitable for transmission, such as adding message headers, tails, etc. information; when receiving data, it can decapsulate the data packet and extract the original data content for the devices in the home local area network to process and use.

[0042] Specifically, Figure 2 is a flowchart of client software in the private cloud access method without firewall penetration according to an embodiment of the present application. As Figure 2 shown, the step S4 includes: S41. The client software in the home router creates and starts a TUN virtual network card and assigns an IP address to it; S42. A heartbeat sending module is installed in the client software. The data packet type of the private protocol fmfp of the heartbeat packet is "H". Information such as the client ID and listening port is written into fmfp. The destination IP is set to the IP address of the relay gateway, and the source IP is set to the wan port address of the home router. A timer is used to trigger the task of sending heartbeat packets every two minutes, which is responsible for constructing heartbeat packets and sending them to the relay gateway to ensure that the client software and the relay gateway maintain a connected state; S43. The home router receives IP packets from the relay gateway and devices in the local area network. If the home router receives a packet through the wan port, it calls the local area network forwarding process; if the home router receives a packet through the lan port, it calls the relay gateway forwarding process.

[0043] Further, for the step S43, when the home router receives a packet through the wan port and calls the local area network forwarding process, it includes: The packet disassembling module of the client software parses and processes the received original packet; the packet disassembling module disassembles the original packet into an IP packet, and determines whether the packet protocol type is fmfpv1 according to the format of the private protocol. If not, the packet is discarded; at the same time, the position and length of the client ID field are determined. If the obtained client ID does not match the local client ID, the packet is discarded; according to the format of the private protocol, the position and length of the device ID field in the packet are extracted, and in the client software, the mapping relationship between the source IP address and the device ID is saved in the form of a table, named the device query table; it is checked whether the source IP address already exists in the device query table. If this source IP arrives at the home router for the first time, a routing entry for this source address is added to the TUN virtual network card; the local area network forwarding module of the home router creates a raw socket using the RAW Socket interface. The socket allows the application program to directly interact with the network layer, send and receive IP data packets, and the IP data packets are sent to the local area network device through RAWSocket; the local area network forwarding module first checks the destination IP address to determine whether an address resolution protocol request needs to be made. If the target IP address is in the same local area network, the local area network forwarding module will send an address resolution protocol request to obtain the target MAC address; after obtaining the MAC address of the target IP, the local area network forwarding module fills the MAC address into the header of the Ethernet frame to ensure that the data packet can be correctly routed in the local area network, determines the next hop address of the data packet according to the routing table, and sends the data packet to the corresponding network interface.

[0044] Furthermore, in step S43, when the LAN port of the home router receives a message and invokes the relay gateway forwarding process, it includes: The message encapsulation module of the client software parses and processes the received original message; the message encapsulation module extracts the destination IP address from the message, looks up the device query table, matches the parsed destination IP with the IPs in the device query table, and obtains the matching device ID; the message encapsulation module encapsulates the original IP data packet into a UDP data packet using the private protocol fmfp, writes the device ID into the device ID field of fmfp, writes the client ID of the local client software into the client ID field of fmfp, sets the data packet type field of fmfp to "F", and finally sends out the data packet.

[0045] In the embodiment of the present application, in step S5, the third network card of the relay gateway receives the message sent by the home router, and the relay gateway unpacks the original message. It should be understood that the unpacking process can extract key information in the message, such as the source IP address, destination IP address, port number, etc. These information are very important for the relay gateway because they determine where the data packet should be forwarded. By unpacking, the relay gateway can determine the source and destination of the data packet, and thus decide the next processing flow of the data packet. For example, if the data packet is sent to a specific device or network, the relay gateway needs to make corresponding routing selections based on this information. During the data transmission process, it may be necessary to encapsulate and de-encapsulate the data packet. The unpacking process allows the relay gateway to remove the original encapsulation information and then re-encapsulate the data packet as needed for transmission in different network environments.

[0046] Specifically, step S5 includes: S51. The third network card of the relay gateway receives an IP request from the home router, sends the request message to the message disassembling module of the relay gateway, and starts to respond to the processing of the original message; S52. The message disassembling module looks up the position and length of the device ID field in the message according to the format of the private protocol, extracts the device ID information, looks up the device registry saved in the relay gateway according to the device ID, and obtains the client ID and the device IP address; S53. Compares the obtained client ID with the data in the client ID field in the message, and if the two are different, discards the message; S54. The message disassembling module disassembles the received message to obtain the original IP packet sent by the IoT terminal device; S55. After disassembling to obtain the original IP data packet, the message disassembling module sets the destination IP address in the IP packet to the device IP address obtained in S52; S56. Calculates the checksum of the IP to ensure the reliability of communication, and looks up the mobile device MAC address cache. If the mobile device MAC address cannot be found through the destination IP, it is sent to the default gateway, and finally all are sent by the first network card to the mobile device in the mobile network.

[0047] In summary, the present invention aims to solve the problem of efficient and secure communication between mobile devices and home private clouds, and proposes an efficient access method based on UDP without firewall penetration. In the operator's mobile network, a relay gateway device is established. Both the mobile network and the home private cloud network are configured with their respective IP / didr addresses. The relay gateway connects the user's mobile device and the home private cloud network. In the relay gateway, a private communication protocol and DPDK technology are used to directly process the communication connection between the mobile device and the home private cloud in the user space, realizing efficient communication. At the same time, client software is installed on the home private cloud to process private communication protocol packets, and a TUN virtual network card is created to process original IP data packets, realizing functions such as packet encapsulation, decapsulation, and forwarding. Since the relay gateway is directly established in the operator's mobile network, all requests of the user do not need to pass through a third-party network, making the entire communication process have higher credibility, stability, and security, thus effectively protecting user privacy.

[0048] By using DPDK network technology, the present invention takes over the first network card and the third network card on the relay gateway through DPDK. The UDP request packets received by the relay gateway will be directly sent to the packet encapsulation module and the packet decapsulation module for processing, improving communication efficiency and supporting a large number of users to be online simultaneously. At the same time, the established relay gateway and home router enable the mobile device to access the home private cloud without penetrating the firewall, can maintain the real-time IP addresses of the mobile device and the home private cloud device, and the mobile device does not need to install any client software, realizing the seamless access of users. The relay gateway is established in the operator's mobile network, and at the same time, the client software is installed on the home router of the user's private cloud. The entire communication process does not need to pass through other third parties. Therefore, the present invention can improve the security of user privacy.

[0049] The embodiments of the present disclosure have been described above. The above description is exemplary and not exhaustive, and is not limited to the disclosed embodiments. Many modifications and variations are obvious to those of ordinary skill in the art in the technical field without departing from the scope and spirit of the described embodiments. The selection of the terms used herein is intended to best explain the principles of the embodiments, the practical application, or the improvement of the technology in the market, or to enable other ordinary skill in the technical field to understand the disclosed embodiments.

Claims

1. A private cloud access method without firewall penetration, characterized in that: include: S1. Establish an operator relay gateway to connect the operator's mobile network and the home private cloud network; S2. Create a private protocol format to enable communication between the relay gateway and the home router; S3. The relay gateway receives an access request from a mobile device to access the home private cloud network through the IP address of the home LAN and processes the request message; S4. The client software is installed on the home router to receive the message sent from the relay gateway or the device in the home private cloud LAN, and forward it to the device or relay gateway in the LAN after processing; S5. The third network card of the relay gateway receives the message sent from the home router, and the relay gateway unpacks the original message.

2. The private cloud access method without firewall penetration according to claim 1 is characterized in that: The step S1 includes: configuring the forwarding strategy of the user plane function in the operator's mobile network, forwarding all messages accessing the home private cloud network to the relay gateway, and the user plane function real-time copies the radius message containing the mobile device IP address to the relay gateway.

3. The private cloud access method without firewall penetration according to claim 2 is characterized in that: The step S2 comprises: S21. Define the private protocol format fmfp, the first byte in its message indicates the protocol version, which is used for the compatibility management of fmfp to ensure that both parties follow the same set of rules for communication; S22. The second to seventh bytes are the protocol identifier, whose value is fixed to fmfpv1, used to distinguish different communication protocol categories; S23. The 8th byte is the data packet type, which is used to identify different data packet types in the fmfp protocol format, where "F" represents a proxy protocol packet sent from the client to the mobile device, "C" represents a proxy protocol packet sent from the mobile device to the client, and "H" represents a heartbeat packet sent from the client to the relay gateway; S24. The protocol formats corresponding to different data packet types are not exactly the same. If the data packet type is "F" or "C", it is used for communication between the mobile device and the client software; if the data packet type is "H", it is used for the client software to send a heartbeat to the relay gateway.

4. The private cloud access method without firewall penetration according to claim 3 is characterized in that: The step S3 comprises: S31. The first network card of the relay gateway receives an IP request from a mobile device, sends the request message to the message encapsulation module, and starts processing the request message in response; S32. The relay gateway packet encapsulation module decodes the received data packet, extracts the destination address field in the IPv4 header, and compares the extracted destination address with the preset home private cloud LAN segment. If the destination address does not belong to the home private cloud LAN segment, the data packet is discarded; S33. The relay gateway parses the header information of the received data packet, extracts the source IP address, uses the extracted source IP, searches the device registry maintained by the packet encapsulation module, finds the matching entry, and takes out the corresponding device ID and client ID; S34. The relay gateway uses the client ID to match the client's IP and port information to communicate with the target client; S35 writes the extracted device ID and client ID into the corresponding fields of the private protocol fmfp, and sets the packet type field to "C", and encapsulates the processed fmfp into a UDP packet; S36. After encapsulating the UDP data packet, the IP layer is processed, the target IP address is set to the client IP, the target port is set to the client software listening port, the source IP address is set to the IP address of the relay gateway, and the source port is set to the corresponding port of the packet encapsulation module; S37. Calculate the checksum of UDP and IP to ensure the reliability of communication, and encapsulate the data packet into an Ethernet frame and send it to the third network card, which then sends it to the home private cloud.

5. The private cloud access method without firewall penetration according to claim 4 is characterized in that: The step S4 comprises: S41. The client software in the home router creates and starts the TUN virtual network card and assigns it an IP address; S42. A heartbeat sending module is installed in the client software. The data packet type of the private protocol fmfp of the heartbeat packet is "H". The client ID and listening port information are written into fmfp. The target IP is set to the IP address of the relay gateway, and the source IP is set to the wan port address of the home router. The task of sending the heartbeat packet is triggered every two minutes using a timer. The task is responsible for building the heartbeat packet and sending it to the relay gateway to ensure that the client software remains connected to the relay gateway. S43. The home router receives IP packets from the relay gateway and the devices in the LAN. If the WAN port of the home router receives the packet, the LAN forwarding process is called; if the LAN port of the home router receives the packet, the relay gateway forwarding process is called.

6. The private cloud access method without firewall penetration according to claim 5 is characterized in that: In step S43, the home router WAN port receives the message and calls the LAN forwarding process, including: The message disassembly module of the client software parses and processes the received original message; The message disassembly module disassembles the original message into IP messages, and determines whether the message protocol type is fmfpv1 according to the format of the private protocol. If not, the message is discarded. At the same time, the position and length of the client ID field are determined. If the obtained client ID does not match the local client ID, the message is discarded. According to the format of the private protocol, the location and length of the device ID field in the message are extracted. In the client software, the mapping relationship between the source IP address and the device ID is saved in the form of a table, which is called the device query table. Check if the source IP address already exists in the device query table. If the source IP arrives at the home router for the first time, add a routing entry for the source address in the TUN virtual network card. The LAN forwarding module of the home router uses the RAW Socket interface to create a raw socket, which allows the application to interact directly with the network layer and send and receive IP packets. The IP packets are sent to the LAN device through the RAW Socket; the LAN forwarding module first checks the destination IP address to determine whether an address resolution protocol request is required. If the target IP address is in the same LAN, the LAN forwarding module will send an address resolution protocol request to obtain the target MAC address; after obtaining the MAC address of the target IP, the LAN forwarding module fills the MAC address into the header of the Ethernet frame to ensure that the data packet can be correctly routed in the LAN, determines the next hop address of the data packet according to the routing table, and sends the data packet to the corresponding network interface.

7. The private cloud access method without firewall penetration according to claim 6 is characterized in that: In step S43, the home router LAN port receives the message and calls the relay gateway to forward the message, including: The message encapsulation module of the client software parses and processes the received original message; The message encapsulation module parses the target IP address from the message, searches the device query table, matches the parsed target IP with the IP in the device query table, and obtains the matching device ID; The message encapsulation module uses the private protocol fmfp to encapsulate the original IP data packet into a UDP data packet, writes the device ID into the device ID field of fmfp, writes the local client ID of the client software into the client ID field of fmfp, sets the data packet type field of fmfp to "F", and finally sends the data packet.

8. The private cloud access method without firewall penetration according to claim 7 is characterized in that: The step S5 comprises: S51. The third network card of the relay gateway receives an IP request from the home router, sends the request message to the message disassembly module of the relay gateway, and starts processing the original message in response; S52. The message disassembly module finds the position and length of the device ID field in the message according to the format of the private protocol, extracts the device ID information, searches the device registry stored in the relay gateway according to the device ID, and obtains the client ID and device IP address; S53. Compare the obtained client ID with the data in the client ID field of the message. If the two are not the same, discard the message; S54. The message disassembly module disassembles the received message to obtain the original IP packet sent by the IoT terminal device; S55 disassembles the original IP data packet, the message disassembly module sets the target IP address in the IP packet to the device IP address obtained in S52; S56. Calculate the checksum of the IP to ensure the reliability of communication, and search the mobile device MAC address cache. If the mobile device MAC address cannot be found through the target IP, it is sent to the default gateway, and finally sent by the first network card to the mobile device in the mobile network.

9. A private cloud access device that does not require firewall penetration, characterized in that: include: Establish a relay gateway module to establish an operator relay gateway to connect the operator's mobile network and the home private cloud network; Create a protocol format module to create a private protocol format to achieve communication between the relay gateway and the home router; The relay gateway processing request message module is used for the relay gateway to receive the access request of the mobile device to access the home private cloud network through the IP address of the home local area network, and process the request message; The client software processing module is used to install the client software on the home router, and is used to receive the message sent from the relay gateway or the device in the home private cloud LAN, and forward it to the device or relay gateway in the LAN after processing; The relay gateway unpacking module is used for the relay gateway to unpack the original message sent from the home router.

Images