Jump to content

Recommended Posts

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

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

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

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

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

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

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

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

Share this post


Link to post
Share on other sites

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

 

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

Share this post


Link to post
Share on other sites

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

Соединены тоннелем - это значит, что в 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)

 

Share this post


Link to post
Share on other sites

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

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

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

Share this post


Link to post
Share on other sites
17.10.2017 в 16:15, ApB сказал:

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

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

Share this post


Link to post
Share on other sites
52 минуты назад, Vipnetishe сказал:

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

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

Share this post


Link to post
Share on other sites
5 часов назад, R.Sheyn сказал:

Покрутите MTU.

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

Share this post


Link to post
Share on other sites
19 часов назад, Vipnetishe сказал:

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

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

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

Share this post


Link to post
Share on other sites

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

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

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

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

Схема сети:

scheme.png

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

mtu.png

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

ping126.png

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

ping134.png

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

ping22.png

 

 

 

 

 

Share this post


Link to post
Share on other sites

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

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

Share this post


Link to post
Share on other sites
4 часа назад, zero сказал:

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

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

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

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

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

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

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

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

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

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

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

Share this post


Link to post
Share on other sites
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) нет;

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

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.