IPSec VPN 中使用的“共享密鑰”是什麼？
有人可以解釋打開/創建 VPN 隧道時“共享秘密”和“密碼”的作用嗎？
在這種特殊情況下，我為我的 Fritz!Box 設置了一個 VPN，並且我必須提供一個共享密鑰（預先生成且非常長）和一個密碼。
我想了解如何在加密方面使用這兩個憑據。
最有可能的是，這個“共享密鑰”實際上是一個 IKE“預共享密鑰”；它用於對雙方進行身份驗證（對於 IKEv1，被攪拌到密鑰中）。它實際上並沒有用作密鑰（因此學習該密鑰的人不能使用它來監聽，除非他們執行主動的中間人攻擊）。
我懷疑密碼是遠端作業系統的身份驗證憑據；它根本不涉及加密。
現在，如果您要問“這個 IKE 預共享密鑰是如何使用的”，那麼我將嘗試為您概述它；底線是擁有預共享密鑰的人無法監聽（或能夠解密先前擷取的會話）。他們將能夠進行中間人攻擊；這是因為預共享密鑰用作身份驗證數據；有它的人可以冒充。
更複雜的是，有兩種不同版本的 IKE（IKEv1 和 IKEv2），它們使用預共享密鑰的方式略有不同。由於我不知道您使用的是哪一個，我將列出它們如何分別工作。
對於兩個版本的 IKE，協商分兩個階段進行；差異（您關心的）發生在第一階段（生成 IKE SA；這是雙方用來協調事物的加密控制通道）。
以下是 IKEv1 第一階段的工作原理（假設您使用的是預共享密鑰身份驗證，並省略了與密鑰生成無關的部分）：
- 雙方交換隨機數
- 雙方進行 Diffie-Hellman 交換
- 雙方各取隨機數、Diffie-Hellman 共享密鑰和預共享密鑰），生成一組 IKE 密鑰
- 他們交換 IKE 加密消息（以驗證兩者是否使用相同的 IKE 密鑰；如果他們使用不同的 IKE 密鑰，則不會）。
對於 IKEv2，第一階段如下所示：
- 雙方交換隨機數
- 雙方進行 Diffie-Hellman 交換
- 雙方各取隨機數，即 Diffie-Hellman 共享密鑰，並生成一組 IKE 密鑰
- 通過 IKE 加密消息，它們交換身份驗證數據。對於預共享密鑰認證，這是預共享密鑰和密鑰數據的複雜（不可逆）功能。這個想法是，如果有一個不知道預共享密鑰的中間人，實際雙方之間的密鑰數據會有所不同，並且中間人將無法調整此身份驗證標籤以解決此問題）。
現在，對於 IKEv1 和 IKEv2，它們都執行第二階段；它們生成 IPSec SA，它們是用於實際加密流量的密鑰（和其他數據）。為此，他們交換 SPI 值和隨機數，可能進行另一次 Diffie-Hellman 交換，並從一些 IKE 密鑰數據、SPI 值（以及 Diffie-Hellman 共享密鑰，如果使用 Diffie-Hellman）創建 IPSec 密鑰.
現在雙方都建立了 IPSec SA，他們現在可以發送和接收加密流量。
而且，由於涉及 Diffie-Hellman 操作，監聽流量的人無法解密任何內容；即使他們知道“預共享密鑰”是什麼。
IKE 協商分兩個階段進行。第一階段用於建立加密連接；在第二階段，建立實際的 VPN 隧道 - 已經加密。特殊的身份驗證程序確保在協商過程中不會以明文形式傳輸密碼或密鑰。使用 IPSec 跟踪 VPN 連接建立的黑客無法獲取任何安全敏感資訊。