NAT principles and implementation

NAT principles and NAT traversal technical principles and implementation recently, when reading things, I found that many network programs need NAT traversal. I would like to summarize it here. First, make an agreement: Intranet A has: A1 (192.168.0.8), A2 (192.168.0.9) Dual-user gateway X1 (a nat device) has A public IP address 1.2.3.4 Intranet B has: B1 (192.168.1.8) b2 (192.168.1.9) dual-purpose users, Gateway Y1 (a NAT device) has a public IP address 1.2.3.5 public network server: C (6.7.8.9) D (6.7.8.10) NAT principle Network Address Translation (NAT, network Address Translation is a transfer technology that converts private (retained) addresses into valid IP addresses. The following describes two NAT Methods: Network Address Translators: 192.168.0.8: 4000--6.7.8.9: 8000 at the client: 1.2.3.4: 4000--6.7.8.9: at the gateway: 8000 the core of server C 6.7.8.9: 8000 is to replace the IP address instead of the port. This will cause 192.168.0.8 to handle 192.168.0.9 after using port 4000? For more information, see RFC 1631. Basically, there are few NAT devices of this type. Maybe we don't have a chance to see it. 2. NAPT (Network Address/Port Translators): in fact, this is what we often call nat napt. It is characteristic that the IP Address of the gateway is used when the gateway is used, however, the port selects a temporary port corresponding to the temporary session. For example, when the client is 192.168.0.8: 4000--6.7.8.9: 8000, 1.2.3.4: 62000--6.7.8.9: 8000 server C 6.7.8.9: 8000, A 1.2.3.4: 62000 session is established on the gateway for 192.168.0.8: communication between 4000 and 6.7.8.9: 8000. For NAPT, there are two major types. The difference is that when two Intranet Users communicate with port 8000 at the same time in different ways: 2.1 and Symmetric NAT) when the client is 192.168.0.8: 4000--6.7.8.9: 8000 192.168.0.8: 4000--6.7.8.10: 8000 at the gateway, two different sessions have different port numbers. 1.2.3.4: 62000--6.7.8.9: 8000 1.2.3.4: 8000 server C 6.7.8.9: 8000 server D 6.7.8.10: 8000 will cause many p2p software failures. 2.2 Cone NAT type (Cone Type) 192.168.0.8: small: 8000 192.168.0.8: 4000--6.7.8.10: 8000 at the gateway, two different sessions with the same port number 1.2.3.4: 62000--6.7.8.9: 8000 1.2.3.4: 62000--6.7.8.10: 8000 server C 6.7.8.9: 8000 server D 6.7.8.10: 8000 this is currently the vast majority of servers. Cone NAT is divided into three types: a) Full Cone NAT (Full Cone type): From the same private IP address port 192.168.0.8: 4000 all requests sent to the public network are mapped to the same public address port 1.2.3.4: 62000,192.168 .0.8. You can receive a datagram sent from any external host to 1.2.3.4: 62000. B) Address Restricted Cone NAT (Address restriction Cone type): All requests sent from the same private IP Address port 192.168.0.8: 4000 to the public network are mapped to the same public IP Address port 1.2.3.4: 62000, only after the internal host 192.168.0.8 sends a datagram to the server C 6.7.8.9 can 192.168.0.8 receive a datagram sent from 6.7.8.9 to 1.2.3.4: 62000. C) Port Restricted Cone NAT (Port restriction Cone type): All requests sent from the same private IP address Port 192.168.0.8: 4000 to the public network are mapped to the same public IP address Port 1.2.3.4: 62000, only when the internal host 192.168.0.8 sends a datagram to the external host address port 6.7.8.9: 8000, 192.168.0.8 can receive the datagram sent from 6.7.8.9: 8000 to 1.2.3.4: 62000. NAT traversal implementation A1 192.168.0.8: 4000--6.7.8.9: 8000 X1 at Gateway 1.2.3.4: 62000--6.7.8.9: 8000 server C 6.7.8.9: 8000 B1 at client 192.168.1.8: 4000--6.7.8.9: 8000 when Y1 is deployed on the gateway, 1.2.3.5: 31000--6.7.8.9: 8000 if two Intranet users want to make direct calls through their respective gateways, the following processes are required: 1. the A1 and B1 clients successfully access server C through the grid gateway, no problem (similar to logon) 2. Server C stores information about A1 and B1 on their respective gateways (1.2.3.4: 62000, 1.2.3.5: 31000. A1 and b2. 3. Will 1.2.3.5: 31000 sent by A1 to B1 gateway be received by B1? The answer is basically no (unless Y1 is set to a fully cone type, but this setting is very rare), because Y1 detects that there is no target IP address or port in its surviving session at 1.2.3.4: 62000. All data packets are discarded! 4. To achieve mutual access between A1 and B1 through X1 and Y1, the server C needs to tell them to establish a "UDP tunnel" on their own gateway, that is, the command A1 sends a 192.168.0.8: for a 31000-62000 datagram, B1 sends a 192.168.1.8: 4000--1.2.3.4: datagram, In the UDP format, so that there are two different sessions with the same IP Ports on X1 and Y1 (obviously, this requires the gateway to be In the Cone NAT type. Otherwise, the Symmetric NAT gateway will enable different ports for different sessions, and the port cannot be known to the server or the other party, which makes no sense ). 5. data packets sent from A1 to Y1 or from B1 to X1 are not discarded and correctly received by the other party. requirements for P2P implementation: 1. The intermediate server saves information and can issue UDP tunnel creation commands. 2. The gateway must be of the Cone NAT type. Symmetric NAT is not suitable. 3. You do not need to establish a udp tunnel for a fully-cone gateway. However, this situation is rare and both sides are required to have fewer gateways of this type. 4. If the X1 gateway is ingress NAT, and Y1 is Address Restricted Cone NAT or Full Cone NAT gateway, a1 can send a datagram to Y1 to B1 through X1 (because Y1 only performs IP-level screening at most ), but B2 sent to X1 will be discarded (because the port in the sent datagram is inconsistent with the port in the X1 session, although the IP address is the same), so it does not make sense. 5. If both parties are using the NAT Gateway, a new port is opened, and the other party can try to guess the port without knowing it, but the success rate is very low in this case, it is not a good solution to bring additional system expenses. 6. The difference between different gateway configurations is that the method of replacing the IP address internally, using different ports and different sessions, and using the same port and different sessions; the IP address, IP address, and port are not restricted. 7. You have not considered the situation where different users access the same server on the same Intranet at the same time. If the gateway uses AddressRestricted Cone NAT or Full Cone NAT, it may cause different user clients to receive packets from others, which is obviously inappropriate. Some commonly used technologies: ALG (Application Layer Gateway): it can be a device or plug-in used to support the SIP protocol. It is similar to opening up a channel on the gateway, it is used to establish a connection between the Intranet and the Internet, that is, it is a custom gateway. It is more suitable for internal application groups that use them. UpnP: it allows the gateway device to find a globally shared IP address as a channel when working, so as to avoid the impact of ports. The device is required to support and enable the upnp function. However, most of the time, these functions are disabled due to security concerns. It is enabled immediately, and the actual application effect has not been tested yet. STUN (Simple Traversalof UDP Through Network): This method is similar to the processing method of server C in the preceding example. This is also a common method. However, the specific implementation is much more complicated than we described. It is up to a lot of work to judge the Nat type of the gateway, which is described in RFC3489. TURN (Traveral Using Relay NAT): This method is to exchange all data through the server, so there will be no obstacle to NAT, however, server load, packet loss, and latency are very serious problems. Currently, many games use this method to avoid NAT problems. This method is not called p2p. ICE (Interactive Connectivity Establishment): It is a combination of the above technologies, but it brings significant complexity.