Добрый день, коллеги.
Опять же рискую получить несколько минусов за капитанство, но информация ниже все равно считаю полезной.
В конце концов, капитанство – это не самый низкий уровень.
Чтобы говорить трюизмы, их нужно как минимум знать.
И если в повседневной жизни и в рамках банальной эрудиции это под силу каждому, за исключением детей самого раннего дошкольного возраста (осень придет за летом), то в профессиональной сфере до этого еще нужно дорасти.
Так что гуру не обязательно смотреть на разрез.
Ну, если тебе просто весело, ты можешь.
Когда-то вашему покорному пришлось наблюдать картину, заставившую его почувствовать то же самое – даже капитанство не светит, потому что ничего не понятно.
Пришлось к одной пользовательской ссылке, которая давно не использовалась, прикрепить один хитрый девайс.
Наследие дел былых времен — отсутствие документации, каких-либо отметок на розетках и все такое, ну вы понимаете.
Без проблем.
Подключим устройство, посмотрим fdb в ядре на предмет mac-адреса, найдем свитч доступа, посмотрим на нем тот же fdb, определим порт и настроим все как нужно.
Мак известен, устройство подключено, устройство точно будет предоставлять трафик для обучения и оно должно «дойти» до ядра — ищем.
В ядре (катализатор 35хх) sh таблица Mac-адресов | я хххх.
хххх.
хххх Но самое странное, что мак загорается сразу в нескольких Вланах, плюс тот, в котором он должен быть.
Да, на устройстве они действительно тегированные, но порт на коммутаторе доступа (AT-85xx) настроен как нетегированный.
И как отмечено, он не включен ни в один Vlan. Автор интуитивно (и очень ошибочно, надо читать мануалы!) ожидал от такого «чистого» нетегированного порта поведения, аналогичного тому, что есть в cisco, когда доступ к режиму коммутатора доступ к коммутатору через VLAN xxx Но, как я уже заметил, все было напрасно.
Дальнейшие исследования на тестовой машине показали, что тегированный трафик на нетегированном порту легко принимается (если, конечно, есть соответствующий Vlan на коммутаторе) и пересылается (заведомо не обратно).
Добавив статическую запись в таблицу arp на тестовой машине для определенного IP из управляющего Vlan и подняв ее в сеть как помеченную, мы смогли легко наполнить ее чем-то большим, чем просто arp-запросами.
Это плохо.
Руководство прояснило ситуацию.
Оказывается, это совершенно нормальное поведение коммутатора, которое можно отключить командой установить переключатель инфильтрации = да Правда в мануале было написано (если я не ошибся), что по умолчанию эта команда существует и наблюдаемое на практике поведение должно быть отключено.
Но дело не в этом.
Кстати, через веб-гуи команда недоступна (вот причина незнания).
И как оказалось, реальная настройка коммутатора по умолчанию больше соответствует стандарту 802.1Q, чем информация о значении параметра по умолчанию из мануала.
ieee.org/getieee802/download/802.1Q-2005.pdf в.
48 8.6.2 Вход Каждый порт может поддерживать параметр «Включить фильтрацию входящего трафика».
Кадр, полученный на порту, который не входит в набор участников (8.8.9), связанный с VID, должен быть отброшен, если этот параметр установлен.
Значение по умолчанию для этого параметра сброшено, т. е.
отключена фильтрация входящего трафика для всех портов.
Любой порт, который поддерживает установку этого параметра, также должен поддерживать его сброс.
Параметр может быть настроен с помощью операций управления, определенных в разделе 12. Теги: #мелочи жизни #капитанство #информационная безопасность
-
Использование Карты «Тройка» Как Полиса Омс
19 Oct, 24 -
Не Настало Ли Время Для Гиков?
19 Oct, 24 -
Медицинский Вопрос №1
19 Oct, 24 -
Еженедельный Подкаст №71
19 Oct, 24 -
Аутсорсинг Интернет-Магазинов
19 Oct, 24 -
Тип Звука № 23
19 Oct, 24
