SCP reproduzvelmente interrompe o pipe SSH [duplicado]

Question

Estou tentando copiar alguns certificados para o meu servidor usando scp .

$ scp ./cert.* [email protected]:/tmp/

cert.crt     100% 2386     0.1KB/s   00:18
packet_write_wait: Connection to 192.168.0.42 port 22: Broken pipe
lost connection

O primeiro arquivo é gravado no servidor, mas não completamente, já que o hashsum não corresponde ao arquivo original.

Isso acontece toda vez que tento scp desses arquivos ( crt , key e p12 ).

Testado com o Ubuntu 16.10 ( OpenSSH_7.3p1 Ubuntu-1, OpenSSL 1.0.2g 1 Mar 2016 ) e com o Windows 10 ( WinSCP 5.9.4 ). Ambos falham ao copiar os arquivos.

Vale a pena mencionar que estou conectado a um servidor OpenVPN para acessar o servidor de destino (192.168.0.42) - mas isso não deve ser um problema.

Por que o pipe quebra e como posso scp com êxito os arquivos no servidor?

edit: Isso, como sugerido nos comentários, provavelmente tem a ver com o MTU - no entanto, não sei bem como corrigir esse problema ainda.

    

Answer 1

Reduzir o MTU da conexão do OpenVPN funcionou para mim.

Do 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. The default value is 1450.

The max parameter is interpreted in the same way as the --link-mtu parameter, i.e. the UDP packet size after encapsulation overhead has been added in, but not including the UDP header itself. Resulting packet would be at most 28 bytes larger for IPv4 and 48 bytes for IPv6 (20/40 bytes for IP header and 8 bytes for UDP header). Default value of 1450 allows IPv4 packets to be transmitted over a link with MTU 1473 or higher without IP level fragmentation.

The --mssfix option only makes sense when you are using the UDP protocol for OpenVPN peer-to-peer communication, i.e. --proto udp.

--mssfix and --fragment can be ideally used together, where --mssfix will try to keep TCP from needing packet fragmentation in the first place, and if big packets come through anyhow (from protocols other than TCP), --fragment will internally fragment them.

Both --fragment and --mssfix are designed to work around cases where Path MTU discovery is broken on the network path between OpenVPN peers.

The usual symptom of such a breakdown is an OpenVPN connection which successfully starts, but then stalls during active usage.

If --fragment and --mssfix are used together, --mssfix will take its default max parameter from the --fragment max option.

Therefore, one could lower the maximum UDP packet size to 1300 (a good first try for solving MTU-related connection problems) with the following options:

--tun-mtu 1500 --fragment 1300 --mssfix

Eu adicionei o seguinte à configuração do OpenVPN:

mssfix 1200

Também presumo que esse valor possa ser ajustado para um melhor desempenho.