使用 StrongSwan 的 VPN 伺服器“找不到匹配的對等配置”——這是什麼意思？
我有一個執行 Ubuntu 的 AWS 伺服器，它有一個用於 VPN 的 pptpd 伺服器，以及許多具有不同憑據的客戶端。它工作得很好。但顯然我不應該再使用它了，我應該使用 ipsec。我首先在執行 Ubuntu 16.04 的本地電腦上嘗試此操作，然後再嘗試在實時伺服器上執行此操作。
我能找到的唯一相關教程就是這個。當我有“公路戰士”設置時，其他人似乎是用於站點到站點的 VPN，或用於其他作業系統，或者通常似乎只是針對每天都這樣做的系統管理員（沒有人付錢給我這樣做） ）。
https://raymii.org/s/tutorials/IPSEC_vpn_with_Ubuntu_16.04.html
該教程說使用證書進行身份驗證，因為它們“更易於使用”。
我按照說明進行操作。伺服器名為“winter”，位於 192.168.3.144。客戶端名為“charly”，位於 192.168.3.138。我生成了這樣的伺服器證書：
ipsec pki --pub --in private/vpnHostKey.der --type rsa | ipsec pki --issue --lifetime 730 --cacert cacerts/strongswanCert.der --cakey private/strongswanKey.der --dn "C=CN, O=Winter, CN=winter.lan" --san winter --san 192.168.3.144 --san @192.168.3.144 --flag serverAuth --flag ikeIntermediate --outform der > certs/vpnHostCert.der系統日誌顯示：
May 30 20:34:36 winter charon: 03[CFG] adding virtual IP address pool 2002:25f7:7489:3::/112 May 30 20:34:36 winter charon: 03[CFG] loaded certificate "C=CN, O=Winter, CN=winter.lan" from 'vpnHostCert.der' May 30 20:34:36 winter charon: 03[CFG] id 'winter.lan' not confirmed by certificate, defaulting to 'C=CN, O=Winter, CN=winter.lan'“sudo ipsec statusall”的連接部分如下所示：
Connections: IPSec-IKEv2: %any...%any IKEv2, dpddelay=300s IPSec-IKEv2: local: [C=CN, O=Winter, CN=winter.lan] uses public key authentication IPSec-IKEv2: cert: "C=CN, O=Winter, CN=winter.lan" IPSec-IKEv2: remote: uses public key authentication IPSec-IKEv2: child: 0.0.0.0/0 === dynamic TUNNEL, dpdaction=clear我生成了這樣的客戶端證書：
cat Charly-public.der | sudo ipsec pki --issue --lifetime 730 --cacert /etc/ipsec.d/cacerts/strongswanCert.der --cakey /etc/ipsec.d/private/strongswanKey.der --dn "C=CN, O=Winter, CN=mat@winter.lan" --san "mat@winter" --san "mat@192.168.3.144" --outform der > Charly-cert.der…現在我正在嘗試使用執行 macOS 10.13.4 的 Macbook 進行連接。我將 macintosh VPN 配置為：
- 伺服器地址：winter
- 遠端 ID：mat@winter.lan
- 本地標識：
…並給它我在身份驗證設置下創建的證書。
當我嘗試連接時，它立即失敗，沒有錯誤消息。在伺服器日誌中：
May 30 20:53:15 winter charon: 06[CFG] looking for peer configs matching 192.168.3.144[mat@winter.lan]...192.168.3.138[192.168.3.138] May 30 20:53:15 winter charon: 06[CFG] peer config match local: 0 (ID_RFC822_ADDR -> 6d:61:74:40:77:69:6e:74:65:72:2e:6c:61:6e) May 30 20:53:15 winter charon: 06[CFG] peer config match remote: 1 (ID_IPV4_ADDR -> c0:a8:03:8a) May 30 20:53:15 winter charon: 06[CFG] ike config match: 28 (192.168.3.144 192.168.3.138 IKEv2) May 30 20:53:15 winter charon: 06[CFG] no matching peer config found這是左右配置：
mat@winter:~$ sudo grep -E 'left|right' /etc/ipsec.conf left=%any leftid=winter.lan leftsubnet=0.0.0.0/0 leftcert=vpnHostCert.der leftsendcert=always right=%any rightsourceip=10.42.42.0/24,2002:25f7:7489:3::/112 rightdns=8.8.8.8,2001:4860:4860::8888我真正的問題是，“尋找與 192.168.3.144 匹配的對等配置”是什麼意思？
$$ mat@winter $$…192.168.3.138$$ 192.168.3.138 $$/找不到匹配的對等配置”是什麼意思？我不明白匹配是如何工作的——什麼值是可以接受的，客戶端發送什麼值，以及我如何控制客戶端和伺服器端的值。我不知道不了解如何解析該行，每個部分代表什麼。 謝謝！
這在下面得到了正確的回答，但這是我用我理解的術語解釋我做錯了什麼。tl;dr：leftid 需要在證書中作為 SAN，而不僅僅是作為 DN 中的 CN。
這個想法是連接兩個證書，一個伺服器證書和一個客戶端證書，這樣雙方就可以相互信任。兩個證書均由證書頒發機構 (“CA”) 簽署，並且雙方都擁有 CA 公鑰。如果雙方承認對方的證書是由同一個 CA 簽署的，他們會很高興。問題在於說服 StrongSwan 認識到傳入的客戶端連接想要連接到特定的伺服器證書。對我來說，這似乎很簡單，因為我只配置了一個證書。但是 StrongSwan 專為更複雜的設置而設計。
關鍵組件是 ipsec.conf 中配置的“leftid”。您可以在 StrongSwan 中配置任意數量的不同 VPN，每個 VPN 由不同的 leftid 區分。當客戶端連接時，它會要求使用此名稱的 VPN，在我的情況下，它是在“遠端 ID”下的 VPN 設置中配置的。然後它期望伺服器向它發送一個證書，並且該證書應該將自己標識為相同的 VPN 名稱/leftid/遠端 ID。
所以 StrongSwan 需要為其 leftid 提供證書。您使用 ipsec 生成伺服器證書。您提供一個“專有名稱”（“DN”），它是一長串組件，例如“C=CN、O=Winter、CN=winter.lan”。您還可以提供任意數量的主題備用名稱（“SAN”）。當伺服器啟動時，它會讀入“leftid”和“leftcert”配置。它嘗試在 DN 或 SAN 中查找 leftid。
訣竅是：如果找不到 leftid，它會丟棄 leftid，而只使用整個 DN。這看起來像：
May 30 20:34:36 winter charon: 03[CFG] id 'winter.lan' not confirmed by certificate, defaulting to 'C=CN, O=Winter, CN=winter.lan'這意味著 VPN 現在不再命名為“winter.lan”，而是命名為“C=CN, O=Winter, CN=winter.lan”。如果客戶端想要連接，它必須詢問該名稱，而不是“winter.lan”。這樣做是有道理的，因為如果名稱不匹配，甚至執行都沒有意義。客戶端可以連接到 winter.lan，但如果伺服器發送該證書，它將與客戶端要求的不匹配，客戶端將中止連接。另一方面，它這樣做真的很糟糕，因為沒有辦法說服 Macintosh 要求那個 leftid。
我正在關注的教程中的大問題是它使用的leftid是“vpn.example.org”，並且在建議的ipsec命令中生成伺服器證書，該證書僅在DN中使用，而不是作為SAN添加。如果我用“winter.lan”這樣做，它會失敗。id 與證書不匹配。
May 31 21:32:00 winter charon: 05[CFG] loaded certificate "C=CN, O=Winter, CN=winter.lan" from 'vpnHostCert.der' May 31 21:32:00 winter charon: 05[CFG] id 'winter.lan' not confirmed by certificate, defaulting to 'C=CN, O=Winter, CN=winter.lan'僅當我還使用 –san 將 leftid 作為 SAN 提供時才有效。該教程甚至說“您需要確保 leftid= 與證書中的 CN 相同”。我不知道他們是否使用了與我不同版本的 strongswan，或者存在什麼問題。
由於不清楚字元串“C=CN, O=Winter, CN=winter.lan”何時何地與字元串“winter.lan”匹配，因此會產生額外的混亂。這可能是因為這些標識符還附加了必須匹配的“類型”，並且這些類型通常在日誌中不可見。
無論如何，要注意的關鍵是伺服器啟動時的“未通過證書確認”行。在修復之前，不要費心嘗試與客戶建立聯繫。
但是，您添加到證書的 subjectAltName 擴展之一是
mat@winter.lan您配置leftid=mat@winter的 . 由於不匹配，本地身份將回退到證書的主題 DN（即C=HK, O=Winter, CN=mat@winter）。反過來，這與客戶端 ( ) 提出的遠端身份不匹配looking for peer configs matching 192.168.3.144[mat@winter]。因此，要麼
leftid=mat@winter.lan相應地在客戶端配置中配置和更改遠端身份，要麼將完整的主題 DN 配置為客戶端上的遠端身份（但一些 IKEv2 客戶端實際上並不支持，尤其是 Apple 的客戶端）。使用更新的配置，
winter.lan必須包含為 subjectAltName。它不會與CN主題 DN 的相對 DN 匹配。所以你必須--san winter.lan在頒發伺服器證書時顯式添加。當配置的本地身份與本地證書中的任何身份（主題 DN 或任何主題AltNames - 請注意類型也必須匹配）不匹配時，主題 DN 將用作身份。載入配置時，日誌中有一條適當的消息（類似
id 'mat@winter' not confirmed by certificate, defaulting to 'C=HK, O=Winter, CN=mat@winter'），這也可以在列出配置的 IP 和身份ipsec statusall的部分的輸出中看到。Connections因此，請確保您配置的身份是 IKE 守護程序在身份驗證期間實際使用的身份。日誌消息的組件
looking for peer config...非常簡單。例如192.168.3.144[mat@winter]...192.168.3.138[192.168.3.138]：
- 192.168.3.144：IKE_SA 的本地 IP 地址（= 響應者/伺服器的 IP）
- $$ mat@winter $$: 發起者/客戶端 (IDr) 提出的響應者/伺服器身份，必須與配置的身份匹配 ( leftid )
- 192.168.3.138：IKE_SA 的遠端 IP 地址（= 發起方/客戶端的 IP）
- $$ 192.168.3.138 $$：發起者/客戶端（IDi）提出的發起者/客戶端身份，必須與伺服器上配置的遠端身份匹配（rightid，預設為*%any*，如果未配置）
請注意，比較身份的類型（例如 FQDN 與 USER_FQDN 或 KEY_ID）也必須匹配（身份在日誌中可能看起來相同，例如
ipsec statusall但它們的類型可能不同）。僅當cfg的日誌級別增加到 3時，才會記錄有關此比較的更多詳細資訊（包括類型）。身份對兩件事很重要。一，它們允許選擇特定的配置。因此，通過在 IDr 有效負載中發送特定身份，客戶端聲明它希望使用該特定身份連接到伺服器，並且伺服器將選擇與該身份匹配的配置。有效負載是可選的，一些客戶端不發送它（例如 Windows 客戶端），這允許伺服器選擇它認為合適的任何配置。客戶端身份也是如此，如果它不匹配，則允許伺服器切換到特定配置（但是，使用rightid=%any，預設情況下，選擇配置時客戶端身份將被忽略 - 但必須由客戶端證書）。
其次，身份對於防止任何擁有有效證書的人使用他們喜歡的任何身份進行身份驗證非常重要。例如，如果您的客戶端除了 CA“X”之外還安裝了其他 CA，並且您沒有強制執行特定身份（它們通常與伺服器的主機名匹配），則客戶端將接受由其中任何一個頒發的任何證書CA，而不僅僅是一個專門為該身份/主機名頒發的 CA（如果 CA“X”是唯一一個不強制執行特定伺服器身份的可信 CA，它甚至會接受另一個客戶端證書作為伺服器證書）。對客戶也是如此。您不希望您的客戶端“Y”使用專門頒發給客戶端“Y”的證書將自己驗證為客戶端“Z”。那’rightid設置，例如不同的子網或虛擬 IP 範圍，以允許基於客戶端身份通過 VPN 訪問不同的網路。
我正在關注的教程中的大問題是它使用的leftid是“vpn.example.org”，並且在建議的ipsec命令中生成伺服器證書，該證書僅在DN中使用，而不是作為SAN添加。
是的，出於某種原因，他們將兩個具有不同 TLD (
.com和.net) 的不相關 SAN 添加到證書中。該教程甚至說“您需要確保 leftid= 與證書中的 CN 相同”。我不知道他們是否使用了與我不同版本的 strongswan，或者存在什麼問題。
它不依賴於 strongSwan 版本，而是依賴於客戶端。如果它不發送遠端身份，伺服器可以自由選擇使用完整主題 DN 作為身份的配置。然後由客戶端決定它在伺服器返回時是否接受該身份。因此，與伺服器發送的 DN 的 CN 匹配他們想要強制執行的遠端身份（例如伺服器的 FQDN）的客戶端就可以了。Windows 客戶端執行此操作，Apple 客戶端也可能執行此操作（儘管某些版本的 macOS 也需要匹配的 SAN）。但是 strongSwan 作為客戶端，不會也將要求配置的遠端身份與伺服器返回的身份（及其類型）完全匹配。有一個特殊的客戶端配置（rightid=%vpn.example.com)，其中 strongSwan 不發送遠端身份，並且還將配置的身份與伺服器證書中的所有身份進行匹配。這允許客戶端強制使用 FQDN 作為身份，而伺服器則使用完整的主題 DN 來標識自己，只要該 FQDN 也作為 subjectAltName 包含在伺服器證書中。
由於不清楚字元串“C=CN, O=Winter, CN=winter.lan”何時何地與字元串“winter.lan”匹配，因此會產生額外的混亂。這可能是因為這些標識符還附加了必須匹配的“類型”，並且這些類型通常在日誌中不可見。
這主要是因為 strongSwan 不會將身份與部分 DN 進行匹配。但如上所述，一些客戶端會這樣做（至少他們將 FQDN 與 CN 匹配）。
無論如何，要注意的關鍵是伺服器啟動時的“未通過證書確認”行。在修復之前，不要費心嘗試與客戶建立聯繫。
檢查該日誌消息或輸出是否
ipsec statusall與預期配置匹配絕對是一個好主意。如果客戶端無法連接
no matching peer config found，請確保將looking for peer configs...日誌消息中列出的 IP 和身份與 中配置的連接的 IP 和身份進行比較ipsec statusall。