Como melhoro a confiabilidade do OpenVPN em um link de alta latência?


11

Estamos executando uma VPN OpenVPN através de um link de satélite BGAN, onde o tempo de ping é de aproximadamente 3 segundos. Nós o usamos em uma configuração tun e estamos rodando no Linux (CentOS). É principalmente o email que será enviado pelo link, mas assim que o email contém anexos grandes, a VPN parece estar paralisada.

O "Eu posso executar ping no túnel, mas qualquer trabalho real faz com que ele bloqueie. Isso é um problema na MTU?" A pergunta no FAQ do OpenVPN parece descrever exatamente o meu problema, mas o uso mssfixe fragmentainda não parece fazer muito para melhorar a situação.

Meu teste principal é copiar um arquivo de 2 MB na VPN com scp . Ele copiará cerca de 192kbytes e, em seguida, reportará um estado parado . Se eu esperar alguns segundos, ele começará a copiar novamente e depois será interrompido novamente após mais alguns kbytes.

Este adiamento ocorre ou não eu definir o fragmentou mssfixopções na minha configuração OpenVPN (embora configuração fragment 1000parecia reduzir o adiamento, mas não eliminá-lo). O OpenVPN mtu-testrelatou 1542 como o tamanho da MTU.

Pesquisei na Internet para obter mais conselhos sobre como e quando usar mssfixe fragment, mas só encontro páginas dizendo o mesmo que as Perguntas frequentes, e não fornecendo detalhes sobre como e quando usar quais parâmetros.

Minhas perguntas são:

  • Quando uso mssfixe fragment?
  • Eu uso mssfixe fragmentem combinação?
  • Se mssfixe fragmentsão a solução, o que são a tun-mtu, link-mtue mtu-discparâmetros para?

Além disso, tenho usado a ferramenta iperf para medir a largura de banda. Sem a VPN, ela mede constantemente na ordem de 210 Kbits / s.

Ao usar o iperf na VPN ( $ iperf -c remoteserver -t60 -i5), ele inicia em 10 Kbits / s, depois sobe continuamente até relatar 1,2 Mb / s e parece que está parado, onde informa 0kbits / seg para várias iterações (I acho que os 1,2 Mbits / s podem ser devido a algum buffer OpenVPN ou mais)

O iperf é a melhor maneira de medir a largura de banda?

Qualquer ajuda com essa situação será muito apreciada.


O openvpn está usando TCP ou UDP no momento?
Pjc50

Atualmente, ele está usando UDP
iWerner

Obrigado por todas as respostas, mas tive que parar temporariamente porque a unidade BGAN ficou sem tempo de antena. Espero começar hoje mais tarde. Devo mencionar que nós preferimos ficar com UDP, como a utilização de TCP dobraria enviou os dados através da rede (e, portanto, o custo, para o qual nosso cliente já é muito sensível)
iWerner

Respostas:


5

1542 como um MTU? Nunca ouvi falar disso em um link WAN. Normalmente, MTU é a carga útil máxima, o tamanho do pacote IP menos o cabeçalho para IP (20 bytes) e ICMP (8 bytes). Isso significa MTU = 1500 para uma LAN Ethernet tradicional. Além disso, a maioria das VPNs introduz uma sobrecarga para o encapsulamento de pacotes. Uma MTU VPN típica é 1400.

Nas redes modernas, é difícil concluir o que o MTU será a qualquer momento, pois os caminhos de entrada e saída podem ser diferentes e também podem mudar devido ao roteamento automático de caminho. Para uma rede como essa, pode ser mais eficaz definir a MTU baixa nos hosts que estão nos dois lados do link VPN, como 576.

MSS (tamanho máximo do segmento) é MTU menos os cabeçalhos IP + TCP (40 bytes). Isso normalmente é negociado pela pilha da rede e geralmente não tem os mesmos problemas de negociação que o MTU, a menos que o MTU esteja errado. (A negociação de MTU geralmente é prejudicada por ICMP bloqueado ou roteadores de buraco negro).

A primeira coisa que eu faria é capturar pacotes de rede no final do envio e classificar a exibição pelo tamanho do quadro (talvez seja necessário adicionar esta coluna no Wireshark). Você deve verificar se não está enviando nenhum quadro de tamanho grande, como seria de esperar. Não é incomum que as placas de rede modernas enviem quadros de tamanho grande, se opções como Large Send Offload ou Jumbo Frames estão ativadas. Vi mais de 30.000 quadros de bytes quando essas opções estão ativadas.


+1 para captura de pacotes antes de alterar qualquer coisa. mesmo se você não encontrar nenhum quadro enorme, poderá ver pacotes 'normais' fragmentados em algum lugar.
Javier

1
Por padrão, o OpenVPN define o MTU do dispositivo tun como 1500 (que é o mesmo que o MTU nos dispositivos Ethernet em nossas máquinas). Ainda não tenho certeza se a fragmentação dos pacotes VPN é uma coisa boa ou ruim. As respostas neste tópico parecem sugerir que é ruim, enquanto as outras referências que encontrei na web implicam que é bom.
IWerner

2
@iwerner: você já tentou determinar o tamanho do mtu com ping? Se o ICMP não estiver desativado em algum lugar, você poderá usar o seguinte no Windows: ping -f -l 1372 <IP de destino>. Continue reduzindo o número até que ele seja bem-sucedido. No Linux, execute ping -s 1372 -M do <destination ip>. Para sua informação, as perguntas frequentes do OpenVPN recomendam o uso do mssfix 1200, mas isso não resolve a causa raiz. O uso de soluções VPN para fragmentar sempre tem o potencial de afetar o desempenho. Se você tiver uma grande configuração de VPN, não poderá usar a fragmentação na extremidade do concentrador central, apenas na extremidade do escritório remoto.
22811 Greg Askew

2

Por curiosidade, você já tentou diminuir o MTU da interface de rede? Talvez o link do satélite estrague muito a fragmentação. Como uma nota contra-intuitiva, você pode tentar o openvpn over TCP para variar. Sei que deve diminuir o desempenho, mas se você não tiver controle sobre a fragmentação ao longo da linha, isso poderá ajudá-lo.


Eu sugeriria o oposto :) - este caso de alta latência é aquele em que os problemas de TCP-in-TCP aparecem e o UDP evita isso.
Pjc50

Eu estava assumindo que ele estava usando a porta UDP padrão para openvpn e, portanto, sugeriu o oposto .. sim, normalmente eu concordo com você. Mas hey, todos nós sabemos que sysadmin é tentativa e erro, e, geralmente, 'try-fazendo-the-oposto, ver-se-it-obras' :)
lorenzog

Obrigado. Estamos usando o UDP no momento, e a tentativa do TCP nunca me ocorreu. (Se eu tivesse mais rep eu teria upvoted você)
iWerner

@ iWerner: obrigado :) também, tente reduzir o MTU progressivamente no iface e veja quando ele pára (se isso acontecer).
Lorenzog 25/11/2009

2

Quando você usa o TCP, aumente o tamanho da janela do TCP; isso ajudará com o "número de pacotes no ar".

Já faz um tempo desde que eu tive que brincar com essas coisas, mas aqui está um link que o Google encontrou para mim.

Depois de reler sua pergunta, vejo que você está executando o BGAN - eu daria uma boa olhada nisso (ou apenas procure no Google por: "BGAN spoofing").

Quanto à medição da largura de banda, achei o iperf bastante decente, desde que você esteja usando tamanhos razoáveis ​​de pacotes.


Isso é interessante - menciona que o acelerador TCP está disponível para o Redhat, enquanto o pessoal da inmarsat com quem conversamos disse que estava disponível apenas para Windows e OS X (e é isso mesmo que o site da Inmarsat / BGAN diz)
iWerner

Eles podem não ter agora; Vejo que a data do documento é 07. Se você se esforçar o suficiente e conversar com pessoas suficientes; você pode encontrar alguém com uma cópia antiga. Geralmente, quando você telefona, recebe suporte de primeiro nível. Vou tentar alguns dos meus contatos, mas não há garantias.
Eddy

Fui informado do nosso provedor de satélite; difícil encontrar alguém que saiba do que está falando. Vou continuar tentando, enquanto isso é algo a tentar: sourceforge.net/projects/pepsal Na descrição do projeto, ele está fazendo praticamente o que o software Inmarsat está fazendo: O PEPsal é um TCP transparente, integrado e de várias camadas Melhor desempenho Proxy que divide a conexão em duas partes, fazendo uso de melhorias Linux TCP quando o envio de dados, e melhorar em grande parte o desempenho em ligações com características diferentes
Eddy

2

Eu acho que você pode estar latindo para a árvore errada. Sempre que tive problemas de MTU errados, o tráfego parava muito antes dos 192KB. Eu acho que está mais relacionado a alguns na janela "em pacotes de vôo", na janela TCP, ou talvez em alguns buffers no próprio uplink de satélite.

Definitivamente fazer algumas capturas longo de pacotes (tanto 'dentro' e 'fora' da VPN) e veja se você está recebendo todos os ACK's

Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.