Eu já vi um problema semelhante e consegui contorná-lo desativando o escalonamento da janela TCP.
sysctl -w net.ipv4.tcp_window_scaling=0
Talvez isso indique a direção certa de onde o problema pode estar.
Eu tenho exatamente o mesmo problema que o descrito aqui, mas não posso solicitar esclarecimentos ao autor, já que sou um novo usuário e não posso postar um comentário sobre isso , por isso estou postando uma nova pergunta (tentei postar isso como uma resposta para referência no mesmo tópico, e ele foi excluído porque não fornece uma resposta ...).
Como evito congelamentos da conexão TCP através de uma rede OpenVPN?
Pergunta: Alguém tem alguma recomendação sobre como solucionar problemas e / ou determinar a causa raiz do problema do TCP descrito nesse encadeamento? É como se o final remoto não estivesse aceitando as mensagens do ACK enviadas pelo cliente VPN.
Minha configuração é exatamente a mesma que na questão original: servidor CentOS (sub-rede de topologia) e dois clientes, um CentOS e um Ubuntu14.03. Quando eu faço um 'ssh cat abc.txt' do ubuntu-client para o centos-client a conexão vpn das bancas cento. A única maneira de recuperá-lo é reiniciar o servidor openvpn (em uma caixa centos) e o cliente openvpn no centos - apenas reiniciar a conexão centos-client não o torna operacional (ele exibirá o tun0 após ~ 1-2 minutos, mas eu não posso mais ping ou ssh a caixa via vpn). Eu também tentei todas as sugestões de ajuste de MTU encontradas em outros tópicos (tun-mtu 1300 / fragment 1100 / mssfix etc) e nenhuma delas ajuda.
O que torna isso ainda mais estranho, é que se eu fizer o mesmo ssh-cat do Ubuntu, usando o servidor CentOS vpn para internet para o endereço IP público do centos-client (assim contornando o centos-client < - gt ; centos-server vpn leg), tudo funciona bem (sem baias, nunca).
UPDATE 1 : Eu encontrei uma solução para corrigir isso, mas é muito feia. Postando aqui, caso algumas pessoas apresentem outras idéias / dicas. Quando eu definir o nível detalhado para 9 no servidor openvpn (não no cliente, apenas servidor), o problema nunca ocorre novamente. O verbo 9 faz com que o servidor openvpn registre muitos dados e use até 100% da CPU em que está sendo executado. Isso limita a velocidade de transferência e faz com que o scp seja concluído com sucesso sem interrupções; scp agora copia com 40-50Kb / seg, enquanto antes estava parado depois de bater acima de 100Kb / seg.
UPDATE 2 : Eu acredito que este é um problema de buffering. O tamanho do arquivo transferido (via scp ou ssh cat) é muito importante. Se eu scp um arquivo 700KB (ou menor), ele sempre terá sucesso , não importa quantas vezes eu tente. Se eu tentar por um arquivo de 800 KB, ele sempre falhará / atrasará após 7xxKb +.
Eu já vi um problema semelhante e consegui contorná-lo desativando o escalonamento da janela TCP.
sysctl -w net.ipv4.tcp_window_scaling=0
Talvez isso indique a direção certa de onde o problema pode estar.