ApB 0 Report post Posted October 17, 2017 Доброго времени суток! Прошу помочь со способом/методом анализа ситуации Есть большая сеть (А) за HW1000 и есть малая сеть (Б) за HW100. Между ними канал в 40MB А если забраться с хоста сети Б в хост сети А, то скорость передачи данных 2MB Интенсивность использования шлюзов низкая. Соединены хосты тоннелем Какова может быть причина падения скорости? Quote Share this post Link to post Share on other sites
KIV 0 Report post Posted October 17, 2017 Что значит тоннелем соединены? На каком то другом оборудовании поднят транспорт, а сверху випнет? Какие версии ПО на координаторах? Quote Share this post Link to post Share on other sites
ApB 0 Report post Posted October 18, 2017 Здравствуйте! Соединены тоннелем - это значит, что в 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) Quote Share this post Link to post Share on other sites
KIV 0 Report post Posted October 18, 2017 Так 2МБайт в сек это около 16 Мбит/сек. Нужно посмотреть производительность HW100 для шифрованного трафика для версии ПО 3. Обновитесь до 3.5. Quote Share this post Link to post Share on other sites
intellegent 0 Report post Posted November 27, 2017 А вы канал без средств защиты тестировали? В нем можно получить 40 Мбит/сек? От этого следует отталкиваться - то что канал действительно способен обеспечить нужную скорость. Quote Share this post Link to post Share on other sites
ApB 0 Report post Posted November 27, 2017 Здравствуйте! Да, тестировал. Если выпустить машину в сеть напрямую, нет никаких проблем со скоростью соединения Quote Share this post Link to post Share on other sites
denis.r 0 Report post Posted November 27, 2017 Попробуйте установить на ПАК параметр mssdecrease=200 http://docs.infotecs.ru/#122/41894.htm Quote Share this post Link to post Share on other sites
Vipnetishe 0 Report post Posted March 1 17.10.2017 в 16:15, ApB сказал: Какова может быть причина падения скорости? Приветствую. Как решилась ваша ситуация в итоге? Наблюдаем такую же историю у себя. Quote Share this post Link to post Share on other sites
R.Sheyn 0 Report post Posted March 1 52 минуты назад, Vipnetishe сказал: Приветствую. Как решилась ваша ситуация в итоге? Наблюдаем такую же историю у себя. падение скорости на неадекватные величины на 99% связано фрагментацией где-то по пути. Покрутите MTU. Quote Share this post Link to post Share on other sites
Vipnetishe 0 Report post Posted March 1 5 часов назад, R.Sheyn сказал: Покрутите MTU. У нас версия FW 4.2.1 на координаторах. Если я правильно прочитал, что MTU можно крутить с версии 4.3.X. У себя пробовали крутить mssdecrease, но результата нет. Quote Share this post Link to post Share on other sites
R.Sheyn 0 Report post Posted March 2 19 часов назад, Vipnetishe сказал: У нас версия FW 4.2.1 на координаторах. Если я правильно прочитал, что MTU можно крутить с версии 4.3.X. У себя пробовали крутить mssdecrease, но результата нет. да, но 4.3.2 уже сертифицирована, можно обновляться. + на 4.2.1 из admin escape можно покрутить mtu стандартными средствами linux, будет работать до перезагрузки. Если поможет, то можно в cron запихнуть, чтобы он после перезагрузки восстанавливал параметры Quote Share this post Link to post Share on other sites
Vipnetishe 0 Report post Posted March 2 Спасибо за ответы и участие! 9 часов назад, R.Sheyn сказал: из admin escape можно покрутить mtu К сожалению, не дало результата. Ставили 1400 и 1300. Я писал об этой проблеме в группе в телеграме, не знаю присутствуете ли вы там. В общем сменили ISP'a в филиале и началась такая история с каналом: скорость в два раза ниже тарифной при копировании по cifs, пинг больше 1400 байт нестабильный в туннеле, устройства за координатором не мониторятся нормально. Самое интересное, что если устройство за проблемным координатором заНАТить в интернет, то оно(устройство) и скорость показывает тарифную, и пинги проходят во вне по 2000-4000 байт. Схема сети: MTU c ПК(заНАТчен) за проблемным филиальным координатором до узла в той же внешней сети, что и головной координатор: PING c ПК(заНАТчен) за проблемным филиальным координатором до узла в той же внешней сети, что и головной координатор: PING c ПК за проблемным филиальным координатором до локального узла(в туннеле) за головным координатором: PING c ПК за головным координатором до локального узла(в туннеле) за беспроблемным координатором в другом филиале: Quote Share this post Link to post Share on other sites
zero 0 Report post Posted March 3 А Вы как-то принципиально не пользуетесь официальной ТП? Форум и телеграм это не официальная, к сведению. Вы учитываете, что vpn строится по udp? Может у Вашего провайдера индивидуальная непереносимость этого протокола? Зачем пинговать такими огромными пакетами? Наоборот, ставьте 1500 и уменьшайте до того момента, пока они не пойдут без потерь, если это вообще произойдет. Вот полученное значение и будет косвенно указывать на ту величину, на которую провайдет "заузил" канал. Хотя если он беспощадно борется именно с udp, то данный путь Вам мало что даст. Quote Share this post Link to post Share on other sites
Vipnetishe 0 Report post Posted March 3 4 часа назад, zero сказал: А Вы как-то принципиально не пользуетесь официальной ТП? Контракта нет на поддержку. 4 часа назад, zero сказал: Вы учитываете, что vpn строится по udp? Может у Вашего провайдера индивидуальная непереносимость этого протокола? Да, первым делом был задан вопрос провайдеру по поводу фильтрации или ограничений по udp. Ответ ожидаемый:" С нашей стороны все порты открыты. Мы не блокируем." 4 часа назад, zero сказал: Зачем пинговать такими огромными пакетами? Проверка большим пингом это так сказать следствие проблемы. Основная проблема: несоответствие, даже близкое тарифной скорости от провайдера. Хотя скорость с другим филиалом в туннеле вполне устраивает. Следом проверили пинг большими размерами, а также обратили внимание, что мониторинг заббикса плохо собирает данные со свитча за проблемным координатором. До смены провайдера вопросов к работе канала между координаторами не было. 4 часа назад, zero сказал: Хотя если он беспощадно борется именно с udp, то данный путь Вам мало что даст. Будем тестировать в этом направлении. Quote Share this post Link to post Share on other sites
Vipnetishe 0 Report post Posted March 5 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) нет; Закинули письмецо провайдеру со своими наблюдениями, посмотрим что он ответит. Quote Share this post Link to post Share on other sites
