Nginx virtual host to solve the enterprise internal and external network access

Nginx Virtual host to solve the enterprise internal and external network access

In the enterprise to deploy services, the need to face a problem is different enterprise complex network environment. In general, private clouds only need to be used within the enterprise, but there are many enterprises that need to be accessible through the extranet. At the same time, for different network access requests, the system also needs to be processed differently. For example, the intranet user requests the download directly can rewrite to the corresponding intranet download machine, but the external network user requests the download may need through the proxy.

Because our system uses Nginx as the total gateway of the network, it is natural to deploy Nginx to solve the internal and external network access problems. For private cloud products, the intranet of Nginx server is very well configured, the difficulty is how to configure the external network server, because there are many network environment, need to consider separately. Basic Knowledge

Before you configure it, first enumerate some of the basics that you need to know about Nginx configuration.

First, let's look at one of the simplest nginx configurations

HTTP {
    server {
        listen 192.168.1.10:80;
        server_name www.domain.com;
        Location/{
            return ' Hello World ';}
        }
}

In the above example, Nginx initiates a server that listens on the 192.168.1.10 80 port and server_name to www.domain.com.

IP and port are well understood, for server_name, can be considered to send HTTP request header inside the host.

When externally sending Http://192.168.1.10:80/hello this HTTP request, the server listening on port 80 will handle it.

At the same time, we can also access through the domain name, such as Http://www.domain.com/hello, because www.domain.com and server_name configuration, so nginx can also handle the response. Of course, the premise is that the enterprise must configure DNS to assign the domain name to 192.168.1.10.

For any HTTP request, Nginx is the first to obtain a matching server, and the specific Nginx select which server, it is the following process:

Identify the server with listen IP and port

If there is more than one server, the server_name is again determined by

If there are still more than one, select the first one in the configuration order

Therefore, through nginx to respond to internal and external network requests, that is, the process of configuring different servers.

For the external network, there are usually 2 cases, with a separate external network IP and NAT map of the external network IP, if the external domain name is provided, IP resolution through the domain name is still the above two cases. independent External Network IP

Assume that the intranet IP is 192.168.1.10, the actual external network IP is 10.20.189.217. No domain name

For machines with independent extranet IP, Nginx is well configured. As follows

server {
    listen 192.168.1.10:80;
    server_name 192.168.1.10;
}

server {
    listen 10.20.189.217:80;
    server_name 10.20.189.217;
}

As you can see, we can directly configure the internal and external network server by listen listening to different IP.

Or we can do it in the following ways:

server {
    listen;
    server_name 192.168.1.10;
}

server {
    listen;
    server_name 10.20.189.217;
}

Here, Nginx listens to the same port, through the corresponding server_name to differentiate the internal and external network. For the case of independent extranet IP, it is recommended to use the former method, direct listen ip:port. have a domain name

If there is a domain name, then we can fill in the corresponding domain name information in the server_name.

server {
    listen 192.168.1.10:80;
    server_name www.domain.com;
}

server {
    listen 10.20.189.217:80;
    server_name www.domain.com;
}

Can be seen, if the internal and external network have the same domain name, then listen must be filled with IP information, if only listen to the port, Nginx can not distinguish the internal and external network through server_name. NAT Extranet IP

If the extranet IP is NAT-mapped, then nginx cannot directly listen the IP. Assume that the NAT map port is still 80, and the extranet NAT address is 10.20.189.217. No domain name

server {
    listen;
    server_name 192.168.1.10;
}

server {
    listen;
    server_name 10.20.189.217;
}

It can be seen that no domain name situation is relatively simple, we can use server_name to distinguish between internal and external network. There are different domain names

If the internal and external network has different domain names, then the situation is the same as no domain name, by configuring the server_name distinction.

server {
    listen;
    server_name www.domain1.com;
}

server {
    listen;
    server_name www.domain2.com;
}

have the same domain name

If the internal and external network has the same domain name, then you can not listen to the same port to distinguish between internal and external network. I can think of the practice is nginx listening to different ports.

server {
    listen;
    server_name www.domain1.com;
}

server {
    listen 10080;
    server_name www.domain2.com;
}

Here, the mapping port of NAT needs to be changed by listening for the 10080来 response to the external network request. End

Can see, inside and outside the network configuration, in fact is Nginx vhost configuration, and the key point lies in listen and server_name. Refer to how Nginx processes a request,server names in detail.

Copyright NOTICE: Free Reprint-Non-commercial-non-derivative-maintain attribution Creative Commons By-nc-nd 3.0