Linux symmetric nat udp Traversal

After discussing the UDP hole-hitting technology with colleagues, I made a simple experiment. Because it was too difficult or impossible to set up NAT on Windows and check its principle, I did an experiment using Linux, we found that symmetric NAT Based on Linux ip_conntrack can also easily Implement UDP traversal, and the experiment is very simple, in addition, this UDP traversal does not require the help of public network servers (because it is very useful for symmetric NAT or connection-based NAT. Before presenting an experiment, you must first understand the following knowledge points.
1. linux NAT is based on ip_conntrack www.2cto.com. This indicates that the NAT rule is searched and matched only for the first packet of a connection determined by the quintuple and saved to the ip_conntrack structure, the subsequent packages automatically apply the NAT information in the ip_conntrack structure for NAT. The quintuple indicates a connection, so: 1 ). even if the same Intranet host initiates a connection, it may not be converted to the same (IP address, protocol port) to 2 ). different destination addresses are not the same connection, so it is impossible to steal a column like cone NAT.
2. currently, Linux does not implement the cone NAT module. Linux NAT is in the Netfilter module, and there is no related support in the standard protocol stack. As long as Netfilter does not support cone NAT, linux NAT does not expect to be penetrated by conventional methods. 3. linux NAT tries its best not to change the source port of the connection. Linux NAT is configured through iptables. For NAT that hides Intranet hosts, iptables SNAT is implemented, if you use man iptables, you will find that:
-- To-source [ipaddr [-ipaddr] [: port [-port] which can specify a single new source IP address, an aggressive range of IP addresses, and optionally, a port range (which is only valid if the rule also specifies-p tcp or-p udp ). if no port range is specified, then source ports below 512 will be mapped to other ports below 512: those between 512 and 1023 random sive will be mapped to ports below 1024, and other ports will be mapped to 1024 or above. where possible, no port alteration will occur. www.2cto.com
Note that in the last sentence, Linux tries its best not to change the source port of the connection. Unless it conflicts with another tuple, we know that a tuple is a quintuple. This gives us some inspiration, that is, we can try different ports until we find the connection that has not been changed to the source port. It is also easy to prove this point, that is, the success of the hole. This also indicates that there is no need for an external server, because it cannot help.
4. It is difficult for TCP to traverse the Linux symmetric NAT. Why? At first, I thought we could use a forged ACK packet for traversal. However, the experiment was not successful. Later I checked the source code and found that ip_conntrack strictly reviewed the TCP state machine and serial number range, anything that fails... how? Ip_conntrack does not have the right to discard it, but directly return ACCEPT, so you don't expect to be able to purchase any existing conntrack, such as the following scenario: A-simulate A public network host 10.16.0.1; n-simulate NAT host 10.16.0.254; host after the B-N; final target: A Connection B configuration: A discarded TCP 6667 packet behavior: 1 ). B binds port 6667 to port 66672 of ). the connection passes through N successfully, leaving the following information on N: tcp 6 52 SYN_SENT src = 172.16.0.35 dst = 10.16.0.1 sport = 6667 dport = 6667 packets = 3 bytes = 180 [UNREPLIED] src = 10.16.0.1 dst = 10.16.0.254 sport = 6667 dport = 6667 packets = 0 bytes = 0 mark = 0 secmark = 0 use = 1 ww Ipv2cto.com a unreplied conntrack3 ). in this case, the client program is stopped and the server listening to the same port is started. 4 ). A connects to 6667 of N with port 66675 ). when the SYN packet reaches N, N sends back the reset, and the experiment fails.
This principle is very simple. If you look at the ip_conntrack_in ip_conntrack entry function, you will find the following logic: [plain] ret = proto-> packet (ct, * pskb, ctinfo ); if (ret <0) {/* Invalid: inverse of the return code tells * the netfilter core what to do */nf_conntrack_put (* pskb)-> nfct ); (* pskb)-> nfct = NULL; CONNTRACK_STAT_INC (invalid); // If the status or serial number is found to be incorrect, return directly, jump out of the current HOOK point of Netfilter return-ret ;}... if (set_reply) set_bit (IPS_SEEN_REPLY_BIT, & ct-> status) The packet callback function is actually the tcp_packet function, which contains complex state machine checks, serial number checks, and other logics. Therefore, it is returned directly after an error, even if the connection to the matched/proc/net/ip_conntrack file is found, the following logic cannot be run, so the UNREPLIED words of the corresponding connection will not be erased, data Packets continue to enter the upper layer of the protocol stack and are finally sent to N local. Because N does not listen for 6667, reset. This behavior of Linux NAT indicates that it is difficult to use the conventional method to traverse. after the experiment briefly understands the above knowledge points, it is very easy to conduct the experiment. We only need three machines to simulate the experiment. The topology scenario is exactly the same as that in the above 4, but we changed TCP to UDP, it is easy to succeed. What if it fails? If the source port is changed during NAT, we only need to try several more ports until we find the port that is not modified. For TCP, because no method has been found, you have to give up... if www.2cto.com wants to verify the connectivity of the two machines behind the NAT server, the principle is the same, because there are not so many machines.
Note: cone NATcone NAT is actually a NAT device that aims to "save IP addresses". They do not maintain the status of each connection and do not adopt any security policies, it is bidirectional. For a full cone device, an internal host is mapped to a specific address and port pair, regardless of the target it accesses, the port mapped from any target to the full cone NAT device can be forwarded to the Intranet by the NAT device. That is to say, the so-called cone NAT, just like its name, is in the shape of an taper, and is scattered from the NAT device to the distance. One IP address and port pair correspond to multiple destination addresses and port pairs. Obviously, such NAT is not implemented based on connection, but based on "per packet. To improve security, you still need to use symmetric NAT or whatever type of NAT, as long as it is implemented based on the connection, just like the implementation of Linux, if the address, from the port pair's perspective, it is indeed sometimes conical. However, if we look at the connection session, it is symmetric, and this NAT traversal is very difficult.
Author dog250