Iptables learning port 03 forwarding

Iptables learning 03 port forwarding two network interfaces: Lan port: 10.1.1.254/24 eth0, Wan port: 60.1.1.1/24 eth1 Lan web server: 10.1.1.1: 80, Lan ftp server: 10.1.1.2: 21 objective: to forward ports to internal servers so that internet users can access the Intranet server. First, confirm that your linux configurations are normal, access Intranet and Internet [plain] iptables-p forward drop [plain] iptables-a forward-mstate -- state ESTABLISHED, RELATED-j ACCEPT must also be added to the Validation Package and associated package. If you want to forward data packets accessing 60.1.1.1: 80 to the web server in the Lan, run the following command [plain] iptables-t nat-A PREROUTI NG-d 60.1.1.1-p tcp -- dport 80-j DNAT -- to 10.1.1.1: 80 ftp service is the same. The command is as follows: [plain] iptables-t nat-a prerouting-d 60.1.1.1-p tcp -- dport 21-j DNAT -- to 10.1.1.2: 21 cannot be accessed yet. Why? I will analyze it in detail below. For iptables, it seems easier to configure external access, while for internal forwarding, there seems to be some problems. There are many reasons for this configuration failure. one by one: first, in this example, our FORWARD policy is DROP. In other words, packets that do not comply with the rules will be discarded, no matter whether they are inside or outside, we will not discuss the problem of confirming the package and associated package here. We don't need to worry about it. I will explain it in detail below. So how can we make this example successful? Add the following rules. [Plain] Does iptables-a forward-d 10.1.1.1-p tcp -- dport 80-j ACCEPT iptables-a forward-d 10.1.1.2-p tcp -- dport 21-j ACCEPT feel dizzy?? Why is the destination address 10. xxx, not 60. xxx, accessed by internet users? Let's go back to the figure above. Where is the FORWARD chain? It is after PREROUTING. That is to say, when the package reaches the FORWARD chain, the destination address has changed to 10. xxx. If the internet user's request is like this: 202.1.1.1: 1333 --> 60.1.1.1: 80, it will become 202.1.1.1: 1333 after our PREROUTING chain --> 10.1.1.1: 80, at this time, if you set a destination address to 60. is the xxx rule useful? This is problem 1. In this case, access to port forwarding should be completed, but sometimes it will not work? Why? Check question 2. Second, the ip Address Configuration of the Intranet server. Here we take the web server as an example to describe it (ftp has some special circumstances. We will discuss it in detail below, I will discuss this issue when confirming the package and associated Package). As mentioned above, sometimes it can be accessed, but sometimes it won't work. This is the IP Address Setting Problem of the web server, if the web server does not specify the default gateway, the web server will receive an internet request after the above configuration, but he does not know where to go back, your local route table does not know your internet ip address. If you use the packet capture tool to view the web server, you will find that the server received a request from 202.1.1.1: 1333 --> 10.1.1.1: 80, because you did not configure the default gateway for the webserver, it does not know how to go back, so it becomes disconnected. What should we do? Two solutions: first, configure a default gateway for the server. Of course, point to the linux server configured for port forwarding. In this example, It is 10.1.1.254. After the configuration is complete, access is guaranteed. Have a question? Do you not need to set a rule on the FORWARD chain to allow the IP address of the web server to access the Internet? Can its package go out? The answer is yes. Because our rule allows validation of the package and associated package, otherwise it will not be available. The second method is more troublesome, But it seems safer for the server. The method is to re-Execute SNAT for this package, that is, add rules on the POSTROUTING chain. The command is as follows: [plain] iptables-t nat-a postrouting-d 10.1.1.1-p tcp -- dport 80-j SNAT -- to 10.1.1.254 ftp has the same method. This command is not easy to understand ?? In fact, it is very simple. If you use this command, your web server can receive this request without setting the default gateway, as long as the lan IP addresses of the web server and linux can communicate with each other (that is, the lan IP addresses of the web server and Linux are in the same broadcast domain ), according to the netfilter flowchart above, we will analyze how this package was handled. First, a request 202.1.1.1: 1333 --> 60.1.1.1: 80 was received by linux and entered PREROUTING, A rule (iptables-t nat-APREROUTING-d 60.1.1.1-p tcp -- dport 80-j DNAT -- to 10.1.1.1: 80) is found to be correct, so this package is changed to 202.1.1.1: 1333 --> 10.1.1.1: 80. Go FORWARD and enter the FORWARD chain, okay. There is also a rule that allows the pass (iptables-AFORWARD-d 10.1.1.1-p tcp -- dport 80-j ACCEPT), go to the route box selection, find the appropriate path, and continue to enter the POSTROUTING chain, yeah? We also found A compliant rule (iptables-t nat-a postrouting-d 10.1.1.1-p tcp -- dport 80-jSNAT -- to 10.1.1.254). It turned out to be an SNAT and changed your source address, the package is changed to 10.1.1.254: xxxx --> 10.1.1.1: 80. Why is xxxx used? The port here is random and I don't know what it will be. The two changes are recorded in ip_conntrack of linux. When the web server receives the package, it finds that it was originally a request from its own brother in the intranet, in another broadcast domain, the return packet is directly thrown to the switch without looking for a gateway. After receiving the return packet, linux performs two transformations Based on the entries in ip_conntrack, returns the real internet user, and completes this access. After reading the two examples above, I don't know if you are clear about the iptables forwarding process. I hope it will be helpful to you. Let's talk about the established I 've been talking about above, what is the RELATED rule and its usefulness. To talk about this, we need to briefly talk about the network data communication method. We know that network access is bidirectional. That is to say, to complete data exchange between a Client and the Server, both parties need to send and receive packets. In netfilter, there are several statuses, namely new, established, related, and invalid. When a client accesses the Internet from a machine on the Intranet in this example, we have set a rule to allow the client to go out, but there is no rule to allow the server to come back, how can we complete the access? This is the status mechanism of netfilter. When a lan User accesses the Internet through this linux system, it sends a request packet. The status of this packet is new, when the internet packet is returned, his status is established. Therefore, linux knows that, oh, this packet is a response packet sent by a machine on the Intranet, and he is allowed. When the Internet tries to initiate a new connection internally, the status of the connection is new, so linux ignores it. This is why we need to add this sentence. There is also the related, which is an association state. What will be used? Both tftp and ftp are used, because their transmission mechanism determines that Client_IP: port --> server: 80 and then server: 80 --> Client_IP: port, unlike http access, ftp uses tcp21 to establish a connection and uses Port 20 to send data. There are two methods: active mode and passive mode. in active mode, the client uses the port command to tell the server which port I use to accept data, and then the server initiates a request to this port. In passive mode, the server uses the port command to tell the client which port it listens to and then the client initiates data transmission to the client. Therefore, this is a troublesome problem for a firewall, because there may be data packets in the new State, but it is a reasonable request, this related state is used at this time. It is an association. In linux, there is a module named ftp_conntrack, which can identify the port command and then release the corresponding port. There are also a few command parameters that are more practical in practice (also use :-). For your reference, the list of [plain] iptables-L-n will skip the linux domain lookup, sometimes using iptables-L is slow, because linux will try to resolve the ip domain name. It's really cool. If your dns server is uncomfortable, iptables-L will make you very uncomfortable, just add a-n parameter. Click the list and click it. Of course, if your linux is a firewall, it is recommended that you remove the nameserver in/etc/resolve. conf, because sometimes the route command is slow to list, it is very uncomfortable. [Plain] the iptables-L-v command will display the number of packets and flow meters in the chain rule. Hey hey, let's see which kids use so much traffic and use tc to limit them. [Plain] cat/proc/net/ip_conntrack: Check the current conntrack. There may be more. You 'd better add a | grep "keyword ", check the link trace you are interested in [plain] wc-l/proc/net/ip_conntrack to check the total number of links [plain] iptables-save>/etc/iptables chain backup, put iptables under/etc, because when the machine is restarted, all the chains will be automatically loaded and backed up frequently. Otherwise, if there are many chains, restart the machine in case of power failure, you will still suffer.