Відсутній Інтернет після оренди dhcp не поновлюється


10

Сьогодні у нас кілька машин перестали отримувати доступ до Інтернету. Після безлічі усунень неполадок, загальною темою є те, що всі вони продовжили оренду dhcp сьогодні (ми тут на 8-денній оренді).

Все, що ви очікуєте, виглядає добре після поновлення оренди: у них дійсна IP-адреса, dns-сервер та шлюз. Вони мають доступ до внутрішніх ресурсів (файли спільного доступу, інтранет, принтери тощо). Трохи більше усунення несправностей виявляє, що вони не в змозі пінг або простежити до нашого шлюзу, але вони можуть дістатися до нашого основного перемикача layer3 прямо перед шлюзом. Призначення статичного IP до машини працює як тимчасове рішення.

Однією останньою зморшкою є те, що поки що звіти надходять лише для клієнтів на тому ж самому рівні, що і шлюз. Наш адміністративний персонал та викладачі знаходяться на тому ж самому рівні, що й сервери та принтери, але телефони, брелоки / камери, студенти / wifi та лабораторії мають власні власті, і наскільки я нічого не бачив у жодному з інших вланів ще мала проблему.

У мене є окремий квиток у постачальника шлюзу, але я підозрюю, що вони вийдуть легко і скажуть мені, що проблема є в інших місцях мережі, тому я прошу і тут. Я очистив кеш-пам'ять 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 у відповіді на ping.

Моя найкраща здогадка на даний момент - це шахрайський маршрутизатор wifi в одній з наших кімнат у гуртожитку в підмережі 10.1.1.0/24 з поганим шлюзом.

... продовжили. Зараз я вимкнув принтер, який ображає право, і пінг на постраждалий хост із шлюзу просто повністю виходить з ладу.

Оновлення 2:
Я перевіряю таблиці arp на встановленій машині, шлюзі та кожному перемиканні між ними. У кожному пункті записи для цих пристроїв були правильними. Я не перевіряв кожен запис у таблиці, але кожен запис, який міг би вплинути на трафік між хостом і шлюзом, був нормальний. ARP - це не проблема.

Оновлення 3:
Наразі справи працюють, але я не бачу нічого, що я їх виправив, тому я не маю уявлення, чи може це бути лише тимчасовим затишшям. Як би там не було, я зараз можу зробити, щоб діагностувати або усунути неполадки, але я буду оновити більше, якщо вона знову порушиться.


Пінг роботи до їх шлюзу? Чи налаштовані DNS-сервери в тій самій підмережі чи деінде? Діапазон DNS працює?
Шейн Мадден

@Shane, все, що працює, і відповідає в тексті
Joel Coel

Ви сказали, що "не в змозі пінг або прослідкувати до нашого шлюзу" - це те, що пристрій пристроїв "перший скачок" або Інтернет-маршрутизатор, на який потрапляє їхній трафік після того, як він перенаправлений іншим пристроєм першого переходу?
Шейн Мадден

2
Я б запустив захоплення пакетів на одному з клієнтів, а потім пінг і простежити маршрут до шлюзу. Подивіться, які MAC-адреси відображаються в захопленні, для яких ip-адреси, а також шукайте переспрямування ICMP. Я також уважно подивився на таблицю ARP на одному з клієнтів, комутатор та шлюз, і переконайтесь, що вони виглядають правильно.
joeqwerty

1
Для уточнення: ви говорите, що на шлюзі є дійсний ARP для постраждалого хоста, а хост має дійсний ARP назад до шлюзу, але шлюз не отримує відповіді при спробі пінг-хосту? Чи потрапляють пакети ping до пристрою чи вони не перемикаються належним чином?
Шейн Мадден

Відповіді:


3

"Моя найкраща здогадка на даний момент - це шахрайський wifi-маршрутизатор в одній з наших кімнат у гуртожитку в підмережі 10.1.1.0/24 з поганим шлюзом".

Це сталося в моєму кабінеті. Апарат, який ображає, виявився шахрайським андроїд-пристроєм:

http://code.google.com/p/android/isissue/detail?id=11236

Якщо пристрій Android отримує IP-шлюз шлюзу з іншої мережі через DHCP, він може приєднатися до вашої мережі і почати відповідати на запити ARP для IP-шлюзу за допомогою свого MAC. Використання загальної мережі 10.1.1.0/24 збільшує ймовірність цього шахрайського сценарію.

Мені вдалося перевірити кеш ARP на ураженій робочій станції в мережі. Там я спостерігав проблему потоку ARP, коли робоча станція перекидалася між правильним MAC та MAC-адресою з якогось негідного пристрою. Коли я подивився на підозрілий MAC, який мала робоча станція для шлюзу, він повернувся з префіксом Samsung. Проникливий користувач із проблемною робочою станцією відповів, що знає, хто має пристрій Samsung у нашій мережі. Виявився генеральним директором.


2

Як уже обговорювалося в розділі коментарів, отримання захоплення пакетів є дуже важливим. Однак є також дійсно чудовий інструмент під назвою arpwatch:

http://ee.lbl.gov/

(або http://sid.rstack.org/arp-sk/ для Windows)

Цей інструмент надішле вам електронну пошту або просто вестиме журнал усіх нових MAC-адрес, які можна побачити в мережі, а також будь-яких змін для MAC-адрес для IP-адрес у певній підмережі (шльопанці). У цьому питанні ви мали б виявити обидві теорії, повідомляючи, що тривають триггери для IP-адрес, що змінюють MAC, або ви побачили новий MAC для маршрутизованого маршрутизатора DHCP, коли він вперше почав спілкуватися з хостами. Одна зі сторін інструменту полягає в тому, що вам потрібно мати хост підключений до всіх мереж, які ви контролюєте, але це невелика ціна за велику інформацію, яку він може надати, щоб допомогти діагностувати подібні проблеми.


1

Швидкий спосіб виявлення типових шахрайських серверів DHCP - це відстежувати шлюз, який він обслуговує, а потім вивчити його MAC у відповідній таблиці ARP. Якщо інфраструктура комутації є керованою, то MAC також можна відстежувати до порту, який розміщує її, і порт може бути або відключений, або відстежений до місця розташування пристрою, що порушує право, для подальшої компенсації.

Використання перемикачів DHCP Snooping, які його підтримують, також може бути ефективним варіантом захисту мережі від недобросовісних серверів DHCP.

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.