Проблемы с остановкой SCP при копировании файлов через VPN

11

У меня есть ряд файлов, которые мне нужно копировать через SCP через VPN на удаленный сервер Linux каждый вечер. Файлы не большие, мы говорим о десятках мегабайт здесь, но копия файла почти всегда останавливается через несколько секунд. Запустив команду SCP с параметром -vvv, я снова и снова вижу следующее в процессе попытки копирования:

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

Есть предположения? Я вижу, что этот вопрос задают в разных местах, но ответов нет. Любая помощь будет оценена.

linux ssh vpn scp MattC
источник
Я много раз сталкивался с подобными вещами, хотя у меня нет ничего, что делает это надежно прямо сейчас. Может быть интересно посмотреть, изменится ли hpn-ssh.
sfink

Ответы:

7

Вы разрешаете ICMP через VPN? «TCP-соединение останавливается через несколько секунд» часто переводится как « черная дыра PMTU ».

Джеральд Комбс
источник
2
так мало кто понимает открытие ICMP PMTU :-(
The Unix Janitor
2
Это звучит интересно, но не совсем понятно. Не могли бы вы уточнить, что именно не так и как это исправить?
Крейг МакКуин
7

Как и в ответе @ Gerald, эта страница http://www.netheaven.com/pmtu.html дает хорошее объяснение MTU Discovery и вариантов решения этой проблемы.

Также технический документ Cisco, в котором обсуждаются IP-фрагментация, MTU Discovery и MSS, относящиеся к VPN-туннелям IPSec, но в равной степени действительные для аналогичных ситуаций. http://www.cisco.com/en/US/tech/tk827/tk369/technologies_white_paper09186a00800d6979.shtml

jjcf89
источник
1

Используете ли вы последнюю версию любых используемых вами ssh-серверов и клиентов? Я также рекомендовал бы поразить их списки адресов электронной почты по этому вопросу, поскольку это кажется довольно неясным.

Марк С
источник
1

У нас были проблемы spurios с scp на некоторых серверах Linux (Debian, 2.6.24-etchnhalf).

Мы смогли покончить с остановками, отключив переменную TCP tcp_sack («выборочные подтверждения tcp») на удаленных серверах:

sysctl -w net.ipv4.tcp_sack=0

В Debian tcp_sack включен по умолчанию. Если я читаю http://www.frozentux.net/ipsysctl-tutorial/chunkyhtml/tcpvariables.html , не имеет смысла отключать эту опцию, но в нашем случае это помогло.

Вы можете сделать это изменение постоянным, добавив строку net.ipv4.tcp_sack=0в /etc/sysctl.conf (в других системах Linux YMMV).

рейс
источник
0

  1. узнать свой путь 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

  2. настроить этот MTU для вашего сетевого подключения

    ip link set eth0 mtu 1196

    (обратите внимание, что это временно)

törzsmókus
источник