Маленькая скорость скачивания по SCP для OVPN клиентов.
-
Здравствуйте.
Есть pfsense 2.4.4 развернутый на VMware ESXi 6.0.0 с настроенным OpenVPN.
Географически располагается в Штатах и там же находится сервер с которого копируется файл по SCP.
Копируется файл как в РФ так и внутри Штатов.В виду тотального перевода сотрудников на удаленную работу было замечено, что скорость скачивания через OVPN подключение не превышает 400KB\s(в среднем 150-200).
С upload всё нормально.
Никаких traffic shaper или limiters не настроено.
Hardware TCP Segmentation Offloading и Hardware Large Receive Offloading в System-Advanced-Networking включены.
Есть правила на фаерволе но они касаются только разграничения доступа + для моей учетной записи, например, нет вообще никаких правил.Буду очень благодарен если кто-нибудь подскажет в какую сторону копать.
Заранее спасибо. -
@paranoik Проблема скорее всего в MTU
Смотрите в wireshark на TCP сессии
Проверьте максимальный MTU с помощьюping -M do -s <size> server
Версию pfSense неплохо бы обновить
-
This post is deleted! -
Здравствуйте.
С MTU похоже всё нормально: -
В wireshark интересная картина - сессия проходит нормально, потом в какой-то момент времени с моего компьютера в сторону сервера начинают отправляться TCP Dup Ack.
Т.е. я вижу пакет о тсервера с seq = 274864 и TCP Len = 1358. В ответ вижу TCP Ack со своего компьютера который акнолиджит ack number 276222.А следующим я вижу от сервера пакет с "Previous segment(s) not captured (common at capture start)" и с моего туннельного интерфейса начинают отправляться TCP сегменты "TCP Dup Ack" у которых Ack seq = 276222.
После некоторого времени я снова вижу нормальную передачу данных, а после снова повторяется ситуация с "TCP Dup Ack"...
Такая ситуация наблюдается только на Download, на Upload всё спокойно и скорость отличная.
-
@paranoik said in Маленькая скорость скачивания по SCP для OVPN клиентов.:
Hardware TCP Segmentation Offloading и Hardware Large Receive Offloading в System-Advanced-Networking включены.
Включены? По идее в виртуальной среде они должны быть выключены, те галки поставлены. Или вы это и имели в виду под "включены"?
-
@pigbrother said in Маленькая скорость скачивания по SCP для OVPN клиентов.:
е
Да, извиняюсь если неточно выразился. Галки на чекбоксах установлены.
-
@paranoik said in Маленькая скорость скачивания по SCP для OVPN клиентов.:
Здравствуйте.
С MTU похоже всё нормально:В Windows это делается так:
ping -f -l 1500 ip-адрес, флаг -f принудительно откл. фрагментацию.
У вас же фрагментация вкл.Проверьте максимальный MTU с помощью ping -M do -s <size> server
Это в никсах. Можно прямо в консоли пф.
-
@werter согласен, был не прав.
Max MTU которое проходит = 1472 byte -
1472 = 1500 - 28 и говорит о том, что все ок. У вас CPU умеет AES-NI ?
-
@werter said in Маленькая скорость скачивания по SCP для OVPN клиентов.:
AES-NI
Да, на сервере, на котором крутится ESXi установлено 2 x Intel(R) Xeon(R) CPU X5660
-
@paranoik
ark.intel.com/content/www/ru/ru/ark/products/47921/intel-xeon-processor-x5660-12m-cache-2-80-ghz-6-40-gt-s-intel-qpi.html
Не умеет. Древний.Зы. В поиске на али 'вбейте x79 x99 kit'. За копейки можно купить приличное железо (даже с 2-мя m.2). На оверах есть огромная ветка по этому делу.
-
@werter странно, я думал вот это и означает, что процессор поддерживает AES-NI:
На данном этапе вообще не целесообразно производить замену - это продакшн окружение, много сотрудников сидит на RA через впн. Да и проблем никаких не было кроме скорости скачивания.
Даже если процессор не поддерживает AES-NI неужели это настолько может повлиять на скорость скачивания - max 400Kb/s?
-
@paranoik
Здр
iperf что показывает ? какие цифры ?
Попробуйте уменьшить MSS до 1360
Попробуйте ( ради интереса ) развернуть IPSEC (site-to-site)
По поводу умеет процессор AES-NI или нет - при невысоких нагрузках это не имеет особого значения (по-моему)
Например , мой виртуальный сервер во Франции (VPS) 1 процессор , 1 ядро
Данные по скорости на основе измерений Yandex (GRE over IPSEC, mss 1360)ifconfig gre1 gre1: flags=8151<UP,POINTOPOINT,RUNNING,PROMISC,MULTICAST> metric 0 mtu 1400 options=80000<LINKSTATE>
Скорость воспроизведения видео
Нагрузка на процессор
last pid: 22091; load averages: 0.52, 0.51, 0.43
iperf (site to site)
Client connecting to 10.10.200.2, TCP port 5001 TCP window size: 64.9 KByte (default) ------------------------------------------------------------ [ 3] local 10.10.200.1 port 60177 connected with 10.10.200.2 port 5001 [ ID] Interval Transfer Bandwidth [ 3] 0.0-10.1 sec 18.0 MBytes 14.9 Mbits/sec
iperf ( удаленный доступ через мобильное устройство с помощью ipsec)
Server listening on TCP port 5001 TCP window size: 64.0 KByte (default) ------------------------------------------------------------ [ 4] local 10.10.200.2 port 5001 connected with 192.168.151.2 port 61768 [ ID] Interval Transfer Bandwidth [ 4] 0.0-11.1 sec 6.25 MBytes 4.73 Mbits/sec
-
странно, я думал вот это и означает, что процессор поддерживает AES-NI:
Точно. Вы правы. Прошу пардону. Тогда вкл. поддержку на пф.
-
@paranoik said in Маленькая скорость скачивания по SCP для OVPN клиентов.:
Даже если процессор не поддерживает AES-NI неужели это настолько может повлиять на скорость скачивания - max 400Kb/s?
@Konstanti said in Маленькая скорость скачивания по SCP для OVPN клиентов.:
По поводу умеет процессор AES-NI или нет - при невысоких нагрузках это не имеет особого значения (по-моему)
На "бытовых" роутерах с (альтернативными прошивками ) и Микротик с отсутствующей поддержкой AES-NI вполне в Open VPN волне достижима скорость порядка 15-20 Мбит\с.
Предположу, что ограничение скорости у ТС мало\слабо связано с отсутствием поддержки AES-NI.
Тем более, ТС утверждает, что
@paranoik said in Маленькая скорость скачивания по SCP для OVPN клиентов.:
С upload всё нормально.
-
@Konstanti что-то не найду где изменить MSS.. не подскажете? Планирую погонять iperf завтра/послезавтра когда активность пользователей будет минимальная.