Use iptables to implement NAT on CentOS

Use iptables to implement NAT on CentOS

Experiment: In the following model, node1 is an intranet host, the IP address is 192.168.10.2, node3 is an Internet host, and the IP address is 10.72.37.177 (assuming this address is a public address ), the web server and FTP Server functions are provided on node3. The intranet host node2 has two NICs with the addresses eth0: 192.168.10.1 and eth2: 10.72.37.91 (assuming this address is a public IP address );

You must use iptables configuration on node2 to implement the SNAT function. The following restrictions are imposed:

1. node1 can access the web Services and ftp services provided by node3.

2. node1 only supports ping connection and ssh connection to node3

SNAT implementation process:

Node1 and node2 are both Intranet hosts in the same network segment. Therefore, node1 can directly ping the address 192.168.10.1 of eth1 on node2 by default. After the gateway of node1 host points to 192.168.10.1, node1 can directly ping the Internet address 10.72.37.91 on the eth0 of node2;

However, in this case, the Intranet host node1 cannot ping the address of node3 on the Internet host. Now, the route forwarding function of node2 host can be enabled to send the request message of node1, it is forwarded to the node3 host through node2, but when node3 responds to this message, it finds that the source address is 192.168.10.1, which is not in the same network segment as itself and will be forwarded by the gateway, by default, the gateway of node3 cannot identify this network, so the response message cannot be returned to node2;

Therefore, you can configure node2 to convert the source address of the request packet from 192.168.10.2 to 10.72.37.91 before forwarding the request packet from node1 to the node3 host, in this process, node2 will automatically generate a NAT session table to record each record forwarded through node2;

When node3 encapsulates the response packet, it is found that the source address is 10.72.37.91, so the target address of the response packet will be 10.72.37.91, and the response packet will be returned to node2, at this time, the NAT session table will be queried on node2, and the target address translation will be performed automatically. The response packet will be sent to node1. this enables communication between node1 on the Intranet host and node3 on the Internet host; the SNAT function of iptables implements this function;

In this process, the transmission path between node1, node2, and node3 is as follows:

After a request message is determined by the route of the node2 host and needs to be forwarded, the request message goes through the netfilter chain of the node2 host in the order of PREROUTING --> FORWARD --> OUTROUTING, therefore, SNAT rules must be configured on the OUTROUTING chain, while filter rules must be configured on the FORWARD chain. (In this path, only the filter function is available on the FORWARD chain, the PREROUTING and OUTROUTING chains do not use filters );

Summary: The configuration required for communication between node1 and node3 is as follows:

1. The default gateway of the node1 host points to the eth1 address of node2.

1. Enable route forwarding on node2 host

2. Configure the SNAT function on the node2 host

Configuration process:

On node1:

# Ping 192.168.10.1 # It Can Be pinged directly.

# Route add default gw192.168.10.1 # add route pointing to 192.168.10.1

# Ping 10.72.37.91 # You can ping another address on the node2 host.

On node2:

# Sysctl-wnet. ipv4.ip _ forward = 1 # enable route forwarding on node2 host

On node1:

# Ping 10.72.37.177 # At this time, node1 cannot ping node3 at the moment, but the ping request packet can already be sent to node3.

On node3:

# Iptables-t filter-a input-j LOG # Add the LOG function to the INPUT chain of the node3 host

# Tail/var/log/messages # You can see that the ICMP request message from 192.168.10.2 or node1 has been recorded.

... ... Kernel: IN = eth0OUT = MAC = 1c: 6f: 65: 03: 1b: 9a: 00: 0c: 29: fa: ea: 2d: 08: 00 SRC = 192.168.10.2DST = 10.72.37.177 LEN = 84 TOS = 0x00 PREC = 0x00 TTL = 63 ID = 0 df proto = icmp type = 8 CODE = 0 ID = 4876 SEQ = 9

# If logs are also recorded in the OUTPUT chain at this time, you can also see the response packet of SRC = 10.72.37.177DST = 192.168.10.2, but this response packet cannot be delivered to node1.

On node2

# Iptables-t nat-APOSTROUTING-s 192.168.10.0/24-j SNAT -- to-source 10.72.37.91

# Add a route entry to the NAT table on the POSTROUTING chain of the node2 host to define the host from 192.168.10.0. No matter what protocol is used, no matter which network you access, you can go through the proxy, convert the source address to 10.72.37.91

# Iptables-t nat-l postrouting-nv # the rules we added are displayed on the POSTROUTING chain of the nat table.

In this case, node1 can ping node3, while the log on the node3 host can see the ICMP request message SRC = 10.72.37.91DST = 10.72.37.177 and the Response Message SRC = 10.72.37.177DST = 10.72.37.91; note that the IP address used to communicate with node3 has been converted to 10.72.37.91 by SANT;

On node1

# Curl-Ihttp: // 10.72.37.177 # test the web service connected to node3

# Tail/var/log/nginx/access. log # view the access log on node3. The source address of the client is 10.72.37.91 after conversion.

As required, node1 can only send ping, shh, and web access requests to node3. Therefore, add the following rules to the FORWARD chain of the filter table on node2:

# Iptables-tfilter-PFORWARDDROP # iptables-tfilter-IFORWARD1-s192.168.10.0/24-picmp -- icmp-type8-jACCEPT # Forward request packets from the ICMP protocol 192.168.10.0/24 # iptables-tfilter-IFORWARD1-s10.72.37.0/24-picmp -- icmp-type0-jACCEPT # Forward ICMP messages from 10.72.37.0/24 protocol Response Message # iptables-tfilter-AFORWAORD-s192.168.10.0/24-ptcp-mstate -- stateNEW-mmultiport -- destination-ports21, -jaccept # forward requests from 192.168.10.0/24 in the NEW status, accessing ftp, ssh, and web # iptables-tfilter-AFORWARD-mstate -- stateESTABLISHED, RELATED-jACCEPT # forward all requests in the ESTABLISHED and RELATED (forftp) statuses

After node1 establishes a command connection with the ftp server through port 21 on node3, because the ftp server works in passive mode by default, therefore, node1 also needs to access a random port greater than 1024 on node3 to establish a data connection, that is, node2 needs to forward all ports greater than 1024 to node3; however, this experiment requires that only ports, 22, and 80 can be forwarded;

At this time, the kernel module nf_contrack_ftp must be mounted on the node3 host. This module can monitor the ftp control flow and be able to know the port used for the ftp data connection to be established in advance, this allows the corresponding packets to pass through, even if the firewall does not open this Port:

# Modprobenf_contrack_ftp # manually mount this kernel module

# Lsmod | grep ftp # Now you can see the mounted

# Or write it to the configuration file/etc/sysconfig/iptables-config, you do not need to manually load it each time, even if it is automatically loaded after restart, add a line: IPTABLES_MOUDLES = "nf_contrack_ftp"

If node3 does not load the kernel module nf_conntrack_ftp and is connected to the ftp service on node3 on node1, the following error message is displayed: unable to establish data connection (10.72.37.177) Port 29814

Lftp user2@10.72.37.177: ~> Debug

Lftp user2@10.72.37.177: ~> Ls

---- Connecting to 10.72.37.177 (10.72.37.177) port 21

<--- 220 (vsFTPd 2.2.2)

---> FEAT

<--- 211-Features:

<--- EPRT

<--- EPSV

<--- MDTM

<--- PASV

<--- REST STREAM

<--- SIZE

<--- TVFS

<--- UTF8

<--- 211 End

---> OPTS UTF8 ON

<--- 200 Always in UTF8 mode.

---> USER user2

<--- 331 Please specify the password.

---> PASS XXXX

<--- 230 Login successful.

---> PASV

<--- 227 Entering Passive Mode (37,177,116,118 ).

---- Establishing data connection (10.72.37.177) Port 29814

'LS' at 0 [Establishing data connection...]

...

The preceding figure shows that the network firewall is implemented based on the FORWARD chain on the node2 host. When the Intranet host accesses the Internet through node2, the access control is implemented through the FORWARD chain.