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

我的理解是:做一個(gè)TCP當(dāng)設(shè)備連接到端口映射設(shè)備（如防火墻）時(shí)，原則上可視為后端服務(wù)器與前端客戶端之間的中間人。無論是前期的三次握手控制連接，還是后續(xù)的數(shù)據(jù)傳輸，中間人都會(huì)先后完成上述步驟。所以問題來了，HTTPS類的TCP三次握手后，證書傳輸、對(duì)稱密鑰生成等后續(xù)開始。這過程涉及私鑰密鑰身份認(rèn)證。我的防火墻沒有額外的配置證書，也沒有在客戶端添加防火墻證書的操作，只是在防火墻上配備了內(nèi)部服務(wù)器的443端口映射。結(jié)果是通過的，我不明白。

作者：車小胖

名詞解釋

NATNetworkAddressTranslation

PATPortAddressTranslation

CDNContentDeliveryNetwork

這種理解偏差可能是由于不熟悉端口映射（PAT）工作原理造成的。

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

Q為什么事先在那里？NAT端口映射設(shè)備？

Q2.為什么不把公網(wǎng)拿走？IP直接配置在https相反，服務(wù)器上有公網(wǎng)IP配置在NAT設(shè)備上？

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

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

以下是問題的答案

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

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

A如果把公網(wǎng)放在一邊IP直接配置在https在服務(wù)器上，公網(wǎng)IP就被https互聯(lián)網(wǎng)用戶無法訪問21、80、445等其他端口號(hào)的服務(wù)器。

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

A三、端口映射工作在三四層，三層為IP，四層為TCP/UDP。

A4:如下圖所示，客戶端TCP連接被https而非服務(wù)器終結(jié)NAT設(shè)備，NAT設(shè)備只做三四層地址 僅此而已。

如上圖，在NAT設(shè)備眼里，TLS及應(yīng)用層的http只是貨物，NAT設(shè)備不關(guān)心這些貨物，更不用說試圖理解或修改了。

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

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

首先，什么是前置代理服務(wù)器？

前置

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

反向代理

代理通常是為客戶端服務(wù)的，作為客戶端的全權(quán)代理，并建立服務(wù)器TCP將從服務(wù)器獲取的網(wǎng)頁連接到客戶端，即代理服務(wù)器。

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

當(dāng)客戶端訪問服務(wù)器的流量通過前置反向代理時(shí)，反向代理直接結(jié)束TCP連接，然后直接結(jié)束TLS安全會(huì)話，好像你是真正的服務(wù)器。

一些學(xué)生會(huì)問，為什么客戶端訪問服務(wù)器的流量首先通過前置反向代理？

由于反向代理位于服務(wù)器前面，上面已經(jīng)解釋過了。

在解釋了前置反向代理服務(wù)器后，您會(huì)發(fā)現(xiàn)反向代理服務(wù)器是以服務(wù)器的名義與客戶端建立的TLS安全會(huì)話，不可避免的話題是，反向代理是否需要服務(wù)器的私鑰和公鑰證書？

當(dāng)然，反向代理作為中間人，已經(jīng)獲得了服務(wù)器的合法授權(quán)。

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

1)在機(jī)房

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

2)距離很遠(yuǎn)的距離

這種就是CDN為了CDN更接近用戶的服務(wù)器可以提高用戶的響應(yīng)速度。

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

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

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

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

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

3、將http里的URL提取出來

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

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

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

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

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

由于服務(wù)器和服務(wù)器之間的反向代理TCP沒有連接TLS所以HTTP如果這些內(nèi)容在互聯(lián)網(wǎng)上傳輸，很容易被盜和泄露，這是一個(gè)安全隱患。

通常這樣，反向代理服務(wù)器和服務(wù)器位于機(jī)房。由于明文流量在公司內(nèi)部傳輸，流量被盜的可能性大大降低。