temos uma instalação OpenVPN (geralmente) funcionando. A versão do servidor é "2.6.3-1+deb12u2" rodando dentro de uma Debian 12 Bookworm VM. Os clientes são OpenVPN community 2.6.10+ Windows 10 (número muito baixo de clientes Linux).
Funcionou por anos e, de fato, funciona agora para mim e para a maioria dos meus colegas. No entanto, recentemente, alguns colegas começaram a relatar problemas quando estão "em casa". Eles não parecem ter problemas com hotéis.
Os colegas se conectam com sucesso, mas não conseguem acessar unidades compartilhadas de um servidor Windows (bem, em casos raros isso funciona...), não conseguem carregar páginas https de dispositivos por meio do túnel VPN (http é possível!), não conseguem baixar ou enviar e-mails via TLS/SSL (IMAPs, SMTPs) e alguns softwares estão relatando erros de conexão com o servidor Microsoft SQL. openssl s_clientNão é possível consultar nenhum ponto de extremidade TLS/SSL.
Esse problema só acontece ao usar UDP (porta 1194). A solução alternativa via TCP 443 parece resolver o problema, mas não é uma solução real.
Não consigo encontrar erros relacionados nos logs do "verbo 4" :-( A única mensagem que vejo com bastante frequência é
MULTI: endereço de origem inválido do cliente [], pacote descartado
que deve ser ignorado até onde eu sei. Às vezes há um único
Ocorreu um retrocesso na janela de reprodução PID_ERR
o que pode ser um sinal de um aumento temporário da latência da rede, portanto não crítico e também não relacionado.
Os parâmetros MTU são relatados pelo cliente e nos logs do servidor como
Parâmetros MTU do canal de dados [ mss_fix:1400 max_frag:0 tun_mtu:1500 tun_max_mtu:1600 headroom:136 payload:1768 tailroom:562 ET:0 ]
padrões, afaict. E como eu disse antes, geralmente funciona. O Windows netsh interface ipv4 show interfacesmostra MTU de 1500 para todas as interfaces não locais, incluindo OpenVPN, estejam conectadas ou não.
Estou ficando sem ideias de onde procurar mais informações ou soluções. Alguma ideia?
Editar: dos comentários:
Tenho um colega, onde testei MTU por ping ( ping server -f -l size). O maior tamanho foi 1380, no entanto funcionou com 'mssfix 1430'. Como 1380 e 1430 estão relacionados?
Então tem outro colega. O tamanho de ping bem-sucedido para ele é 1472, o mesmo que para mim. No entanto, ele tem o problema de bloqueio de SSL. Eu consegui fazer funcionar com 'mssfix 1450'.
Infelizmente, definitivamente não posso tentar tun-mtu porque, ao que parece, ele tem que ser alterado em ambos os lados. Provavelmente não há certeza de que sempre funcionará se eu puder obter um valor funcional no momento.
E, na minha opinião, não faz muito sentido brincar com tun-mtu até que saibamos qual é o problema real. Alguma sugestão para isso?
O que acontece essencialmente é que a descoberta do Path MTU é bloqueada por algo que não está funcionando corretamente, como, por exemplo, a queda do ICMP.
O MTU comum de ponta a ponta é 1500B, e você nunca pode assumir algo maior. Para transportar um pacote de 1500B por VPN, ele tem que ser encapsulado, então ele acaba sendo maior que 1500B, e assim tem que ser dividido.
Um roteador descartará esse pacote e responderá com um pacote ICMP informando ao remetente para fragmentar.
O motivo pelo qual isso afeta o SSL é provavelmente porque o SSL usa um pacote grande com os certificados.