☰

无法将以前使用的静态 IP 地址分配给 OpenVPN 客户端

tag-icon • tag-icon windows networking openvpn ip-address
无法将以前使用的静态 IP 地址分配给 OpenVPN 客户端

我们有一个 OpenVPN 服务器，其 server.conf 如下：

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 实例
  • 使用Nyr OpenVPNOpenVPN 服务器上的 openvpn-install.sh 脚本用于撤销 Linux 客户端
  • 从 OpenVPN 服务器/etc/openvpn/server/easy-rsa/pki/index.txt文件中删除了 Linux 客户端
  • 从 OpenVPN 服务器/etc/openvpn/server/easy-rsa/pki/revoked/certs_by_serial目录中删除了 Linux 客户端的证书
  • 删除了 OpenVPN 服务器/etc/openvpn/ccd目录中的 Linux 客户端文件
  • 删除了 OpenVPN 服务器的/etc/openvpn/server/ipp.txt文件（因为它与 Linux 客户端有 10.8.0.2 的关联）
  • /etc/openvpn/ccd在 Windows Server 2019 实例的OpenVPN 服务器目录中添加了一个新文件，其中包含ifconfig-push 10.8.0.2 255.255.0.0
  • 在 AWS 中创建了一个 Windows Server 2019 实例
  • 已安装OpenVPN 2.4.9在 Windows Server 2019 实例上

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 Adapter V9”）在几秒钟内获取了 IP 地址 169.254.211.103。
  • 然后，OpenVPN 网络适配器会获得 IP 地址 10.8.0.2，持续约一秒钟。在这一秒钟内，ping 10.8.0.1（OpenVPN 服务器）将会成功。在这一秒钟之外，ping 10.8.0.1 将会失败。
  • 然后，OpenVPN 网络适配器将丢失 10.8.0.2 IP 地址，并且在接下来的约 12 秒内没有任何 IP 地址。
  • 获取 169.254.xx 地址，然后获取并丢失 10.8.0.2 地址的过程每 15 秒重复一次。

然后我决定看看如果我尝试为 Windows Server 2019 提供一个以前从未使用过的不同静态 IP 地址会发生什么。我修改了 OpenVPN 服务器目录中 Windows Server 2019 的文件，/etc/openvpn/ccd为其提供了一个静态 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 实例不断丢失 Linux 客户端之前使用过的 10.8.0.2 地址？从我上面列出的步骤中可以看出，我从 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 客户端以查看会发生什么，现在它又恢复了每 15 秒获取 169.254.xx 地址然后获取和丢失 10.8.0.2 地址的行为。

答案1

这是一个 IP 地址冲突，Windows Server 2019 实例上的系统事件日志表明了这一点。

我们还有一些运行 OpenVPN 客户端的额外 Linux 服务器（不同于我在问题中提到的 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。

相关内容