Сегодня у нас было несколько машин, которые перестали получать доступ в Интернет. После долгих поисков неисправностей общая тенденция заключается в том, что сегодня у всех них была продлена аренда dhcp (здесь у нас 8-дневная аренда).
Все, что вы ожидаете, выглядит хорошо после продления аренды: у них есть действующий IP-адрес, DNS-сервер и шлюз. У них есть доступ к внутренним ресурсам (общие файловые ресурсы, интрасеть, принтеры и т. Д.). Дальнейшее устранение неполадок показывает, что они не могут выполнить ping или трассировку нашего шлюза, но они могут добраться до нашего основного коммутатора уровня 3 прямо перед шлюзом. Назначение статического IP-адреса машине работает как временное решение.
Еще одна проблема заключается в том, что до сих пор отчеты приходили только для клиентов на том же vlan, что и шлюз. Наш административный персонал и преподаватели подключены к тому же vlan, что и серверы и принтеры, но телефоны, брелоки / камеры, студенты / Wi-Fi и лаборатории имеют свои собственные vlan, и насколько я не видел ничего ни на одном из других vlan возникла проблема.
У меня есть отдельный запрос к поставщику шлюза, но я подозреваю, что они не торопятся и скажут мне, что проблема в другом месте в сети, поэтому я тоже спрашиваю здесь. Я очистил кеши ARP на шлюзе и главном коммутаторе. Любые идеи приветствуются.
Обновить:
Я попытался выполнить пинг со шлюза обратно на несколько затронутых хостов, и странно то, что я получил ответ: с совершенно другого IP-адреса. Я попробовал еще несколько наугад и в итоге получил следующее:
Fri Sep 02 2011 13:08:51 GMT-0500 (Central Daylight Time) PING 10.1.1.97 (10.1.1.97) 56(84) bytes of data. 64 bytes from 10.1.1.105: icmp_seq=1 ttl=255 time=1.35 ms 64 bytes from 10.1.1.97: icmp_seq=1 ttl=255 time=39.9 ms (DUP!)
10.1.1.97 - это фактическая намеченная цель пинга. 10.1.1.105 должен быть принтер в другом здании. у меня есть никогда раньше видел DUP в ответе ping.
Мое лучшее предположение на данный момент - это мошеннический маршрутизатор Wi-Fi в одной из наших комнат в общежитии в подсети 10.1.1.0/24 с плохим шлюзом.
... продолжение. Я отключил неисправный принтер, и эхо-запросы к затронутому хосту со шлюза полностью завершились неудачно.
Обновление 2:
Я проверяю таблицы arp на задействованной машине, шлюзе и каждом переключателе между ними. На каждом этапе записи для этих устройств были правильными. Я не проверял каждую запись в таблице, но каждая запись, которая могла повлиять на трафик между хостом и шлюзом, была в порядке. ARP - не проблема.
Обновление 3:
В данный момент все работает, но я не вижу ничего, что я сделал, чтобы их исправить, поэтому я понятия не имею, может ли это быть временным затишием. В любом случае, сейчас я мало что могу сделать для диагностики или устранения неполадок, но я обновлю больше, если он снова сломается.
«На данный момент я могу предположить, что в одной из комнат нашего общежития в подсети 10.1.1.0/24 с плохим шлюзом установлен мошеннический маршрутизатор Wi-Fi».
Это произошло в моем офисе. Злоумышленник оказался мошенническим устройством на базе Android:
http://code.google.com/p/android/issues/detail?id=11236
Если устройство Android получает IP-адрес шлюза из другой сети через DHCP, оно может присоединиться к вашей сети и начать отвечать на запросы ARP для IP-адреса шлюза с его MAC. Использование вами общей сети 10.1.1.0/24 увеличивает вероятность этого мошеннического сценария.
Мне удалось проверить кеш ARP на затронутой рабочей станции в сети. Там я наблюдал проблему потока ARP, когда рабочая станция переключалась между правильным MAC-адресом и MAC-адресом от какого-то мошеннического устройства. Когда я нашел подозрительный MAC-адрес, который рабочая станция использовала для шлюза, он вернулся с префиксом Samsung. Проницательный пользователь с неисправной рабочей станцией ответил, что он знает, у кого в нашей сети есть устройство Samsung. Оказался генеральным директором.
Как уже говорилось в разделе комментариев, получение захвата пакета действительно важно. Однако есть действительно отличный инструмент под названием arpwatch:
(или http://sid.rstack.org/arp-sk/ для окон)
Этот инструмент отправит вам электронное письмо или просто будет вести журнал всех новых MAC-адресов, обнаруженных в сети, а также любых изменений MAC-адресов для IP-адресов в данной подсети (триггеры). Для этой проблемы у вас были бы обнаружены обе текущие теории, либо сообщив, что для IP-адресов, меняющих MAC-адреса, произошли триггеры, либо вы бы увидели новый MAC для мошеннического маршрутизатора DHCP, когда он впервые начал связываться с хостами. Недостатком этого инструмента является то, что вам нужно, чтобы хост был подключен ко всем отслеживаемым вами сетям, но это небольшая цена за большую информацию, которую он может предоставить, чтобы помочь диагностировать такого рода проблемы.
Быстрый способ обнаружить типичные мошеннические DHCP-серверы - это проверить связь со шлюзом, который он обслуживает, а затем проверить его MAC в соответствующей таблице ARP. Если коммутационная инфраструктура является управляемой, то MAC также можно отследить до порта, на котором он находится, и порт можно либо отключить, либо отследить до местоположения нарушившего устройства для дальнейшего исправления.
Использование DHCP Snooping на коммутаторах, которые его поддерживают, также может быть эффективным вариантом защиты сети от мошеннических серверов DHCP.