Я работал ИТ-специалистом в правительстве округа более 2,5 лет, и эта проблема возникала 3 раза. Я могу исправить это, перезапустив основной сервер, но я хотел бы исправить это, не выбирая этот маршрут. Вот такая ситуация. На нашем первичном сервере (далее именуемом Server1) у нас работает программное обеспечение под названием Springbrook (корпоративное программное обеспечение для бухгалтерского учета и выставления счетов за коммунальные услуги). Пользователи получают доступ к Springbrook через подключенные диски к Server1. Я размещаю на их рабочих столах ярлык, который извлекает программное обеспечение с подключенного диска. Иногда, я не знаю, почему, 3 или более пользователей теряют доступ к Server1, что приводит к потере доступа к Springbrook. Остальные из нас все еще могут получить доступ к Server1. Теряя доступ к Server1, я имею в виду, что ПК A не может пинговать, подключаться к RD или получать доступ к общим ресурсам на Server1. Ping сообщает мне, что удаленный хост недоступен, RD выдает то же сообщение, и когда я пытаюсь исследовать подключенный диск, сообщение сообщает мне, что сетевой путь недоступен. Если я перезапущу Server1, эти 3 пользователя снова могут получить доступ к Server1.
Я предполагаю, что происходит только одно: сетевая служба перезапускается, но я не знаю, это служба NetLogon, служба AD или что-то еще, о чем я не знаю. Перезагрузка компьютеров пользователей не решает проблемы. Повторное присоединение ПК к домену также не решает проблему; это всегда перезапуск Server1, который решает проблему.
Это случается не часто. Как я уже сказал, за те два с половиной года, что я здесь, это случилось 3 раза. Из этих 3-х раз это были разные ПК. Хотелось бы знать, как это предотвратить или хотя бы как исправить, не перезагружая сервер полностью.
Домен AD. Сервер Windows Server 2008 R2. Межсетевой экран Sonicwall TZ210. Коммутатор Netgear на 24 гигабайта. ПК подключаются к коммутаторам Netgear gig с 5 портами.
Спасибо.
РЕДАКТИРОВАТЬ: Спасибо за ответы. Плохо пишу вопрос с моей стороны. Я не упомянул, что пораженные компьютеры могут связываться с другими компьютерами в сети, даже с Server2 (у нас есть контроллеры домена). Server1 также не может пинговать затронутые компьютеры.
Я нашел ответ на проблему! По крайней мере, в этом году. :)
Проблема возникла снова вчера утром и во время обеда, но на этот раз на прошлой неделе был только один компьютер, который не входил в затронутую группу. Во время задачи я сделал следующее:
За обедом чудовище снова подняло свою уродливую голову.
Зашел на сервер, собрал пакеты wirehark между пораженным ПК и сервером. Затем я перезапустил сервер, потому что знаю, что это работает. Это устранило проблему. Я смог прочитать собранные данные только в течение нескольких минут, потому что возникли другие проблемы (я единственный ИТ-специалист - команда из одного человека), которые занимали мое время до конца смены. Подумал об этом всю ночь. Пришел сегодня утром, собрал сетевой трафик, просто чтобы посмотреть, есть ли какие-нибудь перебои в сетевых процессах, и не смог найти ничего, раздувающего «трубу». Тогда меня осенило: проверьте логи Касперского на сервере. Я проверил журналы блокировщика сетевых атак и обнаружил, что на прошлой неделе «Касперский» обнаружил «атаки» dos.generic.synflood с 3-х пораженных машин на прошлой неделе и зараженной машины вчера. Когда Касперский обнаруживает подобные вещи, он прерывает связь с атакующим узлом на 60 минут. Журналы давали точное время возникновения проблемы, и это время соответствовало времени, когда затронутые пользователи звонили мне по поводу проблемы. Я отследил журналы за 30 дней и заметил, что в них нет атак.
Я установил блокировщик сетевых атак, чтобы блокировать атакующий узел только на 1 минуту. Я также собираюсь исследовать, чем могут быть синфлуд-атаки. По крайней мере, сейчас я знаю, почему эти машины были отключены от сервера. Конечно, теперь мне нужно выяснить источник этих атак dos.generic.synflood.
Если вы не можете проверить связь с сервером, он отключен от сети, и перезапуск любой службы Windows ничего для вас не исправит. У вас проблема либо с самой сетью, либо с сетевой картой сервера.
Учитывая тот факт, что это всего лишь несколько машин и не похоже, что ваша сеть имеет внутреннюю маршрутизацию, один из ваших коммутаторов может выйти из строя или иметь проблемы с ARP. Похоже, они не управляются, поэтому в следующий раз, когда это произойдет, вам придется выполнить некоторые действия по устранению неполадок, пока проблема возникает, чтобы найти неисправность.
Я должен был согласиться с Mfinni, перезапуск любой из упомянутых служб не разрешил / не остановил трафик на ваш сервер. Если что, проверьте свой сервер на наличие конфигураций брандмауэра. К сожалению, эта проблема настолько прерывистая, что вам придется играть в выжидательную игру для устранения неполадок. Лучшее, что вы можете сделать, - это составить план действий на случай, когда это повторится снова. Для этого я бы начал с запуска Wireshark или другого типа сниффера пакетов на сервере и клиенте, пока возникает проблема, и пока у вас есть постоянный пинг с затронутых машин. Я также хотел бы проверить, могут ли эти затронутые машины связываться с любыми другими машинами в локальной / удаленной подсети, чтобы сузить вашу проблему.
Вы пытались отключить, а затем снова включить сетевую карту на Server1?
Я столкнулся с подобной проблемой около года назад, мой файловый сервер не распознавал одного из клиентов. Я сделал следующее:
Пуск-> Выполнить-> cmd (ввод) -> arp -d * (ввод)
Убедитесь, что вы делаете это на Server1 или на том, к которому компьютер не имеет доступа.
Сообщите мне, если это поможет.