VipNet и доступ к ПК-ПВД 3.x

[МФЦЮгорск]

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

[Rinya]

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

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

[МФЦЮгорск]

ОС на клиентских компах Windows 7 x64. Сегодня попробуем, результаты отпишу

[basid]

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 . Изменил значение на ноль, перезагрузил ПК, все также грузит название и белый экран вечной загрузки.

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

[KIV]

Цитата

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

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

[veselov-pv]

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

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

[basid]

1 час назад, МФЦЮгорск сказал:

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

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

[МФЦЮгорск]

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

[Vintik]

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

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

[basid]

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