Shulou(Shulou.com)06/01 Report--

This article introduces the relevant knowledge of "DNAT and SNAT setting methods of iptables under Linux". In the actual case operation process, many people will encounter such difficulties. Next, let Xiaobian lead you to learn how to deal with these situations! I hope you can read carefully and learn something!

DNAT (Destination Network Address Translation) is often referred to as destination mapping. SNAT (Source Network Address Translation) is often referred to as source mapping.

These are two of the ways we often use when setting up Linux gateways or firewalls. I didn't explain them clearly before, but I'll explain them here.

First, we need to understand the structure of IP packets, as shown in the following figure:

In any IP packet, there will be two fields, Source IP Address and Destination IP Address. The router through which the packet passes also determines where the packet is sent from and where it wants to send the packet. DNAT and SNAT of iptables modify Source IP Address and Destination IP Address according to this principle.

Then, let's look at the chain that packets go through in iptables:

The positive diamond area in the figure is the place where the packet is determined to be forwarded. Here, the system distributes packets based on the IP address in the destination ip address of the IP packet. If destination ip adress is the local address, the data will be forwarded to the INPUT chain. If it is not the local address, it is handed over to FORWARD chain detection.

That is to say, the DNAT we want to do before entering this diamond forwarding area, that is, in the PREROUTING chain, for example, we want to forward the access to 202.103.96.112 to 192.168.0.112:

iptables -t nat -A PREROUTING -d 202.103.96.112 -j DNAT --to-destination 192.168.0.112

In this conversion process, in fact, the destination ip address on the packet that has reached the Linux gateway (firewall) is changed from 202.103.96.112 to 192.168.0.112 and then forwarded to the system router.

SNAT naturally operates on the last chain before the packet leaves the machine, which is the POSTRUTING chain.

iptables -t nat -A POSTROUTING -s 192.168.0.0/24 -j SNAT --to-source 58.20.51.66

This statement tells the system to change the source ip address of the data to be sent out of the machine to 58.20.51.66. Thus, after the packet reaches the destination machine, the destination machine will return the packet to 58.20.51.66, which is the local machine. If you don't do this, then your data packet will definitely be lost in the process of transmission.

Note that DNAT target can only be used in the PREOUTING and OUTPUT chains of the nat table, or in chains that are invoked by both chains. Note, however, that a chain containing DNAT target cannot be invoked by other chains, such as POSTRUTING.

The code is as follows:

Table 6-16. DNAT target

Option --to-destination

Example iptables -t nat -A PREROUTING -p tcp -d 15.45.23.67 --dport 80 -j DNAT --to-destination 192.168.1.1-192.168.1.10

Explanation specifies the address to be written to the IP header, which is also where the packet is to be forwarded. The example above is to forward all packets destined for address 15.45.23.67 to the private addresses used by the LAN, namely 192.168.1.1 to 192.168.1.10. As mentioned earlier, in this case, each flow is randomly assigned an address to forward to, but the same flow always uses the same address. We can also specify only one IP address as a parameter, so that all packets are forwarded to the same machine. We can also specify a port or a range of ports after the address. For example: --to-destination 192.168.1.1: 80 or 192.168.1.1:80-100. SNAT has the same syntax as this target, but with a different purpose. Note that ports can only be used if the TCP or UDP protocol is first specified with--protocol.

Because DNAT has a lot of work to do, I'm going to be a little more verbose. Let's give you an example of how it works. For example, I want to publish our website over the Internet connection, but the HTTP server is in our intranet, and we only have one legal IP outside, which is the firewall's external IP--$INET_IP. The firewall also has an intranet IP--$LAN_IP, and the HTTP server IP is %HTTP_IP (of course this is an intranet). To complete our vision, the first thing to do is to add this simple rule to the PREROUTING chain of the nat table:

The code is as follows:

iptables -t nat -A PREROUTING --dst$INET_IP -p tcp --dport 80 -j DNAT / --to-destination $HTTP_IP

All packets coming from the Internet to port 80 of the firewall are now forwarded (or DNAT) to HTTP servers on the intranet. If you try it on the Internet, everything works. Try it again from the intranet. It doesn't work at all. This is actually a routing problem. Let's analyze this problem carefully. For ease of reading, we write the IP address of the machine accessing our server on the extranet as $EXT_BOX.

Packets depart from a machine with address $EXT_BOX and go to a machine with address $INET_IP.

The packet arrives at the firewall.

Firewall DNAT (i.e. forwarding) the packet, and the packet goes through many other chain checks and processing.

The packet leaves the firewall and proceeds toward $HTTP_IP.

The packet arrives at the HTTP server, and the server responds back through the firewall, which of course requires the firewall to act as the HTTP gateway to $EXT_BOX. In general, a firewall is the default gateway for HTTP servers.

The firewall then un-DNAT the return packet, as if the firewall itself had replied to the request packet from the external network.

The return package seems to have not undergone such complicated processing, and it returns to $EXT_BOX as if nothing happened.

Now, consider what happens when a client accesses an HTTP server from the same intranet as the server (in this case, a network where all machines can access each other directly without going through routers, rather than separating the server and client into separate subnets). We assume that the IP of the client is $LAN_BOX, and the other settings are the same as above.

The packet leaves $LAN_BOX and goes to $INET_IP.

The packet arrives at the firewall.

The packet is DNAT, but it also goes through other processing. But the packet doesn't go through SNAT, so the packet still uses its own source address, which is $LAN_BOX. In fact, the processing of this step is the same as the processing of foreign packets, except that the problem of intranet packets lies in this, so here is the reason).

The packet leaves the firewall and arrives at the HTTP server.

The HTTP server attempts to reply to this packet. It sees in the routing database that the packet is from a single machine on the same network, so it sends the reply packet directly to the source address of the request packet (now the destination address of the reply packet), which is $LAN_BOX.

The reply packet arrives at the client, but it is confused because the packet is not from the machine it accessed. In this way, it will throw the packet away and wait for the "real" reply packet.

There is a simple solution to this problem, because these packets are going through the firewall, and they are going to the address that needs to be DNAT, so we just need to do SNAT on these packets. For example, consider the example above. If SNAT is performed on packets that enter the firewall and are destined for $HTTP_IP on port 80, then these packets appear to be coming from $LAN_IP. This way, the HTTP server sends the reply packet to the firewall, which in turn un-DNAT the packet and sends it to the client. The rules for solving the problem are as follows:

iptables -t -nat -A POSTROUTING -p tcp --dst$HTTP_IP --dport 80 -j SNAT / --to-source $LAN_IP

Keep in mind that the POSTROUTING chain is the last chain in the order it is run, so when packets arrive in this chain, they have already been DNATed, so we need to match packets in our rules based on the intranet address $HTTP_IP (the destination of the packet).

Warning: The rule we just wrote will have a great impact on logs, which should be said to be very bad, because packets from the Internet are processed by DNAT and SNAT in the firewall before reaching the HTTP server (example above), so the HTTP server thinks that the packets are sent by the firewall, but does not know that the real source is other IP. Thus, when it logs service, all access logs originate from the firewall IP rather than the actual access source. It's impossible for us to know anything about visits based on these records. So the "easy fix" provided above is not a smart choice, but it does solve the "accessibility" problem, just without taking into account logging.

Other services have similar problems. For example, if you have an SMTP server on your LAN, you need to set up a firewall to forward SMTP traffic. This way you create an open SMTP relay server, and with that comes the logging problem.

It is important to note that the problems mentioned here are only for networks that do not have a DMZ or similar structure, and users on the intranet access the external network address of the server. (Because if you had a DMZ, or if the server and client were on separate subnets, you wouldn't have to bother.) Since all traffic originates outside the server's network, there is no need to do SNAT to change the packet's source address, and logging is not a problem. If the intranet client is directly accessing the intranet address of the server, it is even more fine)

A better solution is to set up a separate DNS server on your intranet for your LAN. The client can directly access the intranet address of the HTTP server, thus avoiding the operation through the firewall, and the source address of the packet can also be used by the log of the HTTP server, and there is no log problem mentioned above.), Or you can simply create a DMZ (this is the best way, but you have to have money, because you use a lot of equipment ah).

The above example should be considered more comprehensive, there is still a problem unresolved, is the firewall itself to access the HTTP server what happens, can access properly? What do you think:) Unfortunately, the current configuration is still not good, think carefully and understand. The basis of our discussion here is to assume that the host accesses the external network address of the HTTP server, then the client will see the page content, but this is not what it wants to see (what it wants is on DNAT), if there is no HTTP service, the client will only receive error messages. The rule given above doesn't work because the request packet from the firewall doesn't go through those two chains. Remember which chains the firewall itself sends packets through:) We want to add the following rule to the OUTPUT chain of the nat table:

The code is as follows:

iptables -t nat -A OUTPUT --dst$INET_IP -p tcp --dport 80 -j DNAT / --to-destination $HTTP_IP

With this last rule, everything is normal. And HTTP server is not in the same network machine can access the service normally, and it in a network machine can also access the service normally, the firewall itself can also access the service normally, there is no problem. I think you can understand that these rules only describe how packets are properly coded by DNAT and SNAT. In addition to this, additional rules (in the FORWARD chain) are needed in the filter table to allow certain packets to pass through the rules written earlier (in the POSTROUTING chain and the OUTPUT chain). Don't forget that packets are DNATed in the PREROUTING chain before they reach the FORWARD chain, that is, their destination addresses have been rewritten, so be careful when writing rules.

"DNAT and SNAT settings for iptables under Linux" is introduced here. Thank you for reading. If you want to know more about industry-related knowledge, you can pay attention to the website. Xiaobian will output more high-quality practical articles for everyone!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.