Problèmes de blocage de SCP lors de la copie de fichiers sur VPN

11

J'ai une série de fichiers que je dois copier via SCP via un VPN vers un serveur Linux distant chaque nuit. Les fichiers ne sont pas volumineux, nous parlons ici de dizaines de mégaoctets, mais la copie des fichiers se bloque presque toujours après quelques secondes. En exécutant la commande SCP avec -vvv, je vois les éléments suivants à plusieurs reprises tout au long du processus de copie tenté:

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

Des pensées? Je vois cette question posée à divers endroits, mais jamais de réponse. Toute aide serait appréciée.

— MattC
source

J'ai vécu des choses similaires à plusieurs reprises, même si je n'ai rien qui puisse le faire de manière fiable en ce moment. Il pourrait être intéressant de voir si hpn-ssh ferait une différence.

— sfink

7

Autorisez-vous ICMP via le VPN? «La connexion TCP se bloque après quelques secondes» se traduit souvent par « trou noir PMTU ».

— Gerald Combs
source

2

si peu comprennent la découverte d'icmp PMTU :-(

— The Unix Janitor

2

Cela semble intéressant, mais n'est pas totalement clair. Pourriez-vous nous expliquer ce qui ne va pas exactement et comment y remédier?

— Craig McQueen

7

Semblable à la réponse de @ Gerald, cette page http://www.netheaven.com/pmtu.html donne une bonne explication de MTU Discovery et des options face à ce problème.

Également un livre blanc de Cisco qui traite de la fragmentation IP, de la découverte MTU et du MSS, tous relatifs aux tunnels VPN IPSec, mais est également valable pour des situations similaires. http://www.cisco.com/en/US/tech/tk827/tk369/technologies_white_paper09186a00800d6979.shtml

— jjcf89
source

1

Utilisez-vous la dernière version des serveurs et clients ssh que vous utilisez? Je recommanderais également de consulter leurs listes de diffusion à ce sujet, car cela semble plutôt obscur.

— Mark C
source

1

Nous avons eu des problèmes similaires avec scp avec certains serveurs Linux (Debian, 2.6.24-etchnhalf).

Nous avons réussi à supprimer les blocages en désactivant la variable TCP tcp_sack ("tcp selective accusé de réception") sur les serveurs distants:

sysctl -w net.ipv4.tcp_sack=0

Sur Debian, tcp_sack est activé par défaut. Si je lis http://www.frozentux.net/ipsysctl-tutorial/chunkyhtml/tcpvariables.html , cela ne devrait pas avoir de sens de désactiver cette option, mais dans notre cas, cela a aidé.

Vous pouvez rendre cette modification permanente en ajoutant une ligne net.ipv4.tcp_sack=0à /etc/sysctl.conf (sur d'autres systèmes Linux YMMV).

— vol
source

0

découvrez votre Path MTU

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

configurer ce MTU pour votre connexion réseau
```
ip link set eth0 mtu 1196
```
(notez que c'est temporaire)

— törzsmókus
source