2017-07-28 85 views
1

我有四个Web应用程序运行在一个ec2实例中,主机名为“ip-10-176-225-83.us-west-2.compute.internal “在端口8888,8088,8042和8890上。所有这些Web应用程序都使用HTTP。配置Nginx基于端口号逆向代理请求到后端服务器

我们的安全团队不允许打开从onpremise到AWS的http端口。建议在需要HTTPS请求的相同VPC子服务器中设置反向代理,并使用HTTP将其转发到后端Web服务器。

我在主机名为“ip-10-176-225-84.us-west-2.compute.internal”的相同子网中创建了一个新实例并安装了Niginx服务器。

如何配置Nginx的,以便它如下

https://ip-10-176-225-84.us-west-2.compute.internal:8080呼叫http://ip-10-176-225-83.us-west-2.compute.internal:8080并响应回

同为其他端口

回答

2

TL; DR:有完成你的几种方法在这里寻找。

在可能的情况下,坚持减少attack surface的原则,通常最好不要将端口暴露给公共互联网,除非绝对必要。反向代理是实现这一目标的绝佳方式。一般情况下,你会希望所有的后端的网络应用程序是在端口443上的反向代理通过HTTPS,你会访问每个服务之一:

  • 具有不同的主机名称,如app1.example.comapp2.example.com
  • 有不同的子目录,如example.com/app1example.com/app2

根据您选择的方法,该配置可以为前者的情况而变化显著,无论是与多个server块,或后者的location块。无论哪种情况,我们都会使用upstreamproxy_pass指令。我将举两个场景的例子。


多台主机

如果您正在使用针对前端多个主机名(或多个端口),你需要为他们创建多个server块:

# Nginx reverse-proxy configuration 
upstream app1 { 
    server 10.176.225.83:8888; 
} 

upstream app2 { 
    server 10.176.225.83:8088; 
} 

upstream app3 { 
    server 10.176.225.83:8042; 
} 

upstream app4 { 
    server 10.176.225.83:8890; 
} 

server { 
    listen 443 ssl; 
    server_name app1.example.com; 

    ssl_certificate_key /path/to/your/ssl-key.pem; 
    ssl_certificate /path/to/your/ssl-cert.pem; 

    location/{ 
     proxy_pass http://app1; 
    } 
} 

server { 
    listen 443 ssl; 
    server_name app2.example.com; 

    ssl_certificate_key /path/to/your/ssl-key.pem; 
    ssl_certificate /path/to/your/ssl-cert.pem; 

    location/{ 
     proxy_pass http://app2; 
    } 
} 

server { 
    listen 443 ssl; 
    server_name app3.example.com; 

    ssl_certificate_key /path/to/your/ssl-key.pem; 
    ssl_certificate /path/to/your/ssl-cert.pem; 

    location/{ 
     proxy_pass http://app3; 
    } 
} 

server { 
    listen 443 ssl; 
    server_name app4.example.com; 

    ssl_certificate_key /path/to/your/ssl-key.pem; 
    ssl_certificate /path/to/your/ssl-cert.pem; 

    location/{ 
     proxy_pass http://app4; 
    } 
} 

有几件事要注意:

  • 所有的已使用upstream指令在顶部定义了后端,现在可以按名称引用它。
    • 如果你不想做这种方式,可以省略upstream块和proxy_pass线是这样的:proxy_pass http://10.176.225.83:8888;
  • 因为每个应用程序被送达不同的主机名,每个获得它自己的server块。如果他们各自在不同的港口服务,情况也是如此。
  • ssl_certificatessl_certificate_key中的每个server块都可以指向不同的证书,甚至是相同的证书,如果在证书中定义了多个SANs
  • 每个应用将可以从它自己的主机名,其中所有点到前端服务器:
    • 应用1:https://app1.example.com
    • 应用2:https://app2.example.com
    • 应用3:https://app3.example.com
    • 应用4: https://app4.example.com

多个目录

使用单个主机和端口的配置,从服务子目录中的后端应用程序,你将使用一个单一的server块多location块:

# Nginx reverse-proxy configuration 
upstream app1 { 
    server 10.176.225.83:8888; 
} 

upstream app2 { 
    server 10.176.225.83:8088; 
} 

upstream app3 { 
    server 10.176.225.83:8042; 
} 

upstream app4 { 
    server 10.176.225.83:8890; 
} 

server { 
    listen 443 ssl; 
    server_name example.com; 

    ssl_certificate_key /path/to/your/ssl-key.pem; 
    ssl_certificate /path/to/your/ssl-cert.pem; 

    location /app1 { 
     proxy_pass http://app1; 
    } 

    location /app2 { 
     proxy_pass http://app2; 
    } 

    location /app3 { 
     proxy_pass http://app3; 
    } 

    location /app4 { 
     proxy_pass http://app4; 
    } 
} 

一还有几件事值得注意:

  • 我们仍然定义所有四个upstream服务,如之前。如果你更喜欢直接路线,你仍然可以省略它们。该指令在复杂的配置中更加有用。
  • 因为所有的应用程序都是由相同的主机名提供服务的,所以它们共享一个server块,但它们各自的子目录有单独的location块。
  • 由于它们全部共享相同的主机名,因此在这种情况下,多个SAN对于服务器证书不是必需的。
  • 每个后端应用程序将可从所述前端服务器上的子目录:
    • 应用1:https://example.com/app1
    • 应用2:https://example.com/app2
    • 应用3:https://example.com/app3
    • 应用4:https://example.com/app4

TLS配置

在这两种情况下,您将需要配置SSL证书,或者由公共CA或内部PKI,签署(如果适用)。如果您的应用程序要面向公众,您需要使用公共证书。然后你将他们的位置添加到上面的Nginx配置中。

进一步阅读

对于现实世界的例子,你可以检查出我使用的Genieacs TR-069服务器Nginx的配置,implements SSLreverse proxies一些其他服务,虽然他们原来的端口,而不是443.如果你想保留它们原来的端口,这可能会很有用。

Nginx网站在反向代理基本配置上也有decent primer