Estou tentando substituir um servidor openvpn rodando Debian stretch e openvpn 2.4.0 por um rodando Debian bullseye e openvpn 2.5.7, infelizmente clientes mais antigos rodando openvpn 2.3 em um sistema operacional antigo não estão conseguindo se conectar ao novo servidor. Não consigo atualizar facilmente esses clientes agora. o cliente diz (censurado).
Socket Buffers: R=[163840->131072] S=[163840->131072]
UDPv4 link local: [undef]
UDPv4 link remote: [AF_INET]xx.xx.xx.xx:1194
TLS: Initial packet from [AF_INET]xx.xx.xx.xx:1194, sid=xxxxxx xxxxxx
Em seguida, ele trava por um tempo e depois relata.
TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
TLS handshake failed
Eu pesquisei um pouco, mas lutei para encontrar uma solução, encontrei uma resposta sobre cifras de canal de dados, mas as coisas nem parecem estar chegando ao ponto de estabelecer o canal de dados.
Portanto, há dois problemas que precisavam ser resolvidos para obter uma conexão bem-sucedida.
A primeira foi que os clientes antigos suportam apenas tls 1.0, mas o openvpn do bullseye nega isso por padrão (acredito que o padrão para isso está relacionado à configuração da biblioteca openssl). O suporte a tls 1.0 pode ser reativado colocando
tls-version-min 1.0a configuração do servidor.O segundo, conforme descrito em https://blog.zs64.net/2021/01/enabling-backwards-compatibility-in-openvpn/ é a cifra do canal de dados, o openvpn não suporta mais uma cifra de fallback para clientes openvpn pré 2.4 por padrão . Eu achei que uma correção maior era necessária do que a especificada lá. Além de configurar
data-cipher-fallbackeu também tive que configurardata-ciphersO conjunto final de configurações extras do lado do servidor foram.
Enquanto no cliente eu definir.