VPN üzerinden dosya kopyalama sırasında SCP'nin durmasıyla ilgili sorunlar

11

SCP üzerinden bir VPN üzerinden her gece uzak bir linux sunucusuna kopyalamam gereken bir dizi dosyam var. Dosyalar büyük değil, burada onlarca megabayttan bahsediyoruz, ancak dosya kopyası neredeyse her zaman birkaç saniye sonra duruyor. -Vvv ile SCP komutunu çalıştırdığımda, kopyalama işlemi sırasında aşağıdakileri tekrar tekrar görüyorum:

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

Düşüncesi olan var mı? Bu sorunun orada çeşitli yerlerde sorulduğunu görüyorum, ama asla cevap vermiyor. Herhangi bir yardım mutluluk duyacağız.

— MattC
kaynak

Birçok kez benzer şeyler yaşadım, ancak şu anda bunu güvenilir bir şekilde yapan hiçbir şeyim yok. Hpn-ssh'ın bir fark yaratıp yaratmayacağını görmek ilginç olabilir.

— sfink

7

VPN üzerinden ICMP'ye izin veriyor musunuz? "Birkaç saniye sonra TCP bağlantısı duruyor" genellikle " PMTU karadelik " anlamına gelir.

— Gerald Combs
kaynak

2

çok az icmp PMTU keşfi anlamak :-(

— The Unix Janitor

2

Kulağa ilginç geliyor ama tam olarak belli değil. Neyin yanlış gittiğini ve nasıl düzeltileceğini açıklayabilir misiniz?

— Craig McQueen

7

@ Gerald'ın bu sayfaya verdiği yanıta benzer şekilde http://www.netheaven.com/pmtu.html MTU Discovery ve bu sorunla karşılaşıldığında seçenekler hakkında iyi bir açıklama sunar.

Ayrıca Cisco tarafından IP Fragmentasyonu, MTU Keşfi ve MSS'nin tümü IPSec VPN tünellerine ait olan, ancak benzer durumlar için eşit derecede geçerli olan bir teknik inceleme. http://www.cisco.com/en/US/tech/tk827/tk369/technologies_white_paper09186a00800d6979.shtml

— jjcf89
kaynak

1

Kullandığınız ssh sunucularının ve istemcilerinin en son sürümünü mü kullanıyorsunuz? Ayrıca oldukça belirsiz görünüyor gibi bu e-posta listelerine isabet öneriyoruz.

— Mark C
kaynak

1

Bazı Linux sunucularına scp ile benzer spurios sorunları yaşadık (Debian, 2.6.24-etchnhalf).

Uzak sunuculardaki tcp_sack TCP değişkenini ("tcp selektif alındı bildirimleri") devre dışı bırakarak tezgahlarla başa çıkabildik:

sysctl -w net.ipv4.tcp_sack=0

Debian'da, tcp_sack varsayılan olarak etkindir. Ben okursanız http://www.frozentux.net/ipsysctl-tutorial/chunkyhtml/tcpvariables.html , bu seçeneği devre dışı bırakmak için hiçbir anlam ifade etmelidir, fakat bizim durumumuzda, o yardımcı oldu.

net.ipv4.tcp_sack=0/Etc/sysctl.conf dosyasına (diğer Linux sistemlerinde YMMV'de) bir satır ekleyerek bu değişikliği kalıcı yapabilirsiniz .

— uçuş
kaynak

0

MTU Yolunuzu bulun

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

ağ bağlantınız için bu MTU'yu ayarlayın
```
ip link set eth0 mtu 1196
```
(bunun geçici olduğunu unutmayın)

— törzsmókus
kaynak