SCP rompe de forma reproducible la tubería SSH

SCP rompe de forma reproducible la tubería SSH

Estoy intentando copiar algunos certificados en mi 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

El primer archivo se escribe en el servidor, pero no completamente, ya que el hashsum no coincide con el archivo original.

Esto sucede cada vez que intento acceder a scpestos archivos ( crt, keyy p12).

Probado con Ubuntu 16.10 ( OpenSSH_7.3p1 Ubuntu-1, OpenSSL 1.0.2g 1 Mar 2016) y con Windows 10 ( WinSCP 5.9.4). Ambos fallan al copiar los archivos.

Puede que valga la pena mencionar que estoy conectado a un servidor OpenVPN para poder llegar al servidor de destino (192.168.0.42), pero eso no debería ser un problema.

¿Por qué se rompe la tubería y cómo puedo transferir con éxito los archivos al servidor?

editar:Esto, como se sugiere en los comentarios, probablemente tenga que ver con la MTU; sin embargo, todavía no estoy muy seguro de cómo solucionar este problema.

Respuesta1

Bajar el MTU de la conexión OpenVPN funcionó para mí.

Del manual de OpenVPN:

--mssfix max Anuncie a las sesiones TCP que se ejecutan en el túnel que deben limitar el tamaño de sus paquetes de envío de modo que después de que OpenVPN los haya encapsulado, el tamaño de paquete UDP resultante que OpenVPN envía a su par no exceda el máximo de bytes. El valor predeterminado es 1450.

El parámetro max se interpreta de la misma manera que el parámetro --link-mtu, es decir, el tamaño del paquete UDP después de agregar la sobrecarga de encapsulación, pero sin incluir el encabezado UDP en sí. El paquete resultante sería como máximo 28 bytes más grande para IPv4 y 48 bytes para IPv6 (20/40 bytes para el encabezado IP y 8 bytes para el encabezado UDP). El valor predeterminado de 1450 permite que los paquetes IPv4 se transmitan a través de un enlace con MTU 1473 o superior sin fragmentación del nivel de IP.

La opción --mssfix sólo tiene sentido cuando se utiliza el protocolo UDP para la comunicación entre pares OpenVPN, es decir, --proto udp.

--mssfix y --fragment se pueden usar idealmente juntos, donde --mssfix intentará evitar que TCP necesite fragmentación de paquetes en primer lugar, y si de todos modos llegan paquetes grandes (de protocolos distintos de TCP), --fragment fragmentarlos internamente.

Tanto --fragment como --mssfix están diseñados para solucionar casos en los que el descubrimiento de MTU de ruta se interrumpe en la ruta de red entre pares OpenVPN.

El síntoma habitual de este tipo de avería es una conexión OpenVPN que se inicia correctamente, pero luego se detiene durante el uso activo.

Si --fragment y --mssfix se usan juntos, --mssfix tomará su parámetro max predeterminado de la opción --fragment max.

Por lo tanto, se podría reducir el tamaño máximo de paquete UDP a 1300 (un buen primer intento para resolver problemas de conexión relacionados con MTU) con las siguientes opciones:

--tun-mtu 1500 --fragmento 1300 --mssfix

Agregué lo siguiente a la configuración de OpenVPN:

mssfix 1200

También asumo que este valor puede modificarse para mejorar el rendimiento.

información relacionada