Method for updating NAT (Network Address Translation) type, network equipment and client

Abstract

The invention provides a method for updating an NAT (Network Address Translation) type, network equipment and a client, and the method comprises the steps: receiving an STUN detection message sent by a first client, and obtaining a first NAT type of the first client from the STUN detection message; and judging whether the strict degree of a self-configured second NAT type is higher than that of the first NAT type, if so, taking the second NAT as the updated NAT type of the first client, generating a notification message, and sending the notification message to the STUN server. Through the method, the STUN server can know the NAT type of each client, and the STUN server informs the corresponding client of the updated NAT type of the client, so that the technical problems of gateway equipment session connection number, CPU (Central Processing Unit), flow load and the like in a branch link are reduced.

Description

Technical Field

[0001] This specification relates to the field of communication technologies, and in particular, to a method for updating the NAT type, a network device, and a client. Background Art

[0002] NAT (Network Address Translation) is the process of converting the IP address in the IP data packet header into another IP address. In practical applications, NAT is mainly applied to edge devices connecting two networks, for the purpose of allowing internal network users to access the external public network and allowing the external public network to access some internal network resources (such as internal servers).

[0003] STUN: STUN (Session Traversal Utilities for NAT), STUN is a network protocol that helps a device identify its public IP address and port after NAT (Network Address Translation). It is mainly used for P2P (peer-to-peer) communication in a NAT environment.

[0004] The STUN server receives requests from the client and returns the client's IP address and port on the public network. This is very useful for NAT traversal and determining the NAT type.

[0005] TURN: TURN (Traversal Using Relays around NAT): When STUN and NAT traversal technologies fail, the TURN server can act as a relay server to help transfer data between devices. Although this increases latency and bandwidth consumption, it ensures the reliability of the connection.

[0006] Full Cone NAT (Full Cone NAT): Any external host can access the internal host through the same mapped public IP and port.

[0007] Restricted Cone NAT (Restricted Cone NAT): Only hosts with specific external IP addresses can access the internal host.

[0008] Port Restricted Cone NAT (Port Restricted Cone NAT): Only hosts with specific external IP addresses and ports can access the internal host.

[0009] Symmetric NAT (Symmetric NAT): Each external request (to a different destination IP address or port) will be assigned a different public IP and port mapping.

[0010] STUN (Session Traversal Utilities for NAT): It is a network protocol mainly used to help clients located behind a NAT (Network Address Translator) discover their public IP addresses and ports, as well as the NAT type. The STUN protocol itself does not directly traverse the NAT, but helps the client understand its "identity" on the public network so that other clients can directly communicate with it. If one end of the client is on the public network, it is easy for the two clients to establish a P2P connection. If both clients are behind the NAT gateway, the two clients need to send STUN requests to the STUN server to obtain their respective public IP addresses, ports, and NAT types, and then the two clients also need to exchange their respective public IP addresses, ports, and NAT types through a signaling server and other steps to establish a P2P connection. Summary of the Invention

[0011] To overcome the problems existing in the related art, this specification provides a method, a network device, and a client for updating the NAT type.

[0012] According to the first aspect of the embodiments of this specification, a method for updating the NAT type is provided, which is applied to a NAT gateway. The method includes:

[0013] Receiving a STUN probe message sent by a first client, and obtaining the first NAT type of the first client from the STUN probe message;

[0014] Judging whether the strictness of the second NAT type configured by itself is higher than that of the first NAT type. If so, taking the second NAT as the updated NAT type of the first client and generating a notification message, and sending the notification message to the STUN server, so that the STUN server sends a feedback message carrying the second NAT type to the first client, and making the first client update the first NAT type to the second NAT type.

[0015] Among them, the STUN probe message includes:

[0016] NAT-Type-Change-Query request message.

[0017] Among them, the judging whether the strictness of the second NAT type configured by itself is higher than that of the first NAT type includes:

[0018] Configuring a NAT type strictness model, where the strictness of the NAT types in the NAT type strictness model, namely no NAT type, full cone NAT, restricted cone NAT, port-restricted cone NAT, and symmetric NAT, increases in sequence;

[0019] According to the strict NAT type model, determine whether the strictness of the second NAT type is higher than that of the first NAT type.

[0020] If so, use the second NAT as the updated NAT type of the first client and generate a notification message, further including:

[0021] Generate a reason identifier for updating the NAT type, and generate a notification message based on this reason identifier and the second NAT.

[0022] According to the second aspect of the embodiments of this specification, a method for updating the NAT type is provided. The method is applied to a client and includes:

[0023] Send a STUN probe message to the STUN server through the NAT gateway, where the current first NAT type of itself is carried in the STUN probe message;

[0024] Receive the feedback message sent by the STUN server, obtain the second NAT type from the feedback message, and update the local ANT record according to the second ANT type;

[0025] Wherein, when the NAT gateway determines that the strictness of the second NAT type configured in the NAT gateway is higher than that of the first NAT type, the NAT gateway sends a notification message carrying the second NAT type to the STUN server, and makes the STUN server send the second NAT type to the client through the feedback message.

[0026] Wherein, the method further includes:

[0027] Obtain the reason identifier for updating the NAT type from the feedback message. The reason identifier is generated when the NAT gateway determines that the strictness of its second NAT type is higher than that of the first NAT type, and the NAT gateway sends the reason identifier to the STUN server, and makes the STUN server send the reason identifier to the client.

[0028] It can be seen from the above embodiments that by judging the strictness of the NAT type of the client through the NAT gateway and updating the NAT type of the client, the STUN server can know the NAT type of each client, and the STUN server can inform the corresponding client of the updated NAT type of the client, thereby reducing technical problems such as the number of session connections, CPU, and traffic load of gateway devices in the branch link.

[0029] According to the third aspect of the embodiments of this specification, a network device is provided. The network device performs the NAT gateway function, and the network device includes:

[0030] A receiving module, configured to receive a STUN probing message sent by a first client, and obtain a first NAT type of the first client from the STUN probing message;

[0031] A judging module, configured to judge whether the strictness of a second NAT type configured by itself is higher than the first NAT type. If so, use the second NAT as the updated NAT type of the first client and generate a notification message;

[0032] A sending module, configured to send the notification message to a STUN server, so that the STUN server sends a feedback message carrying the second NAT type to the first client, and enables the first client to update the first NAT type to the second NAT type.

[0033] Wherein, the network device further includes:

[0034] A configuration module, configured to configure a NAT type strict model, wherein the strictness of the NAT types in the NAT type strict model increases in the order of no NAT type, full cone NAT, restricted cone NAT, port restricted cone NAT, and symmetric NAT;

[0035] The judging module judges whether the strictness of the second NAT type is higher than the first NAT type according to the NAT type strict model.

[0036] According to a fourth aspect of the embodiments of the present specification, a client is provided, and the client includes:

[0037] A sending module, configured to send a STUN probing message to a STUN server through a NAT gateway, where the STUN probing message carries a current first NAT type of itself;

[0038] A receiving module, configured to receive a feedback message sent by the STUN server, obtain a second NAT type from the feedback message, and update a local ANT record according to the second ANT type;

[0039] Wherein, the second NAT type is that when the NAT gateway judges that the strictness of the second NAT type configured in the NAT gateway is higher than the first NAT type, the NAT gateway sends a notification message carrying the second NAT type to the STUN server, and enables the STUN server to send the second NAT type to the client through the feedback message.

[0040] Among them, the receiving module is further configured to obtain a reason identifier for updating the NAT type from the feedback message, where the reason identifier is generated when the NAT gateway determines that the strictness of its second NAT type is higher than that of the first NAT type, and the NAT gateway sends the reason identifier to the STUN server, and the STUN server sends the reason identifier to the client.

[0041] It should be understood that the above general description and the following detailed description are merely exemplary and explanatory, and cannot limit this specification. Brief Description of the Drawings

[0042] The drawings here are incorporated into the specification and form a part of this specification, showing embodiments consistent with this specification, and are used together with the specification to explain the principles of this specification.

[0043] Figure 1 It is a schematic diagram of a network architecture shown according to an exemplary embodiment of this specification.

[0044] Figure 2 It is a schematic flowchart of a method for updating the NAT type shown according to an exemplary embodiment of this specification.

[0045] Figure 3 It is a schematic flowchart of a method for updating the NAT type shown according to an exemplary embodiment of this specification. Detailed Embodiments

[0046] Here, the exemplary embodiments will be described in detail, and the examples are shown in the drawings. When the following description refers to the drawings, unless otherwise indicated, the same numbers in different drawings represent the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this specification. On the contrary, they are merely examples of devices and methods consistent with some aspects of this specification as detailed in the appended claims.

[0047] The terms used in this specification are only for the purpose of describing specific embodiments and are not intended to limit this specification. The singular forms "a", "the", and "said" used in this specification and the appended claims are also intended to include the plural forms unless the context clearly indicates otherwise. It should also be understood that the term "and / or" used herein refers to and includes any or all possible combinations of one or more of the associated listed items.

[0048] It should be understood that although the terms first, second, third, etc. may be used in this specification to describe various information, such information should not be limited to these terms. These terms are only used to distinguish information of the same type from each other. For example, without departing from the scope of this specification, the first information may also be referred to as the second information, and similarly, the second information may also be referred to as the first information. Depending on the context, the word "if" as used herein may be interpreted as "when" or "while" or "in response to a determination".

[0049] UPnP (Universal Plug and Play):

[0050] This protocol allows devices within a local area network to dynamically request the router to open specific port mappings. P2P software can utilize UPnP to automatically request the router to open ports without the need for users to manually configure. When a P2P connection is established between two parties, the connection can be made through the ports opened by the router, ensuring successful hole punching.

[0051] Some UPnP devices may automatically open unnecessary ports, making the network vulnerable to external attacks; most UPnP implementations lack a strict authentication mechanism and are easily controlled by unauthorized devices; the automatic configuration function of UPnP may sometimes malfunction, resulting in the device not working properly.

[0052] As Figure 1 shown, currently, when two clients want to establish a P2P connection, if both client parties are behind a NAT gateway, the simplified process for establishing a P2P connection is as follows:

[0053] 1. Client A and B respectively send STUN requests to the STUN server. The STUN server returns their respective public IP addresses and ports, as well as the NAT type to Client A and B. Client A and B exchange their respective public IP addresses, ports, and NAT type information with each other through the signaling server.

[0054] 2. In the stage of attempting to establish a P2P connection: Client A initiates a P2P connection attempt to Client B based on the public IP address and port of Client B. Client B initiates a P2P connection attempt to Client A based on the public IP address and port of Client A*.

[0055] Due to the existence of NAT, the initial P2P connection attempt is very likely to fail.

[0056] 3. P2P Hole Punching: If the initial connection attempt fails, clients A and B will use the previously exchanged information to perform "hole punching" operations. Depending on the different NAT types, the specific "hole punching" methods may vary, but the basic idea is to make the NAT device allow packets from specific public IP addresses and ports to enter the internal network. For example, if both parties are cone NATs, both parties will simultaneously send packets to the public IP address and port of the other party, so mapping relationships will be created on the NAT devices of both parties. If both parties are symmetric NATs, more complex hole punching techniques (such as relays) are required, or the P2P connection is abandoned.

[0057] 4. Establish a P2P connection: If "hole punching" is successful, clients A and B can directly perform data transmission through the P2P connection. If "hole punching" fails, it may be necessary to use a TURN server for relaying.

[0058] In the above embodiments, there are the following technical problems: 1. When the client communicates with the STUN server about the NAT type of the local machine, it often takes multiple detections to know the egress NAT type of the local machine, which is time-consuming; 2. Different NAT types have different restrictions, and branches may require multiple STUN servers; 3. At the same time, both the client and the STUN also need to send a large number of detection messages, and these detection messages generate session numbers, CPU, memory pressure, etc. on the gateways of the branch links.

[0059] Currently, the core of STUN detecting the NAT type is to send specific STUN requests to the STUN server and observe the IP address and port information in the response returned by the server, so as to infer the behavior of the NAT.

[0060] Steps for STUN to Detect the NAT Type (mainly based on RFC 3489 and RFC 5389)

[0061] 1. Initial Test (Test I)

[0062] Client sends a request: The client first sends a STUN Binding request to the STUN server, and the request does not contain the CHANGE-IP and CHANGE-PORT attributes.

[0063] STUN server responds: The server will return a successful response, which contains the source IP address and port number (Mapped Address) of the client seen by the server.

[0064] Client analyzes the response: The client compares the source address of the request it sent and the mapped address returned by the server.

[0065] Case 1: If the source address and the mapped address are the same: This means there is no NAT or the client is behind a symmetric NAT. Subsequent tests are required.

[0066] Case 2: If the source address and the mapped address are different: This means the client is behind a NAT device. Subsequent tests are required.

[0067] Branch after Test I: Determine whether it is a cone NAT or a symmetric NAT.

[0068] Case 1: The source address and the mapped address are the same.

[0069] Test II

[0070] The client sends a request: The client sends a STUN Binding request with the CHANGE-IP attribute to the STUN server. This means the client requests the server to change the IP address when returning.

[0071] The STUN server responds: If the server receives a request with the CHANGE-IP attribute and the server supports this attribute, then it will return a new response in which the IP address is changed.

[0072] The client analyzes the response:

[0073] The response is not received: If the client does not receive a response, it means the STUN server does not support the CHANGE-IP attribute, or there is a problem with this client, and the test ends.

[0074] The response is received and the mapped address remains unchanged: It means the client is directly exposed to the public network and there is no NAT.

[0075] The response is received and the mapped address has changed: This means the client is behind a symmetric NAT.

[0076] Case 2: The source address and the mapped address are different.

[0077] Test II

[0078] The client sends a request: The client sends a STUN Binding request with the CHANGE-PORT attribute to the STUN server. This means the client requests the server to change the port when returning.

[0079] The STUN server responds: If the server receives a request with the CHANGE-PORT attribute and the server supports this attribute, then it will return a new response in which the port is changed.

[0080] The client analyzes the response:

[0081] No response received: This indicates that the STUN server does not support the CHANGE-PORT attribute, or there is a problem with this client, and the test ends.

[0082] Response received, and both the mapped address and port are the same as those in the first request: This indicates that the client is behind a full cone NAT.

[0083] Response received, the mapped address is the same as that in the first request, but the mapped port is different: This indicates that the client is behind a restricted cone NAT.

[0084] Response received, and the mapped address is different from that in the first request: This indicates that further testing is required.

[0085] Test III

[0086] Client sends a request: The client sends a STUN Binding request with the CHANGE-IP and CHANGE-PORT attributes to the STUN server.

[0087] STUN server responds: If the server receives a request with the CHANGE-IP and CHANGE-PORT attributes and the server supports these attributes, then it will return a new response in which both the IP and port are changed.

[0088] Client analyzes the response:

[0089] No response received: This indicates that the STUN server does not support the CHANGE-IP and CHANGE-PORT attributes, or there is a problem with this client, and the test ends.

[0090] Response received, and both the mapped address and port are the same as those in the first request: This indicates that the client is behind a port-restricted cone NAT.

[0091] Response received, and the mapped address is different from that in the first request: This indicates that the client is behind a symmetric NAT.

[0092] The following are the NAT types obtained from the above tests:

[0093] No NAT (public IP): The source address and the mapped address are the same, and the CHANGE-IP test indicates no address change.

[0094] Full Cone NAT: The mapped address and port remain unchanged, and the CHANGE-PORT response returns the same mapping.

[0095] Restricted Cone: The mapped address remains unchanged, but the mapped port changes. The CHANGE-PORT response returns a different port.

[0096] Port Restricted Cone: The mapped address and port remain unchanged. The CHANGE-IP and CHANGE-PORT responses return the same mapping.

[0097] Symmetric NAT: All tests show a change in the address or port.

[0098] From the above description, according to the above classification, the "strictness" of NAT increases in turn (Full Cone > Restricted Cone > Port Restricted Cone > Symmetric NAT). For STUN detection, the number of servers required and the number of detection times increase in turn. For establishing a P2P session that needs to traverse NAT, the difficulty increases in turn. For the entire NAT link, it can be known that its final NAT type is determined by the strictest NAT gateway.

[0099] To solve the above technical problems, the embodiments of the present disclosure provide a method for updating the NAT type, which is applied to a NAT gateway, as Figure 2 shown. The method includes:

[0100] S201 Receive a STUN detection message sent by a first client, and obtain the first NAT type of the first client from the STUN detection message;

[0101] S202 Determine whether the strictness of the second NAT type configured by itself is higher than that of the first NAT type. If so, use the second NAT as the updated NAT type of the first client and generate a notification message, and send the notification message to the STUN server, so that the STUN server sends a feedback message carrying the second NAT type to the first client, and the first client updates the first NAT type to the second NAT type.

[0102] The NAT gateway receives a STUN detection message sent by a client. This STUN detection message can be a NAT-Type-Change-Query request message, which is sent by the client to the STUN server for querying the NAT type.

[0103] In this embodiment, after obtaining the STUN detection message, the NAT gateway obtains the first NAT type of the client from the STUN detection message.

[0104] Among them, the first NAT type can be one of no NAT, full cone NAT, restricted cone NAT, port-restricted cone NAT, and symmetric NAT.

[0105] In this embodiment, the administrator can pre-configure the second NAT type to be executed in the NAT gateway. After the NAT gateway obtains the first NAT type from the STUN probe message, it uses the second NAT type to compare the strictness with the first NAT type. At this time, if the strictness of the first NAT type is higher than that of the second NAT type, the NAT gateway does not update the first NAT type and directly sends the STUN probe message carrying the first NAT type to the STUN server. If the strictness of the first NAT type is lower than that of the second NAT type, the NAT gateway executes step S202, updates the first NAT type with the second NAT type, and sends the STUN probe message carrying the second NAT type to the STUN server.

[0106] When the STUN server receives the STUN probe message carrying the second NAT type, it will send a feedback message to the client. The feedback message is used to inform the client of the NAT type result it queries. At this time, the second NAT type is carried in the STUN probe message, and the client records the second NAT type.

[0107] In this embodiment, after the NAT gateway updates the first NAT type with the second NAT type, it can also generate a reason identifier for the updated NAT type. The reason identifier can be predefined. For example, 1 refers to the strictness center, 2 refers to the no NAT type, etc.

[0108] Based on the above content, in one example, by supplementing the STUN probe protocol message format and adding functions to the NAT gateway, the NAT type of the overall link of the client can be detected through a pair of messages.

[0109] In this embodiment, the STUN protocol can be extended to introduce new attributes and message types, allowing the NAT gateway to actively inform its NAT type in some cases, specifically as follows:

[0110] 1. New STUN Attribute

[0111] NAT-Type-Changed(0x00xx): This is a new STUN attribute used to inform that the NAT type has changed. This attribute contains the following sub-attributes:

[0112] Original-NAT-Type(0x01xx): Records the original NAT type (e.g., Full Cone, Symmetric NAT).

[0113] New-NAT-Type(0x02xx): Record the new NAT type.

[0114] Change-Reason(0x03xx): Record the reason for the NAT type change (e.g., port exhaustion, session timeout, policy change).

[0115] 2. New STUN Message Type:

[0116] NAT-Type-Change-Indication(0x0400): This is a new STUN message type for the STUN server to send NAT type notifications to the client.

[0117] NAT-Type-Change-Query(0x0500): This is a new STUN message type for the client to query the current NAT type from the STUN server.

[0118] 3. Extended STUN Server Behavior:

[0119] When processing a NAT-Type-Change-Query request, extract the current client NAT type from the message content. When sending a NAT-Type-Change-Indication, extract and notify the client of the NAT type from the record. The NAT-Type-Change-Query and NAT-Type-Change-Indication messages appear in pairs, always initiated by the client and responded to by the STUN server.

[0120] The specific process is as follows:

[0121] 1. Client Initial Probe:

[0122] The client sends a NAT-Type-Change-Query request to the STUN server as usual, carrying the local NAT type of the last negotiation record; if it is the initial probe, fill it with 0; the New-NAT-Type field carried is all set to 0.

[0123] 2. NAT Gateway Rewrites the NAT Type:

[0124] When the NAT gateway supports changing the NAT type of the corresponding traffic, it will perform the following operations:

[0125] By judging the current traffic type initiated by the client and matching it with the current local NAT policy, after matching, perform the rewrite:

[0126] The NAT gateway first determines whether the current New-NAT-Type is empty. If it is empty, it fills it in directly.

[0127] If New-NAT-Type is not empty, it means that a NAT gateway already exists. Then the current NAT gateway needs to compare the current local NAT policy with New-NAT-Type. If the local NAT type is stricter than New-NAT-Type (refer to the above NAT types, and the NAT type of the final NAT link is determined by the strictest NAT gateway), then fill in the local NAT type; otherwise, do not modify it. If there is a modification to the NAT policy of this traffic on the NAT gateway of the local machine and it is inconsistent with the previous time, fill in the corresponding reason for modification in Change Reason.

[0128] 3. STUN server processes the NAT-Type-Change-Query notification:

[0129] After receiving the NAT-Type-Change-Query message, the STUN server updates the NAT type recorded locally.

[0130] At the same time, the STUN server returns a NAT-Type-Change-Indication message to the client and fills in the NAT type recorded this time in New-NAT-Type.

[0131] 4. Client processes the NAT-Type-Change-Indication message:

[0132] After receiving the NAT-Type-Change-Indication message, the client extracts the NAT gateway type of the local machine link returned by the STUN server from the payload and updates the local NAT record at the same time.

[0133] Based on the above embodiments, the embodiments of the present disclosure also provide a method for updating the NAT type. The method is applied to a client, as Figure 3 shown. The method includes:

[0134] S301 sends a STUN probe message to the STUN server through the NAT gateway, where the first NAT type of the client itself is carried in the STUN probe message;

[0135] S302 receives the feedback message sent by the STUN server, obtains the second NAT type from the feedback message, and updates the local ANT record according to the second ANT type;

[0136] Among them, when the NAT gateway determines that the strictness of the second NAT type configured in the NAT gateway is higher than that of the first NAT type, the NAT gateway sends a notification message carrying the second NAT type to the STUN server, and the STUN server sends the second NAT type to the client through a feedback message.

[0137] Among them, obtain a reason identifier for updating the NAT type from the feedback message. The reason identifier is generated when the NAT gateway determines that the strictness of its own second NAT type is higher than that of the first NAT type, and the NAT gateway sends the reason identifier to the STUN server, and the STUN server sends the reason identifier to the client.

[0138] In this embodiment, the client can be a host device, a virtual host device or a cloud tenant.

[0139] Based on the above method embodiments, the embodiments of the present disclosure further provide a network device that performs the NAT gateway function. The network device includes:

[0140] A receiving module, configured to receive a STUN probe message sent by a first client, and obtain a first NAT type of the first client from the STUN probe message;

[0141] A judging module, configured to judge whether the strictness of the second NAT type configured by itself is higher than that of the first NAT type. If so, use the second NAT as the updated NAT type of the first client and generate a notification message;

[0142] A sending module, configured to send the notification message to the STUN server, so that the STUN server sends a feedback message carrying the second NAT type to the first client, and the first client updates the first NAT type to the second NAT type.

[0143] Among them, the network device further includes:

[0144] A configuration module, configured to configure a NAT type strict model, where the strictness of the NAT types in the NAT type strict model, namely no NAT type, full cone NAT, restricted cone NAT, port restricted cone NAT, and symmetric NAT, increases in sequence;

[0145] The judging module judges whether the strictness of the second NAT type is higher than that of the first NAT type according to the NAT type strict model.

[0146] Based on the above method embodiments, the embodiments of the present disclosure further provide a client, and the client includes:

[0147] A sending module, configured to send a STUN probing message to a STUN server via a NAT gateway, where the current first NAT type of itself is carried in the STUN probing message;

[0148] A receiving module, configured to receive a feedback message sent by the STUN server, obtain a second NAT type from the feedback message, and update the local NAT record according to the second ANT type;

[0149] Wherein, when the NAT gateway determines that the strictness of the second NAT type configured in the NAT gateway is higher than the first NAT type, the second NAT type is that the NAT gateway sends a notification message carrying the second NAT type to the STUN server, and enables the STUN server to send the second NAT type to the client through the feedback message.

[0150] Wherein, the receiving module is further configured to obtain a reason identifier for updating the NAT type from the feedback message, where the reason identifier is generated when the NAT gateway determines that the strictness of its second NAT type is higher than the first NAT type, and the NAT gateway sends the reason identifier to the STUN server, and enables the STUN server to send the reason identifier to the client.

[0151] For the device embodiments, since they basically correspond to the method embodiments, the relevant parts can refer to the partial descriptions of the method embodiments. The device embodiments described above are only illustrative. The modules described as separate components may or may not be physically separated. The components shown as modules may or may not be physical modules, that is, they may be located in one place, or may be distributed to multiple network modules. Some or all of the modules can be selected according to actual needs to achieve the purpose of the solution in this specification. A person of ordinary skill in the art can understand and implement it without creative work.

[0152] The specific embodiments of this specification are described above. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps recited in the claims can be performed in a different order than in the embodiments and still achieve the desired result. Additionally, the processes depicted in the figures do not necessarily require the particular order or sequential order shown to achieve the desired result. In certain embodiments, multitasking and parallel processing are also possible or may be advantageous.

[0153] Those skilled in the art will readily conceive of other embodiments of the present specification after considering the specification and practicing the invention claimed herein. This specification is intended to cover any variations, uses, or adaptations of the specification, which follow the general principles of the specification and include known common general knowledge or conventional technical means in the technical field not claimed in this specification. The specification and examples are only to be regarded as exemplary, and the true scope and spirit of this specification are pointed out by the following claims.

[0154] It should be understood that this specification is not limited to the exact structures already described and shown in the drawings, and various modifications and changes can be made without departing from its scope. The scope of this specification is only limited by the appended claims.

[0155] The above are only the preferred embodiments of this specification, and are not intended to limit this specification. Any modifications, equivalent replacements, improvements, etc. made within the spirit and principles of this specification shall be included within the scope of protection of this specification.

Claims

1. A method for updating the NAT type, characterized in that, The method is applied to a NAT gateway, and the method includes: Receiving a STUN probe message sent by a first client, and obtaining a first NAT type of the first client from the STUN probe message; Judging whether the strictness of a second NAT type configured by itself is higher than the first NAT type. If so, taking the second NAT as the updated NAT type of the first client and generating a notification message, and sending the notification message to a STUN server, so that the STUN server sends a feedback message carrying the second NAT type to the first client, and enabling the first client to update the first NAT type to the second NAT type.

2. The method according to claim 1, wherein The STUN probe message includes: A NAT-Type-Change-Query request message.

3. The method according to claim 1, characterized in that, The judging whether the strictness of the second NAT type configured by itself is higher than the first NAT type includes: Configuring a NAT type strict model, where, among the NAT type strict model, the strictness of the no NAT type, full cone NAT, restricted cone NAT, port restricted cone NAT, and symmetric NAT types increases; Judging whether the strictness of the second NAT type is higher than the first NAT type according to the NAT type strict model.

4. The method according to claim 1, wherein The taking the second NAT as the updated NAT type of the first client and generating a notification message further includes: Generating a reason identifier for updating the NAT type, and generating a notification message according to the reason identifier and the second NAT.

5. A method for updating the NAT type, characterized in that The method is applied to a client, and the method includes: Sending a STUN probe message to a STUN server through a NAT gateway, where the STUN probe message carries a current first NAT type of itself; Receiving a feedback message sent by the STUN server, obtaining a second NAT type from the feedback message, and updating a local ANT record according to the second ANT type; Wherein, the second NAT type is that when the NAT gateway judges that the strictness of the second NAT type configured in the NAT gateway is higher than the first NAT type, the NAT gateway sends a notification message carrying the second NAT type to the STUN server, and enables the STUN server to send the second NAT type to the client through the feedback message.

6. The method according to claim 5, wherein The method further includes: Obtaining a reason identifier for updating the NAT type from the feedback message, where the reason identifier is generated when the NAT gateway judges that the strictness of its second NAT type is higher than the first NAT type, and the NAT gateway sends the reason identifier to the STUN server, and enables the STUN server to send the reason identifier to the client.

7. A network device, characterized in that, The network device performs the NAT gateway function, and the network device includes: A receiving module, configured to receive a STUN probe message sent by a first client, and obtain a first NAT type of the first client from the STUN probe message; A judging module, configured to judge whether the strictness of a second NAT type configured by itself is higher than the first NAT type. If so, taking the second NAT as the updated NAT type of the first client and generating a notification message; A sending module, configured to send the notification message to a STUN server, so that the STUN server sends a feedback message carrying a second NAT type to a first client, causing the first client to update the first NAT type to the second NAT type.

8. The network device according to claim 7, wherein The network device further includes: A configuration module, configured to configure a strict model of NAT types, wherein, in the strict model of NAT types, the strictness of the NAT types of no NAT type, full cone NAT, restricted cone NAT, port restricted cone NAT, and symmetric NAT increases in sequence; A judgment module, configured to judge, according to the strict model of NAT types, whether the strictness of the second NAT type is higher than that of the first NAT type.

9. A client, characterized in that, The client includes: A sending module, configured to send a STUN probe message to a STUN server through a NAT gateway, wherein the STUN probe message carries the current first NAT type of the client itself; A receiving module, configured to receive the feedback message sent by the STUN server, obtain the second NAT type from the feedback message, and update the local ANT record according to the second ANT type; wherein, the second NAT type is obtained when the NAT gateway determines that the strictness of the second NAT type configured in the NAT gateway is higher than that of the first NAT type, the NAT gateway sends a notification message carrying the second NAT type to the STUN server, and causes the STUN server to send the second NAT type to the client through the feedback message.

10. The client according to claim 9, wherein the receiving module is further configured to obtain a reason identifier for updating the NAT type from the feedback message, wherein the reason identifier is generated when the NAT gateway determines that the strictness of its second NAT type is higher than that of the first NAT type, and the NAT gateway sends the reason identifier to the STUN server, and causes the STUN server to send the reason identifier to the client.

Images