SSH session através do OpenVPN corta / trava após algumas linhas

10

Eu tenho um grande número de PCs fanless idênticos executando o debian 6 (ARM). A maioria deles está conectada via comcast e funciona ok. Há alguns que estão conectados a modems 'WiMax' e estão tendo problemas de comunicação.

Especificamente: se eu fizer ssh em um desses e tentar um comando como 'ps -ax', recebo cerca de 3 linhas de volta e então a sessão é bloqueada. Se eu deixá-lo sentar, eventualmente ele será fechado com uma 'sessão fechada pelo peer'.

O que eu tentei:

  • ssh -vvv → nenhuma mensagem de erro
  • ssh <user@host> 'command' → às vezes, isso retornará a saída completa do comando. Às vezes não se conecta de maneira alguma.

Sugestões sobre outras coisas para tentar?

Descobri que posso executar alguns comandos com sucesso: por exemplo, acertar o retorno uma dúzia de vezes ou mais é ok. cd ~ e, em seguida, lf funciona como df -h . Posso executar df muitas vezes com êxito, mas, assim que eu tentar algo com mais resultados (por exemplo, ls /etc ), ele será bloqueado.

Faz alguma diferença que eu esteja tentando se comunicar entre esses dois hosts usando o OpenVPN?

    
por ethrbunny 15.04.2014 / 21:20

3 respostas

7

Você tem os sintomas de um problema MTU : algumas conexões TCP congelam, mais ou menos reprodutível para um determinado comando ou URL, mas sem um padrão geral facilmente discernível. Um sintoma revelador é que as sessões ssh interativas funcionam bem, desde que você não execute comandos com saída grande. Consulte Não é possível acessar sites https selecionados no Linux sobre PPPoE para uma explicação.

O OpenVPN tem várias opções relacionadas a MTU - procure por “mtu” no manual. Eu não tenho experiência suficiente para ter certeza sobre qual opção você precisa mudar. (É até possível que você possa alterar alguma coisa na configuração do modem Wimax.) A opção mais provável de alterar é mssfix : tente diminuir o valor até que ele corrija o problema. O padrão é 1450; algo como por volta de 1400 pode resolver o seu problema. Experimente openvpn --fragment 1200 -mssfix ; se ajudar, aumente o valor até começar a quebrar.

    
por 16.04.2014 / 02:23
2

A resposta de Gilles está completamente correta, mas há também outra causa potencial para isso.

Havia um bug na versão 2.3.0 do OpenVPN que desconectava os clientes ao enviar grandes blocos de dados: link

Esse problema ocorreu apenas ao usar o TCP. O UDP não foi afetado.

    
por 16.04.2014 / 03:28
1

Tivemos o mesmo problema e foi de fato um problema de MTU. No entanto, para nós, o problema não estava na configuração openVPN, mas na interface tun0.

Como resolvemos isso: primeiro encontramos o tamanho máximo de pacote que passou, com

ping <host> -s 1500 -M do

e reduzindo o valor de 1500 até que um valor estivesse passando (para nós, 1350).

Quando o valor correto for encontrado, altere a interface tun0 com

sudo ip link set dev tun0 mtu 1350 && echo ":)"

como foi proposto por Sebastian aqui . Depois disso, a VPN estava indo bem.

    
por 01.06.2018 / 16:40