Поиск неполадки в сети (на реальных событиях)

Напишу случай один, как делал траблшутинг в сети. Кто-то удивится, кто-то посмеётся. А кто-то и запомнит, да в иной раз воспользуется советом. В общем дело было так…

Симптоматика банальная – пропал Интернет в организации. Да не у всех разом, а лишь у некоторых. Но число несчастных всё росло. Первым делом проверяю ping на свой шлюз (192.168.1.100) на виртуалке freebsd. Ответы приходят. Пингую внешку 8.8.8.8 – тишина.

Видать на шлюзе проблемы какие-то. Пытаюсь к нему по ssh подключиться – молчок. Вот так новость! Пингуется, но по ssh недоступен. Решаю подключиться к хостовой машине, на которой крутится виртуалка, по RDP. Подключился. И тут вижу сообщения в консоли FreeBSD о том, что имеется другой MAC-адрес в сети с IP как у интерфейса. Такс. Значит кто-то самовольно присвоил себе IP-адрес шлюза и заворачивает на себя весь трафик. Переписал себе MAC-адрес злоумышленника, а также MAC родного интерфейса шлюза. Значит на пинги отвечал вовсе даже и не мой шлюз, а этот негодяй.

Осталось вычислить хулигана и надавать по рукам вернуть настройки в нормальный вид. Только вот как это сделать? Большинство железяк у меня “тупые”, неуправляемые. Есть конечно и Cisco и DLink, но скорее всего дело не в них. А корневой коммутатор – тупой 3Com. Чтож, смотрим локальный кеш ARP:

> arp -a

Обращаем внимание, что напротив 192.168.1.100 MAC-адрес злоумышленника. Значит у нас заражён кеш ARP, а у тех, у кого всё ещё работает, в кеше верный MAC, но скоро он сменится на фейк и тоже перестанет работать.

Как бы вычислить хотябы направление, куда копать? В голову пришла мысль – поставить бесконечный ping и следить за arp кешем, попутно выдёргивая шнурки из коммутатора.
> ping 192.168.1.100 -t
Попутно сверяю arp -a на предмет того, что кеш ARP всё ещё заражён. Причём, если выдернуть шнурок, за которым находится злоумышленник, то ping не пропадёт – отвечать будет легитимный шлюз, но вот MAC в кеше сменится на нормальный! Этот момент я и поймал.

Хммм. Целевой шнурок ведёт на каналосвязующее оптическое оборудование, ведущее далеко-далеко. Значит “с той стороны” что-то прилетает. Отключили вообще этот шнурок, Интернет восстановился. Но это лишь часть решения. На той стороне, как я выяснил, стоит DSL-коммутатор DAS3216, подобный я однажды паял.

Звоню на тот конец, обрисовываю проблему. Как посмотреть таблицу MAC-адресов на портах DSLAM мы оба не знаем. Решаю тестить аналогичным образом – использовать протокол ARP. Только вот не ждать, пока кеш заразится (ведь это может и не произойти, если на все широковещательные ARP-ы мой легитимный сервак будет отвечать раньше злоумышленника). Решил поставить линуксовый arping на шлюз и работать с ним (благо доступ по ssh теперь был).

Как видим, это Arping больного железа. 3 пакета отправлено – 6 получено. Я зацензурил свои IP и MAC-и, там это не важно – важны окончания MAC-ов. Вот у злоумышленника был 76:58. Легитимный 01:a0.

Такого быть не должно – должен отвечать кто-то один. Но это одновременно и является хорошим “пробником”.

Решаем на DSLAM просто отрубать по одному абоненту (командой modify adsl line intf ifname dsl-[1..16] disabled/enabled). Он глушит порты, я проверяю arping. Когда перестанет отвечать негодяй, значит на этом порту он и висел – дальше найти дело техники – распиновка в шкафу и номер телефона.

Первый порт… отвечают оба. Второй порт  – отвечают оба… … пятый… восьмой… десятый… двенадцатый. Я не выдержал.

“– Отключи Uplink вообще от DSLAM!“. Коллега отключил. Отвечают оба.

Значит я пошёл где-то по неверному следу. Но если отключит каналосвязующее оборудование, то отвечает только один!

Значит проблема в каналосвязующем оборудовании. Я знаю, что туда стекается три потока и идут по оптике “далеко”. Что за потоки? Один из них Интернет – с ним и проблемы. Другие? Решаю проверить каждый в отдельности. Отключаем один поток. Отвечает только легитимный сервер! Вот оно! А что это за поток? Предоставление дополнительного канала внутренней сети. Не моя сеть, но нужно её передать дальше. Значит дело в ней? Кто-то в ней взял себе адрес, который брать не нужно.

На моё счастье в этой же сети была Cisco Catalyst 3550. Я быстро подключился к ней консольно и выдал таблицу MAC-адресов:

# show mac-address-table

Просматривая таблицу я натолкнулся на MAC злоумышленника, прямо на первом порту. Оп-па. Мне всё больше эта ситуация стала напоминать детектив или квест. Куда же ведёт этот шнурок? В другой DSL-коммутатор, DAS3224, который я однажды тоже настраивал для разделения разных сетей. Как получить с него MAC-адреса я тоже не особо понимал, но! Есть же отлаженный способ отрубания абонентов по одному и проверки arping.

Я нашёл нужного абонента. Отключил его. Всё. Квест почти решён. Отправляюсь разбираться с сетевыми настройками и, пожалуй, запрещу смену IP.

Вот такое приключение длилось… ну где-то часа два-три. Всё осложнялось распределением оборудования по различным местам (зачастую достаточно удалённым друг от друга).

Какие выводы:

1. Нужно вести базу MAC-адресов всех устройств. Хотябы раз пропинговать все и снять ARP-кеш. Чтобы можно было сравнивать. И быстро находить вероятного злоумышленника.
2. Нужно ставить “умное” оборудование в такие места, где соединяются различные потоки данных, дабы фильтровать MAC-адреса и разграничивать VLAN-ы.
3. Нужно освоить такие инструменты диагностики, как arping и научиться всё-таки работать со всем парком железа, которое расположено в ключевых местах.
4. Для админа важно знать не только принцип работы ICMP, но и таких прикладных протоколов как ARP или DNS. Пригодиться может всё, что угодно!

Как-то так. Не скрою, было интересно. Азарт настоящий.

Выяснил я причины такого действа. Глюк роутера TP-LINK. На компе стоял статичный IP-адрес из другой сети. Но роутер почему-то решил ему ещё дополнительно выдать IP по DHCP. А пул адресов DHCP в аккурат начинается с .100!

Вот такая ерунда.

Вам так же понравится:

Меняется ли MAC или IP адрес при передачи пакета по сети? Атака ARP Spoofing, перехват почты и пароля в локальной сети Общий план устранения неполадок в сети Подключение двух компьютеров к общей сети через один кабель Как происходит передача данных в локальной сети (TCP/IP) Поиск и вычистка постороннего кода на сайте