2017-07-28 140 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