I
Так, ну все равно, один раз авторизованный на мульти-auth и все остальные считай тоже авторизованы
если нет риска, что злодей подменит мак на тот, который прошел аутентификацию, то нет
Size: a a a
2020 November 06
PG
твоей терминологии я не знаю, увы
что значит "моей"? я называю термины из CLI коммутаторов Cisco
PG
Так, ну все равно, один раз авторизованный на мульти-auth и все остальные считай тоже авторизованы
это режим multi-host, а не multi-auth
ZA
если нет риска, что злодей подменит мак на тот, который прошел аутентификацию, то нет
+ можно профилирование настроить.
BL
что значит "моей"? я называю термины из CLI коммутаторов Cisco
вендора, уж прости, ты только сейчас назвал
BL
насколько я помню, Cisco, да и другие вендоры, не очень любили 2+ маков в одном домене data. Что-то поменялось?
PG
зависит от режима 801.1х на порту
PG
в режиме multi-auth можно сколько угодно маков на порту, и каждый будет отдельно аутентифицирован
PG
назначение VLAN работать не будет, но DACL вполне, у каждого будет свой
I
+ можно профилирование настроить.
опять же, зависит от просчитанных рисков
BL
> но DACL вполне, у каждого будет свой
пока TCAM хватает
пока TCAM хватает
BL
сколько там, 256 правил на весь свитч или больше уже можно?
PG
от свитча зависит, но лучше не увлекаться, это да
I
так-то, если анально огораживаться от всего, то можно предположить, что злодей не только маки менять умеет, но и классифицирующие признаки для профайлинга
PG
я к тому, что куча юзеров за неуправляемым свитчом при внедрении 802.1х - реальность, с которой я неоднократно сталкивался
I
но если вот живой пример взять: у меня в доме стоит сигналка, она занимает два ящика, они оба соединены по ethernet
I
но внутри каждого ящика два блока, и каждому нужен отдельный шнурок
BL
я к тому, что куча юзеров за неуправляемым свитчом при внедрении 802.1х - реальность, с которой я неоднократно сталкивался
неуправляемый свитч при внедрении нужно вырезать как класс
PG
неуправляемый свитч при внедрении нужно вырезать как класс
вопрос к заказчику, увы. приходится работать с тем, что есть
I
неуправляемый свитч при внедрении нужно вырезать как класс
вендор железки не обязан раскрывать ее внутреннее устройство