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

Recently, when I was making a solution for a customer, I came across such a scene and buried a hole for myself to record here.

The specific requirements are as follows

Now the customer's domestic server and foreign firewall have been connected to the internal network.

The customer has a WEB server in China to access the external network through a foreign firewall.

You need to be able to origin-pull from a foreign firewall to a domestic WEB server, that is, port 80 of the WEB service can be accessed through the firewall.

Domestic WEB servers have their own public network addresses that need to be managed.

Because at the beginning, the customer did not put forward the third demand for back-to-origin origin, and the solution designed for the customer at that time was

Throw the default route of the customer's domestic machine to the firewall abroad

Do SNAT on foreign firewalls to map the traffic from the internal network segment.

3. Add a static route to the domestic machine and throw the customer's management network segment to the domestic gateway.

The rough topology diagram is as follows

Here, because it is impossible to determine the customer's domestic management address network segment, the default route priority of the static route on the domestic WEB server C is lower than that of the static route, so when the domestic user accesses C, the TCP connection can be established normally through the domestic gateway.

However, at this time, customers also propose that they need to test the quality of origin-pull from foreign servers, that is, to access port 80 of WEB service through the firewall. I thought it was simple to do a DNAT mapping on the firewall to map access to port 80 of the firewall to port 80 of the WEB server. So just do it. After I finished the configuration, I was suddenly confused when I tested the firewall's port 80 in the office network. I was unable to get through port 80 of the firewall. I always reported the error "TIMEOUT". The port 80 of the external network address of the domestic server and the port 80 of the internal network address are OK, that is to say, the web service access is normal, but why can't I access port 80 of the firewall?

So after a variety of tests for half a day, it was found that a phenomenon can normally access port 80 of the firewall from abroad but not at home. When grabbing the packet, I found that the WEB server had received my http request and returned the packet, but the server's return packet did not establish a normal connection with me. The phenomenon should be broken between the second and third handshakes of TCP.

At this time, I suddenly realized why the TCP connection was not established, because I was initiated by a domestic address. When the firewall 80 access was requested to the back-end WEB server through the firewall, the TCP connection could not be established because the domestic routing packet on the server was sent from the domestic gateway instead of the firewall, which caused the source address of the return packet to become the domestic gateway address. The popular explanation is that A made a request to visit B and D responded that A didn't think it was what he wanted, so he denied that the TCP connection could not be established. The diagram is as follows

In order to solve this problem, to sum up, it is necessary to solve the problem of the source in and out of which port the traffic comes in and lets him out. Because WEB server C is equivalent to having two gateway exits, you need to control the direction of traffic on C. So here I think that we can use iproute2 or iptables to achieve the control of routing in essence, so it is more reasonable to use iproute2 to achieve and the performance effect will be better.

A brief introduction to iproute2:

Iproute2 is a new generation of toolkit for managing and controlling TCP/IP network and flow control under linux, which aims to replace the old-school tool chain net-tools, that is, the familiar ifconfigarproutenetstat and other commands. The essential difference between the two sets of tools is that net-tools accesses and changes the kernel network configuration through procfs (/ proc) and ioctl system calls while iproute2 communicates with the kernel through the netlink socket interface.

My solution here is as follows:

Suppose the external network address of my domestic WEB server is 192.168.1.254/30GW:192.168.1.253.

Private network address 192.168.10.2 Default GW192.168.10.1

Leave the default route 10.1 unchanged or go out of the network through a foreign firewall.

Create a new routing table "china" on the WEB server and add the following policy

# echo "1 china" > cat / etc/iproute2/rt_tables# iproute add 192.168.1.252 dev em1 src 30 dev em1 src 192.168.1.254 table china# iproute add default via 192.168.1.253 dev em1 table china# ip rule add from 192.168.1.254 table china3. Delete the previously added national routing table.

4. You can write the routing policy into the network card or rc.local configuration file to ensure that it will still take effect after power on.

Finally: attach a reference link address of the translation on iproute2's 51cto:

Http://os.51cto.com/art/201409/450886.htm

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.