OpenVPN: como atenuar os problemas de MTU do caminho por cliente?

Question

Temos dezenas de dispositivos embarcados instalados nos clientes, todos chamando de lar para nosso serviço OpenVPN. Isso funciona bem em geral, mas alguns dos nossos clientes têm problemas de MTU de caminho severo. Nossa influência sobre os clientes para consertar suas redes é limitada, então precisamos do OpenVPN para lidar com isso. Em poucas palavras, minha pergunta é:

Como posso atenuar as MTUs de baixo caminho de alguns clientes em uma base por cliente, ou seja, sem usar configurações globais que acomodam o pior caso para todos os clientes

Note que o nosso pior caso é muito ruim: o caminho MTU 576, descarta todos os fragmentos, não se fragmenta, não honra DF-bit. Você vê porque eu prefiro não resolver este problema globalmente.

A página de manual do OpenVPN oferece várias opções relacionadas a MTU, principalmente --link-mtu, --tun-mtu, --fragment and --mssfix . Mas também diz

--link-mtu [...] It's best not to set this parameter unless you know what you're doing.

--tun-mtu [...] It's best to use the --fragment and/or --mssfix options to deal with MTU sizing issues.

Então comecei a experimentar com --fragment e --mssfix , mas logo tive que perceber que pelo menos o primeiro deve ser definido não apenas no lado do cliente, mas também do lado do servidor . Eu olhei então para a configuração por cliente do lado do servidor via --client-config-dir mas diz

The following options are legal in a client-specific context: --push, --push-reset, --iroute, --ifconfig-push, and --config.

Nenhuma menção de opções de MTU!

Então, aqui estão minhas perguntas mais específicas:

• Por que exatamente link-mtu e tun-mtu estão desestimulados? Quais são os possíveis problemas com essas opções? Note que estou bastante confortável com o baixo nível de cabeçalho IP.
• Quais das opções link-mtu tun-mtu fragment mssfix precisam ser espelhadas no lado do servidor para funcionar?
• Qual das opções link-mtu tun-mtu fragment mssfix pode ser usada em client-config-dir ?
• Caso todas as quatro opções precisem ser espelhadas no lado do servidor e não possam ser usadas dentro de client-config-dir : Existem alternativas para combater o MTU de baixo caminho por cliente?

Notas:

• Partes de minhas perguntas já foram feitas 5 anos atrás aqui , mas elas não foram respondidas na época, daí Eu ouso duplicá-los.
• O servidor OpenVPN está atualmente 2.2.1 no Ubuntu 12.04. Estamos preparando uma atualização para o 2.3.2 no Ubuntu 14.04
• Os clientes OpenVPN são 2.2.1 no Debian 7.6
• Tenho o prazer de determinar manualmente o caminho do cliente-MTU
• Atualmente, não podemos testar muito do lado do servidor. Mas estamos construindo uma bancada de testes completa e completa, que deve estar pronta em breve.

Sou grato por qualquer conselho útil.

    

Answer 1

Eu resolvi o problema no lado do cliente adicionando a opção mssfix 1300 ao arquivo de configuração.

A partir da página de manual do openvpn:

--mssfix max
    Announce to TCP sessions running over the tunnel that they should limit their send packet sizes such that after OpenVPN has encapsulated them, the resulting UDP packet size that OpenVPN sends to its peer will not exceed max bytes. 

A ideia original para a minha solução veio de personalvpn.org

    

Answer 2

Devido à falta de respostas, estou postando agora uma solução que não é muito elegante, mas simples: Execute outra instância do OpenVPN no TCP para "clientes insatisfatórios"

proto tcp

e diminuir o TCP MSS no cliente, por exemplo

iptables -t mangle -A POSTROUTING -p tcp --tcp-flags SYN,RST SYN -o ${OUT_DEV} -j TCPMSS --set-mss ${PATH-MTU-MINUS-40}

Uma vantagem desta solução é que cada cliente pode definir seu MSS individual.

Isso é reconhecidamente TCP-over-TCP, mas deve ter um bom desempenho em muitos cenários .

Note que ainda estou muito interessada em soluções que não exigem proto tcp , e vou marcá-las como uma resposta válida se elas cumprirem mais ou menos meus requisitos descritos.