Basic about UDP traversal under iptables-iptables and stun

Iptables and stun

STUN Protocol (rfc3489, see http://www.ietf.org/rfc/rfc3489.txt) will be roughly divided into four types of NAT, namely full cone, restricted cone, port restricted cone and structured Ric. The following is an example (Example 1) to illustrate the differences between the four Nat methods:
Machine A is on the private network (192.168.0.4)
Nat server (210.21.12.140)
Machine B is on the public network (210.15.27.166)
Machine C is on the public network (210.15.27.140)
Now machine A is connected to machine B. Assume It is a (192.168.0.4: 5000)-> NAT (210.21.12.140: 8000 after translation)-> B (210.15.27.166: 2000 ).
At the same time, a has never communicated with C.
Different types of NAT have the following results:
Full cone NAT: C sends data to 210.21.12.140: 8000. Nat sends data packets to a (192.168.0.4: 5000 ). Because there is a 192.168.ing between 192.168.0.4: 5000 and 210.21.12.140: 8000 on Nat.
Restricted Cone: C cannot communicate with A, because a never communicates with C, Nat will reject the action C tries to connect to. However, B can communicate with 192.168.0.4: 8000 of A through 210.21.12.140: 5000, and B can use any port to communicate with. For example, 210.15.27.166: 2001-> 210.21.12.140: 8000, Nat will be sent to port 5000 of.
Port restricted Cone: C cannot communicate with a because a never communicates with C. B can only use its 210.15.27.166: 2000 to communicate with 192.168.0.4: 5000 of A, because a never communicates with other ports of B. This type of NAT is port-limited.
Symmetric NAT: The above three types, collectively referred to as cone Nat, have one thing in common: as long as it is a packet from the same internal address and port, nat converts it to the same external address and port. However, distributed Ric is a little different, as long as it is from the same internal address and port, and to the same external destination address and port, nat also converts it to the same external address and port. However, if the source address and port are from the same external destination address and port, Nat will use different ing to convert them to different ports (the external address has only one, ). In addition, like port restricted cone, only the external address that has received the packet from the internal address can send packets to the internal address through the NAT ing address.
Here is an example of symmetric NAT (Example 2 ):
Machine A is connected to machine B. If it is a (192.168.0.4: 5000)-> NAT (210.21.12.140: 8000 after conversion)-> B (210.15.27.166: 2000)
If machine A (192.168.0.4: 5000) still wants to connect to machine C (210.15.27.140: 2000) at this time, a new ing will be generated on Nat, and the corresponding conversion may be a (192.168.0.4: 5000) -> NAT (210.21.12.140: 8001)-> C (210.15.27.140: 2000 ). At this time, B can only use its 210.15.27.166: 2000 to communicate with a's 192.168.0.4: 8000 through NAT 210.21.12.140: 5000, and C can only use its 210.15.27.140: 2000 through Nat's 210.21.12.140: 8001 communicates with 192.168.0.4: 5000 of A, while other ports of B or C cannot communicate with 192.168.0.4: 5000 of.
Through the above example, we understand the basis for the STUN Protocol to classify Nat. Now, based on the above classification criteria (or examples), we will briefly analyze the working principle of iptables (only referring to masquerade and the same below) to see which Nat does it belong?
First, download a tool that uses the STUN Protocol to detect nat on the Internet at http://sourceforge.net/projects/stun/. use this tool to check the iptablescheck result as port restricted Nat detected.
We should not rush to accept this detection result first. Let's analyze how iptables works first!
Iptables follows the following two principles when converting an address:
1. Try not to modify the source port. That is to say, the source port in the disguised IP address remains unchanged as much as possible. (The so-called preserves port number)
2. More importantly, you only need to ensure that the source address/port and target address/port (the so-called socket) are unique after the IP is disguised.
The previous examples are described as follows (Example 3 ):
Machine A is connected to machine B. For example, a (192.168.0.4: 5000)-> NAT (210.21.12.140: 5000 after translation)-> B (210.15.27.166: 2000 ). (Note: Nat follows the principle 1. The port is not changed after the switch)
If host a (192.168.0.4: 5000) still wants to connect to host C (210.15.27.140: 2000), a new ing will be generated on Nat, but the corresponding conversion may still be a (192.168.0.4: 5000)-> NAT (210.21.12.140: 5000 after the conversion)-> C (210.15.27.140: 2000 ). This is because Nat (210.21.12.140: 5000 after translation)-> B (210.15.27.166: 2000) and NAT (210.21.12.140: 5000 after translation)-> C (210.15.27.140: 2000) the two sockets are not repeated. Therefore, for iptables, this is both allowed (2nd principles) and inevitable (1st principles ).
In this example, it seems that iptables does not belong to Nat, because it does not seem to comply with the requirements of NAT: If you come out from the same internal address and port, to another target address and port, Nat will use different ing to convert to different ports (the external address has only one, so it remains unchanged ). On the contrary, it meets the requirements of three cone Nat Methods except NAT: from the same internal address and port, Nat converts it to the same external address and port. In addition, iptables has a port restriction attribute (which is beyond doubt, as evidenced by a counterexample). Therefore, many detection tools report iptables as port restricted Nat.
The following example is further analyzed (Example 4 ):
Add D machines to the same private network as a (192.168.0.5) in hosts)
Machine A is connected to machine B. If it is a (192.168.0.4: 5000)-> NAT (210.21.12.140: 5000 after conversion)-> B (210.15.27.166: 2000)
D machine connected to machine C, if it is D (192.168.0.5: 5000)-> NAT (210.21.12.140: 5000 after conversion)-> C (210.15.27.140: 2000)
According to the iptables conversion principle, the above two conversions are allowed and necessary.
If machine A (192.168.0.4: 5000) still wants to connect to machine C (210.15.27.140: 2000) at this time, a new ing is generated on Nat, but the corresponding conversion is changed to a (192.168.0.4: 5000)-> NAT (210.21.12.140: 5001)-> C (210.15.27.140: 2000 ). This is because, if it is still converted to 210.21.12.140: 5000, the socket (210.21.12.140: 5000-> 210.15.27.140: 2000) it will be consistent with the socket of D-> C, A conflict occurs, which does not comply with the 2nd rules of iptables (Note: Here 5001 represents different ports after conversion, but in fact, iptables does not generate new ports according to the internal port + 1 principle ). In this example, we note that Nat uses different mappings from the same internal address and port A (192.168.0.4: 5000) to different destination addresses and ports, convert to different ports.
The above example is rare in the actual environment. We use QQ as an example to illustrate a real and common example (example 5 ).
Hypothesis
A (192.168.0.4) and D (192.168.0.5) are two private network machines protected by the same Nat server (210.21.12.140), both of which run the QQ client.Program .
Machine B runs the QQ server program on the Internet (210.15.27.166.
Machine C runs the QQ client program on the public network (210.15.27.140.
First log on to B on QQ A. Follow Principle 1 and use the following ing:
A (192.168.0.4: 4000)-> NAT (210.21.12.140: 4000 after translation)-> B (210.15.27.166: 8000) (principle 1, port unchanged)
Then, log on to QQ on d to B. Follow Principle 2 and use the following ing:
D (192.168.0.5: 4000)-> NAT (210.21.12.140: 4001 after translation)-> B (210.15.27.166: 8000) (Principle 2, scoket cannot have duplicates, here, 4001 only indicates different ports after conversion. In actual environment, it is by no means 4001)
Then D wants to communicate with QQ on the public network C (210.15.27.140), according to the iptables conversion principle, use the following ing:
D (192.168.0.5: 4000)-> NAT (210.21.12.140: 4000 after translation)-> C (210.15.27.140: 4000)
As shown in the preceding example, Nat uses different mappings from the same internal address and port D (192.168.0.5: 4000) to different destination addresses and ports, convert to different ports. However, unlike the previous example, this example is obviously common in the actual environment.
The above two examples show that the conclusion is just the opposite of Example 3, that is, iptables should belong to Nat using hierarchical Nat.
Why are there conflicts? First, from the definition of NAT classification, stun and iptables have different understandings of NAT ing. Stun considers that the elements of a ing are the combination of the internal address port and the address port after Nat translation. In iptables, the elements of a ing are the combination of the address port and the external target address port after Nat translation. On the other hand, because the test environment provided by the discovery process in the STUN Protocol is not comprehensive enough, he only considers the special case of a private network machine after Nat (Example 3 ), there is no general example (example 5) where Nat can be followed by multiple private network machines ). These two reasons have directly led to the above conflict. Therefore, all Nat classification detection tools designed in accordance with the STUN Protocol standards for iptables detection results must be port restricted Nat. (In fact, in the case of Example 3, iptables is indeed a standard port restricted Nat)
So what kind of NAT does iptables belong? Let's review the requirements of the STUN Protocol for Cone NAT: all (or as long as it is) packets from the same internal address and port, nat converts it to the same external address and port. Although iptables partially meets the requirement that "packets from the same internal address and port are converted to the same external address and port, however, it cannot meet this requirement in all circumstances. Therefore, in theory, we can only classify iptables as symmetric Nat.
Next, let's take a look at the port restriction attribute of iptables. Let's take a counterexample to prove it (Example 6). The previous examples are as follows:
Machine A is connected to machine B. If it is a (192.168.0.4: 5000)-> NAT (210.21.12.140: 5000 after conversion)-> B (210.15.27.166: 2000)
D machine connected to machine C, if it is D (192.168.0.5: 5000)-> NAT (210.21.12.140: 5000 after conversion)-> C (210.15.27.140: 2000)
Assuming that iptables does not have the port restriction attribute, if another E machine sends a packet to 210.21.12.140: 2000 on the Internet (210.15.27.140: 2001) or C (210.15.27.140: 5000, it should be able to be sent to internal machines. However, when the packet arrives at NAT (210.21.12.140: 5000), Nat will not know whether to send the packet to a (192.168.0.4: 5000) or D (192.168.0.5: 5000 ). Obviously, this packet can only be discarded. This is enough to prove that iptables has a port restriction attribute.
Therefore, iptables is a genuine elastic Ric Nat.

Appendix:
1. Stun stands for simple traversal of UDP through NATs, so all the Packets involved in this article are UDP packets.
2. Although this article analyzes iptables in Linux, if you change the keyword "iptables" in this article to "ICS or NAT in Win2000 ", the analysis process in this article is applicable to ICS or NAT in Win2000. In theory, ICS or NAT in Win2000 are also genuine elastic Ric Nat. However, in fact, all Nat classification detection tools designed according to the STUN Protocol must also obtain port restricted Nat. In fact, not only is iptables in Linux, ICS or NAT in Win2000, or any other Nat product, as long as they follow the same two conversion principles as iptables, so their performance under the STUN Protocol is exactly the same.
3. Although ICS or NAT in Win2000 performs exactly the same as iptables in stun, the NAT principles 1 and iptables are slightly different: iptables applies the preserves port number to all the source ports on the Intranet machine, unless the source port number has to be changed due to a conflict in principle 2, but when changing the port number, it does not follow the internal port + 1 principle (it seems that there is no rule ). ICS or NAT in Win2000 are applicable only to some source ports (1025--3000) from internal private network machines, for those port numbers that exceed 3000 or that conflict with Principle 2, the system re-allocates the ports in order from 1025. In this process, the first two principles are still followed, it's just that principle 1 no longer preserves port number (try to use a small port number again without conflict with Principle 2, so the chance of using 1025 is much higher than 1026, 1027 ...).

The companion Article ---- practical UDP traversal under iptables ---- "iptables and natcheck" will be available soon"