The task of directly connecting machines behind the NAT is as old as the world, and I think many have heard about UDP Hole Punching. When I was just beginning to be interested in the question, I was convinced that it was impossible to pierce symmetric nat and it was not even worth trying. However, recently I came across an article stating that symmetrical nat is not a sentence.
Let's see.
NAT types
Traditionally, in many articles on the Internet, all NATs are divided into four types:
- Full-cone NAT;
- Address-restricted cone NAT;
- Port-restricted NAT NAT;
- Symmetric NAT
In fact, this is not true. More precisely not quite right. Any NAT has two main characteristics:
1) incoming packet filter;
2) port mapping rule.
')
The first characteristic is described in most articles and means which incoming packets to transfer to the machine behind the NAT: all (no filter - Full cone), from a specific address (address-restricted) or from a specific address and port (port-restricted).
The second characteristic is inherent only in symmetric NAT, as the first three types try to make a reflection of one to one. For example, if a client sends a packet from the internal address 192.168.10.24:62145, then from the router the packet will go from the address 1.2.3.4:62145. And regardless of the recipient's address.
Symmetric NAT
And now more about symmetric NAT. At once I will make a reservation that filters of incoming packets can also be any (no filter, address-restricted or port-restricted). And the only difference between this type of NAT and the previous ones is in the choice of the outgoing port on the router, it will almost certainly differ from the source port on the client. Returning to the previous example, the reflection may be as follows: 192.168.10.24:62145 -> 1.2.3.4:1274.
The port is chosen randomly (well, or not by accident, but in turn, but this is not important, since we cannot influence its choice from the outside). But there are certain rules, they are similar to the filter of incoming packets:
- A port can always remain the same, regardless of the receiver (cone);
- A port may remain the same for a specific destination address (address);
- A port can remain the same only for a specific address and port of the recipient (port);
There are also rules for choosing the next port:
This may be some kind of delta (+ 1 / -1 or + 10 / -10) or in general every time by accident.
In addition, I saw one NAT in which each subsequent port defended from the previous one by a random number, but always a multiple of 4096.Instead of conclusion
So, it is clear that knowing the rule of port distribution and the delta, you can guess from which port the outgoing packet will go, respectively, break through the same symmetric NAT. Of course, if you select a port quite by accident, this trick will not work.
Well, we got to the essence and purpose of the article. Answer the question
"Is it possible to determine the rule of distribution of ports and delta, being behind NAT'om?"STUN will help us in this, of course. Our task is to make four requests to different addresses and ports using one socket (one local port) and evaluate the results:
We will be able to understand how outgoing ports are distributed (address or port) and try to calculate that delta.
And here I urge the community to help me with statistics. On the Internet, a simple stun client was found, a little dug out with a sledgehammer and this is what happened:
Source codeLinux users are well aware how to compile this.
Like thisgcc -lpthread -o stun stun.c
Under Windows, a great compilation by the studio, here is a
binary , if there is no studio at hand.
Forgive me stun.counterpath.net for the habr effect :)Here are my results, but I do not have a symmetric NAT and are not interested:
Results
tests: 1010
NAT present: 1
first preserved port: 1
preserves port: 0
type: Port restricted NAT
mapped ports: 55907 55907 55907 55907Thank you all for your help!
udp: Please leave your results in the comments, even if NAT is not symmetrical. Indeed, in any case, it is important to know the pinouts by type.