☰

為不同客戶端設定多個 OpenVPN 實例的最佳實踐

tag-icon • tag-icon linux vpn openvpn pki
為不同客戶端設定多個 OpenVPN 實例的最佳實踐

我正在開發一個項目，需要設定 OpenVPN 實例以將不同客戶的 IoT 設備連接到中央伺服器。每個客戶端都應該有自己獨立的 VPN 連線。我目前正在規劃基礎設施和證書處理，並希望獲得一些有關最佳方法的建議。

對於證書處理，我正在考慮以下結構：

CA.crt
|_Customer1.crt
|  |_ServerCert.crt
|     |_ClientCert1.crt
|     |_ClientCert2.crt
|     |_ClientCertX.crt
|
|_Customer2.crt
   |_ServerCert.crt
      |_ClientCert1.crt
      |_ClientCert2.crt
      |_ClientCertX.crt

因此，我會為每個客戶端設定一個單獨的 OpenVPN 實例，例如/etc/openvpn/server/Client1/和/etc/openvpn/server/Client2/，並使用以下命令啟動它們：

sudo systemctl start [email protected] 這是可以接受的方法嗎？如果您能提供有關組織多個 VPN 用戶端和伺服器基礎架構的見解或替代建議，我將不勝感激。

進一步的問題是：

  • 如何管理大量分散的設備，也許是 Ansible？
  • 對於每個 OpenVPN 實例，我需要一個額外的連接埠。
    • 使用 443 TCP,UDP 和 1194 TCP,UDP 之後接下來會發生什麼？

謝謝你！

答案1

OpenVPN 手冊指出它將信任您在其中配置的 CA 憑證的後代的任何憑證。因此，要真正分離 VPN，您可以從所有設定中省略根憑證。它不會在任何地方使用，不會增加任何價值或好處，那麼為什麼要費心去維護它呢？只需採用 EasyRSA 並為每個 VPN 建立獨立的「根、單級」CA。

我不知道你為什麼在這裡列出連接埠 443；它很少用於 OpenVPN，因為它是眾所周知的 HTTPS 連接埠並且經常被佔用，因此在使用它時通常需要進行涉及port-share.對於這種情況，sslh這是優越的，至少因為你可以使用它的「透明模式」讓守護程式查看遠端的真實 IP，而不必擔心 OpenVPN 使該資訊可用的方式。儘管我懷疑您的專案是否需要這種特性。除此之外，您確實可以使用任意連接埠號碼。 1194 被列為“官方”，但沒有任何內容禁止您設定 11941 或 1195 或 5000（這是十五年前建議的）或其他任何值。選擇一組端口，假設從 1194 及以上端口開始，然後為每個連續的 VPN 實例添加一個端口。

其餘部分是正確的：您為獨立的守護程序使用單獨的（公共）端口，並將它們作為單獨的 SystemD 單元運行。考慮為不同的 VPN 提供單獨的容器：雖然可以在單一命名空間中執行單獨的 VPN 實例，但將它們分開會更容易且不易出錯（並且不會消耗更多資源）。據我了解，您的客戶是不相關的實體，因此這將是更直接的方式將它們分開。在這種情況下，容器內的 VPN 配置可能會使用預設端口，但您將為它們轉發（發布）不同的端口。

指定某個系統專門用於管理VPN；它將儲存您的 CA，因此只有它才能頒發憑證。還需要該系統來發布 CRL；預設情況下，CRL 的有效期為 30 天，如果您配置crl-verify（您會的！），當 CRL 過期時，VPN 將停止接受新連接，直到它再次有效。因此，您真正需要自動化的是 CRL 重新頒發和分發。更新 CRL 檔案時不需要重新載入守護進程，因此簡單地scp覆寫舊檔案的目標系統就足夠了。

建立 OpenVPN 用戶端設定檔範本並從該範本產生帶有嵌入憑證的客戶端設定非常有用；即使沒有 Ansible，這也為我節省了很多時間。我經常自訂捆綁openssl.cnf和vars文件以添加多個字段並刪除未使用的字段，並重新組織內容並使其以更少的問題運行（或沒有問題，用於批次）。對於您的情況，使用此類模板和生成腳本來建立新的 VPN 和伺服器配置可能會很有用。此類範本、腳本和自訂對於實例化新客戶或現有客戶的新 IoT 設備的 Ansible 劇本非常有用。對於後者，最好將憑證的 CN 與物聯網設備的序號連結起來，這應該可以簡化記帳。

相關內容