Проблеми з зупинкою 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

Будь-які думки? Я бачу це запитання в різних місцях, але відповіді ніколи. Будь-яка допомога буде вдячна.

— MattC
джерело

Я багато разів переживав подібні речі, хоча зараз не маю нічого, що би це надійно робило. Можливо, буде цікаво подивитися, чи змінить HPn-ssh значення.

— sfink

7

Чи дозволяєте ICMP через VPN? "Зв'язок TCP через кілька секунд" часто перекладається як " чорна діра PMTU ".

— Джеральд Гребінець
джерело

2

так мало хто розуміє відкриття PMTU в icmp :-(

— Двірник Unix

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

дізнайтеся свій 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

встановіть цей MTU для вашого мережевого з'єднання
```
ip link set eth0 mtu 1196
```
(зауважте, що це тимчасово)

— törzsmókus
джерело