Jump to content

Recommended Posts

День добрый.

Сегодня пошёл шквал жалоб от пользователей (ViPNet-Клиент) с одной и той же симптоматикой.

Юзер включает утром ПК и машина не может получить настройки от DHCP-сервера.

ViPNet-драйвер грузится у всех в 4 режиме.

"Исправить", "Отключить/Включить" сетевое подключение (в режимах 4...2) - не помогает.

Помогает только отключение драйвера (5 режим), после чего жму "Исправить" сетевое соединение и машина успешно получает настройки от DHCP.

Возвращаю обратно 4 (не суть - проверялось и на 3,2 режимах, эффект тот же) режим - машина работает, сеть видит, всё хорошо. Но после следующего reboot`а или выкл./вкл. ситуация повторяется (что самое поганое :( ).

Машины без ViPNet-драйвера работают с DHCP без проблем.

Журнал регистрации IP-пакетов информации для анализа не даёт: в нём фиксируется нормальный входящий, пропущенный, DHCP-пакет (UDP:67-68, IP-адрес, MAC DHCP-сервера - всё в порядке), и всё.

Из доп. информации могу отметить следующее:

- подобные жалобы были и ранее, но они были крайне редки, единичные случаи, поэтому особо не заморачивались;

- на днях в нашей ЛВС был сбой, какие-то проблемы с питанием, активкой и т.п. (детально не вникал, коллеги из управления ИТ авралили), и вот после этого сбоя вышеописанные жалобы пошли буквально пачками от юзеров (у меня нет оснований, пока, как-то связывать эти два события, так что это просто наблюдение).

Корреляции с моделями ПК (сетевых адаптеров) или с установленной ОС не замечено - разные ПК, разные винды, и WinXP и Win7. Патчи/апдейты все стоят - в ЛВС работает WSUS.

Версии ViPNet-Клиент: 3.2(9.14544), 3.2(10.15632).

Ситуация очень неприятная, т.к. АП ViPNet-Клиент в ЛВС сотни, и, учитывая, повторение проблемы после перезагрузки (или включения) ПК, приходится к каждому юзеру бежать и вручную плясать с бубном. Сегодня с утра только этим и занимаюсь... :(

Может быть кто-то сталкивался с таким приключением?

Подскажите, хотя бы, в какую сторону копнуть?

Share this post


Link to post
Share on other sites

Что-то мне подсказывает, что проблема не в випнете... Суть проблемы нужно искать в проблемах сети, которые Вы описали. Просто так, на ровном месте не может ничего сломаться. Причем так массово.

Share this post


Link to post
Share on other sites

Что-то мне подсказывает, что проблема не в випнете... Суть проблемы нужно искать в проблемах сети, которые Вы описали. Просто так, на ровном месте не может ничего сломаться. Причем так массово.

+1

Мои "экстрасенсорные области" в районе копчика :) тоже мне подсказывают, что дело не в ViPNet`е.

Вот думаю - с какой стороны подступиться к проблеме, чтобы её "выловить" и, так сказать, наглядно коллегам из ИТ предъявить...

Попробую со сниферами поиграться.

P.S. Мой тред - ни разу не жалоба на ViPNet, ни в коем случае.

Просто думал: мало-ли, может быть кто-то из пользователей форума уже с таким делом сталкивался, как это порой бывает.

Share this post


Link to post
Share on other sites

Всё. Проблему, кажись, устранил. Но причину так и не установил. :(

Тред можно удалять.

Share this post


Link to post
Share on other sites

Что-то мне подсказывает, что проблема не в випнете... Суть проблемы нужно искать в проблемах сети, которые Вы описали. Просто так, на ровном месте не может ничего сломаться. Причем так массово.

Вот я так и знал! B)

Цитата из доки на Клиент (свежайший):

"... В программе ViPNet Client исправлены следующие ошибки:

Блокировка DHCP-трафика при запущенной программе ViPNet Client в случае,

когда из одного сегмента сети по широковещательной рассылке передается

большое количество запросов к DHCP-серверу. ..."

Вот и верь теперь в людей... :D

Share this post


Link to post
Share on other sites

Это срабатывало средство обнаружения атак получается?

Share this post


Link to post
Share on other sites

Это срабатывало средство обнаружения атак получается?

Дык кто ж признается? Может и так.

Факт в том, что я и мои бойцы тогда, в Мае, километры намотали, скача, как кони, по кабинетам и клацая режимами (при включении 5 режима ПК получал таки параметры от DHCP). Каждое утро начиналось с аврала - юзеры включают компы, а те не видят сетку. Было "весело"... Очень.

И все мне твердили (и тут в т.ч. - см. выше), что это не-е-е, не ViPNet. Ну не может такого быть. Это у вас что-то с сетью или DHCP-сервером.

Хотя, да, Stratos меня почти убедил, что рыть надо мимо ViPNet`а. Было дело, было. Признаю. Копчик метался. :)

Ага...

Я тогда коллегам из нашего Управления ИТ всю плешь проел, они 10 раз проверяли свой DHCP-сервак, разве что под микроскопом не рассматривали. Говорят - да всё в порядке с ним!

Я, для очистки совести, снифер прикрутил - полез анализировать IP-пакеты, блин, побитно. Ну в порядке всё с сеткой, хоть тресни!

Попом чувствовал, что это ViPNet глюкавит...

И, судя по всему, пятая точка в очередной раз оказалась права.

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

Очевидно, что вот эту совокупность обстоятельств "...в случае, когда из одного сегмента сети по широковещательной рассылке передается большое количество запросов..." в Мае только мы словили. Повезло, блин. ))

Share this post


Link to post
Share on other sites

Ну, да... либо средство обнаружения атак сработал, либо просто какая-нибудь таблица переполнялась (или просто DHCP как-то по-особому обрабатывается). Будем иметь ввиду. Мы вообще как только випнет стали активно в сетку внедрять, сразу от DHCP отказались - были глюки, да и разные адреса особо уже не пораздаёшь - блокируются потом по ошибке "незашифрованный пакет от сетевого узла" (а на серверах это неприятно). Да и статика имеет свои преимущества - наобум подключённый компьютер в сеть сразу доступ не получит. Хотя много раз и было желание использовать DHCP. И в журналах при этом ничего блокирующего не писалось? Просто проявлялось как глюк? И почему у Вас именно тогда была такая лавина?

Share this post


Link to post
Share on other sites

...Мы вообще как только випнет стали активно в сетку внедрять, сразу от DHCP отказались - были глюки, да и разные адреса особо уже не пораздаёшь - блокируются потом по ошибке "незашифрованный пакет от сетевого узла" (а на серверах это неприятно). Да и статика имеет свои преимущества - наобум подключённый компьютер в сеть сразу доступ не получит. Хотя много раз и было желание использовать DHCP.

Согласен по всем пунктам.

Моя б воля была бы, я б тоже посадил всех на статику, учитывая особенности ViPNet.

Но, увы, это епархия нашего Управления ИТ. А они настаивают на использовании DHCP. При этом на серверах и ряде критичных ПК таки стоИт статика. Так и живём, "полосато". :unsure: Ничего с этим поделать не могу.

...И в журналах при этом ничего блокирующего не писалось? Просто проявлялось как глюк?

В Журналах регистрации IP-пакетов было девственно чисто (в смысле блокированных), в том-то и дело. Журналы это было первое, куда я кинулся.

В ходе танцев с бубном также было замечено следующее (было это симптоматикой обсуждаемого глюка или просто странным совпадением, теперь уже судить не берусь):

- При установке снифера непосредственно на DHCP-сервере и ловле пакетов была видна такая цепочка: входящий пакет от всплывшего в сети ПК (нормальный пакет) DHCPDISCOVER, далее исходящий пакет от DHCP DHCPOFFER, а вот DHCPREQUEST от ПК уже не дождались. Но зато от MAC-адреса ПК поступал UDP-пакет с портом назначения 55777 :blink: . Т.е. выглядело это так, как будно ПК (АП) ни с того ни с сего, посреди "переклички" решал (вдруг!), что DHCP-сервер телепортировался из родной подсети в туннель, и начинал обращаться к нему, как к туннелируемому хосту. :huh: ПК и DHCP находятся в одной подсети, само собой.

- В ходе развития танцев я удалил IP-адрес DHCP-сервера из туннеля рубежного Координатора (а он там был - его необходимо туннелировать), сформировал/разослал справочники и проблема ушла! Но радости от этого было мало, т.к. IP-адрес DHCP-сервера, увы, повторюсь, туннелировать крайне необходимо. Вернул его в туннель, обновил справочники - проблема вернулась.

Вот такой балет был.

При этом, глюк как неожиданно появлялся и мурыжил нас два-три дня утренними пробежками по этажам, так и неожиданно исчезал.

В итоге, как я уже писал выше, было три "волны" таких. В течение примерно 1...1,5 месяцев. После чего как-то "само собой рассосалось".

Мистика. Сюжет для RenTV. :D

...И почему у Вас именно тогда была такая лавина?...

А вот этого, боюсь, мы уже никогда не узнаем. :D

P.S. Галки обнаружения атак в настройках Мониторов АП вырубали все. Не помогало.

Share this post


Link to post
Share on other sites

Таинственная история. У VIpNet вообще много забавностей. К примеру - его желание оптимизировать через какой экран работать и по каким адресам - виртуальным или реальным. Иногда эта гадость зависает и до перезагрузки координатора никакими метриками ситуацию не поправишь. Такое было несколько раз в относительно приближённые периоды.

Share this post


Link to post
Share on other sites
...У VIpNet вообще много забавностей...

О, да...

Share this post


Link to post
Share on other sites

Добрый день)

Испытываем точно такие же ощущения, уже на протяжении 2-х месяцев... с DHCP выдающем адрес отсутствия в сети сервера.... бегаем по 4-м этажам (в основном с утра пораньше), делаем диагностику сетевого подключения... вылечивается (в исправлениях диагностики говориться про шлюз, что он был не по умолчанию, дословно не напишу)

Иногда, в очень редких случаях такая процедура не помогает, удаляем драйвер адаптера, ставим снова... и вуаля.

Дайте наводку, куда копать, на что обратить внимание..

спасибо!

VipNet Client 3.2 (11.18202)

Share this post


Link to post
Share on other sites

Извините, а зачем туннелировать DHCP если вы находитесь в одной сети? У вас же с начало трафик идет до координатор, а потом попадает на DHCP, а возвращается то он уже на прямую к клиенту, вот и происходит блокирование трафика. Или на DHCP сервере есть куча конфиденциальной информации которая так и лезет изо всех портов которую необходимо зашифровать? Да и вообще зачем туннелировать компы которые находятся все в одной физической сети? У вас же контролируемая зона....

To

Добрый день)

Испытываем точно такие же ощущения, уже на протяжении 2-х месяцев... с DHCP выдающем адрес отсутствия в сети сервера.... бегаем по 4-м этажам (в основном с утра пораньше), делаем диагностику сетевого подключения... вылечивается (в исправлениях диагностики говориться про шлюз, что он был не по умолчанию, дословно не напишу)

Иногда, в очень редких случаях такая процедура не помогает, удаляем драйвер адаптера, ставим снова... и вуаля.

Дайте наводку, куда копать, на что обратить внимание..

спасибо!

VipNet Client 3.2 (11.18202)

Уберите туннель на DHCP или снесите от туда VipNet Client. Или настроййте DHCP на координаторе (если у Вас железяка конечно). Меньше проблем.

Share this post


Link to post
Share on other sites

Извините, а зачем туннелировать DHCP если вы находитесь в одной сети?

Уберите туннель на DHCP или снесите от туда VipNet Client. Или настроййте DHCP на координаторе (если у Вас железяка конечно). Меньше проблем.

Не могу знать, на сервере AD (там и DHCP, и DNS, и еще некоторые службы) стоит VipNet Client, много уже проблем с этой связкой испытали, объяснить немогу для чего он там, это прихоть безопасников!

Думал есть какие то решения, не убирая VipNet Client'а сделать так чтобы сеть работала без сбоев)))

Share this post


Link to post
Share on other sites
...объяснить немогу для чего он там, это прихоть безопасников!...

Я сам безопасник и "махровый" VipNet`чик, причём "злой". :D

Но даже для меня очевидно, что подобная прихоть без наличия состоятельного объективного обоснования - обыкновенная блажь.

Сочувствую.

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.