Сегодня у нас было несколько машин, которые перестали получать доступ в интернет. После большого количества устранения неполадок общий поток - то, что у всех их была продлена их аренда dhcp сегодня (мы на 8 дней аренды здесь).
Все, что вы ожидаете, выглядит хорошо после продления аренды: у них есть действующий IP-адрес, DNS-сервер и шлюз. Они имеют доступ к внутренним ресурсам (общие папки, интранет, принтеры и т. Д.). Немного больше неполадок показывает, что они не могут пропинговать или отследить наш шлюз, но они могут добраться до нашего основного коммутатора layer3 прямо перед шлюзом. Назначение статического IP-адреса машине работает как временное решение.
Последний недостаток заключается в том, что до сих пор отчеты поступали только для клиентов в том же VLAN, что и шлюз. Наш административный персонал и преподаватели работают в том же vlan, что и серверы и принтеры, но у телефонов, брелков / камер, студентов / wifi и лабораторий есть свои собственные vlans, и, насколько я видел, ни в одном из других vlans. была проблема еще.
У меня есть отдельный билет с поставщиком шлюза, но я подозреваю, что они возьмут на себя и скажут мне, что проблема в другом месте в сети, поэтому я спрашиваю и здесь. Я очистил кэши arp на шлюзе и коммутаторе ядра. Любые идеи приветствуются.
Обновление:
я попытался пропинговать от шлюза назад к некоторым затронутым хостам, и странным является то, что я получил ответ: с совершенно другого IP-адреса. Я попробовал еще несколько наугад и в итоге получил это:
Пт 02 сентября 2011 13:08:51 GMT-0500 (центральное дневное время) PING 10.1.1.97 (10.1.1.97) 56 (84) байтов данных. 64 байта из 10.1.1.105: icmp_seq = 1 ttl = 255 время = 1,35 мс 64 байта из 10.1.1.97: icmp_seq = 1 ttl = 255 раз = 39,9 мс (DUP!)
10.1.1.97 - фактическая предполагаемая цель пинга. 10.1.1.105 должен быть принтером в другом здании. Я никогда раньше не видел DUP в ответе на пинг.
Мое лучшее предположение в настоящее время - мошеннический маршрутизатор Wi-Fi в одной из наших комнат общежития в подсети 10.1.1.0/24 с плохим шлюзом.
... продолжение. Теперь я выключил принтер, который нарушил работу, и пропустил эхо-запрос к уязвимому хосту через шлюз.
Обновление 2:
я проверяю таблицы arp на работающей машине, шлюзе и каждом переключателе между ними. На каждом этапе записи для этих устройств были правильными. Я не проверял каждую запись в таблице, но каждая запись, которая могла повлиять на трафик между хостом и шлюзом, была в порядке. ARP не проблема.
Обновление 3: В
данный момент все работает, но я не вижу ничего, что я сделал, чтобы исправить их, и поэтому я не знаю, может ли это быть просто временное затишье. Во всяком случае, я не могу многое сделать для диагностики или устранения неполадок сейчас, но я обновлю больше, если он снова сломается.
источник
Ответы:
«Мое лучшее предположение на данный момент - мошеннический маршрутизатор Wi-Fi в одной из наших комнат общежития в подсети 10.1.1.0/24 с плохим шлюзом».
Это случилось в моем офисе. Устройство-нарушитель оказалось мошенническим устройством 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://ee.lbl.gov/
(или http://sid.rstack.org/arp-sk/ для Windows)
Этот инструмент отправит вам электронное письмо или просто сохранит журнал всех новых MAC-адресов, увиденных в сети, а также любые изменения MAC-адресов для IP-адресов в данной подсети (триггеры). Если бы у вас была эта проблема, он обнаружил бы обе текущие теории, сообщив, что для IP-адресов, меняющих MAC-адреса, происходили триггеры, или вы увидели бы новый MAC-адрес для мошеннического маршрутизатора DHCP, когда он впервые начал взаимодействовать с хостами. Недостатком этого инструмента является то, что вам необходимо подключить хост ко всем сетям, которые вы отслеживаете, но это небольшая цена за большую информацию, которую он может предоставить, чтобы помочь диагностировать такого рода проблемы.
источник
Быстрый способ обнаружения типичных мошеннических DHCP-серверов состоит в том, чтобы пропинговать шлюз, который он обслуживает, и затем проверить его MAC в соответствующей таблице ARP. Если коммутируемая инфраструктура является управляемой, то MAC-адрес также можно отследить до порта, на котором он находится, и порт можно либо отключить, либо проследить до местоположения устройства-нарушителя для дальнейшего восстановления.
Использование DHCP Snooping на коммутаторах, которые его поддерживают, также может быть эффективным вариантом защиты сети от посторонних DHCP-серверов.
источник