|
以下斜體部分是來自讀者的問題 HTTPS為什么可以穿越NAT端口映射設(shè)備？ 我的理解是：當一個TCP連接到達端口映射設(shè)備（比如防火墻）時，該設(shè)備從實現(xiàn)原理上可以看作是作為后端服務(wù)器和前端客戶端之間的中間人角色。無論是前期的三次握手類的控制連接，還是后續(xù)的數(shù)據(jù)傳輸，中間人都與前后端分別陸續(xù)完成上述步驟。那么問題來了，HTTPS類的TCP在三次握手后，后續(xù)開始證書傳輸、對稱密鑰生成等。這個過程涉及到私鑰密鑰身份認證。而我的防火墻上并沒有額外配置證書之類的配置，也沒有在客戶端添加防火墻證書的操作，就是簡單的在防火墻上配置了一個某內(nèi)部服務(wù)器的443的端口映射。結(jié)果就通了，想不明白。 作者 車小胖 名詞解釋 NAT NetworkAddress Translation PAT Port Address Translation CDN Content Delivery Network 之所以產(chǎn)生這個理解偏差，可能是因為不熟悉端口映射（PAT）工作原理而造成的。 為了更好地理解PAT的工作原理，先問自己幾個問題： Q1: 為何事先在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無法被互聯(lián)網(wǎng)用戶訪問，假設(shè)公司的公網(wǎng)IP = 1.1.1.1，服務(wù)器IP = 10.0.0.1，端口映射將產(chǎn)生這個靜態(tài)表項。
NAT設(shè)備一旦接收目的IP + 端口號為1.1.1.1:443的報文，就會轉(zhuǎn)換為10.0.0.1:443，并將轉(zhuǎn)換好的IP報文繼續(xù)轉(zhuǎn)發(fā)給服務(wù)器。 A2：如果把公網(wǎng)IP直接配置在https服務(wù)器上，那么公網(wǎng)IP就被https服務(wù)器獨占了，工作在別的端口號的服務(wù)器，如21、80、445端口就無法被互聯(lián)網(wǎng)用戶訪問。 而在NAT設(shè)備上做21、80、443、445端口映射，可以將這些端口分別映射到特定的服務(wù)器上。
A3：端口映射工作在三四層，三層為IP，四層為TCP/UDP。 A4: 如下圖所示，客戶端的TCP連接被https服務(wù)器終結(jié)，而不是NAT設(shè)備，NAT設(shè)備只是做三四層地址+端口號的轉(zhuǎn)換，僅此而已。 如上圖，在NAT設(shè)備眼里，TLS及應(yīng)用層的http僅僅是貨物，NAT設(shè)備對這些貨物并不關(guān)心是什么，更不會嘗試去理解或修改。 同理，客戶端的TLS安全會話也是終結(jié)在https服務(wù)器上，所以和安全有關(guān)的話題，如安全加密組件協(xié)商、數(shù)字證書認證、服務(wù)器的私鑰簽名、RSA交換密鑰算法、DH交換密鑰算法等等，都是在客戶端與服務(wù)器之間進行的，無需NAT設(shè)備的參與，所以NAT設(shè)備無需任何TLS安全有關(guān)的配置，僅僅做好自己本職工作即可。 目測題主是把端口映射與前置代理服務(wù)器混淆了。 首先來解釋一下什么是前置代理服務(wù)器？ 前置 如上圖所示，在https服務(wù)器前方，有一個https 代理服務(wù)器（proxy），這里的前方的意思是，反向代理服務(wù)器比https服務(wù)器更靠近客戶端，此謂前置。 反向代理 通常意義上的代理，是為客戶端服務(wù)的，作為客戶端的全權(quán)代理，和服務(wù)器建立TCP連接，并將從服務(wù)器獲取的網(wǎng)頁，再轉(zhuǎn)交給客戶端，此謂代理服務(wù)器。 而反向代理，恰恰相反，是為服務(wù)器服務(wù)的，此謂反向代理。 當客戶端訪問服務(wù)器的流量經(jīng)過前置反向代理時，反向代理直接終結(jié)該TCP連接，接下來再直接終結(jié)TLS安全會話，仿佛自己就是真正的服務(wù)器一般。 有同學(xué)會問，為何客戶端訪問服務(wù)器的流量會先經(jīng)過前置反向代理？ 上文其實已經(jīng)解釋過了，因為反向代理的位置在服務(wù)器的前方。 解釋完前置反向代理服務(wù)器，就會發(fā)現(xiàn)，反向代理服務(wù)器既然以服務(wù)器的名義與客戶端建立TLS安全會話，那逃避不了的話題就是，反向代理究竟需不需要服務(wù)器的私鑰與公鑰證書？ 當然需要，反向代理作為一個中間人，獲得了服務(wù)器的合法的授權(quán)。 前置反向代理與服務(wù)器的部署場景有 1） 在一個機房 這種部署場景，希望前置反向代理提供安全防護服務(wù)，只有443端口的流量才能到達服務(wù)器，而其它所有的流量都無法到達服務(wù)器，可以避免服務(wù)器安全漏洞而產(chǎn)生的風(fēng)險。 2） 相距很遙遠的距離 這種就是CDN的部署場景，為的是CDN服務(wù)器更靠近用戶，可以提高用戶響應(yīng)的速度。 CDN服務(wù)器（反向代理）與服務(wù)器，在客戶端請求連接之前，TLS安全會話已經(jīng)建立，這樣大大縮短TLS安全會話的建立時間，間接提高用戶響應(yīng)。 還有一種部署場景，http服務(wù)器不支持TLS安全會話，希望前置反向代理服務(wù)器能夠提供安全會話服務(wù)。 如上圖所示，反向代理服務(wù)器分別與客戶端、服務(wù)器分別建立TCP連接，步驟如下： 1 客戶端與反向代理建立TCP連接（443） 2客戶端與反向代理建立TLS安全會話 （使用服務(wù)器的私鑰、公鑰完成認證） 3 將http里的URL提取出來 4 反向代理服務(wù)器與服務(wù)器建立TCP連接（80） 5 將步驟3的URL發(fā)給服務(wù)器 6 服務(wù)器返回請求的網(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)容是以明文方式傳輸，如果這些內(nèi)容在互聯(lián)網(wǎng)上傳輸，則容易被竊取、泄露，這是一個安全隱患。 通常這種方式，反向代理服務(wù)器與服務(wù)器位于一個機房，由于明文流量在公司內(nèi)部傳輸，這樣就大大減輕了流量被竊取的可能。 |
|
|
