Problemas con el bloqueo de SCP durante la copia de archivos a través de VPN

11

Tengo una serie de archivos que necesito copiar a través de SCP a través de una VPN a un servidor Linux remoto cada noche. Los archivos no son grandes, estamos hablando de decenas de megabytes aquí, pero la copia del archivo casi siempre se detiene después de unos segundos. Al ejecutar el comando SCP con -vvv, veo lo siguiente una y otra vez durante el proceso de intento de copia:

debug2: channel 0: rcvd adjust 131072
debug2: channel 0: rcvd adjust 131072
debug2: channel 0: rcvd adjust 131072

¿Alguna idea? Veo que se hace esta pregunta en varios lugares, pero nunca hay respuestas. Cualquier ayuda sería apreciada.

— MattC
fuente

He experimentado cosas similares muchas veces, aunque no tengo nada que lo haga de manera confiable en este momento. Puede ser interesante ver si hpn-ssh marcaría la diferencia.

— sfink

7

¿Estás permitiendo ICMP a través de la VPN? "La conexión TCP se detiene después de unos segundos" a menudo se traduce como " agujero negro PMTU ".

— Gerald Peines
fuente

2

tan pocos entienden el descubrimiento de icmp PMTU :-(

— The Unix Janitor

2

Eso suena interesante, pero no está totalmente claro. ¿Podrías explicar qué es lo que está mal y cómo solucionarlo?

— Craig McQueen

7

De manera similar a la respuesta de @ Gerald, esta página http://www.netheaven.com/pmtu.html ofrece una buena explicación de MTU Discovery y las opciones para enfrentar este problema.

También un documento técnico de Cisco que trata sobre la fragmentación de IP, MTU Discovery y MSS, todos relacionados con túneles VPN IPSec, pero es igualmente válido para situaciones similares. http://www.cisco.com/en/US/tech/tk827/tk369/technologies_white_paper09186a00800d6979.shtml

— jjcf89
fuente

1

¿Está ejecutando la última versión de los servidores y clientes ssh que está utilizando? También recomendaría acceder a sus listas de correo electrónico sobre esto, ya que parece bastante oscuro.

— Mark C
fuente

1

Tuvimos problemas espurios similares con scp en algunos servidores Linux (Debian, 2.6.24-etchnhalf).

Pudimos eliminar los puestos desactivando la variable TCP tcp_sack ("reconocimientos selectivos de tcp") en los servidores remotos:

sysctl -w net.ipv4.tcp_sack=0

En Debian, tcp_sack está habilitado por defecto. Si leo http://www.frozentux.net/ipsysctl-tutorial/chunkyhtml/tcpvariables.html , no tendría sentido deshabilitar esta opción, pero en nuestro caso, ayudó.

Puede hacer que este cambio sea permanente agregando una línea net.ipv4.tcp_sack=0a /etc/sysctl.conf (en otros sistemas Linux YMMV).

— vuelo
fuente

0

descubre tu MTU Path

ping -M do -s 1472 host.domain
PING host.domain (10.0.0.1) 1472(1500) bytes of data.
ping: sendmsg: Message too long
ping: local error: Message too long, mtu=1196
^C
ping -M do -s 1168 host.domain
PING host.domain (10.0.0.1) 1168(1196) bytes of data.
1176 bytes from 10.0.0.1: icmp_seq=1 ttl=60 time=283 ms
^C

configurar esa MTU para su conexión de red
```
ip link set eth0 mtu 1196
```
(tenga en cuenta que esto es temporal)

— törzsmókus
fuente