| Iptables and SOCKS5 From the "iptables and natcheck" article, we can see that, as long as both ends use iptables for Nat, even if both sides pass the natcheck compatibility test, iptables can never cross each other.
What should we do? One way is to add a Transit server on the public network. UDP Communication Between Intranet machines on both sides is conducted by the Transit server (as long as the transit side is sufficient ). The advantage of this method is that because the Transit server is on the public network, any machine after Nat can establish a connection with the Transit server, that is, machines on different intranets can always implement two-way communication through transit servers. However, the disadvantage of this solution is that it has high requirements on intermediate servers, including CPU processing capability and network bandwidth, in addition, communication latency between clients is inevitable (currently, the most popular Skype on the Internet is an exception. He uses distributed transfer technology, skype clients that are directly mounted on the Internet and are not behind the firewall can provide transit services for others. Therefore, Skype can ensure a high call success rate while ensuring high-quality voice effects ). Another more important factor is that the standards of transit servers are not uniform. As a result, each type of P2P program needs a dedicated Transit server. If resources cannot be shared among these transit servers, there must be a waste of resources (the standard transit protocol seems to be being launched, and the name is traversal Using relay Nat or turn ).
Another better way is to use the SOCKS5 (rfc1928) proxy server to replace the dedicated Transit server. The first reason is that SOCKS5 can support udp well, second, the S5 proxy server has many varieties and a large number of servers deployed on the public network. The most important thing is that SOCKS5 is a standardized protocol. After the client uses the SOCKS5 proxy, its UDP Communication passes through SOCKS5. In the peer's P2P program, the clients who use the SOCKS5 Proxy are directly connected to the public network, that is, as long as one party uses the SOCKS5 proxy, No matter what Nat is used by the other party, it will not be restricted by stun or natcheck. Therefore, iptables and SOCKS5 should have a good cooperation in theory. However, when implementing the SOCKS5 proxy, if you do not have a thorough understanding of the SOCKS5 protocol, it is still unpleasant to work with iptables. The following are two examples.
Assume that one end uses iptables and the other uses SOCKS5. Now the QQ behind SOCKS5 needs to send messages to the online (invisible) QQ behind iptables. When using the SOCKS5 proxy to log on to the QQ server, you must first establish a TCP-based SOCKS5 channel with the SOCKS5 server to control the subsequent UDP connections between the QQ server and the SOCKS5 server. Once the channel is successfully established, the SOCKS5 server will dynamically allocate a UDP port for the QQ to serve as a UDP transit task. When QQ sends a message to the online QQ behind the remote iptables, first, send the message (UDP packet) to the UDP port previously allocated on the SOCKS5 server, and then the server forwards the UDP packet to the remote QQ. When a UDP packet arrives at the remote QQ, it can be seen from the properties restricted by the iptables port, unless the QQ using the SOCKS5 proxy is online and not long ago (three minutes) I have received a UDP packet from QQ behind iptables. Otherwise, the packet cannot be forwarded to QQ behind iptables.
So where did the UDP package go? Let's analyze the process forward after the UDP packet arrives at the Linux host where iptables is located. When a UDP packet arrives in Linux, it is first handled by iptables. iptables first checks whether the UDP packet matches in the/proc/NET/ip_conntrack file. If yes, It is matched; if no, check whether there are matching rules in the prerouting chain. If yes, continue matching. If no, because the destination address of the package is Linux, iptables puts it into the input chain. Because the default input chain policy is accept, the UDP packet will be transferred to the Linux local process for processing, but in fact because such a local process does not exist, the result is that Linux sends an ICMP-Port-unreachable packet back to the machine that generates the UDP packet (note that this packet is generated by the Linux system, not the reject target of iptables ). If the input chain policy is drop, the UDP packet is dropped.
According to the above analysis, generally, the machine where iptables is located will return an ICMP-Port-unreachable packet to the sender QQ. After the SOCKS5 server receives the ICMP-Port-unreachable packet, different SOCKS5 servers have different processing methods. Some SOCKS5 servers (such as SOCKS5 in CCProxy) simply ignore this ICMP-Port-unreachable packet, while QQ does not send successfully (no response message is received ), repeat the above process several times, but it cannot be sent successfully. In the end, it can only be transferred through the server. Although the sending speed is slow due to the transfer, it can always be sent successfully. Some other SOCKS5 servers (such as SOCKS5 in Wingate), after receiving the ICMP-Port-unreachable packet returned by the remote end, think that the UDP connection initiated by the previous QQ is invalid, return a general SOCKS Server failure (reply code '01') to the client through the previously established SOCKS5 channel (TCP), and then immediately close the channel, at the same time, the UDP port used as a transit task on the SOCKS5 server is also disabled. However, QQ does not seem to know that the connection between it and the SOCKS5 server has been cut off. Because it has not been sent successfully (no response message is received), it still sends messages to the closed UDP port on the SOCKS5 server. At this time, because the SOCKS5 server has disabled the corresponding UDP port, it also returns an ICMP-Port-unreachable packet to QQ. After receiving the package, QQ continues to repeat the above process several times, and eventually fails due to timeout, and cannot pass through the server for the same reason. Even more seriously, even now, QQ still does not know that its connection with the SOCKS5 server has been cut off. Therefore, even if QQ sends messages to other offline or invisible QQ messages or online QQ messages that are not behind Nat, it cannot succeed.
The preceding example shows that some SOCKS5 servers and SOCKS5 clients do not have a thorough understanding of the SOCKS5 protocol. Even if SOCKS5 is used, communication will be poor when interworking with iptables.
In another example, the SOCKS5 server is located on the public network. The intranet client first performs Nat through iptables and then connects to the SOCKS5 server.
Reference the following text in the SOCKS5 protocol (rfc1928:
The UDP associate request is used to establish an association within the UDP relay process to handle UDP multicast rams. the DST. ADDR and DST. port fields contain the address and port that the client expects to use to send UDP packets rams on for the association. the server may use this information to limit access to the Association. if the client is not in possesion of the information at the time of the UDP associate, the client must use a port number and address of all zeros.
When the SOCKS5 client performs UDP associate (through the TCP channel), it is required to fill the DST with the address and port of the UDP packet sent by itself. ADDR and DST. port field, so that the SOCKS5 server can ensure that the UDP port allocated by the server only provides the intermediate service for the corresponding SOCKS5 client. However, when the SOCKS5 client connects to the SOCKS5 server over Nat, The SOCKS5 client cannot predict the address and port used by the SOCKS5 server to send the UDP packet in the future, considering the need for Nat address translation. In this case, rfc1928 recommends that the SOCKS5 client fill the DST. ADDR and DST. Port fields with 0, so that the SOCKS5 server will not limit the use of the transit port on the SOCKS5 client. However, many SOCKS5 clients do not seem to be aware of this, such as the e-border driver of the most common NEC Company, which uses the real IP address and port of the client to fill DST. ADDR and DST. port field, while some other SOCKS5 clients that come with P2P programs only fill DST with 0. ADDR field. Because the IP address must change after Nat, e-border driver cannot be used for Nat scenarios. For example, iptables has the preserves port number attribute, fill DST with only 0. the SOCKS5 client of the ADDR field can be used to cross iptables. In addition, cross-Nat also requires the cooperation of the SOCKS5 server. Unfortunately, some SOCKS5 servers still do not fully understand the rfc1928 proposal. At this point, the SOCKS5 of WinGate is better, and the client can fill DST with 0. ADDR and DST. port field, while the SOCKS5 in CCProxy supports filling DST with 0 when the client performs UDP associate. ADDR and DST. port field, and can distribute a UDP port to the client smoothly on the server. However, when the UDP port communicates with the client later, it is not the UDP port corresponding to the client, instead, it is sent to the client to fill the DST with 0. port. As for the widely-spread free SOCKS5 server provided by NEC, simply declare "If the destination port is 0, we will assume the same port as TCP's ", the SOCKS5 client cannot cross Nat.
In this example, iptables has no effect on the SOCKS5 proxy, because the SOCKS5 itself causes poor communication. On the contrary, using iptables to protect source ports also ensures that some SOCKS5 clients can smoothly connect to the SOCKS5 server on the public network through NAT implemented by iptables.
We hope that the two examples in this article will help developers who are about to or have implemented the SOCKS5 proxy.
|
