無法將以前使用的靜態 IP 地址分配給 OpenVPN 客戶端

我們有一個帶有以下 server.conf 的 OpenVPN 伺服器：

local x.x.x.x
port 1194
proto tcp
dev tap
ca ca.crt
cert server.crt
key server.key
dh dh.pem
auth SHA512
tls-crypt tc.key
topology subnet
server 10.8.0.0 255.255.0.0
ifconfig-pool-persist ipp.txt
client-config-dir /etc/openvpn/ccd
client-to-client
keepalive 10 120
cipher AES-256-CBC
user nobody
group nogroup
persist-key
persist-tun
status openvpn-status.log
verb 3
crl-verify crl.pem

我們還在 AWS 中有一個執行 OpenVPN 客戶端的 Linux 實例，我們通過向 OpenVPN 伺服器/etc/openvpn/ccd目錄添加一個具有客戶端通用名稱的文件，成功為其分配了靜態 IP 地址 10.8.0.2，其內容如下：

ifconfig-push 10.8.0.2 255.255.0.0

現在我們想用 Windows Server 2019 實例替換該 Linux 實例，並為其提供相同的 10.8.0.2 靜態 IP 地址。所以我們做了以下事情：

• 刪除 AWS 中的 Linux 實例
• 在 OpenVPN 伺服器上使用Nyr OpenVPN openvpn-install.sh 腳本撤銷 Linux 客戶端
• /etc/openvpn/server/easy-rsa/pki/index.txt從 OpenVPN 伺服器的文件中刪除了 Linux 客戶端
• /etc/openvpn/server/easy-rsa/pki/revoked/certs_by_serial從 OpenVPN 伺服器的目錄中刪除了 Linux 客戶端的證書
• 刪除 OpenVPN 伺服器/etc/openvpn/ccd目錄中的 Linux 客戶端文件
• 刪除了 OpenVPN 伺服器的/etc/openvpn/server/ipp.txt文件（因為它與 Linux 客戶端關聯了 10.8.0.2）
• 在 OpenVPN 伺服器的/etc/openvpn/ccd目錄中為 Windows Server 2019 實例添加了一個新文件ifconfig-push 10.8.0.2 255.255.0.0
• 在 AWS 中創建了一個 Windows Server 2019 實例
• 在 Windows Server 2019 實例上安裝OpenVPN 2.4.9

Windows Server 2019 實例具有以下 OpenVPN 客戶端配置文件：

client
dev tap
proto tcp
remote x.x.x.x 1194
resolv-retry infinite
nobind
persist-key
persist-tun
remote-cert-tls server
auth SHA512
cipher AES-256-CBC
ignore-unknown-option block-outside-dns
block-outside-dns
verb 3

當我們在 Windows Server 2019 實例上啟動 OpenVPN 客戶端時，OpenVPN 客戶端日誌文件中會顯示以下內容：

Wed Jul 14 01:15:02 2021 [server] Peer Connection Initiated with [AF_INET]x.x.x.x:1194
Wed Jul 14 01:15:03 2021 SENT CONTROL [server]: 'PUSH_REQUEST' (status=1)
Wed Jul 14 01:15:03 2021 PUSH: Received control message: 'PUSH_REPLY,route-gateway 10.8.0.1,ping 10,ping-restart 120,ifconfig 10.8.0.2 255.255.0.0,peer-id 0,cipher AES-256-GCM'
Wed Jul 14 01:15:03 2021 OPTIONS IMPORT: timers and/or timeouts modified
Wed Jul 14 01:15:03 2021 OPTIONS IMPORT: --ifconfig/up options modified
Wed Jul 14 01:15:03 2021 OPTIONS IMPORT: route-related options modified
Wed Jul 14 01:15:03 2021 OPTIONS IMPORT: peer-id set
Wed Jul 14 01:15:03 2021 OPTIONS IMPORT: adjusting link_mtu to 1658
Wed Jul 14 01:15:03 2021 OPTIONS IMPORT: data channel crypto options modified
Wed Jul 14 01:15:03 2021 Data Channel: using negotiated cipher 'AES-256-GCM'
Wed Jul 14 01:15:03 2021 Outgoing Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key
Wed Jul 14 01:15:03 2021 Incoming Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key
Wed Jul 14 01:15:03 2021 interactive service msg_channel=0
Wed Jul 14 01:15:03 2021 open_tun
Wed Jul 14 01:15:03 2021 TAP-WIN32 device [Local Area Connection] opened: \\.\Global\{526EF9D3-DC84-41B0-B139-F1D4BAEFBF4F}.tap
Wed Jul 14 01:15:03 2021 TAP-Windows Driver Version 9.24 
Wed Jul 14 01:15:03 2021 Notified TAP-Windows driver to set a DHCP IP/netmask of 10.8.0.2/255.255.0.0 on interface {526EF9D3-DC84-41B0-B139-F1D4BAEFBF4F} [DHCP-serv: 10.8.0.0, lease-time: 31536000]
Wed Jul 14 01:15:03 2021 Successful ARP Flush on interface [11] {526EF9D3-DC84-41B0-B139-F1D4BAEFBF4F}
Wed Jul 14 01:15:03 2021 Block_DNS: WFP engine opened
Wed Jul 14 01:15:03 2021 Block_DNS: Using existing sublayer
Wed Jul 14 01:15:03 2021 Block_DNS: Added permit filters for exe_path
Wed Jul 14 01:15:03 2021 Block_DNS: Added block filters for all interfaces
Wed Jul 14 01:15:03 2021 Block_DNS: Added permit filters for TAP interface
Wed Jul 14 01:15:08 2021 TEST ROUTES: 0/0 succeeded len=-1 ret=0 a=0 u/d=down
Wed Jul 14 01:15:08 2021 Route: Waiting for TUN/TAP interface to come up...
Wed Jul 14 01:15:13 2021 TEST ROUTES: 0/0 succeeded len=-1 ret=0 a=0 u/d=down
Wed Jul 14 01:15:13 2021 Route: Waiting for TUN/TAP interface to come up...
Wed Jul 14 01:15:14 2021 TEST ROUTES: 0/0 succeeded len=-1 ret=0 a=0 u/d=down
Wed Jul 14 01:15:14 2021 Route: Waiting for TUN/TAP interface to come up...
Wed Jul 14 01:15:15 2021 TEST ROUTES: 0/0 succeeded len=-1 ret=0 a=0 u/d=down
Wed Jul 14 01:15:15 2021 Route: Waiting for TUN/TAP interface to come up...
Wed Jul 14 01:15:16 2021 TEST ROUTES: 0/0 succeeded len=-1 ret=0 a=0 u/d=down
Wed Jul 14 01:15:16 2021 Route: Waiting for TUN/TAP interface to come up...
Wed Jul 14 01:15:17 2021 TEST ROUTES: 0/0 succeeded len=-1 ret=0 a=0 u/d=down
Wed Jul 14 01:15:17 2021 Route: Waiting for TUN/TAP interface to come up...
Wed Jul 14 01:15:18 2021 TEST ROUTES: 0/0 succeeded len=0 ret=1 a=0 u/d=up
Wed Jul 14 01:15:18 2021 WARNING: this configuration may cache passwords in memory -- use the auth-nocache option to prevent this
Wed Jul 14 01:15:18 2021 Initialization Sequence Completed

如您所見，Windows Server 2019 實例上的 OpenVPN 客戶端正在從 OpenVPN 伺服器接收 10.8.0.2 IP 地址。但是，我ipconfig在命令行視窗中反復執行，並且每隔 15 秒就會看到以下情況：

• OpenVPN 網路適配器（稱為“TAP-Windows 適配器 V9”）在幾秒鐘內獲得 169.254.211.103 的 IP 地址。
• 然後 OpenVPN 網路適配器在大約一秒鐘內獲得 10.8.0.2 的 IP 地址。在這一秒內，10.8.0.1（OpenVPN 伺服器）的 ping 將成功。在那一秒之外，10.8.0.1 的 ping 將失敗。
• 然後 OpenVPN 網路適配器失去了 10.8.0.2 IP 地址，並且在接下來的約 12 秒內沒有任何 IP 地址。
• 獲取 169.254.xx 地址，然後獲取和失去 10.8.0.2 地址的過程每 15 秒重複一次。

然後我決定看看如果我嘗試為 Windows Server 2019 提供一個以前從未使用過的不同靜態 IP 地址會發生什麼。我修改了 OpenVPN 伺服器/etc/openvpn/ccd目錄中的 Windows Server 2019 文件，為其提供了一個靜態 IP 地址 10.8.0.11：

ifconfig-push 10.8.0.11 255.255.0.0

然後我在 Windows Server 2019 實例上重新啟動了 OpenVPN 客戶端，它可以工作了！客戶端成功使用了 10.8.0.11 IP 地址，並且完全沒有失去它。

那麼，為什麼 Windows Server 2019 實例一直失去 10.8.0.2 的地址，這個地址之前被 Linux 客戶端使用過呢？從我上面列出的步驟中可以看出，我從 OpenVPN 伺服器上撤銷了 Linux 客戶端，並刪除了我在 OpenVPN 伺服器上可以找到的 Linux 客戶端通用名稱的所有痕跡。

我們希望 Windows Server 2019 實例使用 10.8.0.2 地址，因為我們已經編寫了腳本，假設 10.8.0.2 將是靜態 IP，並將這些腳本發送給第三方。如果可能的話，堅持使用 10.8.0.2 會更容易。

更新：

幾天沒看Windows Server 2019實例，現在又看了一遍。令人驚訝的是，它的 IP 地址為 10.8.0.2，而且從未消失。一切都按預期工作。我不知道為什麼，因為我沒有改變任何東西。

所以我在 Windows Server 2019 實例上重新啟動了 OpenVPN 客戶端，看看會發生什麼，現在又回到了獲取 169.254.xx 地址然後每 15 秒獲取和失去 10.8.0.2 地址的行為。

這是一個 IP 地址衝突，如 Windows Server 2019 實例上的系統事件日誌所示。

我們有一些額外的 Linux 伺服器執行 OpenVPN 客戶端（不同於我在問題中提到的 Linux 客戶端）。這些 Linux 伺服器中的每一個都設置了一個 IP 地址為 10.8.0.2 的網橋。該網橋將 OpenVPN 客戶端的 tap0 介面連接到連接到供應商設備的 eth1 介面。此設置允許在 Windows Server 2019 實例上執行的供應商軟體連接到設備。

我關閉了 Linux 伺服器並重新啟動了 Windows Server 2019 實例。Windows Server 2019 實例能夠獲得 10.8.0.2 而不會失去它。然後我啟動了 Linux 伺服器，現在一切正常。Windows Server 2019 和 Linux 實例很高興，在 Windows Server 上執行的軟體能夠通過 OpenVPN 連接到連接到 Linux 伺服器的設備。

因此，解決方案是確保 Windows Server 2019 實例在任何 Linux 實例設置其網橋之前啟動。

編輯：一個更簡單的解決方案是重新啟動 OpenVPN 伺服器，然後立即在 Windows Server 2019 實例上啟動 OpenVPN 客戶端。在任何 Linux 實例能夠重新連接到 OpenVPN 伺服器之前，它將獲得 10.8.0.2。

引用自：https://serverfault.com/questions/1069824