LINUX.ORG.RU
Форум — Admin  

scp / ssh при нестабильном соединении

 , ,


0

4

Есть удалённая точка с подключением по GRPS и OpenVPN. Проблема заключается в том, что как только я начинаю передавать хоть сколько-то объемные данные, соединение разрывается.

Как пример:

> scp keys.tar.gz 10.0.0.2:~
keys.tar.gz                                                                                                                         100% 4782     4.7KB/s   00:00

scp остается висеть на 100% и соединение падает по таймауту.

Если зайти по ssh, то видно, что размер скопированного keys.tar.gz нулевой.

Та же проблема есть с ssh. Просто зайти по ssh возможно, но как только открываю, например, vim - соединение повисает и разрывается по таймауту.

Какие опции scp / ssh можно подкрутить?

P.S. VPN пока трогать нельзя. Как раз хочу его и переделать (т.к. там используется tap-интерфейс).

★★

Последнее исправление: SaBo (всего исправлений: 1)
← iptables сбросить TOS
nagios не отправляет уведомления об ошибках →

проблема с MTU ?

vel ★★★★★
()
Ответ на: комментарий от zolden

А до какого размера?

Вот что получается:

> ping -s 10000 10.0.0.2
PING 10.0.0.2 (10.0.0.2) 10000(10028) bytes of data.
10008 bytes from 10.0.0.2: icmp_seq=1 ttl=64 time=927 ms
10008 bytes from 10.0.0.2: icmp_seq=2 ttl=64 time=1020 ms
10008 bytes from 10.0.0.2: icmp_seq=3 ttl=64 time=1132 ms
10008 bytes from 10.0.0.2: icmp_seq=4 ttl=64 time=1270 ms
^C
--- 10.0.0.2 ping statistics ---
5 packets transmitted, 4 received, 20% packet loss, time 4001ms
rtt min/avg/max/mdev = 927.130/1087.597/1270.331/128.181 ms, pipe 2

> ping -s 5000 10.0.0.2
PING 10.0.0.2 (10.0.0.2) 5000(5028) bytes of data.
5008 bytes from 10.0.0.2: icmp_seq=1 ttl=64 time=755 ms
5008 bytes from 10.0.0.2: icmp_seq=2 ttl=64 time=799 ms
5008 bytes from 10.0.0.2: icmp_seq=3 ttl=64 time=879 ms
5008 bytes from 10.0.0.2: icmp_seq=4 ttl=64 time=820 ms
5008 bytes from 10.0.0.2: icmp_seq=5 ttl=64 time=820 ms
^C
--- 10.0.0.2 ping statistics ---
6 packets transmitted, 5 received, 16% packet loss, time 4998ms
rtt min/avg/max/mdev = 755.772/815.340/879.956/40.047 ms

> ping -s 1000 10.0.0.2
PING 10.0.0.2 (10.0.0.2) 1000(1028) bytes of data.
1008 bytes from 10.0.0.2: icmp_seq=1 ttl=64 time=456 ms
1008 bytes from 10.0.0.2: icmp_seq=2 ttl=64 time=335 ms
1008 bytes from 10.0.0.2: icmp_seq=3 ttl=64 time=365 ms
1008 bytes from 10.0.0.2: icmp_seq=4 ttl=64 time=364 ms
1008 bytes from 10.0.0.2: icmp_seq=5 ttl=64 time=346 ms
^C
--- 10.0.0.2 ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4003ms
rtt min/avg/max/mdev = 335.993/373.742/456.196/42.680 ms
SaBo ★★
() автор топика
Ответ на: комментарий от zolden 
> ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN 
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
    link/ether 0a:18:0b:af:1e:82 brd ff:ff:ff:ff:ff:ff
    inet 172.31.13.65/20 brd 172.31.15.255 scope global eth0
       valid_lft forever preferred_lft forever
    inet6 fe80::818:bff:feaf:1e82/64 scope link 
       valid_lft forever preferred_lft forever
12: tap0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN qlen 100
    link/ether 72:44:b9:0b:bd:80 brd ff:ff:ff:ff:ff:ff
    inet 10.0.0.1/24 brd 10.0.0.255 scope global tap0
       valid_lft forever preferred_lft forever
    inet6 fe80::7044:b9ff:fe0b:bd80/64 scope link 
       valid_lft forever preferred_lft forever

> ip r g 10.0.0.2 
10.0.0.2 dev tap0  src 10.0.0.1 
    cache
SaBo ★★
() автор топика
Последнее исправление: SaBo (всего исправлений: 1)
Ответ на: комментарий от SaBo

Не смотря на MTU 1500 интерфейса, у тебя пролазят большие пакеты, значит на уровне IP фрагментация отрабатывает нормально, и проблема видимо в TCP.
Сними tcpdump на обоих концах

zolden ★★★★★
()
Ответ на: комментарий от zolden

Со стороны сервера я точно сниму, а вот со стороны клиента... попробую :)

Сейчас 18 часов - все с работы едут. Клиент вообще недоступен.
Через пару часов попробую.

P.S. dump на сетевом интерфейсе снимать или на tap?

SaBo ★★
() автор топика
Ответ на: комментарий от SaBo

Кстати, наврал я.

ssh -o 'Compression yes' -o 'CompressionLevel 9' 10.0.0.2

позволяет открыть vim (чего раньше не было). А вот для scp в моей ситуации не помогает.

SaBo ★★
() автор топика
Последнее исправление: SaBo (всего исправлений: 1)
Ответ на: комментарий от zolden

А для тех, кто не понял, можно пояснения? :)

P.S. Переключил на новый VPN. Вот новые конфиги:

3: tun0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN qlen 100
link/none 
inet 10.88.73.1 peer 10.88.73.2/32 scope global tun0

10.88.73.11 via 10.88.73.2 dev tun0 src 10.88.73.1 
cache

Сейчас сниму дампы.

SaBo ★★
() автор топика
Последнее исправление: SaBo (всего исправлений: 1)
Ответ на: комментарий от SaBo 
> ping -c 5 -s 56 10.88.73.11
PING 10.88.73.11 (10.88.73.11) 56(84) bytes of data.
64 bytes from 10.88.73.11: icmp_req=1 ttl=64 time=138 ms
64 bytes from 10.88.73.11: icmp_req=2 ttl=64 time=136 ms
64 bytes from 10.88.73.11: icmp_req=3 ttl=64 time=136 ms
64 bytes from 10.88.73.11: icmp_req=4 ttl=64 time=105 ms
64 bytes from 10.88.73.11: icmp_req=5 ttl=64 time=135 ms

--- 10.88.73.11 ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4002ms
rtt min/avg/max/mdev = 105.333/130.489/138.788/12.637 ms

> ping -c 5 -s 1500 10.88.73.11
PING 10.88.73.11 (10.88.73.11) 1500(1528) bytes of data.
1508 bytes from 10.88.73.11: icmp_req=1 ttl=64 time=158 ms
1508 bytes from 10.88.73.11: icmp_req=2 ttl=64 time=309 ms
1508 bytes from 10.88.73.11: icmp_req=3 ttl=64 time=164 ms
1508 bytes from 10.88.73.11: icmp_req=4 ttl=64 time=154 ms
1508 bytes from 10.88.73.11: icmp_req=5 ttl=64 time=214 ms

--- 10.88.73.11 ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4003ms
rtt min/avg/max/mdev = 154.534/200.437/309.854/58.852 m

> ping -c 5 -s 10000 10.88.73.11
PING 10.88.73.11 (10.88.73.11) 10000(10028) bytes of data.
10008 bytes from 10.88.73.11: icmp_req=1 ttl=64 time=568 ms
10008 bytes from 10.88.73.11: icmp_req=2 ttl=64 time=850 ms
10008 bytes from 10.88.73.11: icmp_req=3 ttl=64 time=1090 ms
10008 bytes from 10.88.73.11: icmp_req=4 ttl=64 time=1510 ms
10008 bytes from 10.88.73.11: icmp_req=5 ttl=64 time=1242 ms

--- 10.88.73.11 ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4008ms
rtt min/avg/max/mdev = 568.191/1052.244/1510.026/323.166 ms, pipe 2
SaBo ★★
() автор топика
Ответ на: комментарий от SaBo

А для тех, кто не понял, можно пояснения? :)

MTU сущность на L3 и судя по пингам на L3 у тебя всё работает, проблема возникает на L4 (TCP), для этого надо манипулировать MSS

Судя по названию MSS будет доводиться до уровня MTU и всё должно заработать

Хотя я всегда думал что пинги в таких случаях тоже не будут пролазить

zolden ★★★★★
()
Ответ на: комментарий от minakov

Кстати, с этими настройками openVPN не висит у меня ssh сессия как раньше

minakov ★★★★★
()
Ответ на: комментарий от minakov 
tun-mtu 1500
fragment 1400

В точку! Всем огромное спасибо за помощь!

SaBo ★★
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.
← iptables сбросить TOS
Admin
nagios не отправляет уведомления об ошибках →