Перейти к контенту

Рекомендуемые сообщения

Коллеги подскажите возможна ли проблема в 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

Поделиться этим сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Подобные проблемы в версии 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

Поделиться этим сообщением


Ссылка на сообщение
Поделиться на других сайтах
2 часа назад, МФЦЮгорск сказал:

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

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

Поделиться этим сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

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

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

Снимок.jpg

Поделиться этим сообщением


Ссылка на сообщение
Поделиться на других сайтах
Цитата

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

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

Поделиться этим сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

Поделиться этим сообщением


Ссылка на сообщение
Поделиться на других сайтах
1 час назад, МФЦЮгорск сказал:

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

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

Поделиться этим сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Поделиться этим сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

Поделиться этим сообщением


Ссылка на сообщение
Поделиться на других сайтах

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-пакет копируется полученное (единица).

Поделиться этим сообщением


Ссылка на сообщение
Поделиться на других сайтах

Создайте аккаунт или авторизуйтесь, чтобы оставить комментарий

Комментарии могут оставлять только зарегистрированные пользователи

Создать аккаунт

Зарегистрировать новый аккаунт в нашем сообществе. Это несложно!

Зарегистрировать новый аккаунт

Войти

Есть аккаунт? Войти.

Войти

×

Важная информация

By using this site, you agree to our Условия использования.