Não é possível atribuir um endereço IP estático usado anteriormente a um cliente OpenVPN

Temos um servidor OpenVPN com o seguinte 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

Também tínhamos uma instância do Linux na AWS executando um cliente OpenVPN e atribuímos com sucesso um endereço IP estático de 10.8.0.2 a ela adicionando um arquivo com o nome comum do cliente ao /etc/openvpn/ccddiretório do servidor OpenVPN com o seguinte conteúdo:

ifconfig-push 10.8.0.2 255.255.0.0

Agora queremos substituir essa instância do Linux por uma instância do Windows Server 2019 e fornecer o mesmo endereço IP estático 10.8.0.2. Então fizemos o seguinte:

• excluiu a instância do Linux na AWS
• usou o script Nyr OpenVPN openvpn-install.sh no servidor OpenVPN para revogar o cliente Linux
• /etc/openvpn/server/easy-rsa/pki/index.txtexcluiu o cliente Linux do arquivo do servidor OpenVPN
• /etc/openvpn/server/easy-rsa/pki/revoked/certs_by_serialexcluiu o certificado do cliente Linux do diretório do servidor OpenVPN
• /etc/openvpn/ccdexcluiu o arquivo do cliente Linux no diretório do servidor OpenVPN
• excluiu o arquivo do servidor OpenVPN /etc/openvpn/server/ipp.txt(já que tinha uma associação de 10.8.0.2 ao cliente Linux)
• adicionou um novo arquivo no diretório do servidor OpenVPN /etc/openvpn/ccdpara a instância do Windows Server 2019 comifconfig-push 10.8.0.2 255.255.0.0
• criou uma instância do Windows Server 2019 na AWS
• instalou o OpenVPN 2.4.9 na instância do Windows Server 2019

A instância do Windows Server 2019 tem o seguinte arquivo de configuração do cliente 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

Quando iniciamos o cliente OpenVPN na instância do Windows Server 2019, o seguinte aparece no arquivo de log do 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 na instância do Windows Server 2019 está recebendo o endereço IP 10.8.0.2 do servidor OpenVPN. No entanto, estou executando repetidamente ipconfigem uma janela de linha de comando e vejo o seguinte acontecer a cada 15 segundos:

• O adaptador de rede OpenVPN (chamado "Adaptador TAP-Windows V9") obtém um endereço IP de 169.254.211.103 por alguns segundos.
• Em seguida, o adaptador de rede OpenVPN obtém um endereço IP de 10.8.0.2 por cerca de um segundo. Durante esse segundo, um ping de 10.8.0.1 (o servidor OpenVPN) será bem-sucedido. Fora desse segundo, um ping de 10.8.0.1 falhará.
• Em seguida, o adaptador de rede OpenVPN perde o endereço IP 10.8.0.2 e não possui nenhum endereço IP pelos próximos 12 segundos.
• Esse processo de obter o endereço 169.254.xx e, em seguida, obter e perder o endereço 10.8.0.2 continua se repetindo a cada 15 segundos.

Então decidi ver o que aconteceria se eu tentasse dar ao Windows Server 2019 um endereço IP estático diferente que nunca havia sido usado antes. Modifiquei o arquivo do Windows Server 2019 no diretório do servidor OpenVPN /etc/openvpn/ccdpara fornecer um endereço IP estático de 10.8.0.11:

ifconfig-push 10.8.0.11 255.255.0.0

Então reiniciei o cliente OpenVPN na instância do Windows Server 2019 e funciona! O cliente está usando com sucesso o endereço IP 10.8.0.11 e não o está perdendo.

Então, por que a instância do Windows Server 2019 continua perdendo o endereço 10.8.0.2, que havia sido usado anteriormente pelo cliente Linux? Como você pode ver nas etapas listadas acima, revoguei o cliente Linux do servidor OpenVPN e excluí todos os vestígios do nome comum do cliente Linux que pude encontrar no servidor OpenVPN.

Preferimos que a instância do Windows Server 2019 use 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.

ATUALIZAR:

Não olhei para a instância do 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 instância do Windows Server 2019 para ver o que aconteceria, e agora ele voltou 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.