HTTPS為什麼可以穿越NAT埠映射設備？

以下斜體部分是來自讀者的問題

HTTPS為什麼可以穿越NAT埠映射設備？

我的理解是：當一個TCP連接到達埠映射設備（比如防火牆）時，該設備從實現原理上可以看作是作為後端伺服器和前端客戶端之間的中間人角色。無論是前期的三次握手類的控制連接，還是後續的數據傳輸，中間人都與前後端分別陸續完成上述步驟。那麼問題來了，HTTPS類的TCP在三次握手後，後續開始證書傳輸、對稱密鑰生成等。這個過程涉及到私鑰密鑰身份認證。而我的防火牆上並沒有額外配置證書之類的配置，也沒有在客戶端添加防火牆證書的操作，就是簡單的在防火牆上配置了一個某內部伺服器的443的埠映射。結果就通了，想不明白。

作者 車小胖

名詞解釋

NAT NetworkAddress Translation

PAT Port Address Translation

CDN Content Delivery Network

之所以產生這個理解偏差，可能是因為不熟悉埠映射（PAT）工作原理而造成的。

為了更好地理解PAT的工作原理，先問自己幾個問題：

Q1:為何事先在NAT設備做埠映射？

Q2:為何不把公網IP直接配置在https伺服器上，而是把公網IP配置在NAT設備上？

Q3:埠映射（PAT）工作在哪層？

Q4：客戶端的TCP連接終結（Termination）在哪裡？

以下是問題的回答

A1:只有公網IP才可以在互聯網上被用戶訪問，而伺服器的私有IP無法被互聯網用戶訪問，假設公司的公網IP = 1.1.1.1，伺服器IP = 10.0.0.1，埠映射將產生這個靜態表項。

NAT設備一旦接收目的IP + 埠號為1.1.1.1:443的報文，就會轉換為10.0.0.1:443，並將轉換好的IP報文繼續轉發給伺服器。

A2：如果把公網IP直接配置在https伺服器上，那麼公網IP就被https伺服器獨佔了，工作在別的埠號的伺服器，如21、80、445埠就無法被互聯網用戶訪問。

而在NAT設備上做21、80、443、445埠映射，可以將這些埠分別映射到特定的伺服器上。

A3：埠映射工作在三四層，三層為IP，四層為TCP/UDP。

A4:如下圖所示，客戶端的TCP連接被https伺服器終結，而不是NAT設備，NAT設備只是做三四層地址+埠號的轉換，僅此而已。

如上圖，在NAT設備眼裡，TLS及應用層的http僅僅是貨物，NAT設備對這些貨物並不關心是什麼，更不會嘗試去理解或修改。

同理，客戶端的TLS安全會話也是終結在https伺服器上，所以和安全有關的話題，如安全加密組件協商、數字證書認證、伺服器的私鑰簽名、RSA交換密鑰演算法、DH交換密鑰演算法等等，都是在客戶端與伺服器之間進行的，無需NAT設備的參與，所以NAT設備無需任何TLS安全有關的配置，僅僅做好自己本職工作即可。

目測題主是把埠映射與前置代理伺服器混淆了。

首先來解釋一下什麼是前置代理伺服器？

前置

如上圖所示，在https伺服器前方，有一個https 代理伺服器（proxy），這裡的前方的意思是，反向代理伺服器比https伺服器更靠近客戶端，此謂前置。

反向代理

通常意義上的代理，是為客戶端服務的，作為客戶端的全權代理，和伺服器建立TCP連接，並將從伺服器獲取的網頁，再轉交給客戶端，此謂代理伺服器。

而反向代理，恰恰相反，是為伺服器服務的，此謂反向代理。

當客戶端訪問伺服器的流量經過前置反向代理時，反向代理直接終結該TCP連接，接下來再直接終結TLS安全會話，彷彿自己就是真正的伺服器一般。

有同學會問，為何客戶端訪問伺服器的流量會先經過前置反向代理？

上文其實已經解釋過了，因為反向代理的位置在伺服器的前方。

解釋完前置反向代理伺服器，就會發現，反向代理伺服器既然以伺服器的名義與客戶端建立TLS安全會話，那逃避不了的話題就是，反向代理究竟需不需要伺服器的私鑰與公鑰證書？

當然需要，反向代理作為一個中間人，獲得了伺服器的合法的授權。

前置反向代理與伺服器的部署場景有

1）在一個機房

這種部署場景，希望前置反向代理提供安全防護服務，只有443埠的流量才能到達伺服器，而其它所有的流量都無法到達伺服器，可以避免伺服器安全漏洞而產生的風險。

2）相距很遙遠的距離

這種就是CDN的部署場景，為的是CDN伺服器更靠近用戶，可以提高用戶響應的速度。

CDN伺服器（反向代理）與伺服器，在客戶端請求連接之前，TLS安全會話已經建立，這樣大大縮短TLS安全會話的建立時間，間接提高用戶響應。

還有一種部署場景，http伺服器不支持TLS安全會話，希望前置反向代理伺服器能夠提供安全會話服務。

如上圖所示，反向代理伺服器分別與客戶端、伺服器分別建立TCP連接，步驟如下：

1客戶端與反向代理建立TCP連接（443）

2客戶端與反向代理建立TLS安全會話 （使用伺服器的私鑰、公鑰完成認證）

3將http里的URL提取出來

4反向代理伺服器與伺服器建立TCP連接（80）

5將步驟3的URL發給伺服器

6伺服器返回請求的網頁內容

7反向代理伺服器將網頁內容，使用TLS安全加密發給客戶端

8客戶端將TLS加密內容解密出來，獲得了明文的網頁內容，並呈現在瀏覽器上。

由於反向代理伺服器與伺服器之間的TCP連接上，沒有TLS安全加密保護，所以HTTP的內容是以明文方式傳輸，如果這些內容在互聯網上傳輸，則容易被竊取、泄露，這是一個安全隱患。

通常這種方式，反向代理伺服器與伺服器位於一個機房，由於明文流量在公司內部傳輸，這樣就大大減輕了流量被竊取的可能。

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！