CN115567497A

CN115567497A - Remote access method, electronic device and storage medium

Info

Publication number: CN115567497A
Application number: CN202110741989.1A
Authority: CN
Inventors: 梁乾灯; 康娇
Original assignee: Huawei Technologies Co Ltd
Current assignee: Huawei Technologies Co Ltd
Priority date: 2021-07-01
Filing date: 2021-07-01
Publication date: 2023-01-03
Also published as: WO2023274146A1

Abstract

The embodiment of the application provides a remote access method, electronic equipment and a storage medium, which relate to the technical field of information, and the method comprises the following steps: performing a QUIC protocol-based session handshake with a second device, wherein the QUIC protocol-based session handshake is used for declaring an application layer protocol type for access authentication; establishing a QUIC session with the second device; and performing access authentication interaction with the second equipment by using the application layer protocol message corresponding to the application layer protocol type for access authentication on the established QUIC session, and completing remote access on the second equipment. The method provided by the embodiment of the application can improve the efficiency of remote access and reduce the cost of network deployment.

Description

Remote access method, electronic device and storage medium

Technical Field

The embodiment of the application relates to the technical field of information, in particular to a remote access method, electronic equipment and a storage medium.

Background

A Dynamic Host Configuration Protocol (DHCP) is a Protocol widely deployed on network devices and intelligent terminals, and is used to implement Dynamic IP address allocation management and other network-related Configuration work, reduce the burden of planning, management and maintenance of a TCP/IP network, and solve the problem of lack of IP address space. It will be appreciated that the above DHCP also includes DHCP, v6 version, DHCP v6.

The DHCP/DHCPv6 is packaged by a User Datagram Protocol (UDP), the client requests the response of a DHCP Server or a DHCP relay/proxy device in a local area network by adopting a two-layer broadcasting mode, one DHCP Server or DHCP relay/proxy device is preferably selected from the DHCP devices which obtain the response to complete the interaction process of the DHCP, and the corresponding IP address is obtained.

At present, when the client equipment is remotely accessed to an organization private network from a local network, DHCP/DHCPv6 can not directly cross a public network. It is common practice to deploy a Virtual Private Network (VPN) Private line, for example, an IPSec tunnel between an egress Access Router (AR) device of a local Network and an ingress AR device of an enterprise Private Network, or a dedicated VPN client on a client device, to enable remote access of the client device from the local Network to the enterprise Private Network. However, the deployment configuration is complex and costly, for example, the deployment of the VPN dedicated line is complex and costly, and the IPSec is less practically applied to the notebook computer and the smart phone.

Disclosure of Invention

The embodiment of the application provides a remote access method, electronic equipment and a storage medium, and aims to provide a way for remotely accessing a client device to an enterprise private network, and connection is established between the client device and the enterprise private network through access authentication interaction based on a QUIC protocol, so that the remote access efficiency can be improved, and the network deployment cost can be reduced.

In a first aspect, an embodiment of the present application provides a remote access method, which is applied to a first device, and includes:

performing session handshake based on QUIC protocol with the second device, wherein the session handshake based on the QUIC protocol is used for declaring an application layer protocol type for access authentication; establishing a QUIC session with a second device; and performing access authentication interaction with the second equipment by using the application layer protocol message corresponding to the application layer protocol type used for access authentication on the established QUIC session, and completing remote access on the second equipment.

In the embodiment of the application, the application layer protocol type used for access authentication is declared in the handshake phase of the QUIC session, and after the QUIC session is established, the declared application layer protocol message is used for remote access interaction on the QUIC session, so that remote access authentication is completed, the efficiency of remote access can be improved, and the network deployment cost can be saved.

In one possible implementation manner, 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 may be improved.

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

In the embodiment of the application, the declaration of the application layer protocol type for forwarding after authentication can be avoided by declaring the application layer protocol type for forwarding in the QUIC handshake phase, so that the efficiency can be improved.

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

on an established QUIC session, the application layer protocol type for forwarding is declared.

In the embodiment of the application, after the authentication is completed, the application layer protocol type for forwarding is declared, so that the first device can be prevented from accessing the managed and controlled network resource of the second device before the authentication is successful, and further, the network security problem can be avoided.

In one possible implementation manner, the application layer protocol types for forwarding include an L2 type and an L3 type. By declaring different types of application layer protocol messages for forwarding, the flexibility of selection may be increased.

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

sending a first message to second equipment, wherein the first message is used for requesting the second equipment to distribute an IP address; receiving a second message sent by second equipment, wherein the second message comprises an assignable IP address; sending a third message to the second device, wherein the third message is used for confirming the assignable IP addresses; and receiving a fourth message sent by the second equipment, wherein the fourth message comprises the allocated IP address.

In one possible implementation, 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 DHCP message or each EAP message is carried by one or more ALP _ STREAM frames, and or one or more STREAM frames, or

Each DHCP message or said EAP message is carried by one or more ALP _ DATAGRAM frames, and/or one or more DATAGRAM frames.

In the embodiment of the present application, the different types of frames (e.g., STREAM frames or DATAGRAM frames) are used to carry the message, so that the flexibility of message transmission can be improved.

In one possible implementation manner, the method further includes:

sending an access message to the second device, wherein the access message is used for requesting to access the network resource of the second device;

and receiving a response message sent by the second equipment, wherein the response message comprises the network resource which is requested to be accessed by the first equipment.

In one possible implementation manner, the access packet is carried by an ALP _ DATAGRAM frame and/or a DATAGRAM frame.

The embodiment of the application further provides a remote access method, which is applied to a second device and includes:

performing session handshake based on QUIC protocol with the first device, wherein the session handshake based on the QUIC protocol is used for declaring an application layer protocol type for access authentication; establishing a QUIC session with a first device; and on the established QUIC session, performing access authentication interaction with the first equipment by using an application layer protocol message corresponding to the application layer protocol type used for access authentication to finish remote access authentication of the first equipment.

In one possible implementation manner, the application layer protocol type used for access authentication includes a dynamic host configuration protocol DHCP type and an extensible authentication protocol EAP type.

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

In one possible implementation manner, after the remote access authentication on the first device is completed, the method further includes:

In one possible implementation, the application layer protocol types used for forwarding include an L2 type and an L3 type.

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

receiving a first message sent by first equipment, wherein the first message is used for requesting allocation of an IP address to second equipment; sending a second message to the first equipment, wherein the second message comprises an assignable IP address; receiving a third message sent by the first equipment, wherein the third message is used for confirming an assignable IP address; and sending a fourth message to the first equipment, wherein the fourth message comprises the allocated IP address.

Each DHCP message or each EAP message is carried by one or more ALP _ DATAGRAM frames, and/or one or more DATAGRAM frames.

In one possible implementation manner, the method further includes:

receiving an access message sent by first equipment, wherein the access message is used for requesting to access network resources of second equipment; and sending a response message to the first equipment, wherein the response message comprises the network resource which is requested to be accessed by the first equipment.

In one possible implementation, the access message is carried by an ALP _ DATAGRAM frame and/or a DATAGRAM frame.

In a second aspect, an embodiment of the present application provides a remote access apparatus, which is applied to a first device, and includes:

the handshake module is used for carrying out session handshake based on a QUIC protocol with the second equipment, wherein the session handshake based on the QUIC protocol is used for declaring the type of an application layer protocol used for access authentication;

the session establishing module is used for establishing a QUIC session with the second equipment;

and the access module is used for performing access authentication interaction with the second equipment by using the application layer protocol message corresponding to the application layer protocol type used for access authentication on the established QUIC session so as to finish remote access on the second equipment.

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

In one possible implementation manner, the apparatus further includes:

and the declaration module is used for declaring the application layer protocol type for forwarding on the established QUIC session.

In one possible implementation manner, the application layer protocol type used for the access authentication is a DHCP type, and the access module is further configured to send a first packet to the second device, where the first packet is used to request the second device to allocate an IP address;

receiving a second message sent by second equipment, wherein the second message comprises an assignable IP address;

sending a third message to the second device, wherein the third message is used for confirming the assignable IP address;

and receiving a fourth message sent by the second equipment, wherein the fourth message comprises the allocated IP address.

In one possible implementation manner, the apparatus further includes:

the access module is used for sending an access message to the second equipment, wherein the access message is used for requesting to access the network resource of the second equipment;

The embodiment of the present application further provides a remote access apparatus, which is applied to a second device, and includes:

the session handshake module is used for carrying out session handshake based on a QUIC protocol with the first equipment, wherein the session handshake based on the QUIC protocol is used for declaring an application layer protocol type used for access authentication;

the session establishing module is used for establishing a QUIC session with the first equipment;

and the authentication module is used for performing access authentication interaction with the first equipment by using the application layer protocol message corresponding to the application layer protocol type used for access authentication on the established QUIC session so as to finish remote access authentication of the first equipment.

In one possible implementation manner, the apparatus further includes:

In one possible implementation, the application layer protocol types used for forwarding include L2 type and L3 type.

In one possible implementation manner, 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 a first device, where the first message is used to request a second device to assign an IP address;

sending a second message to the first equipment, wherein the second message comprises an assignable IP address;

receiving a third message sent by the first equipment, wherein the third message is used for confirming an assignable IP address;

and sending a fourth message to the first equipment, wherein the fourth message comprises the allocated IP address.

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,

In one possible implementation manner, the apparatus further includes:

the response module is used for receiving an access message sent by the first equipment, wherein the access message is used for requesting to access the network resource of the second equipment;

and sending a response message to the first equipment, wherein the response message comprises the network resource which is requested to be accessed by the first equipment.

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

a memory for storing computer program code, the computer program code including instructions that, when read from the memory, cause the first device to perform the steps of:

performing session handshake based on QUIC protocol with the second device, wherein the session handshake based on the QUIC protocol is used for declaring an application layer protocol type for access authentication;

establishing a QUIC session with a second device;

and performing access authentication interaction with the second equipment by using the application layer protocol message corresponding to the application layer protocol type used for access authentication on the established QUIC session, and completing remote access on the second equipment.

In one possible implementation manner, the application layer protocol type for access authentication includes a dynamic host configuration protocol DHCP type and an extensible authentication protocol EAP type.

In one possible implementation manner, when the instruction is executed by the first device, after the step of completing the remote access on the second device, the first device further executes the following steps:

on the established QUIC session, the application layer protocol type for forwarding is declared.

In one possible implementation manner, the application layer protocol type for access authentication is a DHCP type, and when the instruction is executed by the first device, the step of enabling the first device to perform access authentication interaction with the second device includes:

sending a first message to second equipment, wherein the first message is used for requesting the second equipment to distribute an IP address;

sending a third message to the second device, wherein the third message is used for confirming the assignable IP addresses;

and receiving a fourth message sent by the second device, wherein the fourth message contains the allocated IP address.

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

An embodiment of the present application further provides a second device, including:

a memory, wherein the memory is used for storing computer program code, and the computer program code comprises instructions, and when the second device reads the instructions from the memory, the second device executes the following steps:

performing session handshake based on QUIC protocol with the first device, wherein the session handshake based on the QUIC protocol is used for declaring an application layer protocol type for access authentication;

establishing a QUIC session with a first device;

and on the established QUIC session, performing access authentication interaction with the first equipment by using an application layer protocol message corresponding to the application layer protocol type used for access authentication, and completing remote access authentication of the first equipment.

In one possible implementation manner, when the instruction is executed by the second device, the second device further performs the following steps after the step of performing remote access authentication on the first device is performed:

In one possible implementation manner, the application layer protocol type for access authentication is a DHCP type, and when the instruction is executed by the second device, the step of the second device performing access authentication interaction with the first device includes:

receiving a first message sent by first equipment, wherein the first message is used for requesting to allocate an IP address to second equipment;

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

receiving an access message sent by first equipment, wherein the access message is used for requesting to access network resources of second equipment;

In a fourth aspect, embodiments of the present application provide a computer-readable storage medium having stored thereon a computer program, which, when run on a computer, causes the computer to perform the method according to the first aspect.

In a fifth aspect, the present application provides a computer program, which is configured to perform the method of the first aspect when the computer program is executed by a computer.

In a 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 in part or in whole on a memory not packaged with the processor.

Drawings

Fig. 1a to fig. 1c are schematic diagrams of application scenarios provided in an embodiment of the present application;

fig. 2 is a flowchart illustrating an embodiment of a remote access method provided in the present application;

fig. 3 is a schematic structural diagram of an embodiment of a remote access apparatus provided in the present application;

fig. 4 is a schematic structural diagram of another embodiment of a remote access device provided in the present application;

fig. 5 is a schematic diagram of a hardware structure of an electronic device according to an embodiment of the present application.

Detailed Description

The technical solutions in the embodiments of the present application will be described below with reference to the drawings in the embodiments of the present application. In the description of the embodiments herein, "/" means "or" unless otherwise specified, for example, a/B may mean a or B; "and/or" herein is merely an association describing an associated object, and means that there may be three relationships, e.g., a and/or B, which may mean: a exists alone, A and B exist simultaneously, and B exists alone.

In the following, the terms "first", "second" are used for descriptive purposes only and are not to be understood as indicating or implying relative importance or implicitly indicating the number of technical features indicated. Thus, a feature defined as "first" or "second" may explicitly or implicitly include one or more of that feature. In the description of the embodiments of the present application, "a plurality" means two or more unless otherwise specified.

The TCP/IP suite of protocols is the foundation of the internet. The transport layer Protocol includes a Transmission Control Protocol (TCP) and a User Datagram Protocol (UDP). UDP is more lightweight than TCP, but error checking is much less. Since in the UDP protocol, the client does not communicate with the server frequently to see if the packets are delivered or in order, this means that UDP is often more efficient. However, UDP is less reliable than TCP. In general, UDP is used for game, streaming, and VoIP applications, and TCP is used for most applications such as web pages, mail, and telnet.

The DHCP/DHCPv6 adopts encapsulation, the client requests the reply of the DHCP Server or the DHCP relay/proxy equipment in the local area network by adopting a two-layer broadcasting mode, and selects one DHCP Server or the DHCP relay/proxy equipment from the DHCP equipment which obtains the reply to complete the interaction process of the DHCP, so as to obtain the corresponding IP address.

Currently, when a client device remotely accesses an organization's private network from a local network, the DHCP/DHCPv6 cannot directly traverse the public network. It is common practice to deploy a Virtual Private Network (VPN) Private line, for example, an IPSec tunnel between an egress Access Router (AR) device of a local Network and an ingress AR device of an enterprise Private Network, or a special VPN client on a client device, to enable remote access of the client device from the local Network to the enterprise Private Network. However, the above deployment configuration is complex and costly, for example, the deployment of the VPN private line is complex and costly, and IPSec is less practically applied to notebook computers and smart phones.

The fast UDP Internet Connection (QUIC) protocol multiplexes the transport layers: after the basic connection between the client and the server is established, for the transmission of each webpage element, a 'Stream' (Stream) is provided for data transmission, the opening and closing of the Stream are light-weight and do not influence the connection to which the Stream belongs, and the Stream is independent from the Stream and does not influence the transmission of the Stream. The QUIC protocol supports encryption and can provide a secure transmission channel.

The QUIC message is carried over UDP. The QUIC message may contain one or more STREAM frames. The STREAM frame is used as a special type of frame in the QUIC message to distinguish different traffic STREAMs carrying an application. For example, an audio/video service stream, an application text service stream, or an application layer control protocol service stream of the same service. Stream is a reliable transmission mechanism because of the acknowledgment and retransmission mechanisms.

In addition, the QUIC protocol also includes a transport mechanism that carries data frames without reliability guarantees. Wherein, the DATAGRAM frame can also be extended to add a Flow ID field, and the Flow ID is used to identify different service sessions or interactive requests.

In order to solve the above problem, the embodiment of the present application proposes a remote access method based on the above QUIC protocol to implement DHCP remote access, and the above remote access method can be applied to the first device 10 and the second device 20. By way of example, the first device 10 may be a client device, which may include, but is not limited to, a mobile phone, a tablet (pad), a computer with transceiving 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 Driving (Self Driving), a wireless terminal in Remote Medical (Remote Medical), a wireless terminal in Smart Grid, a wireless terminal in Transportation security (Transportation security), a wireless terminal in 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 may include, but is not limited to, devices such as a three-layer switch, a router, a broadband gateway, a firewall, a load balancer, and the like. The second device 20 may be a server. The server may provide services to the client device, e.g., may provide resources to the client device, save client data, and so on.

Fig. 1a to fig. 1c show three application scenarios of the above remote access method.

Fig. 1a is a schematic diagram of an application scenario 1. As shown in fig. 1a, the application scenario 1 includes a first device 10, a second device 20, and a third device 30. 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 a DHCP proxy. The first device 10 is connected to the third device 30 through DHCP, and the second device 20 is interacted with the third device 30 through the DHCP protocol based on QUIC protocol. Thus, the third device 30 may 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 by establishing a QUIC session between the third device 30 and the second device 20, a secure and reliable three-layer tunnel can be provided, and thus a public network can be spanned to realize remote access, and private network device network configuration information transmitted in a DHCP message can be prevented from being intercepted by the intermediate device.

Fig. 1b is a schematic diagram of an architecture of an application scenario 2. As shown in fig. 1b, the application scenario 2 includes a first device 10, a second device 20, and a third device 30. 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 a DHCP proxy. The second device 20 is connected to the third device 30 via a DHCP connection, and the second device 20 is interacting with the first device 10 via a DHCP protocol based on the QUIC protocol. Thus, the third device 30 may be a device on 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 by establishing a QUIC session between the third device 30 and the first device 10, a secure and reliable three-layer tunnel can be provided, and thus a public network can be spanned to achieve remote access, and private network device network configuration information transferred in a DHCP message can be prevented from being intercepted by an intermediate device.

Fig. 1c is a schematic diagram of the architecture of application scenario 3. As shown in fig. 1c, the 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 second device 20 interacts with the first device 10 via the DHCP protocol based on the QUIC protocol. By establishing the QUIC session between the second device 20 and the first device 10, a secure and reliable three-layer tunnel can be provided, which can cross the public network to realize 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.

Next, an example in which the first device 10 remotely accesses an enterprise private network in which the second device 20 is located by way of DHCP interaction will be described.

Fig. 2 is a schematic flowchart of an embodiment of a remote access method provided in the embodiment of the present application, including:

in step 201, the first device 10 sends a remote access request to the second device 20 for establishing a QUIC session with the second device 20.

Specifically, the user may operate on the first device 10, for example, the user may configure an application layer protocol type for access authentication on the first device 10, and may initiate remote access authentication according to the configured application layer protocol type for access authentication, that is, the first device 10 may complete remote access authentication by using an access authentication interaction based on the QUIC protocol. In response to the user's operation, the first device 10 may send a remote access request to the second device 20 to establish a QUIC session with the second device 20 for remote access to the corporate private network where the second device 20 is located.

In addition, the user may also configure the application layer protocol type for forwarding on the first device. The application layer protocol type used for forwarding can be used for forwarding the application layer protocol message after the access authentication is successful. The application layer protocol message may be a data packet corresponding to the application layer protocol type.

In this embodiment of the present application, the application layer Protocol type for access Authentication may include a DHCP type and an Extensible Authentication Protocol (EAP) type. Illustratively, the DHCP types may include DHCP over quick and DHCPv 6over quick. The DHCP over Quic is used for representing DHCP interaction based on the QUIC protocol, and the DHCPv 6over Quic is used for representing DHCPv6 interaction based on the QUIC protocol. In a specific implementation, DHCP over Quic may be identified by the string "dhcpoq", and DHCP over Quic may be identified by the string "dhcpv6 oq".

The application layer protocol types for forwarding may include L2 type and L3 type. The L2 type may include an ethernet over Quic, where the ethernet over Quic is used to characterize ethernet interaction based on the QUIC protocol. In a specific implementation, the ethernet over Quic can be identified by the string "ethoq". The L3 type may include IPv4 over Quic and IPv6over Quic. The IPv4 over Quic is used for representing IPv4 interaction based on the QUIC protocol, and the IPv6over Quic is used for representing Ipv6 interaction based on the QUIC protocol. In specific implementation, IPv4 over Quic may be identified by a character string "IPv4oq", and IPv6over Quic may be identified by a character string "IPv6 oq". The above-mentioned character string may be created in a registry of an Application Layer Protocol Negotiation (ALPN) Protocol.

It is understood that after the first device 10 sends the remote access request to the second device 20, the second device 20 may perform a session handshake based on the QUIC protocol 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 interaction processes between the first device 10 and the second device 20, and the above-mentioned handshake process based on the QUIC protocol may complete authentication, capability negotiation, and key interaction, and specifically, refer to the QUIC protocol, and will not be described herein again. Wherein the above capability negotiation may be used to complete the declaration of the application layer protocol type between the first device 10 and the second device 20.

Optionally, the handshake based on the QUIC protocol may be triggered by a first DHCP Discovery message or a SOLICIT message of the DHCPv6, or may be triggered by other application protocol session establishment requests carried on the QUIC session, and then the DHCP or DHCPv6 may multiplex the QUIC session to complete DHCP or DHCPv6 protocol interaction.

It should be noted that, in the session handshake process based on the QUIC Protocol, the first device 10 and the second device 20 may declare an Application Layer Protocol type of a supported bearer through an Application Layer Protocol Negotiation (ALPN), where the declared Application Layer Protocol type may include an Application Layer Protocol type for access authentication. That is, by declaring the above application layer protocol type, application layer protocol messages supporting the bearer can be declared. For example, the protocol type of "dhcpoq" may be used to declare that the QUIC session supports the transmission of application layer protocol messages corresponding to "dhcpoq", such as DHCP messages; the protocol type of "dhcpoqv6" may be used to declare that the QUIC session supports the transmission of application layer protocol messages corresponding to "dhcpqv 6", such as DHCPv6 messages.

Optionally, the declared application layer protocol type may further include an application layer protocol type for forwarding. Illustratively, 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 an ethernet packet; the protocol type of "IPv4oq" may be used to declare that the above-mentioned QUIC session supports the transmission of application layer protocol messages corresponding to "IPv4", such as IPv4 messages; the protocol type of "Ipv6oq" may be used to state that the above-mentioned QUIC session supports the transfer of application layer protocol messages corresponding to "Ipv6oq", such as the Ipv6 message.

The DHCP message or DHCPv6 message can be carried by the STREAM frame or the DATAGRAM frame, and the Ethernet message, IPv4 message or IPv6 message can be carried by the DATAGRAM frame

Optionally, the DHCP message or the DHCPv6 message may also be carried by an ALP _ STREAM frame or an ALP _ DATAGRAM frame, and the ethernet message, the IPv4 message, or the IPv6 message may also be carried by the ALP _ DATAGRAM frame. Wherein 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. Wherein the ALP field is used to characterize an application layer protocol type.

It is to be understood that when the DHCP message or DHCPv6 message is carried by an ALP _ STREAM frame and/or a STREAM frame, one DHCP message or DHCPv6 message may be carried by one or more ALP _ STREAM frames and/or one or more STREAM frames.

In addition, the types of application layer protocols supported by the above statements may be one or more. Illustratively, the application layer protocol type supported by the declaration may be DHCP over Quic or DHCPv 6over Quic, or may also be ethernet over Quic, IPv4 over Quic or IPv6. That is, when the application layer protocol type supported by the declaration is DHCP over quick or DHCPv 6over quick, the DHCP message or the DHCPv6 message may be carried by an ALP _ STREAM frame and/or a STREAM frame, or an ALP _ DATAGRAM frame and/or a DATAGRAM frame. When the application layer protocol type supported by the declaration is ethernet over Quic, IPv4 over Quic or IPv6over Quic, the DHCP message or DHCPv6 message and other protocol messages can be indirectly carried through the ethernet message, IPv4 message or IPv6 message.

For example, taking the first device 10 sending a DHCP message and applying for an IPv4 address as an example, at this time, the application layer protocol type declared to be supported may be IPv4 over quick. The first device 10 may create an ALP _ DATAGRAM and/or DATAGRAM frame that carries an IPv4 message, it may be understood that the IPv4 message may contain an IPv4 header and a payload that may be a DHCP message with a UDP header, thereby enabling indirect carrying of the DHCP message via the IPv4 message. It will be appreciated that the payload may also be other protocol messages, such as HTTP messages with TCP headers.

Next, taking the example that the first device 10 sends the DHCPv6 packet and applies for the IPv6 address, at this time, the application layer protocol type declared to be supported may be IPv6over quick. The first device 10 may create an ALP _ DATAGRAM and/or DATAGRAM frame that carries an IPv6 message, it being understood that the IPv6 message may contain an IPv6 header and a payload, which may be a DHCPv6 message, thereby enabling indirect carrying of the DHCPv6 message via the IPv6 message. It will be appreciated that the payload may also be other protocol messages, such as HTTP messages.

Further, taking the first device 10 sending a DHCP packet or a DHCPv6 packet as an example, in this case, the type of the application layer protocol declared to be supported may be ethernet over quick. The first device 10 may create an ALP _ DATAGRAM and/or DATAGRAM frame that carries an ethernet packet. It is understood that the ethernet packet may include an ethernet header, an IP header and a payload, and the payload may be a DHCP or DHCPv6 packet with a UDP header, so that indirect bearer of the DHCP or DHCPv6 packet through the ethernet packet may be achieved. The payload may be other protocol messages such as HTTP messages with TCP headers. It is understood that the IP header may be an IPv4 header or an IPv6 header, and the type of the IP header may be determined according to the type of the IP address applied by the first device 10.

Optionally, the declaration of the application layer protocol of the L2 type (e.g., ethernet over Quic) and the application layer protocol of the L3 type (e.g., IPv4 over Quic or IPv6over Quic) may be completed in the handshake process based on the Quic protocol, or may be completed through capability negotiation between the first device 10 and the second device 20 in the established Quic session, that is, the first device 10 may continue to declare the supported application layer protocol of the L2 and/or L3 type in the established Quic session after the access authentication is completed, so as to notify the application layer protocol of the L2 and/or L3 type supported by the second device 20, and the application embodiment does not specially limit the declaration time of the application layer protocol type of the Quic session.

In step 202, the first device 10 sends a first packet to the second device 20, for requesting to assign an IP address.

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 the DHCP message is carried, the first message may be a DHCP Discovery message. The first packet may also be a SOLICIT packet, for example, when the DHCPv6 packet is carried, the first packet may be a SOLICIT packet.

In a specific implementation, the first device 10 may create a bidirectional Stream with an ID of X and a first packet. Wherein X may be a predetermined integer (e.g., X is 16). The bidirectional Stream transmits an ALP _ Stream frame and/or a Stream frame, which may be used to carry the first message. The first message is used to request the second device 20 to assign an IP address, which is an IP address of an agency's private network, to the first device 10.

It is understood that the load of an ALP _ STREAM frame or STREAM frame is usually small and may not be enough to carry a first message carrying a large load, therefore, the first message may be divided into a plurality of sub-messages according to the maximum load of an ALP _ STREAM frame or STREAM frame, the sub-message of each first message is carried by an ALP _ STREAM frame or STREAM frame, and the sub-messages of the plurality of first messages may be reassembled at the second device 20, thereby recovering the first message. That is, the first message may be carried by one or more ALP _ STREAM frames, and or one or more STREAM frames.

Alternatively, when the first device 10 transmits Stream data to the second device 20, the first frame in the Stream may be an ALP _ Stream frame. The ALP _ STREAM frame may include a value of the STREAM ID (for example, the value is 16) and an identifier of an application layer protocol type carried by the STREAM ID (for example, the identifier is dhcpoq), so as to notify the second device 20 that the STREAM bearer corresponding to the STREAM ID is a DHCP message. That is to say, when the first device 10 can subsequently transmit the Stream frame corresponding to the same Stream ID, it is not necessary to continue to transmit the ALP _ Stream frame, so that the second device 20 can immediately recognize that the Stream frame corresponding to the Stream ID carries the DHCP message when it subsequently receives the Stream frame corresponding to the Stream ID.

It should be noted that the foregoing example only schematically illustrates a manner in which the first packet is carried by an ALP _ STREAM frame or a STREAM frame, and does not limit the embodiment of the present application. In some embodiments, the first packet may also be carried by an ALP _ DATAGRAM frame or a DATAGRAM frame, that is, the first packet may be carried by one or more ALP _ DATAGRAM frames and/or one or more DATAGRAM frames. For convenience of description, the ALP _ STREAM frame or the STREAM frame is used to carry other application layer protocol messages (e.g., the second message, the third message, and the fourth message) as an example, but the ALP _ STREAM frame or the STREAM frame is not limited to carry the second message, the third message, and the fourth message.

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

Specifically, after the second device 20 receives the first packet sent by the first device 10, the first packet may be parsed, so that an assignable IP address may be provided according to a parsing result. In a specific implementation, the manner of receiving the first packet by the second device 20 may be to obtain the first packet from an ALP _ STREAM frame or a STREAM frame, or to obtain sub-packets of the first packet from a group of ALP _ STREAM frames or STREAM frames, and to recombine the sub-packets of the first packet into the first packet.

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

Then, after the second device 20 authenticates the local Authentication, authorization and Accounting (AAA) module and the remote AAA server according to the user Authentication information of the first device 10 carried in the first message, a second message (application layer protocol message) may be created and encapsulated into an ALP _ STREAM frame and/or STREAM frame with an ID of X, where the second message may include an allocatable IP address. Then, the second device 20 may transmit the above ALP _ STREAM frame and/or STREAM frame having the ID X to the first device 10.

It can be understood that, if the first message is a DHCP Discovery message, the second message is a DHCP Offer message. And if the first message is the SOLICIT message of the DHCPv6, the second message is the ADVERTISE message of the DHCPv 6.

It should be noted that the second packet may also be divided into a plurality of sub-packets of the second packet, and each sub-packet of the second packet may be carried by one ALP _ STREAM frame or STREAM frame, so that the sub-packets of the plurality of second packets may be reassembled at the first device 10, and then the second packet is restored at the first device 10.

In step 204, the first device 10 parses the second packet, and sends a third packet to the second device 20 according to a parsing result, so as to confirm the allocated IP address.

Specifically, after receiving the second message sent by the second device 20, the first device 10 may analyze the second message, so as to obtain the IP address, which is carried by the second message and allocated by the second device 20, of the second message. The first device 10 may then create a third message (application layer protocol message) based on the assigned IP address. This third message may be used to confirm the use of the allocated IP address to the second device 20. Then, the first device 10 may encapsulate the third packet in an ALP _ STREAM frame and/or a STREAM frame having an ID of X, and may transmit the ALP _ STREAM frame and/or the STREAM frame to the second device 20.

It can be understood that, if the second message is a DHCP Offer message, the third message is a DHCP Request message. And if the second message is the ADVERTISE message of the DHCPv6, the third message is the REQUEST message of the DHCPv 6.

It should be noted that the third packet may also be divided into a plurality of sub-packets of the third packet, and each sub-packet of the third packet may be carried by one ALP _ STREAM frame or STREAM frame, so that the sub-packets of the plurality of third packets may be reassembled at the second device 20, and then the third packet is restored at the second device 20.

In step 205, the second device 20 parses the third packet, and sends a fourth packet to the first device 10 according to the parsing result, so as to confirm that the IP address is allocated.

Specifically, after the second device 20 receives the third message sent by the first device 10, the third message may be parsed, so that the confirmation information of the IP address allocated to the second device 20 in the third message may be obtained. The second device 20 may then assign the IP address to the first device 10 and may create a fourth message (application layer protocol message) based on the confirmation information, which may be used to inform the first device 10 that the IP address has been confirmed to be assigned to the first device 10. Then, the second device 20 may encapsulate the fourth message in an ALP _ STREAM frame and/or a STREAM frame having an ID of X, and may transmit the ALP _ STREAM frame and/or the STREAM frame to the first device 10.

It can be understood that, if the third message is a DHCP Request message, the fourth message may be a DHCP Ack message, and at this time, the DHCP Request message carries acknowledgement information of an IPv4 address allocated to the second device 20. If the third message is a REQUEST message of the DHCPv6, the fourth message is a REPLY message of the DHCPv6, and at this time, the DREQUES message carries confirmation information of the IPv6 address allocated to the second device 20.

It should be noted that the fourth packet may also be divided into a plurality of sub-packets of the fourth packet, and each sub-packet of the fourth packet may be carried by one ALP _ STREAM frame or STREAM frame, so that the sub-packets of the plurality of fourth packets may be reassembled at the first device 10, and the fourth packet is restored at the first device 10.

In step 206, the first device 10 parses the fourth packet, and determines an IP address according to a parsing result, so as to complete DHCP interaction with the second device 20.

Specifically, after receiving the fourth message sent by the second device 20, the first device 10 may analyze the fourth message, so as to obtain information that the second device 20 confirms allocation of the IP address in the fourth message. The IP address can then be used by the first device 10, whereby DHCP interaction with the second device 20 can be completed, i.e. remote access authentication of the first device 10 on the second device 20 is completed. As can be seen, through the interaction of the application layer protocol messages (e.g., the first message, the second message, the third message, and the fourth message), the remote access authentication of the first device 10 on the second device 20 can be achieved.

Optionally, if it is not negotiated that the L2 or L3 type application layer protocol is supported in the handshake phase of the QUIC protocol, the first device 10 may dynamically trigger the QUIC protocol module after receiving the fourth packet sent by the second device 20. Illustratively, the first device 10 may send NEW _ ALP frames to the second device 20 over the established QUIC session described above, which may be used to negotiate with the second device 20 support of an application layer protocol of the L2 or L3 type. In the foregoing manner, the step of negotiating the L2 or L3 type application layer protocol is performed after the authentication is successful, so that the first device 10 can be prevented from accessing the managed network resource of the second device 20 before the authentication is successful, and further, the network security problem can be prevented from being generated.

In step 207, the first device 10 sends a fifth packet to the second device 20 based on the L2 or L3 type application layer protocol, so as to access the resource on the network where the second device 20 is located.

Specifically, after the first device 10 completes the remote access on the second device 20, the second device 20 may be further accessed remotely, that is, the first device 10 may access a network resource managed by the second device 20.

In a specific implementation, the first device 10 may create an access packet for remote access (for convenience of description, the above "access packet for remote access" is hereinafter referred to as a "fifth packet"), and the fifth packet may be carried by an ALP _ DATAGRAM frame or a DATAGRAM frame. For example, the first device 10 may create a DATAGRAM flow that may include a plurality of ALP _ DATAGRAM frames or a plurality of DATAGRAM frames, wherein each ALP _ DATAGRAM frame or DATAGRAM frame may include a flow ID for identifying the identity of the DATAGRAM flow.

Next, the first device 10 may encapsulate the fifth packet into an ALP _ DATAGRAM frame or a DATAGRAM frame, where the ALP _ DATAGRAM frame may include an ALP field, and the ALP field may be used to identify an application layer protocol type (for example, the application layer protocol type may be ipv4 oq).

In step 208, the second device 20 sends a sixth packet to the first device 10, so as to complete the access of the first device 10 to the second device 20.

Specifically, after receiving the ALP _ DATAGRAM frame or DATAGRAM frame sent by the first device 10, the second device 20 may obtain a fifth message (access message) in the ALP _ DATAGRAM frame or DATAGRAM frame, and may forward the fifth message to an upper layer or other network devices (e.g., an intranet resource server) in a network where the second device 20 is located according to routing information in the fifth message. It will be appreciated that the above-described routing information may be used to characterize IP routing, and thus, the upper layers in the above-described second device 20 may be protocol layers above L3 (e.g., IP layer).

Next, after the upper layer or other network devices in the second device 20 receives the fifth message, a corresponding sixth message may be generated according to the fifth message. The sixth message may be a response message, that is, the sixth message may be a response to the fifth message, and the sixth message may include a resource that the first device 10 wants to access. Then, the second device 20 may 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 packet, the second device 20 may directly send the sixth packet to the first device 10; if the other network device generates the corresponding sixth packet, the other network device sends the sixth packet to the second device 20, and the sixth packet may be forwarded to the first device 10 by the second device 20.

In a specific implementation, the second device 20 may send the sixth packet by encapsulating the sixth packet into an ALP _ DATAGRAM frame or a DATAGRAM frame, and sending the ALP _ DATAGRAM frame or the DATAGRAM frame to the first device 10.

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

Specifically, the first device 10 may receive the ALP _ DATAGRAM frame or DATAGRAM frame sent by the second device 20, and may obtain the sixth packet from the ALP _ DATAGRAM frame or DATAGRAM frame. Then, the first device 10 may analyze the sixth message, for example, the first device 10 may analyze an IP header and a transport protocol header in the sixth message to obtain a load in the sixth message, where the load in the sixth message is a resource accessed by the first device 10, and thus, the first device 10 may access a resource of a private network where the second device 20 is located.

It is understood that the above steps 201-206 describe the scenario of applying for an IP address through a DHCP interaction based on the QUIC protocol. Similarly, the above-mentioned manner of steps 201 to 206 is also applicable to the scenario of IP address renewal, for example, the message for IP address renewal may be carried on a STREAM frame or a DATAGRAM frame based on the QUIC protocol, or may be carried on an ALP _ STREAM frame or an ALP _ DATAGRAM frame based on the QUIC protocol, and the specific process may refer to the above-mentioned steps 201 to 206, which are not described herein again.

In the embodiment of the present application, the first device 10 applies for an IP address to the second device 20 through a DHCP interaction based on a QUIC protocol, so that a simple and efficient remote access authentication can be achieved, and a large amount of cost caused by laying a dedicated VPN line or deploying a dedicated VPN client can be saved.

It is understood that the above embodiments only illustrate the process of the first device 10 interacting with the second device 20, and the first device 10 may interact with the second device 20 after being transferred by the third device 30.

In addition, in the above embodiments, steps 201 to 209 are optional steps, and this application only provides one possible embodiment, and may further include more or less steps than steps 201 to 209, which is not limited in this application.

It should be noted that the foregoing example only exemplarily shows an access authentication manner of a DHCP type, and does not constitute a limitation to the embodiment of the present application, and in some embodiments, the access authentication type may further include an EAP type (e.g., EAP over quick), and exemplarily, an access authentication protocol of the EAP type may be characterized by a string "eapoq". The Protocol type of "eapoq" may support an Extensible Authentication Protocol (EAP) packet. That is, with the second device 20 as an authentication point, the first device 10 may carry EAP messages over 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 an EAP message through one or more ALP _ DATAGRAM frames and/or one or more DATAGRAM frames of the QUIC session, so that an access authentication interaction may be completed with the second device 20, and then carry out the application of the private network IP address and the access to the private network resource in the above embodiment through the ALP _ DATAGRAM frame or the DATAGRAM frame carrying the L2 type or L3 type message.

Fig. 3 is a schematic structural diagram of an embodiment of a remote access apparatus according to the present application, and as shown in fig. 3, the application of the remote access apparatus 300 to the first device 10 may include: a handshake module 310, a session establishment module 320, and an access module 330; wherein the content of the first and second substances,

a handshake module 310, configured to perform a session handshake based on the QUIC protocol with the second device, where the session handshake based on the QUIC protocol is used to declare an application layer protocol type for access authentication;

a session establishing module 320 for establishing a QUIC session with a second device;

and the access module 330 is configured to perform access authentication interaction with the second device on the established QUIC session by using an application layer protocol message corresponding to the application layer protocol type used for access authentication, so as to complete remote access on the second device.

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

In one possible implementation manner, the apparatus 300 further includes:

an declaring module 340 for declaring the application layer protocol type for forwarding on the established QUIC session.

In one possible implementation manner, the application layer protocol type used for the access authentication is a DHCP type, and the access module 330 is further configured to send a first packet to the second device, where the first packet is used to request the second device to allocate an IP address;

In one possible implementation manner, the apparatus 300 further includes:

an access module 350, configured to send an access packet to the second device, where the access packet is used to request to access a network resource of the second device;

Fig. 4 is a schematic structural diagram of another embodiment of the remote access apparatus of the present application, and as shown in fig. 4, the application of the remote access apparatus 400 to the second device 20 may include: a handshake module 410, a session establishment module 420, and an authentication module 430; wherein, the first and the second end of the pipe are connected with each other,

a handshake module 410, configured to perform a session handshake based on the QUIC protocol with the first device, where the session handshake based on the QUIC protocol is used to declare an application layer protocol type for access authentication;

a session establishing module 420 for establishing a QUIC session with a first device;

and the authentication module 430 is configured to perform access authentication interaction with the first device by using an application layer protocol message corresponding to an application layer protocol type used for access authentication on the established QUIC session, and complete remote access authentication on the first device.

In one possible implementation, the above-mentioned handshake module 410 is further configured to declare an application layer protocol type for forwarding.

In one possible implementation manner, the apparatus 400 further includes:

an declaring module 440 for declaring the application layer protocol type for forwarding on the established QUIC session.

In one possible implementation manner, 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 a first device, where the first message is used to request a second device to allocate an IP address;

In one possible implementation manner, the apparatus 400 further includes:

a response module 450, configured to receive an access packet sent by a first device, where the access packet is used to request to access a network resource of a second device;

The embodiments shown in fig. 3 and fig. 4 provide a remote access apparatus 300 and a remote access apparatus 400, which can be used to implement the technical solutions of the method embodiments shown in fig. 1 and fig. 2 of the present application, and further refer to the related descriptions in the method embodiments for realizing the principles and technical effects.

It should be understood that the division of the modules of the remote access apparatus shown in fig. 3 and 4 is merely a logical division, and the actual implementation may be wholly or partially integrated into one physical entity or may be physically separated. And these modules can be realized in the form of software called by processing element; or may be implemented entirely in hardware; and part of the modules can be realized in the form of calling by the processing element in software, and part of the modules can be realized in the form of hardware. For example, the detection module may be a separate processing element, or may be integrated into a chip of the electronic device. Other modules are implemented similarly. In addition, all or part of the modules can be integrated together or can be independently realized. In implementation, each step of the above method or each module above may be implemented by an integrated logic circuit of hardware in a processor element or an instruction in the form of software.

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), one or more Field Programmable Gate Arrays (FPGAs), etc. For another example, these modules may be integrated together and implemented in the form of a System-On-a-Chip (SOC).

Exemplary electronic devices provided in the following embodiments of the present application are further described below in conjunction with fig. 5. Fig. 5 shows a schematic structural diagram of an electronic device 500, and the electronic device 500 may be the first device 10 or the second device 20.

The electronic device 500 may include: at least one processor; and at least one memory communicatively coupled to the processor, wherein: the memory stores program instructions executable by the processor, and the processor calls the program instructions to execute the remote access method provided by the embodiments of fig. 1 and 2 of the present application.

Fig. 5 illustrates a block diagram of an exemplary electronic device 500 suitable for implementing embodiments of the present application. The electronic device 500 shown in fig. 5 is only an example, and should not bring any limitation to the functions and the scope of use of the embodiments of the present application.

As shown in fig. 5, the electronic device 500 is in the form of a general purpose computing device. The components of the electronic device 500 may include, but are not limited to: one or more processors 510, a memory 520, a communication bus 540 that connects the various system components (including the memory 520 and the processors 510), and a communication interface 530.

Communication bus 540 represents one or more of any of several types of bus structures, including a memory bus or memory controller, a peripheral bus, an accelerated graphics port, and a processor or local bus using any of a variety of bus architectures. These architectures include, but are not limited to, industry Standard Architecture (ISA) bus, micro Channel Architecture (MAC) bus, enhanced ISA bus, video Electronics Standards Association (VESA) local bus, and Peripheral Component Interconnect (PCI) bus, to name a few.

Electronic device 500 typically includes a variety of computer system readable media. Such media may be any available media that is accessible by the electronic device and includes both volatile and nonvolatile media, removable and non-removable media.

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/nonvolatile computer system storage media. Although not shown in FIG. 5, a disk drive for reading from and writing to a removable, nonvolatile magnetic disk (e.g., a "floppy disk") and an optical disk drive for reading from or writing to a removable, nonvolatile optical disk (e.g., a Compact disk Read Only Memory (CD-ROM), a Digital versatile disk Read Only Memory (DVD-ROM), or other optical media) may be provided. In these cases, each drive may be connected to the communication bus 540 by one or more data media interfaces. Memory 520 may include at least one program product having a set (e.g., at least one) of program modules that are configured to carry out the functions of embodiments of the application.

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

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 devices (e.g., network card, modem, etc.) that enable the electronic device to communicate with one or more other computing devices. Such communication may occur through communication interface 530. Also, the electronic device 500 may communicate with one or more networks (e.g., a Local Area Network (LAN), a Wide Area Network (WAN) and/or a public Network such as the Internet) via a Network adapter (not shown in FIG. 5) that may communicate with other modules of the electronic device via the communication bus 540. It should be appreciated that although not shown in FIG. 5, 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 array (RAID) systems, tape Drives, data backup storage systems, and the like.

The processor 510 executes programs stored in the memory 520 to perform various functional applications and data processing, such as implementing a remote access method provided by an embodiment of the present application.

It should be understood that the interfacing relationship between the modules illustrated in the embodiments of the present application is only an illustration, and does not limit the structure of the electronic device 500. In other embodiments of the present application, the electronic device 500 may also adopt different interface connection manners or a combination of multiple interface connection manners in the above embodiments.

It is to be understood that the electronic device and the like described above include a hardware structure and/or a software module for performing each function in order to realize the functions described above. Those of skill in the art will readily appreciate that the various illustrative components and algorithm steps described in connection with the embodiments disclosed herein may be implemented as hardware or combinations of hardware and computer software. Whether a function is performed as hardware or computer software drives hardware depends upon the particular application and design constraints imposed on the solution. Skilled artisans may implement the described functionality in varying ways for each particular application, but such implementation decisions should not be interpreted as causing a departure from the scope of the embodiments of the present application.

In the embodiment of the present application, the electronic device and the like may be divided into functional modules according to the method example, for example, each functional module may be divided according to each function, or two or more functions may be integrated into one processing module. The integrated module can be realized in a hardware mode, and can also be realized in a software functional module mode. It should be noted that, in the embodiment of the present application, the division of the module is schematic, and is only one logic function division, and there may be another division manner in actual implementation.

Through the above description of the embodiments, it is clear to those skilled in the art that, for convenience and simplicity of description, the foregoing division of the functional modules is merely used as an example, and in practical applications, the above function distribution may be completed by different functional modules according to needs, that is, the internal structure of the device may be divided into different functional modules to complete all or part of the above described functions. For the specific working processes of the system, the apparatus and the unit described above, reference may be made to the corresponding processes in the foregoing method embodiments, and details are not described here again.

Each functional unit in the embodiments of the present application may be integrated into one processing unit, or each unit may exist alone physically, or two or more units are integrated into one unit. The integrated unit can be realized in a form of hardware, and can also be realized in a form of a software functional unit.

The integrated unit, if implemented in the form of a software functional unit and sold or used as a stand-alone product, may be stored in a computer readable storage medium. Based on such understanding, the technical solutions of the embodiments of the present application may be essentially implemented or make a contribution to the prior art, or all or part of the technical solutions may be implemented in the form of a software product stored in a storage medium and including several instructions for causing a computer device (which may be a personal computer, a server, or a network device) or a processor to execute all or part of the steps of the methods described in the embodiments of the present application. And the aforementioned storage medium includes: flash memory, removable hard drive, read only memory, random access memory, magnetic or optical disk, and the like.

The above description is only an embodiment of the present application, but the scope of the present application is not limited thereto, and any changes or substitutions within the technical scope of the present disclosure should be covered by the scope of the present application. Therefore, the protection scope of the present application shall be subject to the protection scope of the claims.

Claims

1. A remote access method applied to a first device is characterized by comprising the following steps:

performing a QUIC protocol-based session handshake with a second device, wherein the QUIC protocol-based session handshake is used for declaring an application layer protocol type for access authentication;

establishing a QUIC session with the second device;

and performing access authentication interaction with the second equipment by using the application layer protocol message corresponding to the application layer protocol type for access authentication on the established QUIC session, and completing remote access on the second equipment.

2. The method of claim 1, wherein the application layer protocol types for access authentication comprise a Dynamic Host Configuration Protocol (DHCP) type and an Extensible Authentication Protocol (EAP) type.

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

4. The method of claim 1 or 2, wherein after completing remote access on the second device, the method further comprises:

5. The method of claim 3 or 4, wherein the application layer protocol types for forwarding comprise L2 type and L3 type.

6. The method of claim 2, wherein the application layer protocol type for access authentication is a DHCP type, and wherein the performing access authentication interaction with the second device comprises:

sending a first message to the second device, wherein the first message is used for requesting the second device to allocate an IP address;

receiving a second message sent by the second device, wherein the second message comprises an assignable IP address;

7. The method of claim 2, wherein 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 said DHCP message or each said EAP message is carried by one or more ALP _ STREAM frames, and/or one or more STREAM frames, or

Each DHCP message or each EAP message is carried by one or more ALP _ DATAGRAM frames and/or one or more DATAGRAM frames.

8. The method according to any one of claims 1-7, further comprising:

sending an access message to the second device, wherein the access message is used for requesting to access a network resource of the second device;

and receiving a response message sent by the second device, wherein the response message comprises the network resource requested to be accessed by the first device.

9. The method of claim 8, wherein the access message is carried by an ALP _ DATAGRAM frame and/or a DATAGRAM frame.

10. A remote access method applied to a second device is characterized by comprising the following steps:

performing a QUIC protocol-based session handshake with a first device, wherein the QUIC protocol-based session handshake is used for declaring an application layer protocol type for access authentication;

establishing a QUIC session with the first device;

and performing access authentication interaction with the first equipment by using the application layer protocol message corresponding to the application layer protocol type for access authentication on the established QUIC session, and completing remote access authentication of the first equipment.

11. The method of claim 10, wherein the application layer protocol types for access authentication comprise a Dynamic Host Configuration Protocol (DHCP) type and an Extensible Authentication Protocol (EAP) type.

12. Method according to claim 10 or 11, characterized in that said QUIC protocol based session handshake is also used to declare the application layer protocol type for forwarding.

13. The method of claim 10 or 11, wherein after the remote access authentication of the first device is completed, the method further comprises:

14. The method according to claim 12 or 13, wherein the application layer protocol types for forwarding comprise L2 type and L3 type.

15. The method of claim 11, wherein the application layer protocol type for access authentication is a DHCP type, and wherein the performing access authentication interaction with the first device comprises:

receiving a first message sent by the first device, wherein the first message is used for requesting the second device to allocate an IP address;

sending a second message to the first device, wherein the second message comprises an assignable IP address;

receiving a third message sent by the first device, wherein the third message is used for confirming the assignable IP address;

16. The method of claim 11, wherein the DHCP-type application layer protocol is used for DHCP messaging, and wherein the EAP-type application layer protocol is used for EAP messaging, wherein,

each DHCP message or each EAP message is carried by one or more ALP _ STREAM frames and/or one or more STREAM frames or

17. The method of claim 10, further comprising:

receiving an access message sent by the first device, wherein the access message is used for requesting to access a network resource of the second device;

and sending a response message to the first device, wherein the response message comprises the network resource which is requested to be accessed by the first device.

18. The method of claim 17, wherein the access message is carried by an ALP _ DATAGRAM frame and/or a DATAGRAM frame.

19. A first device, comprising: a memory for storing computer program code, the computer program code comprising instructions that, when read from the memory by the first device, cause the first device to perform the method of any of claims 1-9.

20. A second apparatus, comprising: a memory for storing computer program code, the computer program code comprising instructions that, when read from the memory by the second device, cause the second device to perform the method of any of claims 10-18.

21. A computer readable storage medium comprising computer instructions which, when run on the first device, cause the first device to perform the method of any of claims 1-9, or which, when run on the second device, cause the second device to perform the method of any of claims 10-18.

22. A computer program product, which, when run on a computer, causes the computer to perform the method of any one of claims 1-18.