Conclusion 1: as long as one Nat is full cone Nat, bidirectional communication can be realized.
Conclusion 2: as long as the nat on both sides are not classified as Nat, two-way communication is also possible. In other words, as long as the nat on both sides belong to the cone Nat, two-way communication can be achieved.
Conclusion 3: Nat on one side belongs to the elastic Ric Nat, and Nat on the other side belongs to the restricted cone, which can also be used for bidirectional communication.
Conclusion 4: The two instances are both hierarchical Nat, hierarchical Nat, and port restricted cone. Therefore, two-way communication is not allowed.Stunu protocol (rfc3489, see http://www.ietf.org/rfc/rfc3489.txt) proposed four types of NAT definition and classification, and gives how to detect
Which type of NAT is used. However, the specifics of how P2P programs apply the STUN Protocol and its classification method to cross Nat are benevolent and wise.
(Because the STUN Protocol does not provide and there is no need to provide the criteria for how to traverse NAT)
In the article "iptables and stun" published by the author, I spent a lot of energy explaining that iptables is theoretically classified as hierarchical Nat rather than port restricted cone.
Many people (including when I first studied the STUN Protocol) have doubts about this, that is, for STUN Protocol itself, port restricted cone and
Although the ing mechanism is a little different, they all have port-restricted attributes. At first glance, the two are
NAT traversal features are similar, especially when external addresses want to send packets to Nat internal addresses. Why is iptables necessary?
This article solves the reader's doubts in this aspect.
Website Region
Test Tool natcheck. Let's still use the instance (Example 1) to illustrate this idea!
Machine A is on the private network (192.168.0.4)
A-side Nat server (210.21.12.140)
Machine B is on another private network (192.168.0.5)
B-side Nat server (210.15.27.140)
Server C acts as an intermediary between server a and server B on the public network (210.15.27.166 ).
Machine A is connected to machine C. If it is a (192.168.0.4: 5000)-> A-side NAT (210.21.12.140: 8000 after translation)-> C (210.15.27.166: 2000)
Machine B is also connected to machine C, if it is B (192.168.0.5: 5000)-> B-side NAT (210.15.27.140: 8000 after conversion)-> C (210.15.27.166: 2000)
After machine A is connected to machine C, A reports its internal address (192.168.0.4: 5000) to C. At this time, C not only knows the external address of
(C through the 210.21.12.140: 8000), you also know the internal address of. Similarly, C knows the external address of B (210.15.27.140: 8000) and
Internal address (192.168.0.5: 5000 ). Then, C serves as an intermediary to tell B the two addresses of a and a two addresses of B.
Assume that a knows the two addresses of B, then a sends packets from 192.168.0.4: 5000 to the two addresses of B at the same time, 192.168.0.5: 5000 and 210.15.27.140: 8000.
Because A and B are behind two different NAT ports, packets from a (192.168.0.4: 5000) to B (192.168.0.5: 5000) cannot be obtained.
Packages from a (192.168.0.4: 5000) to B (210.15.27.140: 8000) are divided into the following two situations:
1. B-side Nat is full cone Nat
Then, no matter whether the-side Nat is a cone Nat or a-ric Nat, the packet can reach B smoothly. If the P2P program is well designed, B can take the initiative to borrow a package from.
If a initiates a channel, the packets sent by B can reach a smoothly even if the nat on the side belongs to Nat.
Conclusion 1: as long as one Nat is full cone Nat, bidirectional communication can be realized. 2. B-side Nat is a restricted cone or port restricted cone.
The package cannot reach B. Further subdivided into two situations
(1) A-side Nat is a restricted cone or port restricted cone
Although the previous initial package did not reach B, the packet sending process has left enough records on the-side NAT:
A (192.168.0.4: 5000)-> (210.21.12.140: 8000)-> B (210.15.27.140: 8000 ). If, before the record times out,
B Also repeats the same action as a, that is, to send a packet to a (210.21.12.140: 8000), although the-side Nat is a restricted cone or port restricted cone,
However, nat on the side has previously considered that a has sent a packet to B (210.15.27.140: 8000), So B can smoothly send a packet to a (210.21.12.140: 8000.
Similarly, the packages from A to B can also be delivered smoothly.
Conclusion 2: as long as the nat on both sides are not classified as Nat, two-way communication is also possible. In other words, as long as the nat on both sides belong to the cone Nat, two-way communication can be achieved. (2) nat on the side belongs to the elastic Ric Nat
Because the-side Nat is an elastic Ric Nat, and the first packet sending process from A to C leaves the following records in the-side NAT:
A (192.168.0.4: 5000)-> (210.21.12.140: 8000)-> C (210.15.27.166: 2000), so the record of A to B packet sending on a side Nat is:
A (192.168.0.4: 5000)-> (210.21.12.140: 8001)-> B (210.15.27.140: 8000) (note that the port has changed after conversion ).
B can only send a packet to a (210.21.12.140: 8000) based on the information that C sends to A. This is because port A is limited.
Let's take a look at the nat on the B side. Because B has also sent a packet to a and the nat on the B side belongs to restricted cone or port restricted cone, the record left on the nat on the B side is:
B (192.168.0.5: 5000)-> (210.15.27.140: 8000)-> A (210.21.12.140: 8000). After that, if a continues to send packets to B
(Because of the same target, the previous ing is still used.) If the nat on side B belongs to restricted cone, packets from a (210.21.12.140: 8001) can successfully reach B;
If the nat on side B belongs to port restricted cone, the packet will never arrive at B.
Conclusion 3: Nat on one side belongs to the elastic Ric Nat, and Nat on the other side belongs to the restricted cone, which can also be used for bidirectional communication. Obviously, we can draw another unfortunate conclusion 4. Both are symmetric Nat, elastic Ric Nat, and port restricted cone,
Therefore, two-way communication is not allowed.
Although the above example only analyzes the initial packet distribution from A to B, given the symmetry of the two, and if the P2P program is designed to be scientific enough,
Then, the previous conclusions have no direction, and both directions are applicable.
Through the above analysis, we know that in terms of NAT traversal, there are essential differences between NAT and port restricted cone, although they seem similar on the surface.
We have come to four conclusions above, and the natcheck website will regard it as one: As long as nat on both sides belongs to the cone Nat
(Including full cone, restricted cone, and port restricted cone.
In addition, we recommend that you use port restricted cone whenever possible on the natcheck website to make full use of its port restriction attributes to ensure security. It is assumed that the reader is familiar with NATs. It has been
Observed that Nat treatment of UDP varies among implementations.
Four treatments observed in implementations are: Full Cone: A full cone Nat is one where all requests from
Same internal IP address and port are mapped to the same external
IP address and port. Furthermore, any external host can send
Packet to the internal host, by sending a packet to the mapped
External address. Restricted Cone: a restricted cone Nat is one where all requests
From the same internal IP address and port are mapped to the same
External IP address and port. Unlike a full cone Nat, an external
Host (with IP address X) can send a packet to the internal host
Only if the internal host had previusly sent a packet to IP
Address X. Port restricted Cone: A port restricted cone Nat is like
Restricted cone Nat, but the restriction includes des port numbers.
Specifically, an external host can send a packet, with source IP
Address X and source port P, to the internal host only if
Internal host had previusly sent a packet to IP address X and
Port p. Specified Ric: a specified Ric Nat is one where all requests from
Same internal IP address and port, to a specific destination IP
Address and port, are mapped to the same external IP address and
Port. If the same host sends a packet with the same source
Address and port, but to a different destination, a different
Mapping is used. Furthermore, only the external host that
Es a packet can send a UDP packet back to the internal host. Determining the type of NAT is important in your cases. Depending on
What the application wants to do, it may need to take the specified object
Behavior into account. Nat differences This document assumes that you are familiar with Nat. Currently, we know that there are differences in UDP processing for various Nat implementations. There are four different processing methods: Full Cone: all requests from the same internal IP address and port are mapped to the same external IP address and port. Moreover, any external host can send packets to the internal host by sending packets (packet) to the mapped external address. Restricted Cone: all requests from the same internal IP address and port are mapped to the same external IP address and port. Unlike full cone, an external host (IP address X) can only send data packets to the internal address that has previously sent data packets to IP address X. Port restricted cone mode: This mode is similar to restricted cone mode, but the restriction scope also includes the port number.
That is, an external host can only send data packets to the internal host that has previously sent data packets to port P of IP address X. Distributed Ric: all requests from the same internal IP address and port to the specified destination IP address and port are mapped to the same external IP address and port. If the same host uses the same source IP address and port but sends it to different targets, different mappings are used. In addition, only the recipient's external host can send UDP packets to the internal host. Determining the NAT type is important in many cases. You need to select a specific method based on the effect of the application. |
