Problemi con lo stallo SCP durante la copia dei file tramite VPN

11

Ho una serie di file che devo copiare tramite SCP su una VPN su un server Linux remoto ogni notte. I file non sono grandi, stiamo parlando di decine di megabyte qui, ma la copia del file si blocca quasi sempre dopo pochi secondi. Eseguendo il comando SCP con -vvv, vedo ripetutamente quanto segue durante il tentativo di copia:

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

qualche idea? Vedo che questa domanda viene posta in vari posti là fuori, ma mai nessuna risposta. Qualsiasi aiuto sarebbe apprezzato.

— MattC
fonte

Ho sperimentato cose simili molte volte, anche se al momento non ho nulla che lo faccia in modo affidabile. Potrebbe essere interessante vedere se hpn-ssh farebbe la differenza.

— sfink

7

Stai permettendo ICMP attraverso la VPN? "La connessione TCP si interrompe dopo alcuni secondi" si traduce spesso in " buco nero PMTU ".

— Gerald Combs
fonte

2

così pochi capiscono la scoperta di PMTU icmp :-(

— Unix Janitor,

2

Sembra interessante, ma non è del tutto chiaro. Potresti approfondire cosa sta succedendo esattamente e come risolverlo?

— Craig McQueen

7

Simile alla risposta di @ Gerald, questa pagina http://www.netheaven.com/pmtu.html fornisce una buona spiegazione di MTU Discovery e delle opzioni per affrontare questo problema.

Anche un white paper di Cisco che parla della frammentazione IP, MTU Discovery e MSS tutti relativi ai tunnel VPN IPSec ma è ugualmente valido per situazioni simili. http://www.cisco.com/en/US/tech/tk827/tk369/technologies_white_paper09186a00800d6979.shtml

— jjcf89
fonte

1

Stai eseguendo l'ultima versione di qualunque server ssh e client stai usando? Consiglierei anche di colpire le loro mailing list su questo in quanto sembra piuttosto oscuro.

— Mark C
fonte

1

Abbiamo avuto problemi di spurios simili con scp ad alcuni server Linux (Debian, 2.6.24-etchnhalf).

Siamo riusciti a eliminare le bancarelle disabilitando la variabile TCP tcp_sack ("riconoscimenti selettivi tcp") sui server remoti:

sysctl -w net.ipv4.tcp_sack=0

Su Debian, tcp_sack è abilitato di default. Se leggessi http://www.frozentux.net/ipsysctl-tutorial/chunkyhtml/tcpvariables.html , non avrebbe senso disabilitare questa opzione, ma nel nostro caso mi ha aiutato.

È possibile rendere permanente questa modifica aggiungendo una riga net.ipv4.tcp_sack=0a /etc/sysctl.conf (su altri sistemi Linux YMMV).

— volo
fonte

0

scopri il tuo 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

configurare quell'MTU per la connessione di rete
```
ip link set eth0 mtu 1196
```
(nota che questo è temporaneo)

— törzsmókus
fonte