![Conexão OpenVPN redefinida a cada 2 minutos](https://rvso.com/image/770126/Conex%C3%A3o%20OpenVPN%20redefinida%20a%20cada%202%20minutos.png)
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 120
configuraçã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-restart
está 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.