Conexão OpenVPN redefinida a cada 2 minutos

Conexão OpenVPN redefinida a cada 2 minutos

Eu tenho um servidor OpenVPN rodando no Ubuntu na AWS e usando o Tunnelblick no macOS para conectar-me a ele. Não tenho problemas para me conectar a outros servidores VPN, mas este parece expirar/reiniciar a cada 2 minutos.

Meu perfil OVPN:

client
dev tun
proto udp
remote ............... 1194
resolv-retry infinite
nobind
user nobody
group nogroup
persist-key
persist-tun
remote-cert-tls server
cipher AES-256-CBC
verb 3
cipher AES-128-CBC
auth SHA256
key-direction 1
<ca>
-----BEGIN CERTIFICATE-----
...
-----END CERTIFICATE-----
</ca>
<cert>
Certificate:
    Data:
        Version: 3 (0x2)
...
-----BEGIN CERTIFICATE-----
...
-----END CERTIFICATE-----
</cert>
<key>
-----BEGIN PRIVATE KEY-----
...
-----END PRIVATE KEY-----
</key>
<tls-auth>
#
# 2048 bit OpenVPN static key
#
-----BEGIN OpenVPN Static key V1-----
...
-----END OpenVPN Static key V1-----
</tls-auth>

Na conexão, o servidor envia as seguintes configurações:

PUSH: Received control message: 'PUSH_REPLY,redirect-gateway def1 bypass-dhcp,dhcp-option DNS 8.8.8.8,route 172.16.0.0 255.255.240.0,route 172.16.16.0 255.255.240.0,route 172.16.128.0 255.255.240.0,route 172.16.144.0 255.255.240.0,route 10.8.0.1,topology net30,ping 10,ping-restart 120,ifconfig 10.8.0.6 10.8.0.5,peer-id 1,cipher AES-256-GCM'

(observe especificamente ping 10,ping-restart 120)

Aumentando o nível de log no cliente, parece que a conexão está enviando pacotes de dados:

2021-09-03 11:31:21.848620 UDP WRITE [62] to [AF_INET]...:1194: P_ACK_V1 kid=0 pid=[ #13 ] [ 6 ]
2021-09-03 11:31:21.848768 UDP WRITE [130] to [AF_INET]...:1194: P_DATA_V2 kid=0 DATA len=129
2021-09-03 11:31:21.848856 UDP WRITE [226] to [AF_INET]...:1194: P_DATA_V2 kid=0 DATA len=225

No entanto, a conexão sempre morre após cerca de 2 minutos. Estados do log do cliente:

2021-09-03 11:40:26.121900 [cc-vpn] Inactivity timeout (--ping-restart), restarting
2021-09-03 11:40:26.122379 SIGUSR1[soft,ping-restart] received, process restarting
2021-09-03 11:40:26.122504 MANAGEMENT: >STATE:1630683626,RECONNECTING,ping-restart,,,,,
2021-09-03 11:40:26.448969 MANAGEMENT: CMD 'hold release'

Nada realmente no log do servidor além de uma conexão sendo reiniciada.

O tempo limite de 2 minutos faz sentido dada a ping-restart 120configuração enviada ao cliente, mas não estou claro por que ele acha que está inativo. o que estou perdendo? Existe uma configuração no cliente que impede que o ping seja enviado corretamente ao servidor?

Especificamente, adicionar ping/ping-restart à configuração do cliente não parece ajudar (presumo que seria substituído pelo PUSH do servidor de qualquer maneira).

Como posso depurar isso e descobrir por que a conexão não está sendo mantida ativa?

Responder1

Muitas vezes, isso é um sinal de que há mais de um cliente usando este par chave/certificado:

  • (1) autentica
  • (2) autentica; o servidor vê o mesmo certificado, então pensa que a conexão acabou de ser substituída e (1) não receberá mais pings de manutenção de atividade
  • (1) perde alguns pings, decide que a conexão foi interrompida e reconecta, agora (2) não receberá pings
  • (2) perde alguns pings, decide que a conexão foi interrompida e reconecta, agora (1) não receberá pings

Você vê o que está acontecendo e também fica claro como o tempo limite de inatividade definido por ping-restartestá envolvido aqui.

Para que isso não aconteça, você deve gerenciar cuidadosamente sua CA VPN. Em particular:

  • Acompanhe onde suas chaves estão instaladas e quem é o responsável pelo dispositivo onde cada chave está instalada. Tenha uma maneira de entrar em contato com qualquer pessoa que tenha chaves VPN ativas (por exemplo, registre seu número de telefone, e-mail, etc., você pode configurar o OpenSSL para que ele solicite esses dados durante a emissão do certificado e registre esses dados diretamente nos certificados e no índice CA) .
  • Nunca use a mesma chave/certificado mais de uma vez; nunca coloque chave/certificado emmodelos; se você clonar algum sistema, limpe as chaves dele. As chaves devem ser sempre geradas e certificadas emitidas novamente cada vez que o sistema forimplantado.
  • Se algum usuário solicitar (outra) chave/certificado enquanto tiver uma chave ativa, ele deverá explicar o porquê. Eles podem ter perdido dados antigos porque o sistema operacional foi reinstalado e se esqueceram de salvar a configuração da VPN; ou eles simplesmente podem precisar de uma VPN em um computador adicional. Como queiras. Avaliando a explicação deles, você primeirorevogarchave antiga antes de emitir outra, ou emitir uma chave com outro CN para evitar conflito.
  • Eduque seus usuários para sempre notificá-lo de que sua chave/certificado não é mais usado (está perdido ou o motivo de sua emissão foi perdido) para que você possa revogá-lo. E então você tem que revogá-lo.
  • Muito importante, eduque os usuários paracom urgêncianotificá-lo se suspeitarem que a chave/certificado foi roubado; nesse caso, você deverá revogá-lo imediatamente.

Estas são partes de um processo denominado “segurança de rede”. A VPN não poderia ser segura sem certa disciplina, não importa quão perfeito seja o software e a criptografia de última geração que esteja usando.


Se alguém estiver se perguntando por que o OpenVPN não detecta essa condição e não a relata nos arquivos de log, conforme comentado abaixo: seria muito pouco confiável e enganoso. Os logs devem conter apenas fatos brutos, e o único fato bem estabelecido é que o mesmo CN se conecta repetidamente a partir de locais diferentes; não deve conter quaisquer suposições sobre o motivo pelo qual isso aconteceu.

Quando você segue os procedimentos de segurança descritos acima, o problema simplesmente não ocorre. Se isso acontecer, só pode significar que o procedimento foi violado. Nesse caso, para garantir a segurança da VPN, o mais seguro é assumir que a chave foi comprometida e revogar imediatamente um certificado. Provavelmente a VPN irá quebrar para alguma pessoa (de quem era a chave), mas essa será a consequência natural dedelesincapacidade de seguir o procedimento estabelecido: não informaram que não estão usando VPN em algum computador e copiaram para outro, ou o certificado foi roubado, tanto faz. Após a reeducação sobre o tema você poderá emitir o novo certificado para eles.

informação relacionada