以下斜體部分是來(lái)自讀者的問(wèn)題

HTTPS為什么可以穿越NAT端口映射設(shè)備？

我的理解是：當(dāng)一個(gè)TCP連接到達(dá)端口映射設(shè)備（比如防火墻）時(shí)，該設(shè)備從實(shí)現(xiàn)原理上可以看作是作為后端服務(wù)器和前端客戶端之間的中間人角色。無(wú)論是前期的三次握手類的控制連接，還是后續(xù)的數(shù)據(jù)傳輸，中間人都與前后端分別陸續(xù)完成上述步驟。那么問(wèn)題來(lái)了，HTTPS類的TCP在三次握手后，后續(xù)開(kāi)始證書(shū)傳輸、對(duì)稱密鑰生成等。這個(gè)過(guò)程涉及到私鑰密鑰身份認(rèn)證。而我的防火墻上并沒(méi)有額外配置證書(shū)之類的配置，也沒(méi)有在客戶端添加防火墻證書(shū)的操作，就是簡(jiǎn)單的在防火墻上配置了一個(gè)某內(nèi)部服務(wù)器的443的端口映射。結(jié)果就通了，想不明白。

作者 車小胖

名詞解釋

NAT  NetworkAddress Translation

PAT   Port Address Translation

CDN   Content Delivery Network

之所以產(chǎn)生這個(gè)理解偏差，可能是因?yàn)椴皇煜ざ丝谟成洌≒AT）工作原理而造成的。

為了更好地理解PAT的工作原理，先問(wèn)自己幾個(gè)問(wèn)題：

Q1: 為何事先在NAT設(shè)備做端口映射？

Q2: 為何不把公網(wǎng)IP直接配置在https服務(wù)器上，而是把公網(wǎng)IP配置在NAT設(shè)備上？

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

Q4：客戶端的TCP連接終結(jié)（Termination）在哪里？

以下是問(wèn)題的回答

A1: 只有公網(wǎng)IP才可以在互聯(lián)網(wǎng)上被用戶訪問(wèn)，而服務(wù)器的私有IP無(wú)法被互聯(lián)網(wǎng)用戶訪問(wèn)，假設(shè)公司的公網(wǎng)IP = 1.1.1.1，服務(wù)器IP = 10.0.0.1，端口映射將產(chǎn)生這個(gè)靜態(tài)表項(xiàng)。

NAT設(shè)備一旦接收目的IP + 端口號(hào)為1.1.1.1:443的報(bào)文，就會(huì)轉(zhuǎn)換為10.0.0.1:443，并將轉(zhuǎn)換好的IP報(bào)文繼續(xù)轉(zhuǎn)發(fā)給服務(wù)器。

A2：如果把公網(wǎng)IP直接配置在https服務(wù)器上，那么公網(wǎng)IP就被https服務(wù)器獨(dú)占了，工作在別的端口號(hào)的服務(wù)器，如21、80、445端口就無(wú)法被互聯(lián)網(wǎng)用戶訪問(wèn)。

而在NAT設(shè)備上做21、80、443、445端口映射，可以將這些端口分別映射到特定的服務(wù)器上。

A3：端口映射工作在三四層，三層為IP，四層為T(mén)CP/UDP。

A4: 如下圖所示，客戶端的TCP連接被https服務(wù)器終結(jié)，而不是NAT設(shè)備，NAT設(shè)備只是做三四層地址+端口號(hào)的轉(zhuǎn)換，僅此而已。

如上圖，在NAT設(shè)備眼里，TLS及應(yīng)用層的http僅僅是貨物，NAT設(shè)備對(duì)這些貨物并不關(guān)心是什么，更不會(huì)嘗試去理解或修改。

同理，客戶端的TLS安全會(huì)話也是終結(jié)在https服務(wù)器上，所以和安全有關(guān)的話題，如安全加密組件協(xié)商、數(shù)字證書(shū)認(rèn)證、服務(wù)器的私鑰簽名、RSA交換密鑰算法、DH交換密鑰算法等等，都是在客戶端與服務(wù)器之間進(jìn)行的，無(wú)需NAT設(shè)備的參與，所以NAT設(shè)備無(wú)需任何TLS安全有關(guān)的配置，僅僅做好自己本職工作即可。

目測(cè)題主是把端口映射與前置代理服務(wù)器混淆了。

首先來(lái)解釋一下什么是前置代理服務(wù)器？

前置

如上圖所示，在https服務(wù)器前方，有一個(gè)https 代理服務(wù)器（proxy），這里的前方的意思是，反向代理服務(wù)器比https服務(wù)器更靠近客戶端，此謂前置。

反向代理

通常意義上的代理，是為客戶端服務(wù)的，作為客戶端的全權(quán)代理，和服務(wù)器建立TCP連接，并將從服務(wù)器獲取的網(wǎng)頁(yè)，再轉(zhuǎn)交給客戶端，此謂代理服務(wù)器。

而反向代理，恰恰相反，是為服務(wù)器服務(wù)的，此謂反向代理。

當(dāng)客戶端訪問(wèn)服務(wù)器的流量經(jīng)過(guò)前置反向代理時(shí)，反向代理直接終結(jié)該TCP連接，接下來(lái)再直接終結(jié)TLS安全會(huì)話，仿佛自己就是真正的服務(wù)器一般。

有同學(xué)會(huì)問(wèn)，為何客戶端訪問(wèn)服務(wù)器的流量會(huì)先經(jīng)過(guò)前置反向代理？

上文其實(shí)已經(jīng)解釋過(guò)了，因?yàn)榉聪虼淼奈恢迷诜?wù)器的前方。

解釋完前置反向代理服務(wù)器，就會(huì)發(fā)現(xiàn)，反向代理服務(wù)器既然以服務(wù)器的名義與客戶端建立TLS安全會(huì)話，那逃避不了的話題就是，反向代理究竟需不需要服務(wù)器的私鑰與公鑰證書(shū)？

當(dāng)然需要，反向代理作為一個(gè)中間人，獲得了服務(wù)器的合法的授權(quán)。

前置反向代理與服務(wù)器的部署場(chǎng)景有

1） 在一個(gè)機(jī)房

這種部署場(chǎng)景，希望前置反向代理提供安全防護(hù)服務(wù)，只有443端口的流量才能到達(dá)服務(wù)器，而其它所有的流量都無(wú)法到達(dá)服務(wù)器，可以避免服務(wù)器安全漏洞而產(chǎn)生的風(fēng)險(xiǎn)。

2） 相距很遙遠(yuǎn)的距離

這種就是CDN的部署場(chǎng)景，為的是CDN服務(wù)器更靠近用戶，可以提高用戶響應(yīng)的速度。

CDN服務(wù)器（反向代理）與服務(wù)器，在客戶端請(qǐng)求連接之前，TLS安全會(huì)話已經(jīng)建立，這樣大大縮短TLS安全會(huì)話的建立時(shí)間，間接提高用戶響應(yīng)。

還有一種部署場(chǎng)景，http服務(wù)器不支持TLS安全會(huì)話，希望前置反向代理服務(wù)器能夠提供安全會(huì)話服務(wù)。

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

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

2客戶端與反向代理建立TLS安全會(huì)話 （使用服務(wù)器的私鑰、公鑰完成認(rèn)證）

3 將http里的URL提取出來(lái)

4 反向代理服務(wù)器與服務(wù)器建立TCP連接（80）

5 將步驟3的URL發(fā)給服務(wù)器

6 服務(wù)器返回請(qǐng)求的網(wǎng)頁(yè)內(nèi)容

7 反向代理服務(wù)器將網(wǎng)頁(yè)內(nèi)容，使用TLS安全加密發(fā)給客戶端

8 客戶端將TLS加密內(nèi)容解密出來(lái)，獲得了明文的網(wǎng)頁(yè)內(nèi)容，并呈現(xiàn)在瀏覽器上。

由于反向代理服務(wù)器與服務(wù)器之間的TCP連接上，沒(méi)有TLS安全加密保護(hù)，所以HTTP的內(nèi)容是以明文方式傳輸，如果這些內(nèi)容在互聯(lián)網(wǎng)上傳輸，則容易被竊取、泄露，這是一個(gè)安全隱患。

通常這種方式，反向代理服務(wù)器與服務(wù)器位于一個(gè)機(jī)房，由于明文流量在公司內(nèi)部傳輸，這樣就大大減輕了流量被竊取的可能。