Problemy z blokowaniem się SCP podczas kopiowania plików przez VPN

11

Mam serię plików, które muszę kopiować za pośrednictwem SCP przez VPN na zdalny serwer linux każdej nocy. Pliki nie są duże, mówimy tutaj o dziesiątkach megabajtów, ale kopia pliku prawie zawsze zatrzymuje się po kilku sekundach. Uruchamiając komendę SCP z opcją -vvv, w trakcie próby kopiowania pojawiają się następujące informacje:

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

jakieś pomysły? Widzę to pytanie zadawane w różnych miejscach, ale nigdy nie ma odpowiedzi. Każda pomoc będzie mile widziana.

linux ssh vpn scp MattC
źródło

Doświadczyłem podobnych rzeczy wiele razy, chociaż w tej chwili nie mam nic, co by to robiło niezawodnie. Interesujące może być sprawdzenie, czy hpn-ssh zrobiłoby różnicę.

sfink

7

Czy pozwalasz ICMP przez VPN? „Połączenie TCP zatrzymuje się po kilku sekundach” często tłumaczy się jako „ czarna dziura PMTU ”.

Gerald Combs
źródło

2

więc niewielu rozumie odkrycie icmp PMTU :-(

The Unix Janitor

2

Brzmi interesująco, ale nie jest całkowicie jasne. Czy mógłbyś wyjaśnić, co dokładnie dzieje się źle i jak to naprawić?

Craig McQueen

7

Podobnie do odpowiedzi @ Geralda, ta strona http://www.netheaven.com/pmtu.html zawiera dobre wyjaśnienie MTU Discovery i opcji w obliczu tego problemu.

Również oficjalna dokumentacja Cisco, która omawia fragmentację IP, MTU Discovery i MSS, wszystkie dotyczące tuneli IPSec VPN, ale jest równie ważna w podobnych sytuacjach. http://www.cisco.com/en/US/tech/tk827/tk369/technologies_white_paper09186a00800d6979.shtml

jjcf89
źródło

1

Czy korzystasz z najnowszej wersji serwerów i klientów ssh, których używasz? Polecam również sprawdzenie ich list e-mail, ponieważ wydaje się to dość niejasne.

Mark C.
źródło

1

Mieliśmy podobne problemy spurios z scp do niektórych serwerów Linux (Debian, 2.6.24-etchnhalf).

Byliśmy w stanie pozbyć się przeciągnięć, wyłączając zmienną TCP tcp_sack („selektywne potwierdzenia tcp”) na zdalnych serwerach:

sysctl -w net.ipv4.tcp_sack=0

W Debianie tcp_sack jest domyślnie włączony. Jeśli przeczytam http://www.frozentux.net/ipsysctl-tutorial/chunkyhtml/tcpvariables.html , wyłączenie tej opcji nie powinno mieć sensu, ale w naszym przypadku pomogło.

Możesz wprowadzić tę zmianę na stałe, dodając wiersz net.ipv4.tcp_sack=0do /etc/sysctl.conf (w innych systemach Linux YMMV).

lot
źródło

0

sprawdź swoją MTU ścieżki

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

skonfiguruj tę jednostkę MTU dla połączenia sieciowego
```
ip link set eth0 mtu 1196
```
(zauważ, że jest to tymczasowe)

törzsmókus
źródło

Problemy z blokowaniem się SCP podczas kopiowania plików przez VPN

Odpowiedzi: