Низкая скорость между точками за hw100 и hw1000

[ApB]

Доброго времени суток!

Прошу помочь со способом/методом анализа ситуации

Есть большая сеть (А) за HW1000 и есть малая сеть (Б) за HW100.

Между ними канал в 40MB

А если забраться с хоста сети Б в хост сети А, то скорость передачи данных 2MB

Интенсивность использования шлюзов низкая.

Соединены хосты тоннелем

Какова может быть причина падения скорости?

[KIV]

Что значит тоннелем соединены? На каком то другом оборудовании поднят транспорт, а сверху випнет?

 

Какие версии ПО на координаторах?

[ApB]

Здравствуйте!

Соединены тоннелем - это значит, что в iplir config прописаны строки типа

Для сети Б

tunnel= 192.168.10.1-192.168.10.255 to 192.168.10.1-192.168.10.255

Для сети А
 

tunnel= 192.168.0.44-192.168.0.44 to 192.168.0.44-192.168.0.44

tunnel= 192.168.0.77-192.168.0.77 to 192.168.0.77-192.168.0.77

на обоих сторонах строки добавленны в соответствующие элементы конфигурационного файла (соответствующие точкам подключения)

Хост из сети 192.168.10.0/24 видит и 192.168.0.44 и 192.168.0.77. Все соответствующие изменения в iplir config firewall внесены.

Если машину из сети А выпустить в интернет на прямую, то имею скорость равную скорости интернет-канала.

Про версию шлюза:
 

# version

Platform: HW100 X2

Version: 3.3 (652)

ViPNet Coordinator version 3.7.3-(6727)

 

[KIV]

Так 2МБайт в сек это около 16 Мбит/сек. Нужно посмотреть производительность HW100 для шифрованного трафика для версии ПО 3.

Обновитесь до 3.5.

[intellegent]

А вы канал без средств защиты тестировали? В нем можно получить 40 Мбит/сек? От этого следует отталкиваться - то что канал действительно способен обеспечить нужную скорость.

[ApB]

Здравствуйте!

Да, тестировал. Если выпустить машину в сеть напрямую, нет никаких проблем со скоростью соединения

[denis.r]

Попробуйте установить на ПАК параметр mssdecrease=200 http://docs.infotecs.ru/#122/41894.htm 

[Vipnetishe]

17.10.2017 в 16:15, ApB сказал:

Какова может быть причина падения скорости?

Приветствую. Как решилась ваша ситуация в итоге? Наблюдаем такую же историю у себя.

[R.Sheyn]

52 минуты назад, Vipnetishe сказал:

Приветствую. Как решилась ваша ситуация в итоге? Наблюдаем такую же историю у себя.

падение скорости на неадекватные величины на 99% связано фрагментацией где-то по пути. Покрутите MTU.

[Vipnetishe]

5 часов назад, R.Sheyn сказал:

Покрутите MTU.

У нас версия FW 4.2.1 на координаторах. Если я правильно прочитал, что MTU можно крутить с версии 4.3.X. У себя пробовали крутить mssdecrease, но результата нет.

[R.Sheyn]

19 часов назад, Vipnetishe сказал:

У нас версия FW 4.2.1 на координаторах. Если я правильно прочитал, что MTU можно крутить с версии 4.3.X. У себя пробовали крутить mssdecrease, но результата нет.

да, но 4.3.2 уже сертифицирована, можно обновляться.

+ на 4.2.1 из admin escape можно покрутить mtu стандартными средствами linux, будет работать до перезагрузки. Если поможет, то можно в cron запихнуть, чтобы он после перезагрузки восстанавливал параметры

[Vipnetishe]

Спасибо за ответы и участие!

9 часов назад, R.Sheyn сказал:

из admin escape можно покрутить mtu

К сожалению, не дало результата. Ставили 1400 и 1300. Я писал об этой проблеме в группе в телеграме, не знаю присутствуете ли вы там. В общем сменили ISP'a в филиале и началась такая история с каналом: скорость в два раза ниже тарифной при копировании по cifs, пинг больше 1400 байт нестабильный в туннеле, устройства за координатором не мониторятся нормально. Самое интересное, что если устройство за проблемным координатором заНАТить в интернет, то оно(устройство) и скорость показывает тарифную, и пинги проходят во вне по 2000-4000 байт. 

Схема сети:

MTU c ПК(заНАТчен) за проблемным филиальным координатором до узла в той же внешней сети, что и головной координатор:

PING c ПК(заНАТчен) за проблемным филиальным координатором до узла в той же внешней сети, что и головной координатор:

PING c ПК за проблемным филиальным координатором до локального узла(в туннеле) за головным координатором:

PING c ПК за головным координатором до локального узла(в туннеле) за беспроблемным координатором в другом филиале:

 

 

 

 

 

[zero]

А Вы как-то принципиально не пользуетесь официальной ТП? Форум и телеграм это не официальная, к сведению.

Вы учитываете, что vpn строится по udp? Может у Вашего провайдера индивидуальная непереносимость этого протокола? Зачем пинговать такими огромными пакетами? Наоборот, ставьте 1500 и уменьшайте до того момента, пока они не пойдут без потерь, если это вообще произойдет. Вот полученное значение и будет косвенно указывать на ту величину, на которую  провайдет "заузил" канал. Хотя если он беспощадно борется именно с udp, то данный путь Вам мало что даст.

[Vipnetishe]

4 часа назад, zero сказал:

А Вы как-то принципиально не пользуетесь официальной ТП?

Контракта нет на поддержку.

4 часа назад, zero сказал:

Вы учитываете, что vpn строится по udp? Может у Вашего провайдера индивидуальная непереносимость этого протокола? 

Да, первым делом был задан вопрос провайдеру по поводу фильтрации или ограничений по udp. Ответ ожидаемый:" С нашей стороны все порты открыты. Мы не блокируем."

4 часа назад, zero сказал:

Зачем пинговать такими огромными пакетами?

Проверка большим пингом это так сказать следствие проблемы. Основная проблема: несоответствие, даже близкое тарифной скорости от провайдера. Хотя скорость с другим филиалом в туннеле вполне устраивает. Следом проверили пинг большими размерами, а также обратили внимание, что мониторинг заббикса плохо собирает данные со свитча за проблемным координатором. До смены провайдера вопросов к работе канала между координаторами не было.

4 часа назад, zero сказал:

Хотя если он беспощадно борется именно с udp, то данный путь Вам мало что даст.

Будем тестировать в этом направлении. 

[Vipnetishe]

03.03.2021 в 15:41, Vipnetishe сказал:

Будем тестировать в этом направлении. 

Вчера ездил на место потестить. В итоге показало, что явно проблема в UDP потому что:

1. На ноутбуке с ПО VipNet Client v4 4.3.2 через сеть нового провайдера наблюдаются такие же проблемы со скоростью и пингами;

2. На ноутбуке с ПО VipNet Client v4 4.3.2 через сеть 4G мобильного оператора связи проблем с пингами нет;

3. На ноутбуке с ПО OpenVPN 2.4.8 по протоколу UDP через сеть нового провайдера история с пингами чуть лучше, но всё равно наблюдаются потери;

4. На ноутбуке с ПО OpenVPN 2.4.8 по протоколу TCP через сеть провайдера проблем с пингами(вплоть до 8192) нет;

Закинули письмецо провайдеру со своими наблюдениями, посмотрим что он ответит.