我有一個防火牆、一個 LoadBalancer（IIS-ARR 負載平衡器）和 2 個 IIS Web 伺服器。 2 個 IIS Web 伺服器將位於具有專用 IP 的 LAN 中。我的網站託管在兩個網站伺服器上。我的實際挑戰是，我的網站中有一個支付網關，只有當請求從網站名稱發送到網站時（例如www.abc.com) 或配置到 IIS-ARR 負載平衡器的公共靜態 IP。
我有 4 個疑問：
當 http 請求由 2 個 Web 伺服器中的任何一個處理時，請求是否來自分配給負載平衡器的網站名稱/公共靜態 IP。或者它將是 Web 伺服器專用 IP。
當 http 請求在 LAN 內以明文形式從負載平衡器流向真實伺服器時，IIS-ARR 負載平衡器上的 SSL 卸載是否容易受到任何攻擊。
在哪裡為我的網站建立 SSL CSR 請求。在 IIS-ARR 伺服器或兩個 Web 伺服器中的任何一個上。需要多少個 SSL 憑證。
如何在整個請求中保留 https (SSL)。從客戶端瀏覽器到防火牆，然後是負載平衡器，然後是真實伺服器。 （沒有 SSL 卸載）
答案1
1. 用戶端期望答案來自於其認為已使用防火牆外部位址啟動的相同 ssl 會話。
客戶端不知道防火牆是否將 tcp 流傳遞到不同的設備，例如 ssl 終止負載平衡器。它也不知道負載平衡器是否將終止的 ssl 會話傳遞到內部後端伺服器（無論負載平衡器是否以重新加密的 https 或未加密的 http 形式將資料傳遞到後端伺服器）。客戶端只知道它以某種方式與某個 IP 位址建立了 ssl 會話，該 IP 位址恰好是防火牆的外部 IP。
透過防火牆、負載平衡器和 ssl 終止層，請求一直到達後端伺服器。然而，當後端準備回應時，如果後端伺服器查看發送者 IP 位址並看到客戶端的外部 IP 位址，它將直接回應客戶端的 IP 位址。直接從後端發送到客戶端的回應將在客戶端發起並發送請求的 ssl 會話之外接收。客戶自然不會期望這樣的回應，並且會拒絕它。
因此，為了確保答案透過用戶端發起的 ssl 會話到達，負載平衡器必須在將請求傳遞到後端伺服器之前調整請求。
它首先解密客戶端 ssl 會話，然後修改原始請求，以便用屬於負載平衡器的來源 IP 位址覆蓋來源 IP 位址，然後將請求傳送到後端伺服器。
後端伺服器現在認為請求源自負載平衡器，並將其回應傳送到負載平衡器而不是原始客戶端。
負載平衡器再次修改數據，以便回應看起來來自負載平衡器而不是來自後端伺服器。之後，負載平衡器將資料加密到與客戶端建立的相同 ssl 會話內，並繼續將回應直接傳送到客戶端。
客戶端高興地接受這一點，並且不知道產生回應所採用的真實網路路徑。
負載平衡器完成的這些 IP 修改稱為來源位址轉換(SNAT)，對於我使用過的所有負載平衡器都是通用的。
為了簡潔起見，我沒有包括公用和私人位址空間之間的防火牆轉換。我建議完全分開這個問題，以免將防火牆完成的重寫與負載平衡器完成的重寫混淆。一旦決定或縮小了防火牆品牌的選擇，防火牆重寫可以透過多種方式完成，並且有其自身的問題。在那之前，請將其視為魔法，當每個入站或出站資料包通過防火牆時，防火牆中就會發生這種情況。
驗證上述設定是否正確的簡單方法是先使用內部用戶端，並在客戶端和負載平衡器之間以及負載平衡器和後端伺服器之間配置未加密的 http 會話。
使用資料包嗅探器，例如Wireshark在客戶端、負載平衡器和後端，人們可以在實踐中看到這些重寫對於任何給定的請求/回應對以及每個網路部分的效果。
一旦設定正常運作並且了解了該過程，就可以先加密客戶端到負載平衡器的路徑，然後加密負載平衡器到後端的路徑。這是緩解學習曲線並促進正確的最終配置的建議。
需要注意的是後端伺服器對請求的感知。
無論外部客戶端的實際數量有多少，後端都只會看到並記錄一個客戶端：內部負載平衡器 SNAT 位址。
這種困境是由負載平衡器對請求進行 SNAT 產生的，透過讓負載平衡器將實際的客戶端外部 IP 位址告知後端伺服器來解決。由於請求來源ip本身被修改，而是透過在http請求中插入http header將真實客戶端ip位址的資訊傳遞給後端。
標頭可以具有任何尚未使用的有效名稱，常見的選擇是X-轉發-用於。
配置負載平衡器以插入此類標頭是此修復發揮作用的第一個要求，第二個要求是通知後端伺服器此標頭的存在。配置特定於負載平衡器和後端伺服器的品牌，很容易透過Google搜尋。這裡例如，如何設定 tomcat 後端以從 x-forwarded-for 進行日誌記錄。自從我上次配置 ARR 以來已經有很長一段時間了，記不起 x-forwarded-for 是如何添加的，但我記得它需要一些實驗和一些谷歌搜索才能開始工作。
2) 是的，由於流量可以透過協定解碼器（如上面建議的 Wireshark）嗅探，因此存在攻擊向量。
這假定攻擊者有權存取網路流量。
如果負載平衡器到後端的流量以明文形式發送，則對負載平衡器或後端伺服器設定錯誤進行故障排除會更容易，但會帶來上述風險。
如何做出這種設計選擇是內部以及任何外部利害關係人值得討論的問題。
3) CSR 通常在 SSL 終止時進行。
若要加密用戶端到負載平衡器的流量，請在負載平衡器上建立 csr 請求。
若要加密負載平衡器到後端的流量，請在後端伺服器上建立 csr。
有多種方法可以將簽名憑證和相應的私鑰作為捆綁包匯出，然後將其匯入到不同的伺服器上。這對於配置負載平衡器叢集非常有用，其中所有成員都需要提供相同的證書，或者配置多個相同的後端以簡化負載平衡器客戶端ssl 配置（即，負載平衡器充當後端伺服器的ssl 客戶端）因為它重新加密了 http 資料）。
4) 決定應在何處完成客戶端 ssl 終止。
可以在某些防火牆中終止 SSL，但更常見的是僅將 tcp 流透過防火牆轉送到負載平衡器，然後負載平衡器終止客戶端 ssl 工作階段。
也可以讓負載平衡器對後端伺服器終止 ssl 的純 tcp 流進行負載平衡。這種情況並不常見，我不會在這裡探討這個選項。
一旦初始 ssl 終止，請決定是否應重新加密數據，例如在負載平衡器和下一個跳轉之間。下一個跳轉可以是後端伺服器或另一個負載平衡器或...
重複此步驟，直到資料應以明文形式發送或到達鏈中的最後一個伺服器。
終止 SSL 是負載平衡器能夠插入 http x-forwarded-for 標頭或執行其他需要存取明文資料的操作的要求。因此，通常在負載平衡器之前或在負載平衡器上或兩者上終止 SSL。
將流量加密傳送到後端和不加密傳送也很常見。這僅取決於組織的情況和發送資料的目的。
SSL 解除安裝只是描述一個過程的術語，其中一項技術取代另一項技術進行 SSL 加密/解密。
它可以是一個負載平衡器，解密 ssl 並將明文傳遞到後端 - 後端已卸載 ssl。
它可以是具有專用於 ssl 加密/解密的專用硬體電路的負載平衡器 - 負載平衡器 CPU 已被 ssl 卸載。等等...