O adaptador de rede OpenVPN na máquina Windows continua obtendo/perdendo o endereço IP a cada 15 segundos

Eu tenho uma instância do Windows Server 2019. Instalei o OpenVPN 2.4.9 nela. Isso resultou em um novo adaptador de rede chamado "Conexão de Área Local / Adaptador TAP-Windows V9", conforme visto no Painel de Controle:

Esta máquina Windows está atuando como um cliente OpenVPN. Aqui está a configuração do cliente OpenVPN na máquina:

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

Outra máquina está atuando como servidor OpenVPN. Aqui está o server.conf dessa máquina:

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

Estou tentando fazer com que o servidor OpenVPN atribua um endereço IP estático de 10.8.0.2 à máquina Windows Server 2019. Aqui está o arquivo no diretório /etc/openvpn/ccd do servidor OpenVPN para o cliente:

ifconfig-push 10.8.0.2 255.255.0.0

Quando o cliente OpenVPN no Windows Server 2019 é iniciado, ele parece se conectar ao servidor OpenVPN. Aqui está o arquivo de log no cliente 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

Como você pode ver, o cliente OpenVPN está recebendo o endereço IP 10.8.0.2 do servidor OpenVPN. No entanto, estou fazendo repetidamente ipconfigem uma janela de linha de comando e o que vejo é que a cada 15 segundos acontece o seguinte:

• o adaptador "Local Area Connection" obtém um endereço IP de 169.254.211.103 por alguns segundos
• em seguida, o adaptador "Conexão de Área Local" obtém um endereço IP de 10.8.0.2 por um segundo. Durante esse segundo, um ping de 10.8.0.1 (o servidor OpenVPN) será bem-sucedido.
• então o adaptador "Local Area Connection" não mostra nenhum endereço IP pelos próximos 12 segundos
• esse processo continua se repetindo a cada 15 segundos

Enquanto isso está acontecendo, posso ver que o adaptador no Painel de Controle às vezes muda para "Identificando...":

Se o cliente OpenVPN está obtendo o endereço 10.8.0.2 do servidor OpenVPN, então por que o adaptador primeiro tem um endereço 169.254.xx atribuído? Então, por que ele tem o endereço 10.8.0.2 atribuído por apenas 1 segundo antes de perdê-lo?

INFORMAÇÃO ADICIONAL:

O endereço IP 10.8.0.2 na verdade foi atribuído a uma máquina diferente antes de ontem - uma instância do Linux em execução na AWS. Então fiz o seguinte:

• excluiu a instância do Linux na AWS
• usou o script Nyr OpenVPN openvpn-install.sh no servidor OpenVPN para revogar esse cliente Linux
• excluiu o arquivo no diretório /etc/openvpn/ccd do servidor OpenVPN para o cliente Linux
• adicionou um novo arquivo no diretório /etc/openvpn/ccd do servidor OpenVPN para a máquina Windows Server 2019 com 10.8.0.2 como seu endereço IP

Verifiquei no diretório /etc/openvpn/ccd do servidor OpenVPN que 10.8.0.2 está sendo atribuído apenas à máquina Windows Server 2019 e não a qualquer outra máquina.

Acabei de tentar fazer com que o servidor OpenVPN atribua 10.8.0.11 à máquina Windows Server 2019 e funciona bem, sem problemas. Então, algo está errado com esse endereço 10.8.0.2, provavelmente pelo fato de ter sido usado anteriormente. Alguma ideia do que possa ser?

Eu preferiria poder usar o endereço 10.8.0.2, porque já escrevemos scripts assumindo que 10.8.0.2 será o IP estático e enviamos esses scripts para terceiros. Será mais fácil ficar com 10.8.0.2, se possível.

MAIS INFORMAÇÕES

Decidi tentar eliminar qualquer vestígio do antigo cliente Linux do servidor OpenVPN:

• Eu deletei do arquivo /etc/openvpn/server/easy-rsa/pki/index.txt.
• Eu deletei seu certificado do diretório /etc/openvpn/server/easy-rsa/pki/revoked/certs_by_serial.

Também notei que o arquivo /etc/openvpn/server/ipp.txt do servidor OpenVPN continha uma associação do antigo cliente Linux ao 10.8.0.2 e uma associação do cliente Windows Server 2019 a um endereço IP incorreto. Eu apaguei o arquivo ipp.txt.

Em seguida, reiniciei o servidor OpenVPN e reconectei o cliente OpenVPN do Windows 2019 Server. Infelizmente continuo com o mesmo comportamento de antes.

ATUALIZAR:

Não olhei para a máquina Windows Server 2019 por alguns dias e agora acabei de olhar novamente. Surpreendentemente, ele tinha o endereço IP 10.8.0.2 e nunca desapareceu. Tudo estava funcionando como esperado. Não sei por que, pois não mudei nada.

Então reiniciei o cliente OpenVPN na máquina Windows Server 2019 para ver o que aconteceria, e agora está de volta ao comportamento de obter um endereço 169.254.xx e depois obter e perder o endereço 10.8.0.2 a cada 15 segundos.