Port binding в роутере что это
Случилось так, что однажды я устроился на должность начальника технического отдела в одном небольшом интернет-провайдере. Компания на тот момент испытывала некоторые проблемы технического характера, технаря найти не могли. В тот момент я как раз искал нормальную работу — за год до этого ушел с великого и могучего завода АвтоВАЗ (работал в Дирекции Информационных Систем) — кризис прижал, денег не давали. После — год работы учителем в школе (параллельно регистрировался как ИП), в общем крутился как мог. И находясь осенью в другом городе, от знакомого узнаю о том, что срочно нужен технарь. Пришел на собеседование без особой надежды, да и большого желания, и как оказалось — зря. После примерно 10-минутной беседы директор попросил выйти сегодня же. И я вышел.
Как там говорится, то все присказка была?
Сеть была построена на разношерстном оборудовании, владельцы определенно не придавали предпочтения ни одному производителю железа. Фактически это была типичная неуправляемая сеть со всеми вытекающими недостатками. Надо сказать, что на тот момент опыта работы с коммутаторами не было практически никакого. Проще сказать — вообще никакого. Не прошло и месяца, как провайдер был куплен другим. Вот здесь все и началось.
Первое, что происходит при слиянии двух провайдеров — перенос абонентской базы купленного провайдера (назову его «Б») в базу купившего (пусть будет «А»). Задача решается достаточно быстро — анализируем обе базы данных, делаем правильные запросы, перетаскиваем нужную информацию в нужный биллинг. Штампуем новые инструкции по подключению. Юридические вопросы не рассматриваю, это не задача технического отдела. Всё, монтажники работой обеспечены.
Следующая задача, с которой пришлось столкнуться — задокументировать сеть. Надо сказать, что в большинстве случаев вся документация — книжка у монтажников со схемами от руки — в какой муфте как проварены волокна. Всё. Никакой электронной документации нет. Т.к. в большинстве своем оборудование установлено неуправляемое — то понять хотя бы в каком порту что находится не предоставляется возможным. Вообще, это тема отдельной статьи, и наверное даже не одной, я же хочу кратко расписать тот механизм, который оттачивается уже пару лет, поэтому не буду сейчас заострять на этом внимание читателей.
В компании «А» трудится, и довольно давно, системный администратор. Все как положено — борода присутствует, linux везде и всюду. Собственно, с ним мы и начали нашу разработку. Изначально планы были туманными и лично у меня не вырисовывались во что-либо четкое и понятное. Были задачи — «нарисовать сеть» и поставить под наблюдение, а также навести порядок в информации об абонентах, ибо последние с заполненным полем ФИО «Мишаня» или «Нужный человек» недопустимы.
В качестве системы мониторинга у нас (компания «Б») стоял старый добрый Friendly Pinger. Понятное дело, в сети из 10 железок Pinger еще сгодится, но никак не в сети провайдера, насчитывающей сотни устройств. Все железо было передано под наблюдение Zabbix'у. А вот визуальная часть была перенесена на карту, для этого мы использовали:
- Quantum GIS — геоинформационная система,
- Карты openstreetmap — подложка,
- БД postgreSQL + расширение PostGIS — хранит устройства и связи.
Следующим шагом стало приведение в порядок адресов абонентов. Девочкам было дано четкое указание, которое они также четко не выполняли — писать адреса полностью и без грамматических ошибок. Параллельно задались вопросом использование КЛАДРа в качестве базы данных адресов. Но когда сопоставили адреса из паспортов абонентов с записями КЛАДРа, решили что не стоит. Т.к. поле адреса в существующем биллинге (UTM) было одним текстовым полем, то отследить, что вводят девчата не представлялось возможным. Пара скриптов, выборка всех адресов из БД, удаление лишних пробелов, деление адреса по запятой с пробелом показали нам все проблемные места. Все адреса, в которых использовались сокращения, ошибки и прочие проблемы были устранены. Так мы получили список населенных пунктов, улиц и домов. Было бы не логично не закинуть эту информацию в базу данных. Сказано — сделано. 3 таблицы, city, street и house были заполнены информацией и теперь можно было реализовать механизм выбора адреса абонента с возможностью дополнять эти таблицы доверенными лицами. В комплекте с другими задачами было решено создать новый интерфейс для добавления и редактирования абонентов. А к старому закрыть доступ. Задача заняло какое-то время, параллельно всплывали новые кривые адреса, все это было устранено. И в один прекрасный день проблема с кривыми адресами исчезла. И возникла другая — теперь надо было привести в порядок адреса оборудования. С этой задачей мы тоже справились достаточно быстро.
Так, в таблице абонентов и таблице устройств появилось новое поле — house_id, по которому мы получали адрес вплоть до дома. И это был серьезный шаг вперед. Стоит сказать, что параллельно с разработкой шла и модернизация сети — все известные медные перекидки были заменены на оптику, все коммутаторы заменены на коммутаторы одного производителя. Мы выбрали D-Link и не жалеем об этом.
В процессе работы с картами писались и скрипты для Zabbix'а — если устройство вдруг переставало работать, запускался скрипт, который устанавливал определенный статус устройству в БД, а соответственно изменялось и визуальное отображение устройства на карте. Все прекрасно, Zabbix работает, директора глядя на карту в браузере видят что в сети происходит — загрузку каналов, где есть проблемы с электричеством, ну и так далее (кстати, «краснота» на карте однажды стала одним из аргументов установки бесперебойного питания).
А мы тем временем шли дальше. Есть абоненты с house_id, есть устройства с house_id.
- Первое: Туманно можем посчитать, сколько абонентов на каждом коммутаторе (если устройств в доме несколько, то пока не можем);
- Второе: Для абонентов, у которых house_id совпадает с house_id коммутатора, запросом в БД можем получить координаты устройства и соответственно показать дом абонента на карте.
Проблема. Нельзя отследить — работает неуправляемый коммутатор или нет. Идем по другому пути — под наблюдение порт управляемого коммутатора, с которого неуправляемый подключен. Ага, хотя бы так. Работает. Zabbix реагирует, ругается даже. И на карте видно. Директора довольны. Мы тоже.
Ну вот, все устройства нанесены, новые сразу добавляются в БД ответственным админом. Вполне себе рабочая схема, но чего-то не хватает. Абоненты на vpn-подключении, постоянные проблемы с настройкой, монтажники тратят время, call-центр тратит время на объяснение абонентам, как им на свежеустановленной системе заново настроить подключение. Не все роутеры поддерживают pptp. Так, а почему бы не перенести авторизацию на коммутатор… Сначала идея кажется нереальной, но чем больше над этим работаем, тем яснее становится решение. Что мы знаем об абоненте? mac-адрес, на его основе выдается прописанный в биллинге ip-адрес. С этим ip-адресом абонент выходит в локалку и стучится на vpn-сервер, где далее проверяется соответствие ip-адреса, логина и пароля.
На фоне всех этих событий приводим все коммутаторы к одинаковой конфигурации, дробим сеть на сегменты (тема отдельной статьи), инструментарий для работы с абонентами растет, туда же переносится система ведения заявок от абонентов, скрипты для работы с оборудованием, и т.д. и т.п. На всех коммутаторах включаем отправку событий на сервер, начинаем следить за mac-адресами. Развиваем это направление. Определяем, что не все связи указаны верно — этот вот коммутатор подключен не с 26-го, а с 27-го порта. А вот этот абонентский mac всплывает на нескольких устройствах на абонентских портах, пишем скрипт анализа топологии сети. Работа нудная, кропотливая. На выходе получаем информацию — в каком порту какого устройства фактически подключен абонент. Заносим в БД, продолжаем анализ. Некоторые абоненты ручками прописали локальный ip-адрес, mac отследить не удалось. Вычислили, с каждым таким абонентом работали индивидуально. Закрыли и эту проблему — кому-то mac сменили, кто-то на автомат поставил. Все. Красота. Знаем какой абонент где подключен. Знаем все виланы. Каждому порту управляемого коммутатора соответствует один абонент. Добавляем в формы дополнительные поля — выбор устройства и порта. Начинаем тестировать impb (ip-mac-port binding), возникают некоторые проблемы, связываемся с поддержкой D-Link'а, решаем вместе. Добиваемся стабильности. Запускаем. Оттачиваем. Пользуемся.
Система работает уже полгода, за это время она претерпела некоторые изменения. Сейчас она работает так: при изменении устройства/порта абонента происходит создание нового конфига impb для коммутатора, с которого абонент перекидывается, и после привязки к новому устройству/порту — создается новый конфиг и для этого устройства. Папка с конфигами находится под наблюдением. Если изменился файл конфига — он автоматом заливается в коммутатор. На практике это выглядит так: монтажник звонит в тех.поддержку, просит привязать абонента к такому-то порту такого-то устройства и называет mac-адрес. Сотрудники поддержки вбивают информацию, щелкают сохранить. В течении пары секунд после этого включается порт и создается запись impb, которая хранит в себе mac-адрес, ip-адрес (назначенный абоненту) и номер порта. Таким образом, даже зная mac-адрес абонента не удастся подключиться с ним в любом другом месте. А свободные порты — выключаются. Схема работает, абонентов потихоньку переводим. Им нравится.
Вот в принципе и всё. У нас получилось уйти от авторизации на серверах. И мы чувствуем разницу. Количество заявок на ремонт уменьшилось в разы. Время подключения абонента сократилось на пять минут точно (учитывая время синхронизации между vpn-сервером и биллингом). Также решилась проблема с совместимостью оборудования — теперь не ограничиваем абонентов в выборе роутеров — пользуйтесь чем хотите. Специально не стал приводить никаких кусков кода, попытавшись объединить в одной статье достаточно широкие аспекты и показать путь, по которому мы шли. Надеюсь, что получилось.
Подводя итог своего повествования, хочу прокомментировать, зачем пишу на Хабр.
Функция IP-MAC-Port Binding в коммутаторах D-Link позволяет контролировать доступ компьютеров в сеть на основе их IP и MAC-адресов, а также порта подключения. Если какая-нибудь составляющая в этой записи меняется, то коммутатор блокирует данный MAC-адрес с занесением его в блок-лист.
Привязка IP-MAC-порт (IP-MAC-Port Binding)
Эта функция специально разработана для управления сетями ETTH/ ETTB и офисными сетями 
Для чего нужна функция IP-MAC-Port binding?
- D-Link расширил популярную функцию IP-MAC binding до более удобной в использовании IP-MAC-Port binding с целью повышения гибкости аутентификации пользователей в сети.
- IP-MAC-Port binding включает два режима работы: ARP (по умолчанию) и ACL.
Сравнение этих двух режимов показано в таблице ниже:
ARP режим
ACL режим
Плюсы
Простота в использовании и
независимость от ACL
Позволяет предотвратить несанкционированное подключение даже если нарушитель использует статический МАС-адрес
Минусы
Невозможность фильтрации в случае если hacker/sniffer присвоит себе статический MAC-адрес для спуфинга коммутатора
Тратится профиль ACL, а также необходимо продумывать целиком всю
стратегию ACL
- IP-MAC-Port будет поддерживаться коммутаторами L2 серии xStack - DES-3500 (R4 – ACL Mode), DES-3800 (R3), and DGS-3400 (R2). На данный момент IP-MAC-Port Binding поддерживается коммутатором DES-3526.
- Данный документ описывает примеры настройки IP-MAC-Port binding, например, против атак ARP Poison Routing.
Пример 1. Использование режима ARP или ACL для блокирования снифера
Шаг 1: Клиенты A и B подключены к одному порту коммутатора, клиент A (sniffer) шлет поддельные ARP
Шаг 2: Сервер C отвечает на запрос и изучает поддельную связку IP/MAC.
Шаг 3: Клиент A хочет установить TCP соединение с сервером C
Шаг 4: Т.к. клиент A не в белом листе, DES-3526 блокирует пакет, поэтому, соединение не сможет быть установлено
Пример 2. Использование режима ACL для предотвращения ARP атаки Man-in-the-Middle
Шаг 1: Sniffer C (Man in the middle) отсылает поддельный пакет ARP-Reply клиентам A и B
Шаг 2: Клиент A хочет установить TCP соединение с клиентом B
Шаг 3: Т.к. С не в белом листе, DES-3526 блокирует пакет, поэтому, соединение не сможет быть установлено
Советы по настройке IP-MAC-Port binding ACL Mode
- ACL обрабатываются в порядке сверху вниз (см. рисунок 1). Когда пакет «соответствует» правилу ACL, он сразу же отбрасывается (если это запрещающее, правило, deny) либо обрабатывается (если это разрешающее правило, permit)
- При использовании IP-MAC-Port binding в режиме ACL автоматически создаются 2 профиля (и правила для них) в первых двух доступных номерах профилей.
- Любое запрещающее правило после IP-MAC-Port binding становится ненужным, поэтому рекомендуется располагать все остальные ACL в более приоритетном порядке.
- Нельзя включать одновременно функции IP-MAC-Port ACL mode и ZoneDefense. Т.к. правила привязки IP-MAC-Port создаются первыми, и правила, создаваемые ZoneDefense автоматически после этого, могут быть неправильными.
Вопрос: Что делать, если необходимо создать еще один профиль, когда режим ACL уже включен (рисунок 2)?
– Нужно использовать команды “disable address_binding acl_mode” (Рисунок 3) и затем “enable address_binding acl_mode” (Рисунок 4)
IP-MAC-Port Binding (пример)
- Задача: Ограничить доступ на портах коммутатора по IP и MAC-адресам одновременно
- Команды для настройки коммутатора:
1) create address_binding ip_mac ipaddress 192.168.0.7 mac_address
00-03-25-05-5F-F3 ports 2
.
.
.
2) config address_binding ip_mac ports 2 state enable
.
.
.
IP-MAC-Port Binding ACL Mode (пример)
- Задача: Ограничить доступ на портах коммутатора по IP и MAC-адресам одновременно
- Команды для настройки коммутатора:
1) create address_binding ip_mac ipaddress 192.168.0.7 mac_address
00-03-25-05-5F-F3 ports 2 mode acl
.
.
.
2) config address_binding ip_mac ports 2 state enable
.
.
.
3) enable address_binding acl_mode
Приветствую! В этой статье мы поговорим о функции «MAC and IP address binding». На самом деле звучать она может по-разному, но всегда означает одно и то же – привязку IP адреса к MAC на конкретном устройстве. Для чего это нужно, примеры настройки и другие полезные советы – смотрим ниже.
Нашли ошибку? Остались какие-то вопросы? Смело пишите их в комментариях. Именно ваше мнение или вопрос могут очень сильно помочь другим людям, читающим эту статью.
Для чего это нужно?
У функции было замечено несколько наименований:
- MAC and IP address binding
- IP & MAC Binding
- IP-MAC-Port Binding
Все это создано для одного – для привязки конкретного IP адреса к конкретному MAC. А где это может применяться?
На примере TP-Link
Если вам это не нужно – не занимайтесь дурью. Обычно построение ARP-таблиц происходит автоматически и без лишних проблем. Если же хотите все-таки заморочиться у себя по одному из соображений выше, покажу вам данный функционал на примере пары моделей роутеров.
Обязательно убедитесь, что привязываемый компьютер имеет статичный IP-адрес – ведь за ним будет закреплена постоянная привязка, а в случае попытки получения этого IP другим устройством – соединение будет заблокировано.
- Переходим в веб-конфигуратор своего роутера. Как это сделать – вы уже должны знать. В противном случае с большой вероятностью вам нечего делать в этой статье. Для временно подзабывших рекомендую поискать свою модель роутера у нас на сайте, там обязательно будет описана процедура входа в настройщик.
- Ищем что-то подобное на эту функцию. У меня она называется «Привязка IP- и MAC- адресов»:
- Задаем MAC и IP адрес нашего компьютера. Сохраняем. Теперь они связаны.
Ничего же сложного нет? Главное – понимать суть этих действий. Теперь роутер знает, что в нашей сети по паре MAC-IP существует только одно устройство, а любой другое автоматически будет блокировано. Бонусом – при DHCP распределении этот IP адрес не будет присваиваться никому другому.
Разберем схему чуть сложнее на примере коммутаторов D-Link – «IP-MAC-Port Binding». То, что конкретному устройству мы можем выделить пару IP-MAC уже понятно из прошлого раздела. А что если для полной защиты мы эту пару прибавим еще и на конкретный порт коммутатора. Т.е. связка уже будет существовать в трехмерном пространстве – IP-MAC-ПОРТ.
Данный способ помогает еще гибче проводить авторизацию узлов в сети, при этом напрягая злоумышленника на большее количество действий, тем самым облегчая его обнаружение в вашей рабочей сети.
Для чистой настройки через консоль, например, здесь можно применять команды вида:
create address_binding ip_mac ipaddress 192.168.0.7 mac_address 00-03-25-05-5F-F3 ports 2
config address_binding ip_mac ports 2 state enable
Кроме типичного ARP режима здесь есть еще ACL mode и DHCP Snooping – но обычно ими интересуются или матерые администраторы, или студенты. Наш же портал для опытных домохозяек и юных эникейщиков пока не готов давать что-то чуть сложнее клика мыши. Поэтому за таким подробностями отправляю или в гугл, и в наши комментарии для развернутой беседы, а возможно и открытия новой темы – а вдруг кому-то захочется.
На этом я закончу эту статью. Основные моменты понятны, действия по созданию привязки вроде бы тоже. До скорых встреч на нашем ресурсе и хорошего вам дня!
Функция IP-MAC-Port Binding (IMPB), реализованная в коммутаторах D-Link, позволяет контролировать доступ компьютеров в сеть на основе их IP- и MAC-адресов, а также порта подключения. Администратор может создать записи («белый лист»), связывающие МАС- и IP-адреса компьютеров с портами подключения коммутатора. На основе этих записей, в случае совпадения всех составляющих, клиенты будут получать доступ к сети. В том случае, если при подключении клиента, связка MAC-IP-порт будет отличаться от параметров заранее сконфигурированной записи, коммутатор заблокирует MAC-адрес соответствующего узла с занесением его в «черный лист».
Рис. 8.8. Функция IP-MAC-Port Binding
Функция IP-MAC-Port Binding специально разработана для управления подключением узлов в сетях ETTH (Ethernet-To-The-Home) и офисных сетях. Помимо этого функция IMPB позволяет бороться с атаками типа ARP Spoofing, во время которых злонамеренные пользователи перехватывают трафик или прерывают соединение, манипулируя пакетами ARP.
Функция IP-MAC-Port Binding включает три режима работы: ARP mode (по умолчанию), ACL mode и DHCP Snooping mode.
ARP mode является режимом, используемым по умолчанию при настройке функции IP-MAC-Port Binding на портах. При работе в режиме ARP коммутатор анализирует ARP- пакеты и сопоставляет параметры IP-MAC ARP-пакета с предустановленной администратором связкой IP-MAC. Если хотя бы один параметр не совпадает, то МАС-адрес узла будет занесен в таблицу коммутации с отметкой «Drop» (Отбрасывать). Если все параметры совпадают, МАС-адрес узла будет занесен в таблицу коммутации с отметкой
При функционировании в ACL mode, коммутатор на основе предустановленного администратором «белого листа» IMPB создает правила ACL. Любой пакет, связка IP-MAC
которого отсутствует в «белом листе», будет блокироваться ACL. Если режим ACL отключен, правила для записей IMPB будут удалены из таблицы ACL
Режим DHCP Snooping используется коммутатором для динамического создания записей IP-MAC на основе анализа DHCP-пакетов и привязки их к портам с включенной функцией IMPB (администратору не требуется создавать записи вручную). Таким образом, коммутатор автоматически создает «белый лист» IMPB в таблице коммутации или аппаратной таблице ACL (если режим ACL включен). При этом для обеспечения корректной работы, сервер DHCP должен быть подключен к доверенному порту с выключенной функцией IMPB. Администратор может ограничить максимальное количество создаваемых в процессе автоизучения записей IP-MAC на порт, т.е. ограничить для каждого порта с активизированной функцией IMPB количество узлов, которые могут получить IP-адрес c DHCP-сервера. При работе в режиме DHCP Snooping коммутатор не будет создавать записи IP-MAC для узлов с IP-адресом установленным вручную.
Внимание:режим DHCP Snooping используется совместно с режимами ARP или ACL.
При активизации функции IMPB на порте администратор должен указать режим его работы:
· Strict Mode– в этом режиме порт по умолчанию заблокирован. Прежде чем передавать пакеты он будет отправлять их на ЦПУ для проверки совпадения их параметров IP-MAC с записями в «белом листе». Таким образом, порт не будет передавать пакеты до тех пор, пока не убедится в их достоверности. Порт проверяет все IP и ARP-пакеты.
· Loose Mode– в этом режиме порт по умолчанию открыт. Порт будет заблокирован, как только через него пройдет первый недостоверный пакет. Порт проверяет только пакеты ARP и IP Broadcast.
Функция IP-MAC-Port Binding (IMPB), реализованная в коммутаторах D-Link, позволяет контролировать доступ компьютеров в сеть на основе их IP- и MAC-адресов, а также порта подключения. Администратор сети может создать записи ("белый лист "), связывающие МАС- и IP-адреса компьютеров с портами подключения коммутатора. На основе этих записей, в случае совпадения всех составляющих, клиенты будут получать доступ к сети со своих компьютеров. В том случае, если при подключении клиента, связка MAC-IP- порт будет отличаться от параметров заранее сконфигурированной записи, то коммутатор заблокирует MAC-адрес соответствующего узла с занесением его в "черный лист ".
Функция IP-MAC-Port Binding включает три режима работы: ARP mode (по умолчанию), ACL mode и DHCP Snooping mode .
ARP mode является режимом, используемым по умолчанию при настройке функции IP-MAC-Port Binding на портах. При работе в режиме ARP коммутатор анализирует ARP -пакеты и сопоставляет параметры IP-MAC ARP -пакета с предустановленной администратором связкой IP-MAC. Если хотя бы один параметр не совпадает, то МАС-адрес узла будет занесен в таблицу коммутации с отметкой " Drop " ("Отбрасывать"). Если все параметры совпадают, МАС-адрес узла будет занесен в таблицу коммутации с отметкой "Allow" ("Разрешен").
При функционировании в ACL mode коммутатор на основе предустановленного администратором "белого листа" IMPB создает правила ACL . Любой пакет, связка IP-MAC которого отсутствует в "белом листе", будет блокироваться ACL .
Режим DHCP Snooping используется коммутатором для динамического создания записей IP-MAC на основе анализа DHCP -пакетов и привязки их к портам с включенной функцией IMPB (администратору не требуется создавать записи вручную). Таким образом, коммутатор автоматически создает "белый лист " IMPB в таблице коммутации или аппаратной таблице ACL (если режим ACL включен). При этом для обеспечения корректной работы сервер DHCP должен быть подключен к доверенному порту с выключенной функцией IMPB. Администратор может ограничить максимальное количество создаваемых в процессе автоизучения записей IP-MAC на порт , т.е. ограничить для каждого порта с активизированной функцией IMPB количество узлов, которые могут получить IP-адрес c DHCP -сервера. При работе в режиме DHCP Snooping коммутатор не будет создавать записи IP-MAC для узлов с IP-адресом, установленным вручную.
При активизации функции IMPB на порте администратор должен указать режим его работы:
- Strict Mode — в этом режиме порт по умолчанию заблокирован;
- Loose Mode — в этом режиме порт по умолчанию открыт.
Цель: Научиться управлять подключением узлов к портам коммутатора и изучить настройку функции IP-MAC-Port Binding на коммутаторах D-Link.
Оборудование:
Перед выполнением задания необходимо сбросить настройки коммутатора к заводским настройкам по умолчанию командой
Настройка работы функции IP-MAC-Port Binding в режиме ARP
Настройка DES-3200-28
Внимание! Замените указанные в командах МАС-адреса на реальные.Создайте запись IP-MAC-Port Binding, связывающую IP-MAC-адрес станции ПК1 с портом 4 (по умолчанию режим работы функции ARP)
Создайте запись IP-MAC-Port Binding, связывающую IP-MAC-адрес станции ПК2 с портом 14
Активизируйте функцию на портах 4, 14 (по умолчанию режим работы портов Strict)
Проверьте созданные записи IP-MAC-Port Binding
Проверьте порты, на которых настроена функция и их режим работы
Подключите рабочие станции к коммутатору, как показано на схеме 1 .
Упражнения
Выполните тестирование соединения командой ping от ПК1 к ПК2 и наоборот
Измените подключение рабочих станций. РС1 подключите к порту 14, РС2 к порту 4.
Повторите тестирование соединения командой ping .
Читайте также: