Remote access method, electronic device and storage medium

Abstract

The embodiments of the present application provide a remote access method, electronic device, and storage medium, relating to the field of information technology. The method includes: performing a QUIC protocol-based session handshake with a second device, wherein the QUIC protocol-based session handshake is used to declare the application layer protocol type used for access authentication; establishing a QUIC session with the second device; and on the established QUIC session, using an application layer protocol message corresponding to the application layer protocol type used for access authentication, performing access authentication interaction with the second device to complete remote access on the second device. The method provided by the embodiments of the present application can improve the efficiency of remote access and reduce the cost of network deployment.

Description

Technical Field

[0001] The embodiments of the present application relate to the field of information technology, and in particular to a remote access method, electronic device, and storage medium. Background Art

[0002] The Dynamic Host Configuration Protocol (DHCP) is a widely deployed protocol on network devices and smart terminals. It manages dynamic IP address allocation and other network-related configuration tasks, reducing the planning, management, and maintenance burden of TCP / IP networks and addressing the shortage of IP address space. It is understood that the DHCP mentioned above also includes the version 6 of DHCP, also known as DHCP v6.

[0003] DHCP / DHCPv6 uses User Datagram Protocol (UDP) encapsulation. The client uses Layer 2 broadcast to request a response from a DHCP server or DHCP relay / proxy device within the local area network. The client selects a DHCP server or DHCP relay / proxy device from the responding DHCP devices to complete the DHCP interaction process and obtain the corresponding IP address.

[0004] Currently, when a client device remotely accesses an institution's private network from a local network, DHCP / DHCPv6 cannot directly traverse the public network. The usual practice is to deploy a virtual private network (VPN) dedicated line, for example, deploying an IPSec tunnel between the local network's egress access router (AR) device and the institution's private network's ingress AR device, or deploying a dedicated VPN client on the client device to enable the above-mentioned client device to remotely access the institution's private network from the local network. However, the above-mentioned deployment configuration is relatively complex and costly. For example, the deployment of a VPN dedicated line is complex and costly, and IPSec is rarely used in laptops and smartphones. Summary of the Invention

[0005] An embodiment of the present application provides a remote access method, electronic device, and storage medium to provide a way for a client device to remotely access an institution's private network. A connection is established between the client device and the institution's private network through access authentication interaction based on the QUIC protocol, thereby improving the efficiency of remote access and reducing the cost of network deployment.

[0006] In a first aspect, an embodiment of the present application provides a remote access method, applied to a first device, comprising:

[0007] Perform a QUIC protocol-based session handshake with the second device, where the QUIC protocol-based session handshake is used to declare the application layer protocol type used for access authentication; establish a QUIC session with the second device; and on the established QUIC session, use application layer protocol messages corresponding to the application layer protocol type used for access authentication to perform access authentication interaction with the second device, thereby completing remote access on the second device.

[0008] In an embodiment of the present application, by declaring the application layer protocol type used for access authentication during the QUIC session handshake phase, and after establishing the QUIC session, using the above-mentioned declared application layer protocol message to perform remote access interaction on the QUIC session, thereby completing remote access authentication, the efficiency of remote access can be improved, and network deployment costs can be saved.

[0009] In one possible implementation, the application layer protocol type for access authentication includes a Dynamic Host Configuration Protocol (DHCP) type and an Extensible Authentication Protocol (EAP) type. By declaring different types of application layer protocol messages for access authentication, the flexibility of selection can be improved.

[0010] In one possible implementation, the QUIC protocol-based session handshake is also used to declare the application layer protocol type for forwarding.

[0011] In an embodiment of the present application, by declaring the application layer protocol type for forwarding during the QUIC handshake phase, it is possible to avoid declaring the application layer protocol type for forwarding after authentication, thereby improving efficiency.

[0012] In one possible implementation, after completing remote access on the second device, the method further includes:

[0013] Announces the application layer protocol type to use for forwarding on an established QUIC session.

[0014] In an embodiment of the present application, after authentication is completed, the application layer protocol type used for forwarding is declared, thereby preventing the first device from accessing the managed network resources of the second device before authentication is successful, thereby avoiding network security issues.

[0015] In one possible implementation, the application layer protocol type for forwarding includes L2 type and L3 type. By declaring different types of application layer protocol messages for forwarding, the flexibility of selection can be improved.

[0016] In one possible implementation, the application layer protocol type for access authentication is a DHCP type, and the access authentication interaction with the second device includes:

[0017] Sending a first message to the second device, wherein the first message is used to request allocation of an IP address to the second device; receiving a second message sent by the second device, wherein the second message includes an assignable IP address; sending a third message to the second device, wherein the third message is used to confirm the assignable IP address; receiving a fourth message sent by the second device, wherein the fourth message includes the assigned IP address.

[0018] In one possible implementation, a DHCP-type application layer protocol is used for DHCP message interaction, and an EAP-type application layer protocol is used for EAP message interaction, wherein:

[0019] Each DHCP message or each EAP message is carried by one or more ALP_STREAM frames, and or one or more STREAM frames, or

[0020] Each DHCP message or the EAP message is carried by one or more ALP_DATAGRAM frames and / or one or more DATAGRAM frames.

[0021] In an embodiment of the present application, the flexibility of message transmission can be improved by carrying the above-mentioned messages through the above-mentioned different types of frames (such as STREAM frames or DATAGRAM frames).

[0022] One possible implementation method also includes:

[0023] Sending an access message to the second device, wherein the access message is used to request access to network resources of the second device;

[0024] A response message sent by the second device is received, wherein the response message includes the network resource requested to be accessed by the first device.

[0025] In one possible implementation manner, the access message is carried by an ALP_DATAGRAM frame and / or a DATAGRAM frame.

[0026] The embodiment of the present application further provides a remote access method, applied to a second device, including:

[0027] Perform a QUIC protocol-based session handshake with the first device, where the QUIC protocol-based session handshake is used to declare the application layer protocol type used for access authentication; establish a QUIC session with the first device; and on the established QUIC session, use application layer protocol messages corresponding to the application layer protocol type used for access authentication to perform access authentication interaction with the first device, thereby completing remote access authentication for the first device.

[0028] In one possible implementation, the application layer protocol type used for access authentication includes a Dynamic Host Configuration Protocol (DHCP) type and an Extensible Authentication Protocol (EAP) type.

[0029] In one possible implementation, the QUIC protocol-based session handshake is also used to declare the application layer protocol type for forwarding.

[0030] In one possible implementation, after completing remote access authentication for the first device, the method further includes:

[0031] Announces the application layer protocol type to use for forwarding on an established QUIC session.

[0032] In one possible implementation, the application layer protocol type used for forwarding includes an L2 type and an L3 type.

[0033] In one possible implementation, the application layer protocol type for access authentication is a DHCP type, and the access authentication interaction with the first device includes:

[0034] Receive a first message sent by a first device, wherein the first message is used to request allocation of an IP address to a second device; send a second message to the first device, wherein the second message includes an assignable IP address; receive a third message sent by the first device, wherein the third message is used to confirm the assignable IP address; send a fourth message to the first device, wherein the fourth message includes the assigned IP address.

[0035] In one possible implementation, a DHCP-type application layer protocol is used for DHCP message interaction, and an EAP-type application layer protocol is used for EAP message interaction, wherein:

[0036] Each DHCP message or each EAP message is carried by one or more ALP_STREAM frames, and or one or more STREAM frames, or

[0037] Each DHCP message or each EAP message is carried by one or more ALP_DATAGRAM frames and / or one or more DATAGRAM frames.

[0038] One possible implementation method also includes:

[0039] An access message sent by a first device is received, wherein the access message is used to request access to network resources of a second device; and a response message is sent to the first device, wherein the response message includes the network resources requested to be accessed by the first device.

[0040] In one possible implementation manner, the access message is carried by an ALP_DATAGRAM frame and / or a DATAGRAM frame.

[0041] In a second aspect, an embodiment of the present application provides a remote access device, applied to a first device, including:

[0042] a handshake module, configured to perform a QUIC protocol-based session handshake with the second device, wherein the QUIC protocol-based session handshake is used to declare an application layer protocol type for access authentication;

[0043] A session establishment module, configured to establish a QUIC session with a second device;

[0044] The access module is used to perform access authentication interaction with the second device on the established QUIC session using an application layer protocol message corresponding to the application layer protocol type used for access authentication, thereby completing remote access on the second device.

[0045] In one possible implementation, the application layer protocol type used for access authentication includes a Dynamic Host Configuration Protocol (DHCP) type and an Extensible Authentication Protocol (EAP) type.

[0046] In one possible implementation, the handshake module is further configured to declare an application layer protocol type for forwarding.

[0047] In one possible implementation, the apparatus further includes:

[0048] A declaration module that declares the application layer protocol type to be forwarded on an established QUIC session.

[0049] In one possible implementation, the application layer protocol type used for forwarding includes an L2 type and an L3 type.

[0050] In one possible implementation, the application layer protocol type used for access authentication is a DHCP type, and the access module is further configured to send a first message to the second device, wherein the first message is configured to request allocation of an IP address to the second device;

[0051] receiving a second message sent by a second device, wherein the second message includes an assignable IP address;

[0052] Sending a third message to the second device, wherein the third message is used to confirm the allocatable IP address;

[0053] Receive a fourth message sent by the second device, where the fourth message includes the allocated IP address.

[0054] In one possible implementation, a DHCP-type application layer protocol is used for DHCP message interaction, and an EAP-type application layer protocol is used for EAP message interaction, wherein:

[0055] Each DHCP message or each EAP message is carried by one or more ALP_STREAM frames, and or one or more STREAM frames, or

[0056] Each DHCP message or each EAP message is carried by one or more ALP_DATAGRAM frames and / or one or more DATAGRAM frames.

[0057] In one possible implementation, the apparatus further includes:

[0058] an access module, configured to send an access message to the second device, wherein the access message is used to request access to network resources of the second device;

[0059] A response message sent by the second device is received, wherein the response message includes the network resource requested to be accessed by the first device.

[0060] In one possible implementation manner, the access message is carried by an ALP_DATAGRAM frame and / or a DATAGRAM frame.

[0061] The embodiment of the present application further provides a remote access device, applied to a second device, including:

[0062] a handshake module, configured to perform a QUIC protocol-based session handshake with the first device, wherein the QUIC protocol-based session handshake is used to declare an application layer protocol type for access authentication;

[0063] A session establishing module, configured to establish a QUIC session with the first device;

[0064] The authentication module is used to perform access authentication interaction with the first device on the established QUIC session using an application layer protocol message corresponding to the application layer protocol type used for access authentication to complete remote access authentication of the first device.

[0065] In one possible implementation, the application layer protocol type used for access authentication includes a Dynamic Host Configuration Protocol (DHCP) type and an Extensible Authentication Protocol (EAP) type.

[0066] In one possible implementation, the handshake module is further configured to declare an application layer protocol type for forwarding.

[0067] In one possible implementation, the apparatus further includes:

[0068] A declaration module that declares the application layer protocol type to be forwarded on an established QUIC session.

[0069] In one possible implementation, the application layer protocol type used for forwarding includes an L2 type and an L3 type.

[0070] In one possible implementation, the application layer protocol type used for access authentication is a DHCP type, and the authentication module is further configured to receive a first message sent by the first device, wherein the first message is used to request allocation of an IP address to the second device;

[0071] Sending a second message to the first device, wherein the second message includes an assignable IP address;

[0072] receiving a third message sent by the first device, wherein the third message is used to confirm an allocatable IP address;

[0073] A fourth message is sent to the first device, where the fourth message includes the allocated IP address.

[0074] In one possible implementation, a DHCP-type application layer protocol is used for DHCP message interaction, and an EAP-type application layer protocol is used for EAP message interaction, wherein:

[0075] Each DHCP message or each EAP message is carried by one or more ALP_STREAM frames, and or one or more STREAM frames, or

[0076] Each DHCP message or each EAP message is carried by one or more ALP_DATAGRAM frames and / or one or more DATAGRAM frames.

[0077] In one possible implementation, the apparatus further includes:

[0078] a response module, configured to receive an access message sent by the first device, wherein the access message is used to request access to network resources of the second device;

[0079] A response message is sent to the first device, where the response message includes the network resource requested to be accessed by the first device.

[0080] In one possible implementation manner, the access message is carried by an ALP_DATAGRAM frame and / or a DATAGRAM frame.

[0081] In a third aspect, an embodiment of the present application provides a first device, including:

[0082] A memory, wherein the memory is used to store computer program code, wherein the computer program code includes instructions, and when the first device reads the instructions from the memory, the first device performs the following steps:

[0083] Performing a QUIC protocol-based session handshake with the second device, where the QUIC protocol-based session handshake is used to declare an application layer protocol type for access authentication;

[0084] Establishing a QUIC session with the second device;

[0085] On the established QUIC session, use the application layer protocol message corresponding to the application layer protocol type used for access authentication to interact with the second device for access authentication and complete remote access on the second device.

[0086] In one possible implementation, the application layer protocol type used for access authentication includes a Dynamic Host Configuration Protocol (DHCP) type and an Extensible Authentication Protocol (EAP) type.

[0087] In one possible implementation, the QUIC protocol-based session handshake is also used to declare the application layer protocol type for forwarding.

[0088] In one possible implementation, when the instruction is executed by the first device, the first device further performs the following steps after completing the step of remotely accessing the second device:

[0089] Announces the application layer protocol type to use for forwarding on an established QUIC session.

[0090] In one possible implementation, the application layer protocol type used for forwarding includes an L2 type and an L3 type.

[0091] In one possible implementation, the application layer protocol type for access authentication is a DHCP type. When the instruction is executed by the first device, the first device performs the steps of performing access authentication interaction with the second device, including:

[0092] Sending a first message to the second device, wherein the first message is used to request allocation of an IP address to the second device;

[0093] receiving a second message sent by a second device, wherein the second message includes an assignable IP address;

[0094] Sending a third message to the second device, wherein the third message is used to confirm the allocatable IP address;

[0095] Receive a fourth message sent by the second device, where the fourth message includes the allocated IP address.

[0096] In one possible implementation, a DHCP-type application layer protocol is used for DHCP message interaction, and an EAP-type application layer protocol is used for EAP message interaction, wherein:

[0097] Each DHCP message or each EAP message is carried by one or more ALP_STREAM frames, and or one or more STREAM frames, or

[0098] Each DHCP message or each EAP message is carried by one or more ALP_DATAGRAM frames and / or one or more DATAGRAM frames.

[0099] In one possible implementation, when the instruction is executed by the first device, the first device further performs the following steps:

[0100] Sending an access message to the second device, wherein the access message is used to request access to network resources of the second device;

[0101] A response message sent by the second device is received, wherein the response message includes the network resource requested to be accessed by the first device.

[0102] In one possible implementation manner, the access message is carried by an ALP_DATAGRAM frame and / or a DATAGRAM frame.

[0103] The embodiment of the present application further provides a second device, including:

[0104] A memory, the memory being used to store computer program code, the computer program code including instructions, and when the second device reads the instructions from the memory, the second device performs the following steps:

[0105] Performing a QUIC protocol-based session handshake with the first device, where the QUIC protocol-based session handshake is used to declare an application layer protocol type for access authentication;

[0106] Establishing a QUIC session with the first device;

[0107] On the established QUIC session, use the application layer protocol message corresponding to the application layer protocol type used for access authentication to interact with the first device for access authentication and complete the remote access authentication of the first device.

[0108] In one possible implementation, the application layer protocol type used for access authentication includes a Dynamic Host Configuration Protocol (DHCP) type and an Extensible Authentication Protocol (EAP) type.

[0109] In one possible implementation, the QUIC protocol-based session handshake is also used to declare the application layer protocol type for forwarding.

[0110] In one possible implementation, when the instruction is executed by the second device, the second device further performs the following steps after completing the step of remote access authentication for the first device:

[0111] Announces the application layer protocol type to use for forwarding on an established QUIC session.

[0112] In one possible implementation, the application layer protocol type used for forwarding includes an L2 type and an L3 type.

[0113] In one possible implementation, the application layer protocol type for access authentication is a DHCP type. When the instruction is executed by the second device, the second device performs the steps of interacting with the first device for access authentication, including:

[0114] receiving a first message sent by the first device, wherein the first message is used to request allocation of an IP address to the second device;

[0115] Sending a second message to the first device, wherein the second message includes an assignable IP address;

[0116] receiving a third message sent by the first device, wherein the third message is used to confirm an allocatable IP address;

[0117] A fourth message is sent to the first device, where the fourth message includes the allocated IP address.

[0118] In one possible implementation, a DHCP-type application layer protocol is used for DHCP message interaction, and an EAP-type application layer protocol is used for EAP message interaction, wherein:

[0119] Each DHCP message or each EAP message is carried by one or more ALP_STREAM frames, and or one or more STREAM frames, or

[0120] Each DHCP message or each EAP message is carried by one or more ALP_DATAGRAM frames and / or one or more DATAGRAM frames.

[0121] In one possible implementation, when the instruction is executed by the second device, the second device further performs the following steps:

[0122] receiving an access message sent by the first device, wherein the access message is used to request access to network resources of the second device;

[0123] A response message is sent to the first device, where the response message includes the network resource requested to be accessed by the first device.

[0124] In one possible implementation manner, the access message is carried by an ALP_DATAGRAM frame and / or a DATAGRAM frame.

[0125] In a fourth aspect, an embodiment of the present application provides a computer-readable storage medium, which stores a computer program. When the computer-readable storage medium is run on a computer, the computer executes the method described in the first aspect.

[0126] In a fifth aspect, an embodiment of the present application provides a computer program, which, when executed by a computer, is used to execute the method described in the first aspect.

[0127] In one possible design, the program in the fifth aspect may be stored in whole or in part on a storage medium packaged with the processor, or may be stored in whole or in part on a memory not packaged with the processor. BRIEF DESCRIPTION OF THE DRAWINGS

[0128] Figure 1a-Figure 1c Schematic diagram of application scenarios provided by embodiments of the present application;

[0129] Figure 2 A flowchart of an embodiment of the remote access method provided by this application;

[0130] Figure 3 A schematic structural diagram of an embodiment of a remote access device provided by this application;

[0131] Figure 4 A schematic structural diagram of another embodiment of the remote access device provided by this application;

[0132] Figure 5 A schematic diagram of the hardware structure of an electronic device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0133] The following describes the technical solutions in the embodiments of the present application in conjunction with the accompanying drawings. In the description of the embodiments of the present application, unless otherwise specified, " / " represents "or." For example, A / B can represent A or B. "And / or" in this document is merely a description of the association relationship between associated objects, indicating that three relationships can exist. For example, A and / or B can represent: A exists alone, A and B exist simultaneously, or B exists alone.

[0134] In the following, 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 technical features indicated. Therefore, a feature defined as "first" or "second" may explicitly or implicitly include one or more of the features. In the description of the embodiments of this application, unless otherwise specified, "plurality" means two or more.

[0135] The TCP / IP protocol suite is the foundation of the Internet. The transport layer protocols include the Transmission Control Protocol (TCP) and the User Datagram Protocol (UDP). Compared to TCP, UDP is more lightweight but also requires far less error checking. Because the client doesn't frequently communicate with the server to check if data packets are delivered or in order, UDP is often more efficient. However, UDP isn't as reliable as TCP. Typically, UDP is used for applications like gaming, streaming media, and VoIP, while TCP is used for most applications like web pages, email, and remote login.

[0136] The Dynamic Host Configuration Protocol (DHCP) is a widely deployed protocol on network devices and smart terminals. It manages dynamic IP address allocation and other network-related configuration tasks, reducing the planning, management, and maintenance burden of TCP / IP networks and addressing the shortage of IP address space. It is understood that the DHCP mentioned above also includes the version 6 of DHCP, also known as DHCP v6.

[0137] DHCP / DHCPv6 uses encapsulation. The client uses Layer 2 broadcast to request a response from a DHCP server or DHCP relay / proxy device within the LAN. The client selects a DHCP server or DHCP relay / proxy device from the DHCP devices that receive the response, completes the DHCP interaction process, and obtains the corresponding IP address.

[0138] Currently, when a client device remotely accesses an institution's private network from a local network, DHCP / DHCPv6 cannot directly traverse the public network. The usual practice is to deploy a virtual private network (VPN) dedicated line, for example, deploying an IPSec tunnel between the local network's egress access router (AR) device and the institution's private network's ingress AR device, or deploying a dedicated VPN client on the client device to enable the above-mentioned client device to remotely access the institution's private network from the local network. However, the above-mentioned deployment configuration is relatively complex and costly. For example, the deployment of a VPN dedicated line is complex and costly, and IPSec is rarely used in laptops and smartphones.

[0139] The Quick UDP Internet Connection (QUIC) protocol multiplexes the transport layer: after establishing a basic connection between the client and the server, it provides a separate "stream" for the transmission of each web page element. The opening and closing of streams are lightweight and do not affect the connection to which they belong. Streams are independent of each other and do not affect their own transmission. The QUIC protocol supports encryption and provides a secure transmission channel.

[0140] QUIC packets are carried over UDP. They can contain one or more STREAM frames. STREAM frames, a special type of frame within QUIC packets, are used to distinguish between different service flows carrying an application. For example, the audio and video service flow, the application text service flow, or the application layer control protocol service flow of the same service. Because of its acknowledgment and retransmission mechanisms, Stream is a reliable transport mechanism.

[0141] In addition, the QUIC protocol also includes a transport mechanism that does not require reliability, using DATAGRAM frames. The DATAGRAM frames can also be expanded to include a FlowID field, which identifies different service sessions or interaction requests.

[0142] In order to solve the above problems, the embodiment of the present application proposes a remote access method based on the above QUIC protocol to realize DHCP remote access. The above remote access method can be applied to the first device 10 and the second device 20. Exemplarily, the first device 10 can be a client device, which can include but is not limited to a mobile phone, a tablet computer (pad), a computer with transceiver function, a virtual reality (VR) terminal device, an augmented reality (AR) terminal device, a wireless terminal in industrial control (Industrial Control), a wireless terminal in self-driving (Self Driving), a wireless terminal in remote medical (Remote Medical), a wireless terminal in smart grid (Smart Grid), a wireless terminal in transportation safety (Transportation Safety), a wireless terminal in smart city (Smart City), a wireless terminal in smart home (Smart Home), a wearable device, a vehicle-mounted device and a network device, wherein the network device can include but is not limited to a three-layer switch, a router, a broadband gateway, a firewall, a load balancer and the like. The second device 20 can be a server. The server can provide services to the client device, for example, it can provide resources to the client device and save client data.

[0143] Figure 1a-Figure 1c These are three application scenarios of the above remote access method.

[0144] Figure 1a This is a schematic diagram of the architecture of application scenario 1. Figure 1a As shown, the above application scenario 1 includes a first device 10, a second device 20 and a third device 30. Among them, the first device 10 is a client device, the second device 20 is a DHCP server, and the third device 30 is a DHCP relay or DHCP proxy. There is a DHCP connection between the first device 10 and the third device 30, and there is a DHCP protocol interaction based on the QUIC protocol between the second device 20 and the third device 30. Therefore, the third device 30 can be an access router device in the same local network as the first device 10. By establishing a local DHCP connection between the first device 10 and the third device 30, and establishing a QUIC session between the third device 30 and the second device 20, a secure and reliable three-layer tunnel can be provided, which can then cross the public network to achieve remote access, and can prevent the network configuration information of the private network device transmitted in the DHCP message from being intercepted by the intermediate device.

[0145] Figure 1b This is a schematic diagram of the architecture of application scenario 2. Figure 1bAs shown, the above-mentioned application scenario 2 includes a first device 10, a second device 20 and a third device 30. Among them, the first device 10 is a client device, the second device 20 is a DHCP server, and the third device 30 is a DHCP relay or DHCP proxy. There is a DHCP connection between the second device 20 and the third device 30, and the DHCP protocol interaction between the second device 20 and the first device 10 is based on the QUIC protocol. Therefore, the third device 30 can be a device in the same external network as the second device 20. By establishing a local DHCP connection between the second device 20 and the third device 30, and establishing a QUIC session between the third device 30 and the first device 10, a secure and reliable three-layer tunnel can be provided, which can then cross the public network to achieve remote access, and can prevent the network configuration information of the private network device transmitted in the DHCP message from being intercepted by the intermediate device.

[0146] Figure 1c This is a schematic diagram of the architecture of application scenario 3. Figure 1c As shown, the above-mentioned application scenario 3 includes a first device 10 and a second device 20. The first device 10 is a client device, and the second device 20 is a DHCP server. The DHCP protocol interaction between the second device 20 and the first device 10 is based on the QUIC protocol. By establishing a QUIC session between the second device 20 and the first device 10, a secure and reliable Layer 3 tunnel can be provided, thereby enabling remote access across the public network and preventing the network configuration information of private network devices transmitted in the DHCP message from being intercepted by intermediate devices.

[0147] Next, an example is given in which the first device 10 remotely accesses the private network of the organization where the second device 20 is located through DHCP interaction.

[0148] Figure 2 A flowchart of an embodiment of a remote access method provided in an embodiment of the present application includes:

[0149] Step 201: The first device 10 sends a remote access request to the second device 20 to establish a QUIC session with the second device 20.

[0150] Specifically, the user can perform an operation on the first device 10. For example, the user can configure the application layer protocol type for access authentication on the first device 10 and initiate remote access authentication based on the configured application layer protocol type for access authentication. In other words, the first device 10 can complete remote access authentication using an access authentication interaction based on the QUIC protocol. In response to the user's operation, the first device 10 can send a remote access request to the second device 20 to establish a QUIC session with the second device 20, thereby achieving remote access to the private network of the organization where the second device 20 is located.

[0151] In addition, the user can also configure the application layer protocol type for forwarding on the first device. The application layer protocol type for forwarding can be used to forward application layer protocol messages after successful access authentication. The application layer protocol message can be a data packet corresponding to the above application layer protocol type.

[0152] In an embodiment of the present application, the application layer protocol type used for access authentication may include a DHCP type and an Extensible Authentication Protocol (EAP) type. Exemplarily, the DHCP type may include DHCP over QUIC and DHCPv6 over QUIC. DHCP over QUIC is used to characterize DHCP interactions based on the QUIC protocol, and DHCPv6 over QUIC is used to characterize DHCPv6 interactions based on the QUIC protocol. In a specific implementation, DHCP over QUIC can be identified by the string "dhcpoq", and DHCP over QUIC can be identified by the string "dhcpv6oq".

[0153] The above-mentioned application layer protocol types used for forwarding may include L2 types and L3 types. The above-mentioned L2 types may include Ethernet over QUIC, wherein Ethernet over QUIC is used to characterize Ethernet interactions based on the QUIC protocol. In specific implementation, Ethernet over QUIC may be identified by the string "ethoq". The above-mentioned L3 types may include IPv4 over QUIC and IPv6 over QIC. Among them, IPv4 over QIC is used to characterize IPv4 interactions based on the QUIC protocol, and IPv6 over QIC is used to characterize IPv6 interactions based on the QUIC protocol. In specific implementation, IPv4 over QIC may be identified by the string "ipv4oq", and IPv6 over QIC may be identified by the string "ipv6oq". The above-mentioned strings may be created in the registry of the Application Layer Protocol Negotiation (ALPN) protocol.

[0154] It is understandable that after the first device 10 sends a remote access request to the second device 20, the second device 20 can perform a QUIC protocol-based session handshake with the first device 10 to establish a QUIC session between the first device 10 and the second device 20. The above-mentioned handshake process based on the QUIC protocol may include multiple interactive processes between the first device 10 and the second device 20. The above-mentioned handshake process based on the QUIC protocol can complete authentication, capability negotiation and key interaction. For details, please refer to the QUIC protocol and will not be repeated here. Among them, the above-mentioned capability negotiation can be used to complete the declaration of the application layer protocol type between the first device 10 and the second device 20.

[0155] Optionally, the QUIC protocol-based handshake can be triggered by the first DHCP Discovery message or DHCPv6 SOLICIT message, or by other application protocol session establishment requests carried on the QUIC session. Then, DHCP or DHCPv6 can reuse the QUIC session to complete the DHCP or DHCPv6 protocol interaction.

[0156] It should be noted that, during the above-mentioned session handshake process based on the QUIC protocol, the first device 10 and the second device 20 can declare the supported bearer application layer protocol type through Application Layer Protocol Negotiation (ALPN), wherein the above-mentioned declared application layer protocol type may include the application layer protocol type used for access authentication. In other words, by declaring the above-mentioned application layer protocol type, the application layer protocol message supported by the bearer can be declared. For example, the protocol type of "dhcpoq" can be used to declare that the above-mentioned QUIC session supports the transmission of application layer protocol messages corresponding to "dhcpoq", such as DHCP messages; the protocol type of "dhcpoqv6" can be used to declare that the above-mentioned QUIC session supports the transmission of application layer protocol messages corresponding to "dhcpoq", such as DHCPv6 messages.

[0157] Optionally, the application layer protocol type declared above may also include an application layer protocol type for forwarding. For example, the protocol type of "ethoq" may be used to declare that the QUIC session supports the transmission of application layer protocol messages corresponding to "ethoq", such as ethernet packets; the protocol type of "ipv4oq" may be used to declare that the QUIC session supports the transmission of application layer protocol messages corresponding to "IPv4", such as IPv4 packets; and the protocol type of "ipv6oq" may be used to declare that the QUIC session supports the transmission of application layer protocol messages corresponding to "ipv6oq", such as IPv6 packets.

[0158] Among them, DHCP messages or DHCPv6 messages can be carried by STREAM frames or DATAGRAM frames, and Ethernet messages, IPv4 messages or IPv6 messages can be carried by DATAGRAM frames.

[0159] Optionally, the DHCP message or DHCPv6 message can also be carried by an ALP_STREAM frame or an ALP_DATAGRAM frame, and the Ethernet message, IPv4 message, or IPv6 message can also be carried by an ALP_DATAGRAM frame. The ALP_STREAM frame has one more ALP field than the STREAM frame, and the ALP_DATAGRAM frame has one more ALP field than the DATAGRAM frame. The ALP field is used to identify the application layer protocol type.

[0160] It is understandable that when the above-mentioned DHCP message or DHCPv6 message is carried by ALP_STREAM frames and / or STREAM frames, one DHCP message or DHCPv6 message may be carried by one or more ALP_STREAM frames and / or one or more STREAM frames.

[0161] In addition, the application layer protocol types supported by the above declaration may be one or more. Exemplarily, the application layer protocol types supported by the above declaration may be DHCP over QUIC or DHCPv6 over QUIC, or may be Ethernet over QUIC, IPv4 over QUIC or IPv6. That is, when the application layer protocol type supported by the above declaration is DHCP over QUIC or DHCPv6 over QUIC, DHCP messages or DHCPv6 messages may be carried by ALP_STREAM frames and / or STREAM frames, or ALP_DATAGRAM frames and / or DATAGRAM frames. When the application layer protocol type supported by the above declaration is Ethernet over QUIC, IPv4 over QUIC or IPv6 over QUIC, the above DHCP messages or DHCPv6 messages and other protocol messages may be indirectly carried by Ethernet messages, IPv4 messages or IPv6 messages.

[0162] For example, taking the example of the first device 10 sending a DHCP message and applying for an IPv4 address, the application layer protocol type declared to be supported may be IPv4 over QUIC. The first device 10 may create an ALP_DATAGRAM and / or DATAGRAM frame, which carries an IPv4 message. It is understood that the IPv4 message may include an IPv4 header and a payload, which may be a DHCP message with a UDP header, thereby indirectly carrying the DHCP message via the IPv4 message. It is understood that the payload may also be another protocol message, such as an HTTP message with a TCP header.

[0163] Next, taking the example of first device 10 sending a DHCPv6 message and applying for an IPv6 address, the application layer protocol type declared as supported can be IPv6 over QUIC. First device 10 can create ALP_DATAGRAM and / or DATAGRAM frames, which carry IPv6 messages. It is understood that the IPv6 message can include an IPv6 header and a payload, which can be a DHCPv6 message. This allows the DHCPv6 message to be indirectly carried by the IPv6 message. It is understood that the payload can also be messages from other protocols, such as HTTP messages.

[0164] Furthermore, taking the example of the first device 10 sending a DHCP message or a DHCPv6 message, at this time, the application layer protocol type declared to be supported may be ethernet over QUIC. The first device 10 may create an ALP_DATAGRAM and / or DATAGRAM frame, which carries an ethernet message. It is understandable that the ethernet message may include an ethernet header, an IP header, and a payload, and the payload may be a DHCP or DHCPv6 message with a UDP header, thereby enabling indirect carrying of a DHCP or DHCPv6 message through an ethernet message. The payload may be a message of another protocol, such as an HTTP message with a TCP header. It is understandable that the above-mentioned IP header may be an IPv4 header or an IPv6 header, and the type of the above-mentioned IP header may be determined according to the type of the IP address applied for by the first device 10.

[0165] Optionally, the declaration of the above-mentioned L2 type application layer protocol (for example, Ethernet over QUIC) and L3 type application layer protocol (for example, IPv4 over QUIC or IPv6 over QUIC) can be completed in the above-mentioned QUIC protocol-based handshake process, or can be completed through re-capability negotiation between the first device 10 and the second device 20 in the established QUIC session. That is, the first device 10 can continue to declare the supported L2 and / or L3 type application layer protocols in the established QUIC session after the access authentication is completed, so as to notify the second device 20 of the supported L2 and / or L3 type application layer protocols. The embodiment of the present application does not impose any special limitation on the declaration time of the application layer protocol type of the above-mentioned QUIC session.

[0166] In step 202 , the first device 10 sends a first message to the second device 20 to request allocation of an IP address.

[0167] Specifically, after the first device 10 establishes a QUIC session with the second device 20, the first device 10 may send a first message (application layer protocol message) to the second device 20. The first message may be a DHCP Discovery message. For example, when carrying a DHCP message, the first message may be a DHCP Discovery message. The first message may also be a SOLICIT message. For example, when carrying a DHCPv6 message, the first message may be a SOLICIT message.

[0168] In a specific implementation, the first device 10 can create a bidirectional stream with an ID of X and a first message. Here, X can be a preset integer (for example, X is 16). The bidirectional stream transmits ALP_STREAM frames and / or STREAM frames, which can be used to carry the above-mentioned first message. The first message is used to request the second device 20 to assign an IP address to the first device 10, and the IP address is the IP address of the organization's private network.

[0169] It is understandable that the payload of an ALP_STREAM frame or STREAM frame is usually small and may not be sufficient to carry a first message carrying a larger payload. Therefore, the first message can be divided into multiple sub-messages based on the maximum payload of an ALP_STREAM frame or STREAM frame. Each sub-message of the first message is carried by an ALP_STREAM frame or STREAM frame, and the sub-messages of the multiple first messages can be reassembled at the second device 20 to restore the first message. In other words, the first message can be carried by one or more ALP_STREAM frames and / or one or more STREAM frames.

[0170] Optionally, when the first device 10 sends Stream data to the second device 20, the first frame in the above Stream may be an ALP_STREAM frame. The ALP_STREAM frame may include the value of the StreamID (for example, the value is 16) and the identifier of the application layer protocol type it carries (for example, the identifier is dhcpoq), which is used to notify the second device 20 that the Stream corresponding to the StreamID carries a DHCP message. In other words, when the first device 10 can subsequently send a STREAM frame corresponding to the same Stream ID, it does not need to continue to send ALP_STREAM frames, thereby allowing the second device 20 to immediately identify that the STREAM frame corresponding to the StreamID carries a DHCP message when it subsequently receives the STREAM frame corresponding to the StreamID.

[0171] It should be noted that the above example only schematically illustrates the method of carrying the first message through the ALP_STREAM frame or the STREAM frame, and does not constitute a limitation on the embodiments of the present application. In some embodiments, the above-mentioned first message can also be carried by the ALP_DATAGRAM frame or the DATAGRAM frame, that is, the above-mentioned first message can be carried by one or more ALP_DATAGRAM frames, and / or one or more DATAGRAM frames. For the convenience of explanation, the following uses the ALP_STREAM frame or the STREAM frame to carry other application layer protocol messages (for example, the second message, the third message and the fourth message) as an example for explanation, but is not limited to carrying the above-mentioned second message, the third message and the fourth message through the ALP_STREAM frame or the STREAM frame.

[0172] In step 203 , the second device 20 parses the first message and sends a second message to the first device 10 according to the parsing result, so as to provide an assignable IP address.

[0173] Specifically, after the second device 20 receives the first message sent by the first device 10, it can parse the first message and provide an assignable IP address based on the parsing result. In a specific implementation, the second device 20 can receive the first message by obtaining the first message from an ALP_STREAM frame or STREAM frame, or by obtaining sub-messages of the first message from a group of ALP_STREAM frames or STREAM frames, and reassembling multiple sub-messages of the first message into the first message.

[0174] For example, if it is known through parsing the above-mentioned first message (for example, the first message is a DHCP Discovery message) that the first device 10 requests an IPv4 address, the second device can provide an assignable IPv4 address; if it is known through parsing the above-mentioned first message (for example, the first message is a SOLICIT message) that the first device 10 requests an IPv6 address, the second device can provide an assignable IPv6 address.

[0175] Then, after the second device 20 passes authentication in the local authentication, authorization, and accounting (AAA) module and the remote AAA server based on the user authentication information of the first device 10 carried in the first message, it can create a second message (application layer protocol message) and encapsulate the second message into an ALP_STREAM frame and / or STREAM frame with an ID of X, wherein the second message can include an assignable IP address. Then, the second device 20 can send the ALP_STREAM frame and / or STREAM frame with an ID of X to the first device 10.

[0176] It is understandable that if the first message is a DHCP Discovery message, the second message is a DHCPOffer message. If the first message is a DHCPv6 SOLICIT message, the second message is a DHCPv6 ADVERTISE message.

[0177] It should be noted that the above-mentioned second message can also be divided into multiple sub-messages of the second message, and each sub-message of the second message can be carried by an ALP_STREAM frame or a STREAM frame, thereby enabling the above-mentioned multiple sub-messages of the second message to be reassembled at the first device 10, and then the second message can be restored at the first device 10.

[0178] In step 204 , the first device 10 parses the second message and sends a third message to the second device 20 according to the parsing result to confirm the allocated IP address.

[0179] Specifically, after the first device 10 receives the second message sent by the second device 20, it can parse the second message to obtain the IP address assigned by the second device 20 carried by the second message. Then, the first device 10 can create a third message (application layer protocol message) based on the assigned IP address. The third message can be used to confirm the use of the assigned IP address to the second device 20. Then, the first device 10 can encapsulate the third message in an ALP_STREAM frame and / or a STREAM frame with an ID of X, and can send the ALP_STREAM frame and / or STREAM frame to the second device 20.

[0180] It is understandable that if the second message is a DHCP Offer message, the third message is a DHCP Request message. If the second message is a DHCPv6 ADVERTISE message, the third message is a DHCPv6 REQUEST message.

[0181] It should be noted that the above-mentioned third message can also be divided into multiple sub-messages of the third message, and each sub-message of the third message can be carried by an ALP_STREAM frame or a STREAM frame, thereby enabling the above-mentioned multiple sub-messages of the third message to be reassembled at the second device 20, and then the third message can be restored at the second device 20.

[0182] In step 205 , the second device 20 parses the third message and sends a fourth message to the first device 10 according to the parsing result to confirm the allocation of the IP address.

[0183] Specifically, after the second device 20 receives the third message sent by the first device 10, it can parse the third message to obtain confirmation information of the IP address allocated to the second device 20 in the third message. Then, the second device 20 can allocate the IP address to the first device 10 for use, and can create a fourth message (application layer protocol message) based on the confirmation information. The fourth message can be used to notify the first device 10 that the IP address has been confirmed to be allocated to the first device 10. Then, the second device 20 can encapsulate the fourth message in an ALP_STREAM frame and / or STREAM frame with an ID of X, and can send the ALP_STREAM frame and / or STREAM frame to the first device 10.

[0184] It is understandable that if the third message is a DHCP Request message, the fourth message may be a DHCPAck message. In this case, the DHCP Request message carries confirmation information of the IPv4 address assigned to the second device 20. If the third message is a DHCPv6 REQUEST message, the fourth message is a DHCPv6 REPLY message. In this case, the DREQUES message carries confirmation information of the IPv6 address assigned to the second device 20.

[0185] It should be noted that the above-mentioned fourth message can also be divided into multiple sub-messages of the fourth message, and each sub-message of the fourth message can be carried by an ALP_STREAM frame or a STREAM frame, thereby enabling the above-mentioned multiple sub-messages of the fourth message to be reassembled at the first device 10, and then the fourth message can be restored at the first device 10.

[0186] In step 206 , the first device 10 parses the fourth message and determines the IP address according to the parsing result to complete the DHCP interaction with the second device 20 .

[0187] Specifically, after the first device 10 receives the fourth message sent by the second device 20, it can parse the fourth message to obtain the information in the fourth message confirming the allocation of the IP address by the second device 20. The first device 10 can then use the IP address to complete the DHCP interaction with the second device 20, thereby completing the remote access authentication of the first device 10 on the second device 20. It can be seen that through the interaction of the above-mentioned application layer protocol messages (e.g., the first message, the second message, the third message, and the fourth message), remote access authentication of the first device 10 on the second device 20 can be achieved.

[0188] Optionally, if support for L2 or L3 type application layer protocols is not negotiated during the handshake phase of the above-mentioned QUIC protocol, the first device 10 may dynamically trigger the QUIC protocol module after receiving the above-mentioned fourth message sent by the second device 20. Exemplarily, the first device 10 may send a NEW_ALP frame to the second device 20 on the above-mentioned established QUIC session, and the NEW_ALP frame may be used to negotiate support for L2 or L3 type application layer protocols with the second device 20. Since in the above-mentioned method, the step of negotiating the L2 or L3 type application layer protocol is performed after successful authentication, it is possible to avoid the first device 10 from accessing the network resources controlled by the second device 20 before successful authentication, thereby avoiding network security issues.

[0189] In step 207 , the first device 10 sends a fifth message to the second device 20 based on an L2 or L3 application layer protocol to access resources on the network where the second device 20 is located.

[0190] Specifically, after the first device 10 completes remote access to the second device 20 , it can further remotely access the second device 20 , that is, the first device 10 can access the network resources controlled by the second device 20 .

[0191] In a specific implementation, the first device 10 may create an access message for remote access (for ease of explanation, the above-mentioned "access message for remote access" will be referred to as the "fifth message" below), and the fifth message may be carried by an ALP_DATAGRAM frame or a DATAGRAM frame. Exemplarily, the first device 10 may create a DATAGRAM flow, and the DATAGRAM flow may include multiple ALP_DATAGRAM frames or multiple DATAGRAM frames, wherein each ALP_DATAGRAM frame or DATAGRAM frame may include a flow ID, and the flow ID is used to identify the identity of the DATAGRAM flow.

[0192] Then, the first device 10 may encapsulate the fifth message into an ALP_DATAGRAM frame or a DATAGRAM frame, wherein the ALP_DATAGRAM frame may include an ALP field, and the ALP field may be used to identify the application layer protocol type (for example, the application layer protocol type may be ipv4oq).

[0193] In step 208 , the second device 20 sends a sixth message to the first device 10 to complete the access of the first device 10 to the second device 20 .

[0194] Specifically, after receiving the ALP_DATAGRAM frame or the DATAGRAM frame sent by the first device 10, the second device 20 can obtain the fifth message (access message) in the ALP_DATAGRAM frame or the DATAGRAM frame, and can forward it to the upper layer or other network devices (for example, an intranet resource server) in the network where the second device 20 is located based on the routing information in the fifth message. It can be understood that the routing information can be used to represent IP routing. Therefore, the upper layer in the second device 20 can be a protocol layer above L3 (for example, the IP layer).

[0195] Then, when the upper layer or other network device in the second device 20 receives the fifth message, a corresponding sixth message can be generated based on the fifth message. The sixth message can be a response message, that is, the sixth message can be a response to the fifth message, and the sixth message can include the resources that the first device 10 wants to access. Then, the second device 20 can send the sixth message to the first device 10. It can be understood that if the upper layer in the second device 20 generates the corresponding sixth message, the second device 20 can directly send the sixth message to the first device 10; if other network devices generate the corresponding sixth message, the other network devices will send the sixth message to the second device 20, and the second device 20 can forward it to the first device 10.

[0196] In a specific implementation, the second device 20 may send the sixth message by encapsulating the sixth message into an ALP_DATAGRAM frame or a DATAGRAM frame, and may send the ALP_DATAGRAM frame or the DATAGRAM frame to the first device 10 .

[0197] In step 209 , the first device 10 receives and parses the sixth message sent by the second device 20 , and obtains resource information in the sixth message.

[0198] Specifically, the first device 10 can receive the ALP_DATAGRAM frame or the DATAGRAM frame sent by the second device 20, and can obtain the sixth message from the ALP_DATAGRAM frame or the DATAGRAM frame. Then, the first device 10 can parse the sixth message. For example, the first device 10 can parse the IP header and the transport protocol header in the sixth message to obtain the payload in the sixth message. The payload in the sixth message is the resource accessed by the first device 10, thereby enabling the first device 10 to access the resources of the private network where the second device 20 is located.

[0199] It is understandable that the above steps 201 to 206 describe the scenario of applying for an IP address through a DHCP interaction based on the QUIC protocol. Similarly, the above steps 201 to 206 are also applicable to the scenario of IP address renewal. For example, the message for IP address renewal can be carried on a STREAM frame or DATAGRAM frame based on the QUIC protocol, or on an ALP_STREAM frame or ALP_DATAGRAM frame based on the QUIC protocol. The specific process can be referred to the above steps 201 to 206, which will not be repeated here.

[0200] In an embodiment of the present application, the first device 10 applies for an IP address from the second device 20 through DHCP interaction based on the QUIC protocol, thereby achieving simple and efficient remote access authentication and saving a lot of costs caused by laying a VPN dedicated line or deploying a dedicated VPN client.

[0201] It is understandable that the above embodiment only exemplarily illustrates the process of interaction between the first device 10 and the second device 20 , and the first device 10 may also interact with the second device 20 after being transferred through the third device 30 .

[0202] In addition, in the above embodiment, steps 201 to 209 are all optional steps. This application only provides a feasible embodiment, which may also include more or fewer steps than steps 201 to 209. This application does not limit this.

[0203] It should be noted that the above example only illustrates a DHCP type of access authentication method and does not constitute a limitation on the embodiments of the present application. In some embodiments, the above access authentication type may also include an EAP type (e.g., EAP over QUIC). For example, the string "eapoq" may be used to represent the access authentication protocol of the above EAP type. The protocol type of "eapoq" may support Extensible Authentication Protocol (EAP) messages. That is, with the second device 20 as the authentication point, the first device 10 may carry EAP messages through one or more ALP_STREAM frames and / or one or more STREAM frames of the QUIC session. Optionally, the first device 10 may also carry EAP messages through one or more ALP_DATAGRAM frames and / or one or more DATAGRAM frames of the QUIC session, thereby completing the access authentication interaction with the second device 20, and then carrying L2 or L3 type messages through ALP_DATAGRAM frames or DATAGRAM frames to apply for a private network IP address and access private network resources in the above embodiment.

[0204] Figure 3 This is a structural diagram of an embodiment of the remote access device of the present application, as shown in FIG. Figure 3 As shown, the remote access device 300 is applied to the first device 10 and may include: a handshake module 310, a session establishment module 320 and an access module 330; wherein,

[0205] The handshake module 310 is configured to perform a QUIC protocol-based session handshake with the second device, wherein the QUIC protocol-based session handshake is used to declare an application layer protocol type for access authentication;

[0206] A session establishing module 320, configured to establish a QUIC session with a second device;

[0207] The access module 330 is used to perform access authentication interaction with the second device on the established QUIC session using an application layer protocol message corresponding to the application layer protocol type used for access authentication, thereby completing remote access on the second device.

[0208] In one possible implementation, the application layer protocol type used for access authentication includes a Dynamic Host Configuration Protocol (DHCP) type and an Extensible Authentication Protocol (EAP) type.

[0209] In one possible implementation, the handshake module 310 is further configured to declare the type of application layer protocol used for forwarding.

[0210] In one possible implementation, the apparatus 300 further includes:

[0211] The declaration module 340 is used to declare the application layer protocol type used for forwarding on the established QUIC session.

[0212] In one possible implementation, the application layer protocol type used for forwarding includes an L2 type and an L3 type.

[0213] In one possible implementation, the application layer protocol type used for access authentication is a DHCP type, and the access module 330 is further configured to send a first message to the second device, wherein the first message is configured to request allocation of an IP address to the second device;

[0214] receiving a second message sent by a second device, wherein the second message includes an assignable IP address;

[0215] Sending a third message to the second device, wherein the third message is used to confirm the allocatable IP address;

[0216] Receive a fourth message sent by the second device, where the fourth message includes the allocated IP address.

[0217] In one possible implementation, a DHCP-type application layer protocol is used for DHCP message interaction, and an EAP-type application layer protocol is used for EAP message interaction, wherein:

[0218] Each DHCP message or each EAP message is carried by one or more ALP_STREAM frames, and or one or more STREAM frames, or

[0219] Each DHCP message or each EAP message is carried by one or more ALP_DATAGRAM frames and / or one or more DATAGRAM frames.

[0220] In one possible implementation, the apparatus 300 further includes:

[0221] An access module 350 is configured to send an access message to the second device, wherein the access message is used to request access to network resources of the second device;

[0222] A response message sent by the second device is received, wherein the response message includes the network resource requested to be accessed by the first device.

[0223] In one possible implementation manner, the access message is carried by an ALP_DATAGRAM frame and / or a DATAGRAM frame.

[0224] Figure 4 This is a structural diagram of another embodiment of the remote access device of the present application, as shown in FIG. Figure 4 As shown, the remote access device 400 is applied to the second device 20 and may include: a handshake module 410, a session establishment module 420 and an authentication module 430; wherein,

[0225] The handshake module 410 is configured to perform a QUIC protocol-based session handshake with the first device, wherein the QUIC protocol-based session handshake is used to declare an application layer protocol type for access authentication;

[0226] A session establishing module 420, configured to establish a QUIC session with the first device;

[0227] The authentication module 430 is used to perform access authentication interaction with the first device on the established QUIC session using an application layer protocol message corresponding to the application layer protocol type used for access authentication, thereby completing remote access authentication of the first device.

[0228] In one possible implementation, the application layer protocol type used for access authentication includes a Dynamic Host Configuration Protocol (DHCP) type and an Extensible Authentication Protocol (EAP) type.

[0229] In one possible implementation, the handshake module 410 is further configured to declare the type of application layer protocol used for forwarding.

[0230] In one possible implementation, the apparatus 400 further includes:

[0231] The declaration module 440 is used to declare the application layer protocol type used for forwarding on the established QUIC session.

[0232] In one possible implementation, the application layer protocol type used for forwarding includes an L2 type and an L3 type.

[0233] In one possible implementation, the application layer protocol type used for access authentication is a DHCP type, and the authentication module 430 is further configured to receive a first message sent by the first device, wherein the first message is used to request allocation of an IP address to the second device;

[0234] Sending a second message to the first device, wherein the second message includes an assignable IP address;

[0235] receiving a third message sent by the first device, wherein the third message is used to confirm an allocatable IP address;

[0236] A fourth message is sent to the first device, where the fourth message includes the allocated IP address.

[0237] In one possible implementation, a DHCP-type application layer protocol is used for DHCP message interaction, and an EAP-type application layer protocol is used for EAP message interaction, wherein:

[0238] Each DHCP message or each EAP message is carried by one or more ALP_STREAM frames, and or one or more STREAM frames, or

[0239] Each DHCP message or each EAP message is carried by one or more ALP_DATAGRAM frames and / or one or more DATAGRAM frames.

[0240] In one possible implementation, the apparatus 400 further includes:

[0241] A response module 450 is configured to receive an access message sent by the first device, wherein the access message is used to request access to network resources of the second device;

[0242] A response message is sent to the first device, where the response message includes the network resource requested to be accessed by the first device.

[0243] In one possible implementation manner, the access message is carried by an ALP_DATAGRAM frame and / or a DATAGRAM frame.

[0244] Figure 3 and Figure 4 The remote access device 300 and the remote access device 400 provided in the embodiment shown can be used to execute the present application. Figure 1a 、 Figure 1b 、 Figure 1c and Figure 2The technical solution of the method embodiment shown, its implementation principle and technical effects can be further referred to the relevant description in the method embodiment.

[0245] It should be understood that the above Figure 3 and Figure 4 The division of the various modules of the remote access device shown is merely a division of logical functions. In actual implementation, they can be fully or partially integrated into a single physical entity or physically separated. Furthermore, these modules can be implemented entirely as software invoked through a processing element, or entirely as hardware. Alternatively, some modules can be implemented as software invoked through a processing element, while others can be implemented as hardware. For example, the detection module can be a separate processing element or integrated into a chip within an electronic device. The implementation of other modules is similar. Furthermore, these modules can be fully or partially integrated or implemented independently. During implementation, each step of the above method or each of the above modules can be completed by hardware integrated logic circuits within a processor element or by software instructions.

[0246] For example, the above modules may be one or more integrated circuits configured to implement the above methods, such as one or more application-specific integrated circuits (ASICs), one or more microprocessors (DSPs), or one or more field programmable gate arrays (FPGAs). For another example, these modules may be integrated together to implement a system-on-a-chip (SOC).

[0247] The following combination Figure 5 The exemplary electronic devices provided in the following embodiments of the present application are further introduced. Figure 5 A structural schematic diagram of an electronic device 500 is shown, and the electronic device 500 may be the first device 10 or the second device 20 described above.

[0248] The electronic device 500 may include: at least one processor; and at least one memory in communication with the processor, wherein the memory stores program instructions that can be executed by the processor, and the processor calls the program instructions to execute the application. Figure 1a 、 Figure 1b 、 Figure 1c and Figure 2 The illustrated embodiment provides a remote access method.

[0249] Figure 5 A block diagram of an exemplary electronic device 500 suitable for implementing embodiments of the present application is shown. Figure 5 The electronic device 500 shown is merely an example and should not limit the functions and scope of use of the embodiments of the present application.

[0250] like Figure 5 As shown, electronic device 500 is implemented as a general-purpose computing device. Components of electronic device 500 may include, but are not limited to, one or more processors 510, memory 520, a communication bus 540 connecting various system components (including memory 520 and processor 510), and a communication interface 530.

[0251] Communication bus 540 represents one or more of several types of bus structures, including a memory bus or memory controller, a peripheral bus, an accelerated graphics port, a processor, or a local bus using any of a variety of bus architectures. Examples of these architectures include, but are not limited to, the Industry Standard Architecture (ISA) bus, the Micro Channel Architecture (MAC) bus, the Enhanced ISA bus, the Video Electronics Standards Association (VESA) local bus, and the Peripheral Component Interconnection (PCI) bus.

[0252] The electronic device 500 typically includes a variety of computer system readable media, which can be any available media that can be accessed by the electronic device, including volatile and non-volatile media, removable and non-removable media.

[0253] The memory 520 may include computer system readable media in the form of volatile memory, such as random access memory (RAM) and / or cache memory. The electronic device may further include other removable / non-removable, volatile / non-volatile computer system storage media. Figure 5Not shown, a disk drive for reading and writing to a removable non-volatile disk (e.g., a "floppy disk"), and an optical disk drive for reading and writing to a removable non-volatile optical disk (e.g., a Compact Disc Read Only Memory (hereinafter referred to as: CD-ROM), a Digital Video Disc Read Only Memory (hereinafter referred to as: DVD-ROM), or other optical media) may be provided. In these cases, each drive can be connected to the communication bus 540 via one or more data medium interfaces. The memory 520 may include at least one program product having a set (e.g., at least one) of program modules that are configured to perform the functions of the various embodiments of the present application.

[0254] A program / utility having a set (at least one) of program modules may be stored in memory 520. Such program modules include, but are not limited to, an operating system, one or more application programs, other program modules, and program data, each of which, or some combination thereof, may include an implementation of a network environment. The program modules generally perform the functions and / or methods of the embodiments described herein.

[0255] The electronic device 500 may also communicate with one or more external devices (e.g., keyboard, pointing device, display, etc.), one or more devices that enable a user to interact with the electronic device, and / or any device that enables the electronic device to communicate with one or more other computing devices (e.g., network card, modem, etc.). Such communication may be performed through the communication interface 530. In addition, the electronic device 500 may also communicate with the network adapter ( Figure 5 The network adapter can communicate with other modules of the electronic device through the communication bus 540. It should be understood that although Figure 5 Not shown, other hardware and / or software modules may be used in conjunction with the electronic device 500, including but not limited to: microcode, device drivers, redundant processing units, external disk drive arrays, disk arrays (Redundant Arrays of Independent Drives; hereinafter referred to as: RAID) systems, tape drives, and data backup storage systems.

[0256] The processor 510 executes various functional applications and data processing by running the programs stored in the memory 520, such as implementing the remote access method provided in the embodiment of the present application.

[0257] It is understood that the interface connection relationship between the modules illustrated in the embodiment of the present application is merely an illustrative illustration and does not constitute a structural limitation on the electronic device 500. In other embodiments of the present application, the electronic device 500 may also adopt a different interface connection method from the above embodiment, or a combination of multiple interface connection methods.

[0258] It is understandable that, in order to realize the above functions, the above-mentioned electronic devices and the like include hardware structures and / or software modules corresponding to the execution of each function. Those skilled in the art should easily realize that, in combination with the units and algorithm steps of each example described in the embodiments disclosed herein, the embodiments of the present application can be implemented in the form of hardware or a combination of hardware and computer software. Whether a function is executed in the form of hardware or computer software driving hardware depends on the specific application and design constraints of the technical solution. Professional and technical personnel can use different methods to implement the described functions for each specific application, but such implementation should not be considered to exceed the scope of the embodiments of the present application.

[0259] The embodiment of the present application can divide the functional modules of the above-mentioned electronic device etc. according to the above-mentioned method example. For example, each functional module can be divided corresponding to each function, or two or more functions can be integrated into one processing module. The above-mentioned integrated module can be implemented in the form of hardware or in the form of software functional modules. It should be noted that the division of modules in the embodiment of the present application is schematic and is only a logical function division. There may be other division methods in actual implementation.

[0260] Through the description of the above embodiments, those skilled in the art will clearly understand that for the sake of convenience and brevity, only the division of the above functional modules is used as an example. In actual applications, the above functions can be assigned to different functional modules as needed, that is, the internal structure of the device can be divided into different functional modules to complete all or part of the functions described above. The specific working processes of the above-described systems, devices, and units can refer to the corresponding processes in the aforementioned method embodiments and will not be repeated here.

[0261] The functional units in the various embodiments of the present application may be integrated into a single processing unit, or each unit may exist physically separately, or two or more units may be integrated into a single unit. The aforementioned integrated units may be implemented in the form of hardware or software functional units.

[0262] If the integrated unit is implemented in the form of a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the embodiment of the present application is essentially or the part that contributes to the prior art or all or part of the technical solution can be embodied in the form of a software product, and the computer software product is stored in a storage medium, including a number of instructions for enabling a computer device (which can be a personal computer, a server, or a network device, etc.) or a processor to perform all or part of the steps of the method described in each embodiment of the present application. The aforementioned storage medium includes: various media that can store program codes, such as flash memory, mobile hard disk, read-only memory, random access memory, magnetic disk or optical disk.

[0263] The above is only a specific embodiment of the present application, but the scope of protection of this application is not limited to this. Any changes or substitutions within the technical scope disclosed in this application should be included in the scope of protection of this application. Therefore, the scope of protection of this application should be based on the scope of protection of the claims.

Claims

1. A remote access method, applied to a first device, characterized in that: The method comprises: Performing a QUIC protocol-based session handshake with the second device, wherein the QUIC protocol-based session handshake is used to declare an application layer protocol type for access authentication; Establishing a QUIC session with the second device; On the established QUIC session with the second device, use the application layer protocol message corresponding to the application layer protocol type used for access authentication to perform access authentication interaction with the second device to complete remote access on the second device.

2. The method according to claim 1, characterized in that The application layer protocol type used for access authentication includes a Dynamic Host Configuration Protocol (DHCP) type and an Extensible Authentication Protocol (EAP) type.

3. The method according to claim 1 or 2, characterized in that The QUIC protocol-based session handshake is also used to declare the application layer protocol type for forwarding.

4. The method according to claim 1 or 2, characterized in that After completing the remote access on the second device, the method further includes: Declare an application layer protocol type for forwarding on the established QUIC session with the second device.

5. The method according to claim 3, characterized in that The application layer protocol type used for forwarding includes L2 type and L3 type.

6. The method according to claim 4, characterized in that The application layer protocol type used for forwarding includes L2 type and L3 type.

7. The method according to claim 2, characterized in that The application layer protocol type for access authentication is a DHCP type, and the performing access authentication interaction with the second device includes: Sending a first message to the second device, wherein the first message is used to request allocation of an IP address to the second device; receiving a second message sent by the second device, wherein the second message includes an assignable IP address; Sending a third message to the second device, wherein the third message is used to confirm the allocatable IP address; Receive a fourth message sent by the second device, wherein the fourth message includes the allocated IP address.

8. The method according to claim 2, characterized in that The DHCP type application layer protocol is used for DHCP message interaction, and the EAP type application layer protocol is used for EAP message interaction, wherein: Each of the DHCP messages or each of the EAP messages is carried by one or more ALP_STREAM frames and / or one or more STREAM frames, or Each of the DHCP messages or each of the EAP messages is carried by one or more ALP_DATAGRAM frames and / or one or more DATAGRAM frames.

9. The method according to claim 1 or 2, characterized in that The method further comprises: Sending an access message to the second device, wherein the access message is used to request access to network resources of the second device; A response message sent by the second device is received, wherein the response message includes the network resource requested to be accessed by the first device.

10. The method according to claim 9, characterized in that The access message is carried by an ALP_DATAGRAM frame and / or a DATAGRAM frame.

11. A remote access method, applied to a second device, characterized in that: The method comprises: Performing a QUIC protocol-based session handshake with the first device, wherein the QUIC protocol-based session handshake is used to declare an application layer protocol type for access authentication; Establishing a QUIC session with the first device; On the established QUIC session with the first device, use the application layer protocol message corresponding to the application layer protocol type used for access authentication to perform access authentication interaction with the first device to complete remote access authentication of the first device.

12. The method according to claim 11, characterized in that The application layer protocol type used for access authentication includes a Dynamic Host Configuration Protocol (DHCP) type and an Extensible Authentication Protocol (EAP) type.

13. The method according to claim 11 or 12, characterized in that The QUIC protocol-based session handshake is also used to declare the application layer protocol type for forwarding.

14. The method according to claim 11 or 12, characterized in that After completing the remote access authentication of the first device, the method further includes: Declare an application layer protocol type for forwarding on the established QUIC session with the first device.

15. The method according to claim 13, characterized in that The application layer protocol type used for forwarding includes L2 type and L3 type.

16. The method according to claim 14, characterized in that The application layer protocol type used for forwarding includes L2 type and L3 type.

17. The method according to claim 12, characterized in that The application layer protocol type for access authentication is a DHCP type, and the access authentication interaction with the first device includes: receiving a first message sent by the first device, wherein the first message is used to request allocation of an IP address to the second device; Sending a second message to the first device, wherein the second message includes an assignable IP address; receiving a third message sent by the first device, wherein the third message is used to confirm the allocatable IP address; Send a fourth message to the first device, where the fourth message includes the allocated IP address.

18. The method according to claim 12, characterized in that The DHCP type application layer protocol is used for DHCP message interaction, and the EAP type application layer protocol is used for EAP message interaction, wherein: Each of the DHCP messages or each of the EAP messages is carried by one or more ALP_STREAM frames and / or one or more STREAM frames, or Each of the DHCP messages or each of the EAP messages is carried by one or more ALP_DATAGRAM frames and / or one or more DATAGRAM frames.

19. The method according to claim 11 or 12, characterized in that The method further comprises: receiving an access message sent by the first device, wherein the access message is used to request access to network resources of the second device; A response message is sent to the first device, wherein the response message includes the network resource requested to be accessed by the first device.

20. The method according to claim 19, characterized in that The access message is carried by an ALP_DATAGRAM frame and / or a DATAGRAM frame.

21. A first device, characterized in that: include: A memory, wherein the memory is used to store computer program code, wherein the computer program code includes instructions, and when the first device reads the instructions from the memory, the first device executes the method according to any one of claims 1 to 10.

22. A second device, characterized in that: include: A memory, wherein the memory is used to store computer program code, wherein the computer program code includes instructions, and when the second device reads the instructions from the memory, the second device executes the method according to any one of claims 11 to 20.

23. A computer-readable storage medium, characterized in that The method comprises computer instructions, which, when the computer instructions are executed on the first device, cause the first device to execute the method as described in any one of claims 1-10, or when the computer instructions are executed on the second device, cause the second device to execute the method as described in any one of claims 11-20.

24. A computer program product, characterized in that When the computer program product is run on a computer, the computer is caused to perform the method according to any one of claims 1 to 20.

Images