Jump to content

Recommended Posts

Коллеги подскажите возможна ли проблема в VipNet client 4.3 ? На компьютерах пользователей установлен VipNet client 4.3 в нем доступен координатор росреестра с номером 6415, в нем прописан туннель (с ip 10.86.112.220) до сервера росреестра ПК-ПВД. Пинги до сервера http://10.86.112.220 идут без проблем, даже при просмотре журнала IP пакетов VipNet client 4.3 на этом координаторе 6415, видно что весь трафик пропускается(Скриншот 1)

Что имеем, на трех ПК пользователей из 15, нет доступа к веб сайту росреестра по адресу http://10.86.112.220. Все ПК одинаковые как по конфигурации железа т.к и по установленному и настроенному ПО.

Что пробовали на проблемных ПК:

1) Отключить антивирус Касперский (управление централизованное через политики, на всех ПК все одинаково)

2) В Vip-net Client в фильтры открытой сети создали временной фильтр с разрешением Источник - Все, Назначение - Все, порты - Все (Скриншот 2)

3) Обновляли java, flash player

4) Меняли браузеры начиная от IE11, FF57, Chrome

5) Пользователи работаю под ограниченной учетной записью, пробовал заводить нового пользователя. Заходили даже под Администратором домена и локального ПК.

Сайт росреестра загружает только название, далее ни один css стиль, ни один JS не подгружается, только белый экран с бесконечная загрузка страницы во всех браузерах.

Такая проблема только на 3 ПК, из 15, на остальных все замечательно работает.

Снимок1.jpg

Снимок2.jpg

Снимок3.jpg

Share this post


Link to post
Share on other sites

А можно узнать ОС на проблемных компах?

Подобные проблемы в версии 3 решал так. помогало одно из следующих, незнаю как в 4 версии, но можете попробовать, если что вернете обратно.

  1. HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Infotecs\PatchEngine присвойте параметру Flags значение 0.
  2. HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa и в параметре  Security Packages удаляем sspp и itcssp и прописываем schannel

Share this post


Link to post
Share on other sites
2 часа назад, МФЦЮгорск сказал:

Пинги до сервера http://10.86.112.220 идут без проблем

ping -l 2000 10.86.112.220 - тоже без проблем?
Превентивное уменьшение MTU байт на 100-200 в настройках клиента делали?

Share this post


Link to post
Share on other sites

Пинги ping -l 1000 10.86.112.220 тоже без проблем. Но при 2000 байт, превышен интервал запроса.

Превентивное уменьшение MTU байт на 100-200 в настройках клиента делали - это где посмотреть можно, подскажите?

В реестре нашел только HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Infotecs\PatchEngine . Изменил значение на ноль, перезагрузил ПК, все также грузит название и белый экран вечной загрузки.

Сегодня еще взяли чистый системник, на него установили вип нет и ДСТ одного из проблемных ПК, все заработало. Грешим на ОС. Завтра на одном из ПК будет перестанавливать операционку. 

Снимок.jpg

Share this post


Link to post
Share on other sites
Цитата

уменьшение MTU байт на 100-200

Вот это сделайте на клиентах с которыми проблема. В настройках MSS измените 0 на 100.

Share this post


Link to post
Share on other sites

уменьшение MTU байт на 100-200

VipNet Client: Сервис -> Настройка приложения -> Защищенная сеть (+Дополнительные параметры) -> Уменьшить максимальный размер сегмента (MSS) протокола TCP на:

Share this post


Link to post
Share on other sites
1 час назад, МФЦЮгорск сказал:

Но при 2000 байт, превышен интервал запроса.

На будущее.
Если "маленькие" пакеты проходят, а большие - нет, то этот нехороший человек (падла где-то на маршруте) режет ICMP-пакеты.
Если есть возможность - расстрелять из рогатки, а потом гуглить path MTU discovery.
Ну и запомнить уже ICMP коды. Тип 3 - в особенности.

Share this post


Link to post
Share on other sites

Коллеги всем огромное спасибо, уменьшение максимального размера сегмента (MSS) в VipNet cliente помогло в решении проблемы. Осталось выяснить на каком этапе(роутере, координаторе) уменьшен размер MTU или где запрещена пересылка ICMP. Кстати почему такое происходит не на всех ПК, ведь все в одной локальной сети и трафик идет по одному пути.

Share this post


Link to post
Share on other sites

Возможно где то ответ от ICMP приняли во внимание (я про железку) и на ответ "не проходят пакеты, слишком толстые, уменьшите пожалуйста" система уменьшила их и зафиксировала, а где то такой ответ заблокировал МЭ и конечный узел не может этого знать и так и отправляет как есть. Тут уже вам поможет только полный анализ всего трафика, но думаю на это не у кого не будет время.

Самое главное вы нашли решение.

Share this post


Link to post
Share on other sites

Usage: ping [-t] [-a] [-n count] [-l size] [-f] [-i TTL] [-v TOS]
            [-r count] [-s count] [[-j host-list] | [-k host-list]]
            [-w timeout] [-R] [-S srcaddr] [-4] [-6] target_name

Options:
...
    -l size        Send buffer size.
    -f             Set Don't Fragment flag in packet (IPv4-only).
    -i TTL         Time To Live.
...

Начинаем с TTL=1 и постепенно увеличиваем, пока какой-то из промежуточных узлов не начнёт "молчать".
Ну и не забываем про всякие "ICMP-приколы" из RFC. Например, "корявый" TTL, когда вместо стандартного значения (128-255), в ответный ICMP-пакет копируется полученное (единица).

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×

Important Information

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