Security

Так, один из важных достаточно модулей для задачи экзамена по коммутации будет посвящен безопасности в коммутируемой сети. Модуль на самом деле достаточно большой, то есть материал в нем обширный, материал из самых разных областей. И все эти области так или иначе решают одну большую задачу. Как сделать так, чтобы ваша сеть была надежна, стабильна и, соответственно, сейчас мы этот модуль будем с вами разбирать. Понятное дело, что в коммутируемой сети у нас много проблем есть, которые будут связаны с безопасностью, потому что свечей в коммутируемой сети много. Каждому абоненту нужно дать отдельный провод и, соответственно, чем больше у вас абонентов, тем больше у вас коммутаторов. Как правило, на этих коммутаторах очень мало возможностей противостоять каким-то злым атакам. То есть абонентские коммутаторы, они тупые.

И, соответственно, эти тупые коммутаторы, они, как правило, не имеют инструментов для противодействия каким-то нехорошим вещам. Перекладывать задачи по безопасности на какие-то другие свечи, которые будут более умные, чем свечи доступа, дешевые, свечи доступа, тоже нехорошо. Потому что после того, как вы подозрительный трафик пропустили в сеть, дальше уже теряются информации о том, откуда этот трафик пришел. То есть самая важная информация, из-под какого порта пришел какой кадр. После того, как вы этот кадр профорвали, уже все потеряно безвозвратно. Поэтому защищаться от большинства атак надо именно на самой первой точке входа трафика в сеть. Это вот на порту, на абонентском порту. Можно будет проверять не только, соответственно, то, что к вам пришло, не только сам кадр, но и какие-то другие свойства того, что к вам пришло. Например, порт источник – это очень важная информация, которую можно проанализировать на коммутаторе доступа, но нельзя проанализировать где-то еще.

После того, как вы кадр передали, уже нигде в заголовке не будет написано, что этот кадр пришел на абонентском порту на таком-то коммутаторе. А в то же время коммутаторы абонентские, они достаточно тупые. И, соответственно, часто бывает так, что у них вообще толком ничего нету того, что можно повключать и побороться с какими-то нехорошими вещами. Но в этом случае, да, надо будет использовать такое оборудование, которое поддерживает необходимые вам механизмы. За счет того, что коммутаторов много, поскольку портов на них много, настраивать все руками абсолютно не вариант. Поэтому чем больше мы сможем автоматизировать в части безопасности, тем лучше. То есть, естественно, не вариант абсолютно прописывать, допустим, на каждом порту, там, условно говоря, аксесс-листы. Потому что сколько этих портов, сколько этих аксесс-листов, задолбаемся все прописывать. Поэтому прописываем какие-то автоматические механизмы, которые позволят нашим коммутаторам защищаться от, ну, самых злобных вещей самостоятельно.

Чтобы мы один раз прописали какую-то одну команду, и дальше оно бы как-то само волшебным образом работало. Начинается все с физической безопасности коммутаторов. То есть, про это мы даже не говорим. Особенно, что если у вас есть доступ к консоли устройства, то фактически у вас есть доступ ко всему устройству. На коммутаторах защищаем их, прячем в шкафчике. Шкафчики закрываем на ключ. Ключ выбрасываем в речку с крокодилами. Ну и если говорим про свечи младшенького уровня, то включаем механизм No Password Recovery. Для того, чтобы, если вдруг кто-то все-таки будет подключаться к консоли и будет пытаться сбросить конфигурацию, чтобы стартап-конфик царялся целиком, а не позволял бы его перезапись. Так, далее. По поводу аксесс-листов. Мы с вами умеем прописывать аксесс-листы еще с курса ICND1 на интерфейсах, но эти интерфейсы у нас будут маршрутизируемые.

Соответственно, если у нас есть роутер, мы можем повесить аксесс-лист на вход, аксесс-лист на выход и тем самым фильтровать IP-трафик, который на роутере приходит на те или иные интерфейсы. Когда мы говорим про то, что у нас есть мультилейер-свитч, мы помним, что на самом деле мультилейер-свитч цисковский имеет в себе несколько виртуальных коммутаторов за каждый VLAN по отдельности. И плюс у него есть воображаемый роутер, который во все эти воображаемые коммутаторы смотрит отдельными воображаемыми интерфейсами. Это интерфейсы будут называться словом SVI, Switch Virtual Interface. Ну, например, интерфейс VLAN и, соответственно, у нас здесь какой? Ну, допустим, не знаю, 10. А вот это другой интерфейс. Интерфейс VLAN, допустим, 20. Ну, пример, да? То есть у нас есть воображаемый роутер, у него есть воображаемые интерфейсы, которые смотрят в воображаемые коммутаторы, которые форвардят трафик только определенного VLAN. За 10 VLAN у нас зеленый свитч, за 20 VLAN у нас желтый свитч. Но вешать аксесс-листы на сами интерфейсы SVI мы, конечно же, можем,

но мы тем самым будем обрабатывать только трафик, который проходит через SVI, то есть который проходит для дальнейшей маршрутизации на наш роутер. При этом на вход мы можем отфильтровать вообще весь трафик, а на выход, как и в любом другом случае с оборудованием Cisco, выходные аксесс-листы в IP обрабатывают только транзитный трафик. И на самом деле проверяются они в тот же момент, когда проверяются входящий трафик. То есть здесь кажется, что у нас вот трафик пришел, дальше задумался, куда бы его девать, нашел выходящий интерфейс, и вот там отдельно якобы аксесс-лист висит. Но я напоминаю вам, что на самом деле это только как бы глобальная картинка так должна выглядеть. На самом деле физически там работает CF, и CF одновременно проверяет и входящие, и исходящие аксесс-листы. То есть приходит кадр на вход, и вот он в этот момент одновременно и принимает маршрутные решения, и проверяет аксесс-листы на вход, и проверяет аксесс-листы на выход. Потому что когда примется маршрутное решение, оно примется уже сразу с указанием,

это можно туда фарвардить или это нельзя туда фарвардить. Там такой хитрый механизм, что это не три разных этапа. Проверили на вход, выполнили маршрутное решение, поиск маршрутного решения, проверили на выход. Это именно одно и то же решение на самом деле физически происходит. Поэтому если вы проверяете входящий трафик, да, его можно аксесс-листом зарубить. Но выходящий с роутера трафик, который сам роутер придумал, нельзя зарубить аксесс-листом. Трафик, который сам роутер придумал, никогда не попадет под исходящий аксесс-лист, Просто потому, что он не прошел через входной интерфейс и, как следствие, не подвергался CEF. Он придуман самим роутером и только выходит через интерфейс. И поэтому просто запомните, что выходящие аксесс-листы трафик самого роутера не обрабатывают. Но как бы там ни было, мы можем повесить аксесс-лист на вход, мы можем повесить аксесс-лист на выход на ISVI, и трафик, который будет проходить через маршрутизатор на нашем мультилейр-свиче, он будет подвергаться как одному аксесс-листу, так и другому.

Это просто самые обычные аксесс-листы, которые мы вешаем на интерфейс командой access-group. Если мы говорим про IPv6, это будет трафик-фильтр. Но это не единственные аксесс-листы, которые можно будет повесить на свиче. Во-первых, есть такая штука, как порт аксесс-листы. Это то же самое, что аксесс-листы, обычные IP-шные аксесс-листы, на которые мы вешали на интерфейсы, маршрутизируемые на роутерах, на интерфейсы SVI-ки на свичах. Но эта штука вешается на физические порты, которые коммутируемые. В конфигурации там будет точно то же самое, что и в IPv4, что и в IPv6. На свиче вы можете повесить так называемый порт аксесс-лист на вход. И, соответственно, трафик, который будет входить на ваш свич, он будет подвергаться анализу. И только после того, как он подвергнется анализу, и аксесс-лист, который висит на интерфейсе, даст свое положительное заключение, этот трафик дальше уйдет в коммутируемую среду.

Порт аксесс-листы нельзя повесить на выход. Ровно по той же самой причине, почему выходной трафик не попадает под выходящий аксесс-лист. Дело в том, что на роутере у нас есть возможность придумать какой-то трафик, который будет отправляться в сеть назначения. И он не будет проходить через вход, поэтому вот там у нас есть такая возможность отдельно сказать, что у нас есть какой-то выходящий трафик, отдельно сказать, что мы этот самый трафик придумываем. В случае с порт аксесс-листами, которые работают на коммутируемых интерфейсах, трафик на свиче может зародиться только одним образом, он может прийти снаружи. И поэтому, когда мы вешаем порт аксесс-лист на вход, вот мы можем такой трафик обработать. На выход порт аксесс-лист повесить нельзя. Просто такой возможности нет. Это, пожалуй, единственное отличие аксесс-листов, которые вешаются на марштизируемые интерфейсы и на коммутируемые. Мы видим, что на марштизируемый интерфейс можно повесить аксесс-лист на выход,

а на коммутируемые интерфейсы аксесс-лист на выход повесить нельзя. Но при этом работать эта штука будет точно так же. Она будет анализировать что угодно. То есть можно анализировать IP-пакеты. Можно IPv4, IPv6. Можно анализировать заголовки L2, то есть Ethernet. Мы можем посмотреть на кадры Ethernet, которые проходят через наш интерфейс, и сказать, что они нам нравятся или не нравятся. То есть мы можем на уровне порт аксесс-листа отбросить те кадры, которые нам почему-то не интересны. То есть, например, вы можете сказать, что мы пропускаем через наш интерфейс только пакеты, которые подходят под определенные условия. Например, 0x0800 – это IP-пакеты IPv4. 0x086D – это IP-пакеты IPv6. И 0x0806. Если вот такие вот три поля в Ethertype будут, эта штука – это ARP. Вот если такие у нас пакеты будут, то мы такие пакеты пропускаем.

А все остальные пакеты мы не пропускаем. И таким образом, если вы будете вешать такой аксесс-лист на вход, который будет смотреть на заголовок Ethernet и будет рассматривать поле Ethertype и пропускать пакеты только по определенным Ethertype, то вы можете, например, зарубить Spanning 3. Почему бы и нет? То есть у Spanning 3 нету поля Ethertype. Там у него есть LLC-вложение. В зависимости от версии Spanning 3 оно будет, либо если это стандартный Spanning 3, только LLC-вложение с кодом 42. Если это Snap-вложение, то... Если это PVST, то это будет Snap-вложение. Но в любом случае, да, вы можете сказать, что вот Spanning 3-шные кадры на порту мы просто отпрасываем, а IP-трафик, IPV4, IPV6 и плюс к нему служебный ARP мы пропускаем. Кроме того, когда у вас какой-то кадр приходит через физический интерфейс, он проходит через Pucle, Pucle его проверяет, и дальше этот кадр направляется на матрицу коммутации. Если помните, да, сравнение матрицы коммутации с волком из Нупагади,

из игрушки, которая электроника была такая, клон японских электронных игрушек. Вот. И там этот волк брал корзинку, и яйца, которые на него катились, перекладывал в разные стороны. Ну, сначала ловил кадры, а потом, соответственно, принимал решение, что с этими яйцами делать. И там еще говорили, что когда до конца этой игрушки доиграешь, покажут мультик. Ну, до мультика никто не доигрывал, потому что было очень сложно. Ну, так вот. Вот эта самая матрица коммутации, она может принимать коммутационное решение, и она может принимать решение, что куда мы этот кадр деваем. По все порты, кроме некоторых. Никогда не обрабатываем этот кадр, не отправляем его обратно в порт источника. Никогда не отправляем этот кадр в те порты, которые формируют тот же самый порт-ченнел, что и порт источника. Никогда не отправляем этот кадр в все остальные порты, кроме одного, если мы знаем, где сидит Unicast-овый MAC-пилучателя. Никогда не делаем там всякие разные другие вещи.

Никогда не отправляем в кадр все порты, которые заблокированы в Spanning 3. И еще одна штука здесь появляется. Никогда не отправляем кадр никуда, если он не попал под аксесс-лист. Вот этот вот самый аксесс-лист, который будет проверяться при коммутации, будет называться вакл, виланный аксесс-лист. И он вешается именно на процедуру коммутации. То есть ваклами вы можете сказать, что у нас есть несколько интерфейсов, которые смотрят в определенный вилан. И вот на одном интерфейсе мы говорим, мы хотим пропускать только IPv4 и IPv6. А на других интерфейсах, которые в том же вилане, мы такую штуку не вешаем. А потом ваклом мы говорим, окей, мы проверяем еще дополнительно что-нибудь. Например, что IP-шники в этих IP-пакетах, они там, не знаю, четные. То есть это два разных механизма, которыми можно проверить годность трафика в двух разных местах. Можно проверить прямо на отдельном интерфейсе физическом, а можно проверить на процедуре коммутации, что кадр, который проходит через процедуру коммутации, через виртуальный свитч, он хороший и правильный.

Соответственно, если у нас есть свитч, который просто коммутирует трафик без каких-либо, без какой-либо процедуры маршрутизации, то трафик проходит один раз через вот этот самый виланный аксесс-лист. И как следствие, соответственно, мы его можем проверить на хорошесть, на годность. Если у нас выполняется маршрутизация на мультилэйр аксесс-листе, то трафик проходит, на самом деле, через две процедуры коммутации. Один раз он проходит через процедуру коммутации вилана А, а другой раз он проходит через процедуру коммутации вилана Б. И он проходит, на самом деле, под два вакла виланных аксесс-листа. Под оба. А на роутед порт, если мы вешаем, это просто обычный IP-шный порт. То есть вот этот порт у нас, роутед порт, no-switch порт, он попадает напрямую в мозг роутера, и на него можно повесить только обычный аксесс-лист, который на входе на IP-трафейсе.

Вся вот эта штука – это только про коммутацию, про свитч порт. Таким образом, давайте со слайда сотру. Когда у нас приходит какой-то кадр на мультилэр-свитч, который нужно прокоммутировать между виланами, то есть у нас фактически будет выполняться интервилан роутинг, входящий порт у нас в вилане А, а выходящий порт, ну мы случайно знаем, что мы куда его прокоммутируем, выходящий порт у нас будет в вилане Б, то такой кадр будет коммутироваться на воображаемом роутере. Он сначала пройдет через один виртуальный свитч, потом попадет на виртуальный роутер, потом попадет на другой виртуальный свитч и выйдет через выходной интерфейс. Вот в этом случае его можно будет проверить в пяти разных местах. Сначала его можно проверить ПАКЛом, порт аксесс-листом на входящем коммутируемом интерфейсе, потом его можно будет проверить ВАКЛом на процедуре коммутации во входящем вилане, потом его можно будет проверить на СВАйке, И потом после маршрутизации его можно будет проверить на выходной SWI и на выходном вакле.

Выходной пакл уже повесить нельзя, запрещено. То есть вот 5 аксесс-листов могут повлиять на прохождение трафика через наш мультилейр-свич. И естественно в обратную сторону, когда пойдут ответные пакеты, обратные пакеты тоже будут попадать под те же самые 5 аксесс-листов, только уже, соответственно, здесь будет на входе пакл висеть входящий пакл. Дальше входящий вакл, входящий обычный аксесс-лист на входе на SWI кубе, выходящий аксесс-лист на SWI кубе, дальше опять вакл, и здесь у нас уже пакла не будет. Как выглядят обычные паклы, порт аксесс-листы, как самые обычные аксесс-листы? То есть если говорить про IP-аксесс-листы, вот мы говорим, у нас есть либо стандартный, либо расширенный, либо именованный аксесс-лист. Вот давайте именованный. Разберем IP, аксесс-лист, extended и дальше говорим IP-ACL.

Дальше пишем permit, IP, там хост туда-сюда. Ну, в общем, обычный аксесс-лист, ничего нового. То есть самый-самый простой аксесс-лист. Если IPv6 будет, ну тоже самый обычный простой IPv6 аксесс-лист. IPv6, аксесс-лист, бла-бла-бла. Там permit, deny, все, как обычно мы привыкли. И потом на интерфейсе, с коммутируемым интерфейсом подчеркну, мы вешаем команды привычными IP, access-group, дальше название или номер аксесс-листа и направление. Или IPv6, трафик-класс, название аксесс-листа и направление. То же самое, что и с маршрутизируемыми интерфейсами мы проходили на ACND1. Единственное, что можно сделать нового на коммутируемых интерфейсах, чего не было на ACND1, это сделать MAC-аксесс-лист. Конфигурация у него точно такая же, как у IP-аксесс-листов, но по смыслу можно понять, что эта штука будет оперировать заголовками L2, а не L3. Она будет смотреть на MAC-адреса в заголовке или на какие-то другие поля в заголовке Ethernet.

Ну, соответственно, MAC-аксесс-лист. Дальше указываете ключевое слово Extended, которое позволяет вам смотреть на разные поля в заголовке Ethernet. Даете какое-то название и точно так же Permit, откуда, куда. Можно дополнительные ограничения давать, например, на Ethertype. То есть можно, например, сказать, что на определенном интерфейсе мы принимаем кадры только из-под MAC-адресов, начинающихся на определенные символы. Вы знаете, что у вас, к примеру, все оборудование куплено по алфавиту от Apple, и у вас есть MAC-аксесс-лист, который говорит. Мы говорим «да» на те MAC-адреса, которые имеют OUI-шку Apple, и, соответственно, мы говорим «нет» на все остальные MAC. И вот в этом случае вы можете на уровне коммутатора сказать, что на уровне интерфейса коммутатора мы принимаем кадры только от железок Apple. По MAC-адресам мы знаем, какие у них левые части MAC-адреса. Вот, мы таким образом будем проверять это. Там можно писать в Wildcard маске.

Ну, то есть вы можете, да, достаточно гибко анализировать эти самые MAC-адреса. Если у нас есть IP-аксесс-лист, который висит на интерфейсе, то ShowIP интерфейс дальше показывает Gigabit Ethernet 01. Мы говорим «покажи нам свойства интерфейса Gigabit 01». Если бы мы это сделали на марштизируемом интерфейсе, нам бы показали простыню. И простыня была бы действительно большая. Там показали бы, какой IP-шник на интерфейсе висит, какой MAC-адрес, какой аксесс-лист, какой МТУ, какая еще разная лабуда. Ну, то есть вы ShowIP интерфейс видели много раз команду на марштизируемых интерфейсах. Но она есть и на коммутируемых интерфейсах тоже. И эта команда дает очень маленький вывод. Если вы просто повесили IP-аксесс-лист на интерфейс коммутируемый, то вот это вот все, что вам покажет, что интерфейс в API, и что вы повесили аксесс-лист на этот интерфейс, если вы его повесили. Ну и можно аналогичную команду сделать – ShowMacAccessGroup,

посмотреть на интерфейсе, висит ли MAC-аксесс-лист. Вот в нашем случае мы видим, что на вход висит MAC-аксесс-лист, на выход не висит. А когда мы вешаем IP-аксесс-лист, мы можем повесить только на вход. То есть на выход его повесить нельзя. Насколько мне известно, IPv6 – команды, которые позволят посмотреть, висит ли IPv6-аксесс-лист на интерфейсе или нет, не существует. То есть только через конфиг. Вы можете повесить на интерфейс только один пакл, но зато каждого типа. То есть отдельно можно повесить IP-аксесс-лист, можно повесить IPv6-аксесс-лист, можно повесить MAC-аксесс-лист на вход, но нельзя повесить два аксесс-листа, допустим, IP-шных. Ну, логично, да, что нам кто-то один должен сказать, разрешаем ли мы такие кадры, разрешаем ли мы такие IP-пакеты IPv4, разрешаем ли мы такие IP-пакеты IPv6. Все три аксесс-листа повесить можно одновременно,

но только при условии, что они все будут разные, разного типа. Если говорить про ваклы, ваклы будут проверять коммутацию в пределах Вилана. Там нету явного какого-то направления. Мы просто говорим, что у нас есть виртуальный коммутатор, и вот любой кадр, который через него проходит, он пытается куда-то там пройти. Вот неважно, откуда он идет и куда, поэтому классификация в ваклах идет по заголовкам для всех-всех-всех кадров. Можно проверять MAC-адреса, можно проверять IPv4. IPv6 на сегодня ваклы обрабатывать не могут. Для того, чтобы ваклы использовать, вы должны будете написать политику. И когда мы говорим слово политика, вы уже должны будете понимать, да, что речь идет про роудмапы. То есть, да, называется эта штука вакл, виланные аксесс-листы, а по факту это на самом деле роудмап. Но только роудмап, который называется вилан аксесс-мап. По сути своей то же самое, только называется по-другому. Мы пишем блоки, в каждом блоке пишем матчи и указываем действия.

Либо фарвардим, либо не фарвардим. Вот. Все, что не попало под вот этот вот самый виланный аксесс-лист-мап, он же роудмап, все будет отброшено. Вы можете указывать одно из трех действий для каждого кадра. Соответственно, редирект – это вы перенаправляете кадр куда-то в нужное вам место. Фарвард – просто разрешаете его. Фарвардинг и дроп – это убиваете кадр. Ну, дроп – название говорящие, да? Вот как будет выглядеть вакл. Соответственно, мы создаем виланный аксесс-мап. Вот он. Да, то есть в нашем случае у нас будет два блока. Виланный аксесс-мап будет называться виланмап 1. И блок будет иметь номер 10 и номер 20. Мы говорим, что в этом вилане коммутация кадров у нас будет разрешена по двум критериям.

Если там внутри будет лежать хттпшное вложение, то мы такой кадр разрешаем. Если там внутри будет лежать телнетное вложение, мы такой кадр запрещаем. Если там внутри будет что-то еще, например, лежать, то мы тоже это запрещаем. По-хорошему, здесь, конечно, надо было бы еще какой-то третий пункт сказать, что... Ну, а все остальное разрешаем. Ну, понятно, да, что там. Вы такое можете самостоятельно писать. Здесь просто в качестве примера показали, что если там HTTP, разрешаем, если TILNET, запрещаем. При этом мы указываем матчи, те же самые, которые мы указывали в курсе Rode для roadmap, ну, например, policy-based routing. Мы указываем матч IP-адрес, мы указываем матч MAC-адреса. То есть мы можем матчи делать достаточно гибкие, можем с помощью этих матчей отбирать трафик, который будет нам интересен. И можно внутри VLAN-дого аксесс-листа ссылаться на MAC-адреса, можно ссылаться на IP-адреса, но только на IPv4. К сожалению, IPv6 он матчить не умеет. Вот, к примеру, у нас есть IP-аксесс-лист, который называется HTTP. И мы говорим, HTTP – это любой трафик, который идет на 80-й порт или на 440-й порт.

По-хорошему, конечно же, надо будет еще написать здесь два правила, которые скажут, что если оно идет с 80-го порта и с 443-го порта, то тоже его фарвардить нужно. Вот, но, да, что… Здесь просто для краткости показали только такой вариант. Ну и с Телнетом то же самое, да, что делаем отдельный аксесс-лист, который Телнет тоже пермитит. И тоже по-хорошему надо было бы написать два правила. Permit TCP AnyEQ23 и Permit TCP AnyEQ23 Any. Что и туда кадры с 23-м портом туда, и обратно кадры с 23-м портом обратно будут фарвардиться. Потому что сейчас мы только син-пакеты будем пропускать, а син-плюсаки пропускать не будем. Ну и в итоге, после того, как мы написали аксесс-листы, после того, как мы написали правила VLAN Аксесс-мапа, нужно будет сказать, что вот этот вот Roadmap или Аксесс-мап, как вам больше удобно, его надо где-то использовать.

Потому что сам Аксесс-лист, равно как и сам Roadmap, он же VLAN Аксесс-мап, он ничего сам по себе не делает. Он лишь классифицирует трафик, говорит да или нет. И если да, то что с ним делать, если нет, то опять же, что с ним делать. Нам этот классификатор надо где-то заказывать. И мы указываем, что нас интересует фильтрация кадров в определенной VLAN. VLAN-фильтр. Дальше мы указываем название Roadmap'а и в каких VLAN-ах он будет работать. Вот VLAN-лист с 300 по 302. Мы говорим, в таких VLAN-ах мы будем проверять кадры на корректность. Если они хорошие, мы их пропускаем. Если они не хорошие, мы их не пропускаем. И вот после того, как вы это сделали, в вот этих трех VLAN-ах с 300 по 302, то есть 300, 301, 302, у вас будут пропускаться только кадры, содержащие IP-пакеты, идущие на либо 80, либо 443, либо 23 порты. Да, есть команда, которая покажет список всех VLAN-ах, VLAN-ах этих Roadmap'ов, show VLAN-access map.

Здесь показывается вот содержимое. И есть команда, которая покажет, какие VLAN-ы вы по факту фильтруете с помощью VLAN-ах access-map'ов. Вот мы видим, что у нас есть VLAN-map1, который фильтрует вот эти вот три VLAN-а. Так же, как и в случае с Roadmap'ами, если вы не указали что-то явное, то предполагается, что неявно, совсем не подошедшим под явное правило случится что-то плохое. То есть что-то плохое с точки зрения VLAN-ах access-map'ов – это implicit drop. Если вы не сказали, что с кадром делать, то он дропается. Если вы сказали, что делать, то он форвардится. Ну, чаще всего используется именно форвард. Дальше. Как можно защищаться от атаки вида? У нас есть некто, кто подключился к нашей сети,

и дальше он взял MAC-адрес кого-то другого, и, соответственно, с чужим MAC-ом притворяется кем-то другим. То есть у нас есть, например, вот в сети несколько узлов. Это узел один, узел другой и узел третий. И узел третий, там сидит гадкий злоумышленник. Он знает, что два первых узла обмениваются между собой какими-то полезными кадрами. И он хочет узнать, что именно там такое передается. Чтобы это сделать, он может отправить кадр из-под MAC-адреса жертвы. И тогда весь кадр, в смысле, кадр, который придет на абонентский свитч из-под MAC-адреса жертвы, он вызовет MAC-лёрнинг, и свитч будет думать, что жертва теперь сидит за другим портом. То есть с ее точки зрения случится одноразовый MAC-флаппинг, и дальше весь трафик, который будет идти на свитч на MAC-адрес жертвы, он будет приходить на порт атакующего жертвы, при этом такой кадр получать вовсе даже не будет. С такой штукой можно будет бороться с помощью двух механизмов.

Первый из них будет называться 802.1x, продвинутый протокол, при котором для того, чтобы получить доступ к коммутации кадров, вы должны будете заранее аутентифицироваться, и аутентификацию вы будете проводить из-под какого-то MAC. И вот этот MAC будет разрешен на порту, все остальные разрешены не будут. Или второй механизм, более старый порт security, который мы с вами изучали на CCNA. Порт security, помимо прочего, будет также позволять защищаться от другой атаки, которая называется переполнение таблицы MAC-ов. То есть, если у вас есть какой-то атакующий, и он знает, что у вас есть два вот этих вот узла, которые обмениваются интересными кадрами, и он хочет узнать, что там такое передается, причем он хочет перехватить и трафик компьютера А, и трафик компьютера Б. В этой ситуации он понимает, что switch нормальный, когда у него нормальная работа идет, он передает кадр только между этими двумя портами, он знает, где кто сидит, и, соответственно, на всех остальных портах трафик этой серии будет фильтроваться.

Но, если атакующий очень сильно хочет получить копии всех чужих кадров, ну или почти всех, он может мусорным трафиком из-под множества разных MAC-ов отправить кадры, мелкие-мелкие кадры, но их будет много, на свой порт, и тем самым он, если будет отправлять кадры из-под множества придуманных MAC-ов, он забьет таблицу MAC-адресов на свече. Размер этой таблицы ограничен, ограничен он, как вы помните, размером TK, и, соответственно, если у вас switch не очень мощный, не очень продвинутый, то количество записей в этой таблице будет не очень большое. Ну, в зависимости от 3750, например, да, в зависимости от конкретного шаблона, который вы используете SDM, там от 2000 до 8000, до 12000 записей в таблице MAC-адресов 3750 switch может хранить. Ну, если вы посчитаете, например, представим себе, что вот этот порт 100-мегабитный. Ну, нормальная ситуация, да, в корпоративной сети 100-мегабитный порт.

А 100 мегабит – это, соответственно, 10 миллионов байт в секунду. Если вы отправляете самые мелкие кадры, а вам как раз интересно отправлять самые мелкие кадры, то размер у этих кадров будет 64 байта. Плюс еще 8 байт преамбулы, плюс 12 байт – это интерфрейм спейсинг, который вы должны будете молчать перед отправкой каждого конкретного кадра. То есть, если вы пытаетесь отправлять просто какие-то разные кадры со случайным мусором, чтобы забить таблицу MAC-адресов на свече, то получается, что у вас будет 84 байта передаваться на каждый кадр. 84 здесь, 84 тут, 84 тут. И, соответственно, получается, что… Ну, примерно можно считать, да, что вот эти кадры будут примерно по 100 байт для ровного счета. 10 миллионов байт в секунду мы можем передать. Плюс-минус километр. То есть, 100 мегабит – это чуть больше, на самом деле, чем 10 мегабайт.

И каждый кадр будет 100 байт. На самом деле, чуть меньше – 84 байта. Поэтому мы таких кадров можем отправить 100 тысяч штук в секунду. 100 тысяч штук кадров мы можем за секунду отправить. При условии, что на свечах 37,5 мы выбрали самый жирный шаблон с коммутацией с Виланами, у нас размер таблицы MAC-адресов – это 12 тысяч записей. Мы меньше, чем за одну десятую секунды переберем всю эту, соответственно, таблицу MAC-адресов. Мы ее забьем мусором. И когда кадр будет какой-то проходить от одного свеча, от одного абонента до другого, его MAC будет забиваться на свече не позже, чем через одну десятую секунды. Если атакующий получит доступ к гигабитному порту, он сможет забить этот порт в 10 раз быстрее. То есть, через одну сотую секунды трафик до этого абонента будет идти уже через механизм Unicast Floating.

Ну и, соответственно, атакующий получит доступ ко всем кадрам, потому что свеч, который не знает, куда девать какой-то кадр, он его разбрасывает на все порты, кроме порта источника. Ну и плюс какие-то еще порты, которые он там знает. Но как бы там ни было, получится, что атакующий у нас сможет получить доступ ко всем-всем-всем кадрам, которые передаются через свеч. Да, некоторые кадры будут проходить между абонентами напрямую. Если у нас узел А отправляет какой-то кадр, и узел Б почти сразу ему в ответ что-то посылает, в этой ситуации свеч еще будет помнить, куда девать такой кадр, и он его профарвардит Unicast. Но если взаимодействие между двумя этими узлами идет все-таки не очень быстро, то атакующий может получить доступ ко всему-всему-всему трафику. Это неприятно. Бороться с этой штукой можно с помощью порт-секьюрити. Порт-секьюрити – механизм, который изначально был придуман для того, чтобы бороться и с переполнением таблицам MAC-адресов,

и с появлением неавторизованных MAC-ов на порту. Но, соответственно, сегодня порт-секьюрити для предотвращения неавторизованного доступа вести уже как-то неудобно. Просто потому, что количество MAC-адресов в сети большое. Поддерживать все списки MAC-ов на портах в актуальном состоянии очень тяжело, около невозможно. Поэтому порт-секьюрити сегодня работает в таком немножко расслабленном режиме, когда оно защищает таблицу от переполнения, но не защищает от появления каких-то левых адресов. Работа порт-секьюрити будет идти следующим образом. Вы на каждом порту будете вести белый список MAC-ов, которые допустимы в качестве MAC-ов источника. Этот белый список можно будет либо автоматически каким-то образом пополнить, ну, не каким-то, а автоматически пополнить из приходящих кадров. То есть, если вы говорите, что приходит какой-то кадр, и по каким-то причинам мы определяем, что этот кадр не вызывает нарушение безопасности, то мы MAC-источника этого кадра заносим в белый список.

Либо мы можем сказать, что мы будем ручками эти MAC-и пополнять, ну, и можно, на самом деле, и то, и другое делать. То есть сказать, что у нас на порту, например, разрешено максимум 10 адресов в этом белом списке, 4 из них мы заносим ручками, и 6 из них могут лернуться автоматически. Вот порт-секьюрити как раз так и будет работать, что если приходит какой-то кадр, который приходит от известного MAC, который уже из белого списка, он фарвардится. Если приходит какой-то кадр от MAC, который отсутствует в списке, но у нас еще есть свободные места в этом списке, потому что мы сдаем ограничения сверху на количество адресов в белом списке. Вот у нас, допустим, в списке может быть 10 адресов, по факту, только там 8. Вот мы говорим, окей, приходит какой-то кадр из-под неизвестного MAC, и мы этот MAC заносим в белый список, В следующий раз мы будем эти кадры уже фарвардить по... Не в следующий раз, даже в этот раз мы будем фарвардить просто по наличию адреса в белом списке. Но если приходит какой-то новый кадр от Mac, нового, которого в списке нету,

и записи в белом списке соответствующие нету, и места в белом списке тоже нету, то мы говорим, что случилось нарушение безопасности, с таким кадром мы дальше будем как-то бороться. Каким образом можно будет пополнять белый список? Как я уже, в принципе, сказал, белый список хранится в отдельной памяти. Это не t-cam, это не running config, то есть это отдельная прям вот область, отдельная микросхема фактически. И при перезагрузке она будет обнуляться. Поэтому если вы хотите, чтобы после перезагрузки все записи, которые были в этом белом списке, они бы как-то сохранились, вы должны будете включить так называемый режим стики. Тогда запись, которая будет пополнять белый список, она же будет копироваться и в running config. И тогда, если вы хотите перезагрузиться, и чтобы белый список у вас сохранился, вы просто сохраняете конфигу, running config изменился, вы его сохраняете, перезагружаетесь, и у вас записи из running config будут попадать в этот белый список, ну как будто они были статические.

Соответственно, статические адреса вы... Продон. Статические адреса вы занете ручками, стики попадают в конфигурацию, ведут себя как статические, хотя на самом деле они залернились динамически когда-то давно, но после этого попали в конфигу и дальше уже неотличимы по сути от статиков. Ну и есть просто динамические, которые добавляются по факту получения кадра без нарушения, и после перезагрузки вы про них забудете. В конфиге они при этом не присутствуют. Port Security включается на порту командой switchport port security. При этом, если вы ее включаете, она по умолчанию настроена следующим образом. При получении неавторизованного кадра порт целиком гасится, и максимальное количество записей на порту в белом списке будет одна запись. Не всегда это будет удобно, то есть это когда-то были очень неплохие варианты в конце 90-х, когда этот механизм был придуман, вы включали port security на порту, и у вас одна запись в белом списке гарантировала,

что на этом порту может подключиться только один узел, у которого только один маг. Сегодня относительно нормально будет получать кадры из-под нескольких разных магов, но из-под не очень большого количества. Поэтому перед тем, как включать switchport port security, вы должны будете сказать, какое количество записей в таблице белого списка будет максимальное. Плюс к тому, вы должны будете сказать, что будет происходить при срабатывании системы защиты. То есть что происходит, когда у нас приходит какой-то кадр из-под мака, которого нету в белом списке, и пополнить белый список на лету невозможно. Возможны три режима – shut down, protect и restrict. Мы с вами их обсуждали на CCNA, но чуть дальше я повторю про это. Можно будет включить port security только на порту, который работает по факту в аксессе. Или если вы говорите, что этот порт смотрит на сервер, то port security вы можете включить на транковом порту, который смотрит на конечного абонента.

Нельзя включить port security, если он работает в динамическом режиме. Если порт работает в динамическом режиме. То есть switchport mode dynamic desirable, switchport mode dynamic auto не покатит. Фиксируете на порту аксесс, либо trunk, и указываете switchport, port security, и все остальное, что там можно будет задать. Можно будет указать, как скоро записи из этого белого списка будут исчезать, если по ним не проходит трафик. Это, в принципе, неплохая идея, потому что по умолчанию записи не устаревают. Если вы полгода назад залернили какой-то Mac в белый список, то вот switch с аптаймом полгода будет помнить про тот Mac, который он видел полгода назад. По-хорошему, конечно же, вы можете сказать, что учитывая, что port security нас не защищает от атаки, вида кто-то поменял просто один раз Mac, а port security нас в реальности защищает от атаки на переполнение таблицы Mac-адресов, нет особенного смысла помнить в течение слишком долгого времени

про какие-то Mac, которые на порту виделись уж очень давно. И вы указываете, что у вас есть на этом порту aging time. Вы указываете, какой этот самый aging time будет, то есть 180 минут, простите, это 3 часа. И вы говорите, с момента последней активности Mac-адреса должно пройти 3 часа, после чего мы его из белого списка вычеркиваем. Вот. Можно будет указать aging time in activity, или можно указать aging type absolute. То есть с момента, когда в первый раз вы увидели Mac, вот он проходит 3 часа и сбрасывает этот Mac, и потом снова лернет. По умолчанию как раз именно такой режим, если мне память не изменяет. Но в любом случае aging выключен. По умолчанию вы можете его включить. Дальше. Рекомендую вам команду switchport port security включать самый последний. После того, как вы все настройки просто switchport port security со всеми пирожками сделали,

только после этого включаете сам движок port security на порту. Иначе вы получите, да, что если у вас кадры приходят из-под двух разных Mac, то есть все мы проходили через какие-то ошибки. Вот включаешь port security на порту, он сразу падает, потому что на порту кадры приходят из-под разных Mac. Сначала настраиваем port security, только потом его включаем. То есть вот эти вот команды switchport port security violation, там что-то, максимум что-то, они не включают сам движок. Они только говорят, что когда он будет работать, оно будет работать вот так. Команда showport security на интерфейсе покажет текущее состояние port security. Показывается, включен ли движок port security. В каком состоянии сейчас порт. Secure up, значит, с портом все хорошо, он в API. Есть еще secure shutdown, это порт выключен, порт disabled. Violation mode указывает, что будет происходить с портом, если вдруг у нас случится нарушение безопасности.

Shutdown, restrict и, соответственно, protect. Три возможные варианта. Protect. Ну, aging time, уже показано, что они есть. Можно включить устаревание или aging даже для тех адресов, которые вы ручками занесли в таблицу. Смысла в этом особого нет, поэтому по умолчанию эта фича выключена, и включать ее, в общем, особо какой-то разумной логики нет. Максимум MAC адресов в нашем случае 2. То есть, соответствует тому, что мы прописали в конфиге. Прямо сейчас записи в белом списке одна. Это один MAC, который мы каким-то образом, видимо, залернили. Еще одна свободная запись есть. В принципе, мы можем эту запись занять, указав какой-то статический адрес. Но прямо сейчас мы пока этого не сделали, и у нас еще есть одна запись в белом списке. Дальше. Configured MAC адресов – это сколько записей статических мы сделали. Sticky addresses – это сколько MAC-ов мы залернили, и они попали в running config, так что мы можем сохраниться, перезагрузиться.

И, соответственно, у нас эти самые стики адреса снова пополнят белый список автоматически. Мы указали команду switchportportsecurety macadres.sticky, так что это действительно будет происходить. Последний кадр, который штатно приходил на порту, штатный или нештатный в нашем случае, был из-под MAC адреса. Вот такого через двоеточие показан VLAN. И счетчик нарушения безопасности указывает, сколько раз с портом происходила какая-то нездоровая фигня. Так, далее. Showport security покажет, на каких портах как у вас настроен port security. То есть вводную табличку в нашем случае мы видим, что у нас на двух портах FastSternet.00 и FastSternet.01 включен port security. Максимум на верхнем порту два адреса, максимум на нижнем порту один адрес. И вот сейчас тут такое вот количество MAC адресов на порту по факту есть. И в случае обнаружения проблем указан Action Shutdown.

Максимальное количество MAC, которое port security может поместить в свою вот эту вот специальную хитрую память, это 4096 штук. Это количество MAC, которые сам движок port security может залернить. Но есть нюанс. Один MAC адрес на одном порту можно будет залернить на халяву. То есть у вас есть отдельно сам вот движок port security, который хранит 4096 записей. И плюс еще на каждом физическом порту один MAC можно будет лернить. Если трафик проходит через интерфейс и, соответственно, одна запись на нем лернется, то место в 4096 вот этих самых адресах уже не занимается. Но, естественно, что если у вас тут два MAC проходят через один и тот же интерфейс, то, допустим, на соседний интерфейс вот этот вот самый заимствовать у него ячейку под один MAC, возможно, мне представляется. Поэтому там вот такой хитрый механизм показывается, сколько максимальное количество записей и сколько по факту залернено. Но вот это вот сколько по факту залернено здесь показывается подозрительной ноль.

Хотя мы на самом деле знаем, что вот на одном порту как минимум один адрес мы уже залернили точно. Это как раз происходит, потому что вот здесь вот один адрес мы залернили, но минус один за счет того, что он хранится бесплатно. И получается по факту ноль. Если бы здесь вот, например, залернили два, то минус один у нас бы получилось бы один адрес мы храним на платной основе. И вот здесь вот была бы циферка единичка. И можно посмотреть, какие именно адреса залернились. ShowPortSecurityAdress показывается в каком вилане, на каком порту, какой MAC-адрес и почему мы считаем в белом списке находится. Если у нас включено устаревание, будет показано через сколько он устареет. Опять же справочно показывается, сколько записей в белом списке может быть, сколько по факту есть. PortSecurity штука хорошая, но использовать ее имеет смысл с какими-то настройками, которые защитят вас от атаки на переполнение MAC-ов.

То есть сделать так, чтобы злые люди не прислали вам 100 тысяч кадров в секунду из-под разных MAC-ов. Вот это PortSecurity может сделать хорошо. Когда-то давным-давно PortSecurity использовался для того, чтобы прямо четко в белом списке хранить только те записи, которые, только те MAC, которые по факту на порту присутствуют. Если вдруг абонент менял MAC, то, соответственно, его порт десейблился, пристреливался, и дальше с ним происходило что-то нехорошее. Вы, конечно, можете использовать PortSecurity с ограничением на один MAC-адрес и жестко прописывать эти MAC-адреса или, например, эти MAC-адреса лернить каким-то образом. Но в целом это просто не очень удобно. По поводу Restrict Protect Shutdown. Shutdown выключает порт целиком в R-Disable. Restrict пристреливает кадры, которые не соответствуют белому списку, но при этом кадры из белого списка продолжают коммутироваться. И Protect делает то же самое, только, соответственно, разница между Restrict и Protect заключается в том,

что Restrict будет гадить в логе, будет оповещать администратора, будет увеличивать счетчик нарушения безопасности, а Protect будет просто тихо дропать левые кадры, и администратору ябедничать при этом не будет. И счетчик нарушения расти тоже не будет. То есть разница между Restrict и Protect заключается в том, что если вдруг вы находитесь где-то на пляже, на Карибах, пьете пинакаладу и потом приезжаете в офис и смотрите на счетчики, что вот в одном случае вам интересно посмотреть на счетчики, интересно посмотреть, что на каком-то порту там было нарушение безопасности, а в другом вам неинтересно, и вы говорите, нет чего нам гадить в логе, ну поменялся мак, ну что же делать, ну бывает. Вот. В то же время использовать порт-секьюрити для именно определения того, что кто-то там поменял мак, это прямо очень неудобно. Если вам хочется отслеживать, у кого какой мак был,

и сделать так, чтобы вот прям вот пользователи с левыми маками проходить сеть не могли, порт-секьюрити для этого прям сильно неудобен, потому что слишком много накладных расходов, слишком много административных задач по нему есть. И для того, чтобы предоставлять доступ к коммутации только правильным устройствам, только из-под правильных маков, лучше использовать централизованный механизм, когда у вас есть какой-то сервер, есть новая железка, которая подключается к сети, и она предъявляет какое-то свое право подключиться к сети. Это право проверяется на центральном сервере. Центральный сервер говорит, да, можно пустить такую железку, или нет, такую железку пустить нельзя. Для этого нам нужно будет использовать специальный протокол, с помощью которого можно предъявить такие учетные данные. Это протокол 802.1x. И нам нужен будет какой-то внешний сервер, который будет разрешать или не разрешать подключаться к сети. Соответственно, это будет сервер с использованием протоколов RADIUS или TACACS. Сами реквизиты, которые будут предъявлять,

сами учетные данные, которые будут предъявляться, это либо какая-то учетная запись, чаще всего используется учетка Active Directory, либо можно использовать доступ по сертификатам, то есть у вас есть железка, которая подключается к свечу, показывает свой сертификат по 802.1x, свеч этот сертификат проверяет и дальше пускает устройство в сеть, разрешает коммутировать его кадры. А до тех пор, пока аутентификация не пройдет, соответственно, кадры просто не коммутируются. Два протокола, которые можно будет использовать для передачи учетных данных между свечом и внешним сервером, это, соответственно, RADIUS и TACACS. В рамках экзамена вряд ли вас будут прям мучить сравнениями этих двух протоколов, поэтому я рамочно сейчас побыстренько между ними пробегусь, посравниваю и перейдем к, соответственно, к более приземленным каким-то вещам. RADIUS. Стандартный протокол поддерживается многими вендорами. Изначально он когда-то был проприетарным,

но сейчас он по факту стал стандартом в индустрии. Используют для работы UDP. Каких-то прям совсем стандартных портов нет, но чаще всего используются порты вот такие. 1812 для аутентификации и авторизации и 1813 для аккаунтинга. В RADIUS аутентификация и авторизация будут единым процессом. То есть SWITCH посылает учетные данные на RADIUS сервер, и RADIUS отвечает, да, я верю, что это действительно тот, кто показывает учетку, учетка правильная, и он одновременно показывает, что это учетке можно. То есть аутентификация отвечает на вопрос, кто это, а авторизация, что ему можно. Из того, что к нам приходит пользователь, который называется SuperMegaAdmin, и пароль у него 123, вот следует, что аутентификация говорит, да, это пользователь SuperMegaAdmin, да, действительно у него пароль 123.

То есть мы проверили по какой-то локальной базе пользователя, мы убедились, что пароль правильный. Это аутентификация. Мы подтвердили, что это он. Но авторизация показывает, что SuperMegaAdmin, какие права у него будут, то есть что ему можно делать. Можно, например, ему войти в консоль, но с пользовательским режимом. Можно ему войти в консоль и получить доступ к привилегированному режиму, к решеточке. Можно ему подключиться к PPP, можно ему подключиться к 802.1x, можно подключиться к чему-то еще. То есть что ему можно? То есть одно дело мы говорим, да, это действительно он, а другое, что с ним можно делать. Да, можно, например, вьюшку отдать. То есть мы упускаем его в привилегированный режим и говорим, но ему можно не все, а только кое-что. В радиусе это один и тот же процесс. То есть мы одновременно говорим, и да, это он, и да, мы ему разрешаем сделать кое-что. Радиус не использует шифрование. То есть все данные, которые передаются в самом радиусе,

они не прошифрованы, но при этом некоторые протоколы аутентификации, которые радиусом будут использоваться, в частности PPP, CHAP, ну PPP нет, CHAP, YAP и прочее, они, соответственно, могут использовать шифрование сами. Сам радиус ничего не шифрует. И радиус чаще всего, да, применяется как раз для того, чтобы получить доступ к сети. Мы говорим, у нас есть свитч, к нему подключается пользователь. Пользователь хочет что-то там заиметь. Он говорит, я бы хотел получить доступ, например, 802.1x как раз тот же самый. И, соответственно, свитч говорит, окей, я пересылаю это дело на радиус-сервер. Радиус-сервер говорит, можно ли. Радиус говорит, например, да, можно. И мы отвечаем по 802.1x2 можно. Радиус как раз для этого будет довольно удобен. Если сравнивать радиус с TACACS, то TACACS это на сегодняшний момент проприетарный протокол. TACACS+, точнее говоря, проприетарный протокол, фирменный CISCO.

CISCO пытается его стандартизовать, но идет это все дело очень медленно. Когда-то это был протокол стандартный, который назывался просто TACACS, без ничего. Ну, вот TACACS+, это фирменный CISCO-вский вариант стандартного протокола TACACS. TACACS использует TCP, 49-й порт. TACACS в рамках одной и той же сессии позволяет вам выполнить отдельную аутентификацию, отдельную авторизацию и отдельную аккаунтинг. То есть можно сначала спросить, кто это, а потом что ему можно. И прямо это будут два отдельных разных вопроса. Например, это очень удобно сделать для доступа к консольке. Когда у вас кто-то к консоли подключается, говорит, я хочу получить доступ, например, к Тилнету. И мы говорим, вот он показывает логин и пароль, можно ему пустить в Тилнет в пользовательский режим? Мы говорим, да, можно. То есть это отдельная аутентификация и авторизация на доступ к консоли. А потом он говорит, я хочу набрать команду там show version.

И мы можем отдельный вопрос задать, а можно ему эту команду выполнить в рамках той же сессии? И, соответственно, нам отдельный придет рассказ, да, ему эту команду тоже выполнить можно. То есть мы можем в рамках одной и той же сессии авторизацию выполнять несколько раз для каких-то разных задач. И очень удобно это использовать как раз для управления доступом, чтобы на лету пытаться понять, кому пользователю, какие команды можно вводить. Но в нашем случае нас интересует как раз 802.1x. 802.1x использует для своей работы протокол, который называется EAP, Extensible Authentication Protocol. На самом деле вы этот протокол могли видеть в Wi-Fi. То есть наверняка в Wi-Fi вы видели там WPA2 PSK и WPA2 EAP. Вот такие вот штуки. Вы наверняка в точках доступа в айфонах, там в телефонах видели, когда Wi-Fi настраивали. И вот PSK обычно выбирают. Это пришедки, когда вы просто пароль указываете. И все, кто знают пароль, может подключиться к сети.

А вот второй вариант, это так называемый такой корпоративный Wi-Fi, когда у вас для подключения к сети надо не просто пароль показать, а логин и пароль. И дальше этот логин и пароль будут именно ваши. И на основании именно ваших логин и паролей вас пустят или не пустят в сеть. Вот та же самая история, только в проводе будет называться 802.1x. Это точно тот же самый протокол EAP, немножко обернутый в другую среду. Что можно будет с 802.1x сделать? Вы подключаетесь к сети, вы показываете свои учетные данные. Switch вас пускает в сеть. Но он помимо того, что пускает вас в сеть, он говорит, да, я тебя авторизовал, я тебя аутентифицировал, я действительно подтверждаю, что ты это ты. Я тебя авторизую на доступ к сети. Я тебя авторизую по-разному. То есть я могу тебе назначить разные VLAN. У вас есть Switch, у него есть один и тот же порт. Но когда к этому порту подключается компьютер, не знаю, Сережа, он попадает в один VLAN.

Когда к этому порту подключается другой компьютер, не знаю, Пети, он подключается в другой VLAN. А когда к этому порту подключается кто-то, кто 802.1x вообще не умеет, он попадает вообще в третий гостевой VLAN. Вот такие вот штуки можно будет сделать, опять же, с помощью 802.1x. Вы можете на порт на лету назначать аксесс-листы. К вам подключается Сережа. Вы по 802.1x проверяете, кто это. Он говорит, я Сережа. Вы проверяете, что ему можно. И вот радиус сервера вам отдает указание. Да, это Сережа. Да, его можно пустить в сеть. Авторизую доступ к сети. Но авторизую доступ к сети с вот таким аксесс-листом. Можно будет сделать доступ на основе каких-то групп. То есть, если пользователь включен в какую-то группу, вы выпускаете. Если пользователь не включен в группу, вы не выпускаете. Можно на основе времени. Что если кто-то пытается подключиться в нерабочее время, и он не администратор, то, соответственно, доступ ему блокируется. Можно будет на одном и том же порту несколько разных клиентов по Mac авторизовать. То есть, вы говорите, что вот у нас есть порт.

К этому порту кто-то подключил маленький дешевый свитчик и, соответственно, производит процедуру аутентификации на порту. И потом подключает к этому же свитчику какую-то другую железку. И вот надеется, что получится авторизоваться одним устройством, а доступ иметь к другому. Нет. 8002.1x такие штуки тоже может побороть. Если у вас используется 8002.1x в сети, то там по факту будет протокол, который будет ЯП передавать по кадрам Ethernet. Называется ЯП Overlan. ЯПол. Если у вас есть клиент, который поддерживает этот протокол, он будет называться специальным словом. Супликант. Но бывает такое, что железка не поддерживает вот этот вот самый 8002.1x супликант. Она тупая. Это, не знаю, какой-нибудь принт-сервер или что-то такое, ну, совсем простенькое. И вот на нем нету клиента 8002.1x. Он не умеет показывать свои реквизиты, не умеет показывать логин и пароль свитчу.

И для этого на свитчах Cisco есть фича, которая называется Mac Authentication Bypass. Вы просто видите, что приходят какие-то кадры, ну, совершенно обычные нормальные кадры. И у них есть Mac-адреса. И вы отправляете запрос на радиус с криками, тут ко мне пришел какой-то дурачок, он не умеет ЯП, нормальный, полноценный. Он просто посылает кадры из-под вот этих вот Mac-ов. Можно ли кадры из-под этих Mac-ов forwardить или нельзя? И вы в радиус access request'е посылаете сообщение с вот этим вот Mac-ом. Можно будет сделать какую-то более продвинутую вещь, например, использовать веб-аутентификацию. Если пользователь пришел, подключился к своим ноутбукам, не настраивал саппликант 802.1x, и ему показывается так называемый hotspot, типа скажи логин, пароль и проходи. Можно использовать порт security как альтернативу ЯП и Верлана. Но, соответственно, если вы все это дело внедряете, то вы должны будете предусмотреть, что делаем с железками, которые поддерживают 802.1x, что делаем с железками, которые не поддерживают 802.1x.

Как их аутентифицируем, по каким критериям. Сразу скажу, что внедрение 802.1x в существующие сети, как правило, это очень сильно больная вещь, потому что много разных устройств, как правило, зоопарк. Часть железок поддерживает одно, часть железок поддерживает другое. И все это дело собрать воедино, это все требует достаточно больших усилий. Но, тем не менее, это окупается. Как все это дело будет работать? У нас есть, как уже говорилось, некий субликант, то есть железка, которая аутентифицируется. Это клиент. У нас есть радиус-сервер. Это просто сервер, на нем запущен процесс радиуса. Он, возможно, подключен к Active Directory. То есть где-то там есть контроллер домена Active Directory. И у нас есть наш свитч, который будет называться аутентификатор. Или он же будет еще называться NAS. Network Access Station. Субликант запрашивает аутентификатор, говорит, я хочу с такими вот логином, паролем пройти в сеть.

Аутентификатор пересылает этот запрос на радиус, access request. Радиус отвечает либо access accept, либо access reject. И аутентификатор отправляет субликанту сообщение. Да, проходи или нет, не проходи. Вот. Более детально это рассказ. Да, что у нас субликант говорит, что я хочу подключиться к сети. Процесс на самом деле может быть инициирован как самим субликантом, так и аутентификатором. То есть аутентификатор может послать сообщение типа покажи логин, пароль. И тогда субликант будет показывать пароль по запросу аутентификатора. Но чаще всего субликант инициирует подключение. Он подключается к сети. Он отсылает сообщение я пол старт. Дальше. Свитч говорит, я согласен проверить тебя по япу. Покажи логин, пароль и проходи. То есть сообщение я по request identity. Это вот сообщение типа я согласен проверить тебя по япу.

Субликант показывает какое-то сообщение. Вот это response identity. Там внутри содержится яповское сообщение. Внутри сообщения яп response identity содержится некая информация. И там по факту содержится только хэши от паролей. Как правило, не содержится паролей в plaintext. И сам свитч при этом не ведет базу учетных записей. Он берет мясо, которое прибежало в япу респонзе и пересылает это в сообщение access request. То есть яповское сообщение, которое прибежало в респонзе, пересылается в яповском сообщении в access request на радиус сервер. Это из одного протокола мясо перекладывается в другой протокол. Сам свитч не знает, что там внутри передается. Он просто перекладывает содержимое из одного сообщения в другое. Радиус понимает, что это за яповское сообщение. Он говорит, я понимаю, что у нас вот этот вот супликант, давайте назовем его, не знаю, PC1.

Вот он, response identity, показывает внутри япа, что его зовут PC1. И мы перекладываем это сообщение. И радиус сервер видит, что прибежало сообщение от компьютера, который называется PC1. Мы говорим ему, на тебе челлендж. Тоже сообщение яповское будет внутри. Но это access challenge в обычный радиус сообщение упакованное. Мы опять же берем на свитче, перепаковываем содержимое в виде какого-то яп сообщения. Мы не понимаем, что внутри написано, но мы перекладываем это все дело в сторону яп клиента. Яп сообщает нам, что вот ты просил из челленджа и моего пароля сделать какой-то результат. Вот одноразовый результат OTP мы посылаем в сторону аутентификатора. Опять же, аутентификатор перекладывает все это дело в access request и получает access accept. Access accept переворачивается в япс уксес и у нас начинает порт нормально работать. Авторизация порта означает, что кадры из подавторизованного мака нормально коммутируются.

Если супликант принимает решение, что хватит, поработали и довольны, он посылает сообщение яп логов и, соответственно, порт обратно переходит в неавторизованное состояние. Все кадры на этом порту будут дропаться. И в случае, если мы не включаем MAP, MAC address bypass authentication, соответственно, вот в этом случае будем посылать постоянно яп реквест идентифицировать на все попытки отправить чего-нибудь. Как это настраивается? Вряд ли от вас потребуется настройка этого дела на экзамене. Но просто в общих чертах представлять, как это выглядит, вы будете должны. 802.1.x потребует работы с радиусом. Радиус включается только при наличии нового механизма работы с AAA, с авторизацией, аутентикацией и аккаунтингом. То есть указываем new model, после этого можем настраивать радиусы. Настраиваем радиус сервер, который называется radius server 1, с определенным айпишником, с определенным ключом. Если у нас несколько радиус серверов, а это чаще всего так, настраиваем второй.

Дальше создаем группу из нескольких радиус серверов, которые мы сделали. Радиус сервер 1, радиус сервер 2. И указываем вот такую вот хитрую команду. Хитрая команда будет иметь вид AAA, authentication. То есть мы работаем с аутентификацией, с тому, что мы кого-то можем куда-то, про кого-то сказать, что да, это действительно он. Дальше указываем, какую подсистему мы будем аутентификацию настраивать. В нашем случае .1x, то есть мы разрешаем доступ к сети. После чего указывается название так называемого списка. Каждая конкретная подсистема умеет работать со списками аутентификации и авторизации. И если мы редактируем список default, то все подсистемы, указанные системы, по умолчанию будут использовать именно этот список. Либо можем сделать специальные списки для конкретных отдельных подсистем. Например, если мы бы настраивали VTI-ки, то есть линию управления, мы могли бы сказать, что у нас некоторые VTI-ки будут использовать один список проверки подлинности, а некоторые другой.

И мы бы могли сделать, допустим, на одних линиях управления, сказали бы, что мы отсылаем на одни радиус сервера, а на других линиях управления мы бы сказали, а на этих линиях управления мы вообще не так как отправляем. А на третьей линии управления мы бы сказали, что у нас только вбитый логин и пароль в саму циску работает. То есть можно было бы разные способы проверки подлинности использовать. Ну вот здесь мы делаем редакцию списка методов проверки пользователя, который называется default. И по умолчанию как раз все подсистемы для проверки DOT 1X будут использовать именно его. И мы указываем, что когда у нас идет проверка учетных данных в протоколе 802.1X, мы проверку этих данных выполняем на любом сервере из группы, который называется Radius Group. А в Radius Group у нас два Radius Server, Radius 1 и Radius 2. Это мы указали, что если мы проверяем учетные данные 802.1X, то мы проверяем их вот таким образом. Но дальше надо волшебную команду сказать, что мы вообще-то запускаем сам движок проверки 802.1X.

Команда DOT 1X System Out Control. И у нас на свече начинает работать сервис проверки учетных данных. Опять же, этого недостаточно для того, чтобы у нас все заработало. С одной стороны, мы сказали, что если 802.1X будет работать, проверяем мы учетные данные вот так. С другой стороны, мы запустили сервис проверки и сказали, что если вдруг 802.1X надо будет на каком-то порту запустить, мы к этому готовы. Ну и последнее действие. Надо на порту будет сказать, что 802.1X, собственно, работать будет. 802.1X включается только на аксессовых портах. То есть на динамических портах, опять же, его включить не получится. Самих команд не будет. Указываем Authentication Port Control Auto или старый синтаксис, который будет на экзамене. DOT 1X Port Control Auto. То есть на экзамене, если вдруг будут команды, то они будут вот такие. На новых свечах Authentication Port Control Auto. Это что при подключении к этому порту надо предъявлять учетку.

Все просто. Authentication Host Mode. Здесь вы можете сказать, что если кто-то аутентифицировался на порту, то кого вы, собственно говоря, будете аутентифицировать? Либо весь порт целиком, либо только обладателя Mac, из-под которого прошла аутентификация. Host Mode Single Host. Это как раз то, что нельзя взять, воткнуть какой-то хабик или маленький тупой свитчик в порт, провести через него аутентификацию. Дальше все остальные устройства пропускать через него в надежде, что они тоже аутентифицированы. То есть если у нас есть вот такой красивый наш свитч, мы сделали здесь 802.1X проверку. У нас раньше был порт, который напрямую включался абонент. И мы говорили, вот мы показываем здесь учетку и, соответственно, разрешаем доступ для этого компьютера. А потом злой пользователь захотел подключить второй компьютер, но, соответственно, не показывать для него учетные данные. Вот он сказал, давайте здесь поставим маленький свитчик. И когда мы аутентифицируемся, мы аутентифицируемся типа целиком на порту. Но мы в этот же свитчик еще включаем второй комп, и он тоже получает доступ типа к этому же порту.

Но вот нет. Если вы указываете Host Mode Single Host, то это два разных компьютера считаются. И один компьютер аутентифицируется отдельно. Указывается, какой Mac у этого компьютера будет разрешен. И другой компьютер, если он из-под другого Mac будет отправлять данные, он тоже должен будет аутентифицироваться отдельно. И можно будет указать, что будет, если пользователь не может аутентифицироваться. Если он прямо не пытается аутентифицироваться. Это Authentication Event No Response. Вы указываете, мы пускаем такого юзера, но пускаем в определенный VLAN. Или, если пользователь не может аутентифицироваться, потому что он постоянно пароль неправильно показывает. Вот в этом случае мы можем тоже его запихать в отдельный VLAN. Как быть своим телефоном и клиентом, подключенным в него гирляндой? Ну, смотреть. Если у вас телефон поддерживает 802.1x, то пускать. Вот. Но, как правило, да, телефон у нас живут в отдельном VLAN. И вы можете сказать, что трафик пользовательского VLAN, который приходит, он у нас подвергается 802.1x.

И тогда вот в пользовательском VLAN, который из Switchport Access VLAN, вы выполняете 802.1x аутентификацию. Если у вас телефон при этом сквозной, и он не поддерживает 802.1x, то просто в телефонном VLAN, который у вас помечен как VLAN, вы эту аутентификацию не включаете. Здесь, да, здесь вы можете указывать, для каких VLAN вы можете это делать. В каких VLAN вы выполняете аутентификацию, а каких нет. Так. Что еще здесь можно будет сделать? Если у вас модные новые свечи 3850 или что-то там 9-тонники каталисты, то вы можете развернуть систему, которая называется Cisco ThrustTech. Она предполагает, что у вас есть какой-то механизм централизованного управления. И ThrustTech будет заключаться в следующем.

Кадры, которые будут отправляться из-под обычных пользователей, на входе в вашу защищенную сеть, в периметр вашей сети, они будут получать специальную метку. То есть, помимо того, что бывают всякие метки 802.1Q и прочее, вы можете дополнительно к этим меткам еще хитрую метку вешать, которая будет называться метка SecurityGroupTag. И вот эта метка аутентификации будет указывать на то, кто этот вообще пакет отправил. И дальше коммутация может вестись уже на основе этих меток. То есть, вы можете, допустим, сказать, что кадр, который вы получили на порту, который смотрят на айтишников, это кадра с меткой, например, 3. И дальше вы отправляете эти кадры по таблице коммутации. И на каждом свитче вы можете сказать «Ага, я вижу метку 3». То есть, это означает, что эта метка пришла от айтишников. И в какой-то момент вы можете сказать, что у нас есть какой-то порт, и на этом порту нельзя отправлять кадры с меткой 3.

То есть, мы такие кадры будем блокировать. Или вот здесь, например, у нас какой-то хитрый сервер есть, бухгалтерский, куда айтишников пускать нельзя. На порт айтишный пускать их можно, а на порт бухгалтерский нельзя. Это фактически как фильтрация на основе полей заголовка кадра, но, соответственно, просто специально предназначенные для этого поля, которых изначально в обычных кадрах нет. Это специальное поле, вот это вот Security Group Tag, куда можно писать какие-то метки аутентификации. На входе в сеть вы их проставляете, на выходе из сети вы их снимаете. Для разворачивания инфраструктуры TrustTech вам понадобится какой-то софт, который умеет управлять централизованно всей инфраструктурой. То есть это фактически уже начинается такое облако белогривая лошадка, где у вас потребуется либо APIC EM, но я не уверен, что он с TrustTech на самом деле работает, либо называется это, как оно называется-то, не Cisco DNA, да, Cisco DNA.

Cisco DNA продукт, это, соответственно, вот как раз штука, которая с этими самыми Security Group Tags может работать с TrustTech. Еще одна штука, которую можно будет использовать, она уже более стандартная, это MacSec. По сути своей это тот же IPsec, только для кадров Ethernet. То есть в IP мы можем взять и кадр зашифровать с помощью IPsec, и по этому кадру будет видно, что он зашифрован. И в какой-то момент мы можем зашифровать кадр, в какой-то момент мы можем расшифровать кадр. Вот в MacSec, да, та же самая история. Так, про метки. Да, метки, метки, метки. Если вы будете использовать метки Security Group Tag, то эти метки можно будет либо на уровне портов коммутатора вешать, либо на IPшники какие-то, либо использовать эти самые метки при аутентификации 802.1x, как раз что и рекомендуется делать.

Если вы разворачиваете Cisco DNA, то вы как раз используете инфраструктуру 802.1x, и все ваши коммутаторы, они будут просто говорить, что при подключении нашего пользователя, мы говорим, что вот у тебя будет порт такой-то, в таком-то вилане, и метки у тебя будут вот такие. И дальше на основе этих меток вы можете писать аксесс-листы, просто обычные, обычнейшие аксесс-листы, вот типа deny TCP, tag 99 any, tag куда-то там, FTP 14. Вы указываете на уровне кадра, соответственно, откуда и куда он идет, и вот вы можете проверять метки в каждом конкретном кадре. Эти самые метки могут передаваться в заголовки, которые называются Cisco metadata, то есть это дополнительный заголовок, который будет Cisco проштамповывать, и в них будут эти самые метки писаться. Это будет заголовок использовать такой же механизм, как 802.1x,

просто там будет добавляться еще одно поле, еще два на самом деле поле. Одно поле будет указывать на то, что внутри лежит, и другое, соответственно, будет указывать на то, что такой заголовок циска метод-данной вообще существует. И вот у него будет хорошо заметный Ethertype 8909. Если вдруг у вас какие-то транзитные свечи не поддерживают вложения 8909, то вы можете использовать дополнительный протокол, который называется Security Group Tag Exchange Protocol, который будет просто на свечах нацистских синхронизировать базу этих самых меток, которые будут не проставляться внутри каждого конкретного кадра, но они будут как бы в кавычках назначаться на каждый конкретный кадр при транзите. У нас есть какой-то свитч, он не умеет работать с inline-tagging, поэтому кадр, который будет приходить, это будет просто самый обычный кадр, но в этом кадре у нас есть заголовок IP, заголовок Ethernet,

и, соответственно, когда мы этот кадр фарвардим, мы его внимательно изучаем, и, соответственно, мы эту метку на лету на него, ну, воображаем, вспоминаем, какая она должна быть. И у нас будет с помощью вот этого самого протокола SXP пополняться некая табличка, которая указывает, да, кадр, который прибежал, в нем никаких специальных меток нет, но если бы там была метка, какая она была бы быть. По поводу, соответственно, вот этих самых security group access листов, они очень быстро работают, то есть они работают на wirespeed, если вдруг вы будете их использовать, то вот, как у вас есть производительность свитча, там 48 гигабитных портов на нем есть, вот все 48 гигабит вы можете фильтровать с помощью этих access листов. Производительности потери не будет, это очень, конечно, крутая штука. Но работать с этой штукой неудобно просто потому, что она требует для своей работы продвинутую инфраструктуру, которая далеко не у всех есть, и новые свитчи, которые, опять же, тоже не у всех есть. MaxSec – штука более популярная, хотя бы потому, что он есть намного чаще,

встречается чаще. И, соответственно, если мы используем MaxSec, то он позволит нам кадры зашифровать. Можно будет использовать MaxSec в разных сценариях. Соответственно, вы можете сказать, что у нас есть пользователь, он подключается к какому-то свитчу, этот свитч подключается к какому-то еще свитчу, и этот свитч подключается к какому-то еще свитчу, и дальше у нас тут есть какой-то другой сервер, с которым у нас ведется взаимодействие. И вот в какой-то момент мы хотим пошифровать наши данные. И возникает вопрос, где мы можем пошифровать это? Традиционно считается, что шифровать надо отдельно данные в каждом Point-to-Point-Link. То есть у нас вот здесь данные будут шифроваться, и, соответственно, здесь они шифруются, здесь они расшифровываются. Если мы потом дальше эти данные будем передавать, то мы их снова здесь вот зашифруем, снова здесь вот расшифруем. И мы в каждом отдельном линке их должны будем заново шифровать, заново расшифровывать. Идея изначально была именно такой.

Но она требует, естественно, чтобы на каждом транзитном свитче у вас была бы поддержка этого самого Максека. Если где-то у вас Максека нету на свитче, то сама идея уже становится нереализуемой. В то же время вы можете, если хотите, шифровать не везде. Вы можете сказать, давайте мы кадры будем отправлять зашифрованные с помощью Максека, и это будут просто же самые обычные кадры. Вот мы можем здесь вот начинать зашифровывать кадры, отправлять их по сети, и, соответственно, расшифровывать их уже на конечном получателе. Такие штуки тоже возможны. То есть, если вы между супликантами, между Максек узлами будете шифровать данные в пределах одного широкопричательного домена, это все, в принципе, будет нормально работать. Все зависит от того, что именно и почему именно вы хотите шифровать. Если вы хотите шифровать трафик между всеми супликантами, вообще всеми, всеми, всеми, и вы не хотите, чтобы нигде в сети кадры не передавались в открытном виде, ну, тогда проще всего просто с помощью какой-нибудь политики групповой раздать на все абоненты указание, что, ребята, мы используем Максек.

Проблема здесь будет очевидна, что супликанты, как правило, Максековские, их полторы коллеги всего. То есть, на обычных абонентах, как правило, супликантов Максек просто тупо нету. Поэтому вы, как правило, просто не можете на обычном абоненте сказать, давайте шифровать все кадры, которые у нас будут. Есть ферменный цисковский клиент Максековский, но если у вас оборудование не поддерживает ни вот этот ферменный цисковский клиент, ни какой-то там стандартный клиент Максека, у вас будет какая-нибудь винда старая, все, вы приехали, вы не можете включить шифрование. Поэтому в таких ситуациях вам придется использовать шифрование где-то вот между свечами. Если у вас есть недоверенный линк, вы в этом недоверенном линке хотите передавать кадр, например, вам провайдер предоставляет L2 канал. Вот он говорит, я тебе даю темную оптику, зум даю, что это темная оптика. И вы не доверяете ему, вы говорите, ага, мы сейчас будем думать, что это темная оптика, а ты там таб-перехватчик поставил и будешь все кадры наши читать. Вот в этом случае вы с одной стороны включаете Максек,

с другой стороны включаете Максек, и все данные, передаваемые в этом проводе, у вас будут по факту шифроваться. И пусть зумышленник или провайдер перехватывает кадры сколько угодно, они все равно все зашифрованы. Максек предполагает шифрование данных с помощью достаточно, на сегодняшний день уже не сильного алгоритма АЕС-128. Плюс к тому он не использует Message Authentication Codes, то есть он хэшами не подписывает кадры, он только их шифрует. Используется там симметричное шифрование, если ключ уйдет, то, соответственно, уйдет. Дальше. Формат кадра будет немножко хитрый, соответственно, у нас есть какой-то оригинальный кадр, который мы хотим передать с каким-то payload. И мы для того, чтобы зашифровать данные, добавляем свой Максековский заголовок, и дальше все после этого заголовка начинаем шифровать. В конце передается Integrity Check Value, ну, фактически чек-сумма,

в которой показывается, что действительно данные, которые передаются, они правильные, они действительно зашифрованы правильным образом. Если вы хотите передавать внутри Максека какие-то данные, которые будут, ну, например, передавать тут же самую метку CGT, то это совершенно отдельно делается независимо, и у вас будет передаваться отдельно 802.1 кюшный кадр, то есть вот это вот, это просто мясо оригинального незашифрованного кадра, которое было зашифровано, вот там внутри и 802.1 кюшная метка, и Cisco metadata, то есть те самые CGT, например, вот они, и дальше оригинальный EtherType, и дальше вот мясо кадра, которое изначально было, то, чего все и предполагалось. Ну вот, да, такой вот механизм, если вы хотите его использовать, пожалуйста, используйте. На 37,5-х свечах он есть. Не то, чтобы прямо уж он был очень мощный, но он работает действительно довольно быстро. За счет того, что алгоритм не очень мощный, а Е128 зашифровать данные можно довольно в большом объеме.

Но, конечно, не надо думать, что он зашифровать может вообще прям все в бешеных количествах. Давайте теперь поговорим про то, что у нас будет передаваться внутри этих кадров, которые мы хотим, собственно говоря, защищать. Там у нас, как правило, будет бегать протокол IP, то есть либо IPv4, либо IPv6, и можно будет встретиться с атаками на этот протокол IP. Опять же, история заключается в том, что если вдруг у нас есть какая-то ситуация вида подмены IPшника, когда злоумышленник отправляет кадры, содержащие IP-пакеты из-под неправильного IP-адреса, то после того, как мы такой кадр дальше профарвардим в сеть, например, на distribution уровень, отследить ситуацию со сменой IPшника будет уже очень тяжело. Мы уже не сможем отличить кадры из-под правильных IPшников и кадры из-под неправильных IPшников. Поэтому это, опять же, нужно делать на абонентском порту.

Здесь нам в помощь придет механизм, который мы с вами разбирали несколько, наверное, модулей назад. Это механизм DHCP-снупинг. Если у нас есть абонент, который получает IPшник по DHCP, то мы можем ввести базу, кто с какого порта, с какого мака, какой IPшник получил, и дальше на основе этого механизма, этой таблички, принимать коммутационные решения о фарвардинге или нефарвардинге кадров, которые приходят из-под определенного интерфейса, из-под определенного мака, из-под определенного IPшника. То же самое можно сделать в IPv6. Но в IPv6 у нас добавляются немножко сложности, связанных с тем, что там есть механизм слаг, там есть механизм автоматического назначения IP-адресов, и, в общем, непонятно, кто какие IPшники будет получать. Там есть DHCP в разных вариациях, там есть этот самый DHCP префикс delegation. Ну, в общем, есть что позащищать в IPv6 отдельно от IPv4.

Так, начнем с IPv4. Так, да, вот как раз атака на переполнение, на неперенеполнение, на отравление кэша ARPA будет заключаться в том, что если у нас есть свитч, и этот свитч обслуживает трех абонентов. Один абонент, соответственно, 1002, другой абонент 1001, и третий абонент атакующий 1003. Атакующий хочет сделать так, чтобы, соответственно, трафик проходил через него. Ему очень интересно, чем обмениваются между собой узлы 1001 и 1002. свитч, в общем-то, в норме, естественно, когда у нас будет работать фарвардинг трафика между абонентами первым и вторым. Это у нас второй, это у нас первый. Соответственно, позволит фарвардить кадры друг другу между этими абонентами, и узел 1 выясняет, какой IPшник у узла 2, там, 1002, выясняет ARPA его MAC-адрес, и понимает, что кадры надо отправлять на MAC,

ну, какой-то вот ААА. То же самое второй узел выясняет MAC-адрес первого, и IP-пакеты внутри кадров Ethernet отправляют, соответственно, на MAC-адрес сразу получателя. Если у нас есть атакующий, который ему интересно, что там передается между этими двумя узлами, атакующий может спамить всех соседей ARPA-ми с чужими IPшниками и своими MAC-ами. И, соответственно, он будет постоянно отправлять так называемые gratuitos ARPA, и он будет постоянно говорить, что у меня с моим MAC-ом IPшник вот такой, у меня с моим MAC-ом IPшник вот другой. Рано или поздно эти ARPA придут в ответ на что-нибудь, то есть либо кто-то скажет, у кого из вас IPшник 1001, и ему сразу придет ответ 1001 у MAC-а CCCC. И, соответственно, все IP-пакеты, приходящие на MAC-адрес атакующего, они, соответственно, будут перехватываться. А дальше атакующий, если захочет,

он может из-под своего уже MAC-адреса отправлять в сторону другого узла эти же самые IP-пакеты. И таким образом узел 1, да, он сможет получить пакеты, перехваченные атакующим, и даже не догадываться о том, что эта атака произошла. То есть он сможет в такой ситуации получить оригинальные данные, которые ему отправлялись, но, да, при этом атакующий будет видеть эти данные. Может быть такое, что атакующий перехватит сразу обе сессии. По факту трафик между узлом 1 и 2 будет ходить вообще целиком через атакующего. То есть у нас трафик будет ходить вот так вот, дальше он будет пересылаться вот так вот, и, соответственно, ответы будут бежать вот так. Эта штука будет называться атака man in the middle, когда у нас атакующий перехватывает все какие-то данные и, может быть, даже каким-то образом их модифицирует. Ну, то есть, что именно он сможет с этим сделать, это уже остается за пределами нашего курса,

но, в принципе, натворить дело он может нам довольно знатно. Естественно, мы хотим бороться с такими ситуациями, и для того, чтобы бороться с ними, нам нужно будет использовать какие-то механизмы защиты протокола ARP. В цисках есть штука, которая называется Dynamic ARP Inspection, которая использует базу DHCP-снопинга или использует какую-то свою отдельную базу для того, чтобы проверять, может ли из-под определенного интерфейса приходить ARP-ответы на определенные IP-шники. То есть, мы на каждом интерфейсе говорим, будет ли работать Dynamic ARP Inspection или не будет. Если мы помечаем интерфейс как доверенный, то в этом случае трафик ARP не проверяется. Мы говорим, все, что из-под этого интерфейса приходит, все заведомо правильное. А вот если мы помечаем интерфейс как недоверенным, то все ответы ARP из-под этого интерфейса будут проверяться инспекцией MAC-ов и IP-шников внутри них. И, соответственно, можно использовать базу DHCP-снопинга. Если вы знаете, что у вас в сети везде DHCP используется,

либо если у вас где-то есть статические адреса, можно статику прописать, сказать прямо в самой базе вот этого самого Dynamic ARP Inspection, что некоторые адреса прописаны ручками, это нормально, они не получают адресов по DHCP, но, тем не менее, все нормально работает. И либо можно будет использовать так называемые ARP-акцесс-листы. То есть, вы привязываете IP-шники к MAC-ам и делаете это в акцесс-листе. И, соответственно, у вас это будет удобно использовать там, где база DHCP-снопинга не используется. Оба механизма могут работать одновременно. Сначала срабатывает ARP-акцесс-листы, потом база снопинга. Как это будет выглядеть? Если мы настраиваем базу DHCP-снопинга, то мы просто говорим, что у нас в определенном интерфейсе работает DHCP-снопинг. То есть, мы включаем DHCP-снопинг глобально, мы включаем DHCP-снопинг в каком-то VLAN. И дальше мы рядышком в этом же VLAN включаем IP ARP Inspection.

Дальше говорим в каком-то VLAN. Вот мы включаем Dynamic ARP Inspection. И если у нас будут какие-то интерфейсы, из-под которых ARP могут приходить из совершенно непредсказуемых адресов, ну, например, у нас есть какой-то сервер, не сервер, а роутер, и на этом роутере работает ProxyARP. Вот в этом случае мы можем сказать IP ARP Inspection Trust. То есть, на определенном интерфейсе ARP могут приходить совершенно любые, не надо их проверять. Если у вас есть какой-то узел, на котором IP-шник прописан жестко, руками, и, соответственно, в базу DHCP-снопинга он штатно не попадает, вы можете ручками добавить запись в базу DHCP-снопинга. Команда будет там немножко странная, она не из конфига выполняется, а из решетки, потому что база снопинга – это не конфигурация, это отдельная память, так же, как PortSecurity использует отдельную область памяти. Вот DHCP-снопинг использует отдельную область памяти, и поэтому эта команда добавляет в отдельную область памяти адрес,

и она не сохраняется после перезагрузки. Поэтому вы должны будете ее пополнять каждый раз ручками. Это неудобно. И IP DHCP-снопинг – вы указываете новый байндинг, указываете MAC-адрес, указываете, в каком Вилане, какой IP-шник, на каком интерфейсе у вас будет жить, ну и с каким сроком годности, так скажем. Вот эти вот ручные записи добавлять очень неудобно, именно потому что у них есть срок устаревания, и вам придется, если вы укажете срок устаревания 3600 секунд, это один час, просто каждый час на вашу отсыску заходить и каждый час ее переконфигурировать. Это прям очень неудобно. Если вы хотите сказать, что у вас есть статический узел, у которого статический MAC прописан, не MAC, а IP-шник прописан, удобнее использовать ARP-акцесс-листы, которые конфигурируются именно в конфиге, в running-конфиге, после перезагрузки они сохраняются, и для этого мы должны будем сделать так называемый ARP-акцесс-лист, даем ему название, и дальше указываем permit IP, хост такой-то,

MAC, хост сякой. То есть, какие IP-шники с wildcard-масками и какие MAC-адреса у нас могут соответствовать. Обычно прописывается хост IP-шник и хост MAC-адрес, но вы можете сказать, что у определенного IP-шника MAC-адреса могут быть любые, допустим, начинающиеся на определенную OOI-шку. Ну, да, чаще всего используются статические привязки хостами. И дальше нужно будет этот static access-list, static ADR-ARP, привязать к механизму IP-ARP-inspection. Мы указываем IP-ARP-inspection, фильтр static ADR-ARP, и потом указываем, в каком вилане мы включаем фильтрацию, и слово static указываем, что эта штука используется вместо базы DHCP-сноупинга. Если не указать, то будут работать вместе. То есть, IP-ARP-inspection фильтр указывает, что мы сначала проверяем по static ADR-ARP, а потом используем DHCP-сноупинг. Как проверить,

что dynamic ARP-inspection работает? Ну, в общем, что IP-ARP-inspection и всякие его подключи. Из интересных, на каких интерфейсах включено, какая статистика, что заблочено, что не заблочено, ну и что IP-ARP-inspection лог показывает последние действия с ARP-inspection. На экзамене нужно будет знать, что dynamic ARP-inspection существует. Вряд ли от вас потребуется команда по настройке, но, тем не менее, знать, что эта штука есть, оно, конечно, нужно. В реальности я вам рекомендую dynamic ARP-inspection использовать, потому что оно избавляет от множества неприятных вещей, связанных с протоколом ARP. То есть, если вы его включаете, главное не забыть, что вы его включили, у вас, соответственно, так и на ARP становится уже невозможно. ARP-ответы будут приходить только из-под тех IP-шников, которые действительно разрешены администратором. Либо DHCP-сервер разрешил, либо администратор разрешил в явном виде.

Второй механизм, который будет использовать базу снопинга, это IP-source-гард. Он будет проверять у входящих IP-пакетов на интерфейсе IP-шник источника. Может также проверять и MAC-адрес, но по умолчанию этого не делает. Опять же, надо будет включить снопинг. Снопинг будет пополнять базу снопинга, и дальше мы по этой базе будем проверять IP-шники во входящих пакетах. Если вдруг, опять же, статически какой-то адрес будет прописан, то нужно будет статическую привязку сделать отдельно. На интерфейсе указываем, что у нас есть недоверенный порт no IP DHCP-snooping-thrust, и дальше указываем команду IP-verify-source. То есть по умолчанию как раз все интерфейсы, кстати, недоверены, но здесь просто в явном видео показано, что интерфейс должен быть недоверенным, чтобы там verify-source включать. И verify-source будет как раз использовать базу снопинга. Если вдруг у нас в базе снопинга какого-то IP-шника нету,

потому что он статический, значит, надо ручками в базу занести эту запись. IP-source-binding. Указываем, какой MAC-адрес, в каком вилане, какой IP-шник, на каком интерфейсе будет жить. Можно будет показать show IP-verify-source на нужном интерфейсе. Вот покажется, какие у нас IP-шники известные, то есть либо ручками занесены, либо с помощью D-HCP-снопинга зарезолвились. И, соответственно, кто у нас на каком порту будет разрешен. Здесь хорошо видно, что MAC-адреса не прописаны в базе снопинга по умолчанию. Ну, то есть не прописаны в базе IP-source-гарда по умолчанию. То есть нужно отдельный механизм использовать для того, чтобы эти MAC-адреса появились. И фильтрация идет только по IP-шникам. На самом деле на порту при этом создается пакл, порт-аксес-лист. Если он у вас прописан был, то, соответственно, будут сложности, чтобы два пакла одновременно бы работали. То есть либо вы пакл ручками прописываете, либо вы используете IP-source-гард. И тогда пакл вы на интерфейс

IP-аксес-лист повесить не можете. И эта штука не работает с private-vlan, которые мы с вами еще не проходили, но которые дальше будут. Вот. Если вы хотите MAC-адрес проверять, то вам нужно будет включить порт-секьюрити на порту. Опять же, нужно будет просто иметь эту самую базу порт-секьюрити. Не обязательно вы должны будете как-то остро зажимать этот порт-секьюрити, но вы должны будете ввести базу белого списка вообще глобально. И тогда у вас тип фильтра меняется на IP-MAC, и, соответственно, MAC-адреса здесь начинает тоже фигурировать. Чтобы это произошло, нужно включить порт-секьюрити и нужно сказать IP-верифай-сорс-порт-секьюрити вместо просто IP-верифай-сорс. То есть, что SourceGuard у вас начинает работать в паре с порт-секьюрити, начинает проверять и то, и другое. Опять же, рекомендуется к использованию. Если вы знаете, что у вас есть какие-то порты, которые, за которыми сидит, например, администратор, и он может постоянно менять IP-шники

по своему усмотрению, тогда этот порт следует пометить как доверенный. На портах обычных пользователей включаете IP-верифай-сорс-порт-секьюрити и проверяете, что пакеты, которые приходят из-под этих пользователей, они в точности соответствуют тому, из-под какого MAC-а, из-под какого на какой IP, в смысле, из-под какого MAC-а запросы, на какие адреса были получены по протоколу DHCP. Очень удобная вещь. Если у вас она поддерживается, включайте. Что касается IPv6, там по большому счету все то же самое. То есть, есть механизм DHCP-V6-снупинг, который будет проверять, что адреса получены по DHCP-V6-stateful. Если вы используете IPv6-MD-снупинг, Neighbor Discovery-снупинг, он будет проверять, проверять, что вы отдаете указание, что у вас вот такой вот MAC-адрес в ответ на запрос

у кого из вас такой вот IPv6-ой адрес. То есть, это аналогичный механизм Dynamic Arp Inspection. IPv6-Rayguard это указание на то, что из-под пользовательских портов нельзя рассылать роутер-анонс, роутер-адвертайзменты, потому что, если у нас есть порт, который роутерный, оттуда приходят указания, мы сидим все вот в такой вот сети, придумывайте себя и пишники из этой сети. Если у вас пользователи начинают анонсировать свои префиксы, то, соответственно, у вас другие пользователи будут получать какие-то левые адреса и ни к чему хорошему это не приведет. Поэтому RA-guard это вы указываете, какие порты недоверенные и запрещаете приемы рашек оттуда. Sourceguard, ну, аналог, да, Sourceguard, только проверяет он по базе Neighbor Discovery, а не по DHCP-снопингу. И, соответственно, есть еще разновидности IPv6 Sourceguard. Это префикс guard. Вы знаете, какие префиксы у вас на порту есть, вот, и вы

можете сказать, что вот если мы получили по DHCP-6 префикс, или если мы получили префикс путем назначения IP-шника вручную, и мы, соответственно, рассылаем эти префиксы в роутер-анонсментах, то мы проверяем, что IP-шники, которые приходят на порту в пакетах, они соответствуют этим префиксам. Это более расслабленная штука, чем Sourceguard, потому что Sourceguard проверяет именно по базе Neighbor Discovery. Мы сначала соседа заносим в список соседей, мы его, допустим, проверили, мы узнали, что у него вот такой IP-шник, вот такой вот маг, а потом, соответственно, только по этим парам, только по этим привязкам работаем. А Previx.gr говорит, мы знаем, что у нас на интерфейсе вот такой IP-шник висит, допустим, с таким-то префиксом. Любые IP-шники из-под этого префикса можно будет, соответственно, пропускать. В этом случае пользователь может хапнуть IP-шник другого пользователя, но не может хапнуть IP-шник какой-то совсем кривой. Ну, да,

более расслабленная версия Sourceguarda. Есть еще штука, которая называется Destination Guard. Она защищает от атаки на переполнение таблицы Neighbor Discovery. Важная, важная вещь, обязательно ее включайте, если вы знаете, что у вас в сети есть недоверенные узлы. Дело в том, что в IPv4 мы обычно на интерфейсе вешаем сетку slash 24. Ну, чаще всего, да, что если у нас есть там роутер, он смотрит на свитч, на этом свитче у нас юзеры сидят. Вот мы говорим, здесь у нас там 10.0.0.1 slash 24 адрес. И, соответственно, в этой сети, в этом широкопрещательном домене всего может быть 256 IP-адресов. Если атакующий начнет пытаться переполнить таблицу ARPA, он будет говорить, у меня IP-шник вот такой, у меня IP-шник вот другой, у меня IP-шник вот пятый, у меня IP-шник десятый. Он больше, чем 256 IP-шников не сможет нам отправить. И переполнить таблицу соседей он не может. В то же время в IPv6 мы обычно на интерфейсе вешаем 64-ю сетку.

И, соответственно, если у нас есть роутер, который подключен к свечу, к которому подключены пользователи, среди которых завелся гадкий атакующий, он вам может отправить хреновую тучу квинтиллионов разных указаний, что у него вот такой вот IP-шник, у него вот такой вот мах. И у вас на роутере переполнится кэш Neighbor Discovery. И, соответственно, у вас Neighbor Discovery перестанет после этого работать. Вот для того, чтобы не попадать под такую ситуацию, вы можете воспользоваться двумя механизмами. Первый, вы можете сказать, если у нас действительно есть такая вероятность того, что нас будут таким образом атаковать, мы можем не использовать 64-й сетки на интерфейсах на пользователе. Мы можем использовать, например, 120-й сетки. Это аналогично по смыслу слэш 24. То есть, у нас 8 бит под адрес хоста остается, мы эти IP-шники раздаем с помощью чего-нибудь типа DHCP Stateful. Мы говорим,

что все механизмы, которые предполагают, что в IPv6 адресов много, они у нас ломаются. У нас у каждого юзера будет один IPv6 адрес. Ну, да, то есть, вот, дальше мы начинаем работать в логике IPv4. Либо второй механизм, вы говорите, что у нас, если есть кэш нейбор дискавери, и, соответственно, приходит какой-то запрос, не запрос, приходит какое-то указание, что у меня вот такой вот IP-шник, у меня вот такой вот Mac, вы проверяете, есть ли в таблице нейбор дискавери такой IP-шник уже. Если нету, то вы его просто выбрасываете. Штука, конечно, немножко стрёмная, потому что, по сути, свои, до тех пор, пока вы сами не захотите пообщаться с кем-нибудь, вот IPv6 destination guard будет, ну, немножко некорректно себя, наверное, вести с точки зрения IPv6, но, тем не менее, это довольно эффективно защищает вас от атаки на переполнение кэша ND.

Еще есть механизм дочерний к destination guard, который называется ND Resolution Rate Limiter, который указывает, что если у вас отправляются запросы или ответы ND-шные нейбор дискавери, они не могут отправляться слишком часто, опять же, для того, чтобы не слишком быстро переполнять этот самый кэш. Вот. Чтобы вы понимали, масштаб проблемы на современных роутерах, на современных свечах обычно кэш ND, он, ну, например, там 8000 записей или там 12000 записей, то есть он небольшой. Иногда он 2000 записей может быть. Ну, то есть переполнить его как нечего делать фактически. Поэтому, для того, чтобы с проблемой недоступности вообще всех канальных адресов не столкнуться, защищать эту штуку все-таки нужно. Так, еще одна вещь, которую постоянно все забывают,

но которую обязательно нужно будет делать, это инфраструктурные аксесс-листы. На входе в вашу сеть вы должны будете отбрасывать весь трафик до заведомо некорректных адресов. То есть, либо с некорректных адресов, либо до некорректных адресов идущие. Если у вас есть какой-то пакет, приходящий из интернета, этот пакет в принципе не может идти из-под адресов частных. То есть, вешаете на вход фильтрацию заведомо кривых пакетов. Приходит какой-то пакет из интернета, и там у него 192.168.01 стоит в качестве адреса источника. Расстрелять. Приходит у вас пакет с адресом назначения 192.168.01 из интернета. Расстрелять. Если вы знаете, что у вас есть какие-то айпишники для сети управления, которые гипотетически могут быть доступны из интернета, вот не пускать никакие пакеты, которые приходят из-под обычного интернета на адреса управления. То есть, все, что может

повредить вашей сети, все нужно будет тщательно расстреливать. Мы это говорили на курсе по роутингу, но здесь я просто напоминаю, что в принципе в сети коммутируемые, все то же самое будет работать. То есть, аксесс-листами закрывайтесь, не пускайте ни пользователей, то есть, это с одной стороны периметра вашей сети, ни узлы, которые там в интернете, это с другой стороны вашей сети до интерфейсов управления. Тщательно прописывайте, кому можно получать доступ к сети управления и, соответственно, ни в коем случае не выставляйте интерфейсы управления доступными ни пользователям, ни в интернет. Если вы знаете, что у вас используется L3-аксесс, то проверяйте на аксессе и на пограничных портах с интернетом правильность IP-адресов в пакете. В качестве очень мощного инструмента можно использовать механизм, который называется Unicast Reverse Path Forwarding или URPF.

Когда приходит какой-то пакет, вы можете посмотреть, из-под какого адреса он пришел и помимо того, что вы смотрите на какой адрес он пришел при принятии маршрутного решения, вы смотрите, где доступен адрес назначения, в какую сторону этот пакет уйдет. Вы точно то же самое делаете с IP-шником источника. Вы смотрите, где находится маршрут в сторону IP-шника источника. Вы находите тот интерфейс, за которым доступен IP-шник источник и смотрите, из-под этого ли интерфейса пришел пакет. Если пакет, соответственно, пришел из другого интерфейса, то вы можете расстрелять такой пакет. Команда будет на интерфейсе IP-верify unicast-source и дальше у вас есть два варианта reachable-via-rx. Это значит, что пакет должен пройти ровно из-под того интерфейса, куда смотрит маршрут до адреса источника. Это более безопасный вариант, но он вызывает проблемы с equal-host-multipath и с некоторыми

другими механизмами и либо reachable-via-any называется. Это более такой более расслабленный вариант, при котором маршрут до адреса назначения должен хотя бы быть за любым интерфейсом. Это позволит вам отбрасывать те пакеты, которые идут из-под адресов, которых вообще нет в таблице маршрутизации. Далее. Еще одна штука, которую надо будет знать при работе с коммутируемой сетью, это то, что иногда приходится иметь дело с legacy. Legacy заключается в том, что у вас есть огромный широкомещательный домен. В этом широкомещательном домене все друг друга видят, там огромное количество браткаста, и вам очень сильно хочется сделать так, чтобы в этом широкомещательном домене не было взаимодействия каждой с каждым. По умолчанию такое взаимодействие есть. Соответственно, хочется взять и разделить

один большой широкомещательный домен на несколько маленьких, но если мы это будем делать штатным IP-шным образом, мы должны будем сказать, окей, мы меняем IP-адресацию, мы разделяем один большой, например, VLAN на несколько маленьких VLAN-ов, в каждом VLAN-е мы меняем IP-шники, но тут просто реальность такова, что вы не всегда можете поменять IP-адресацию. Иногда бывает так, что вы приходите к клиенту, клиент это какой-то, ну не знаю, завод, и на этом заводе стоит хреновая туча всякого разного оборудования, всякие датчики, станки, системы мониторинга, системы маркировки, и вы не знаете, как это настраивать, и вы не можете это настроить, вы не можете сказать, вы знаете, я не хочу, чтобы у вас тут тысяча узлов в одном VLAN-е было, я хочу этот VLAN поделить на две части, на вас очень сильно посмотрит главный инженер и скажет, мы не дадим вам наше оборудование перенастраивать, потому что хрен его знает, что это такое, что там получится. Это оборудование поставили 20 лет назад, с тех пор все, кто настраивал это оборудование уже либо ушли на пенсию, либо померли, либо что-то еще с ним случилось, короче говоря,

оно работает, дышать на него нельзя, и вы сталкиваетесь с ситуацией, когда вам нужно разделить сеть на отдельный широковещательный домен, сегментировать ее, но перенастраивать клиентов вы не имеете возможности. Адресация должна остаться той же, но некоторые клиенты должны перестать друг друга видеть. И в этой ситуации вас спасет механизм, который называется PrivateVLAN. Это штатный механизм, это не фирменный цисковский механизм, это штатный механизм 802.1Q, когда у вас кадры, которые будут получать ваш свитч, будут получать какую-то VLAN ID, не следует путать VLAN ID кадра с меткой 802.1Q. Метка 802.1Q это указание на отправляемом кадре, к какому VLAN этот кадр мы отнесли. То есть, когда к вам приходит какой-то кадр, вы ему назначаете VLAN ID, вы, допустим, говорите, этот кадр пришел в VLAN SOTAN. Это просто самый обычный кадр, и вы его коммутируете без каких-либо 802.1Q меток. А дальше вы говорите,

я отправляю этот кадр по транковому порту, допустим, на соседний свеч. И для того, чтобы соседний свеч понял, к какому VLAN я его относил, и чтобы он тоже отнес этот кадр к тому же самому VLAN, я вот поставляю ему 802.1Q метку сотого VLAN. То есть, мы говорили с вами как раз, что метка добавляется в момент отправки кадра на транковом порту, метка срезается 802.1Q в момент приема кадра на транковом порту. Но, если у нас есть один большой VLAN, и нам надо его разрезать на несколько маленьких VLAN, то у нас получается, что нужно будет иметь более сложную структуру. Нам нужно будет сказать, что у нас есть несколько пользователей, которые принадлежат глобально к одному и тому же VLAN. Если вдруг мы будем принимать какие-то кадры от этих пользователей и будем отправлять их, например, в какой-нибудь транк, мы должны будем делать вид, что эти пользователи все действительно из одного и того же VLAN будут приходить. Но, на самом деле, внутри себя мы должны понимать, что это на самом деле пользователи

в разных VLAN. То есть, мы должны будем такой корпускулярный волновой дуализм проявлять, что пользователи в одном VLAN, но при этом в разных. И, соответственно, у вас этот механизм будет реализован следующим образом. Вы создаете один VLAN большой, называете его Primary VLAN. Primary VLAN. И дальше у вас есть маленькие VLAN. Например, вот этот один маленький VLAN. Вот этот другой маленький VLAN. И вы эти VLAN называете Secondary. И у вас получается, что когда кадр какой-то приходит, learning MAC-адреса происходит в таблице сразу нескольких VLAN. Приходит какой-то кадр от абонента, и вы говорите, окей, мы приняли кадр на вот этом порту, мы знаем, что вот этот VLAN родительский большой Primary VLAN будет называться VLAN, например, сотом, а маленький дочерний VLAN под VLAN как бы, ну да, дочерний

Secondary, вот он имеет номер 101. И мы MAC-адрес вот этого абонента, который мы получили, learning и в таблицу сотого VLAN, и в таблицу 101 VLAN. Но назначаем мы метку только Secondary. Вот VLAN ID мы будем назначать 101 VLAN. И, соответственно, когда кадр такой приходит, мы говорим, да, 101 VLAN нормально. Вот. Входящему кадру сопоставляется всегда только один VLAN ID. Мы не можем сказать, что мы сопоставляем этому кадру и метку сотого VLAN, и метку 101 VLAN, то есть VLAN ID только в Secondary. Но при этом MacLearning идет и туда, и сюда. И в дочерний, и в родительский VLAN одновременно. Дальше. Если у нас вдруг какой-то кадр приходит, и кадр приходит снаружи, ну, например, по какому-то транковому порту, и у нас есть указание, соответственно, что вот кадр прибегает с местной 802.1Q, и, соответственно, у него

внутри стоит указание, к какому VLAN это все относится. И там написано, что это какой-то внешний кадр с сотой меткой. Мы говорим, окей, мы этой метке верим, этот кадр у нас относится к сотому VLAN, и мы по таблице сотого VLAN пытаемся найти адрес получателя. Мы говорим, да, в сотом VLAN мы уже залернили этот кадр, вот этот вот абонент сидит за вот этим вот портом в сотом VLAN, отправляем этот кадр туда. По транку там все сложнее, то есть, если у нас есть кадры, которые приходят в транке с меткой родительского VLAN, то лукап в таблице, тот самый принятие коммутационного решения, будет выполняться по таблице того VLAN, который там написан. Приходит метка сотого VLAN в 802.1 Q метка, значит, пытаемся найти в таблице сотого VLAN. Приходит вдруг кадр с меткой 802.1 Q 101 VLAN, делаем лукап в таблицу 101 VLAN. То есть, что приходит, тому верим. Транковый порт как раз отличается тем,

что мы верим тому, что написано в его 802.1 Q метке. Приходит кадр с определенной 802.1 Q меткой, мы говорим, окей, написано 101 VLAN. Запускаем таблицу коммутации, 101 VLAN и находим выходной интерфейс. Приходит 102 кадр со 102 меткой, окей, запускаем таблицу коммутации, 102 VLAN и находим выходной интерфейс. Приходит 100 VLAN родительский, окей, значит, ищем во всем родительском VLAN. Вот, то есть, у вас есть какой-то кадр, вы его получили, и вы ему сопоставляете всегда только один номер VLAN. Какой этот номер VLAN будет, сейчас не суть важна. Дальше вы говорите, окей, мы приняли какой-то кадр, неважно на каком порту, на родительском, на дочернем, на каком-то третьем, который вообще к правилам не относится, мы посмотрели на него, сказали, ага, мы приняли решение на основании каких-то настроек или на основании того, что в кадре прибежало, что VLAN у этого кадра, VLAN ID, VID, будет, не знаю, какой-то, некоторый.

Дальше нужно будет запустить коммутацию этого кадра, принять коммутационное решение, принять решение, куда мы этот кадр отправляем. И мы запускаем коммутацию только по тому VLAN ID, который мы приняли. То есть, мы посмотрели на кадр, сказали, ага, кадр мы отнесли к VLAN номер 200. Запускаем коммутацию по таблице 200 VLAN. Это все никак пока не связано с Private VLAN. Это просто самый обычный движок коммутации, который мы с вами рассматриваем вот уже третью неделю. В чем фишка Private VLAN? Все точно то же самое, только когда у нас происходит в обычной коммутации прием какого-то кадра, мы смотрим на MAC адрес источника, и мы этот MAC адрес источника запихиваем в таблицу коммутации, в тот самый forwarding database, MAC адрес table, как угодно называйте. Мы принимаем решение, что у нас кадр относится к определенному VLAN, и мы MAC learning ведем в один VLAN. В случае несколько VLAN,

и в дочерний, и в родительский. То есть, если вы принимаете какой-то кадр на порту, и этот порт относится к Private VLAN, на этом порту у нас есть указание, порт относится к дочернему VLAN, и порт относится к родительскому VLAN одновременно. Но VLAN ID мы назначаем только дочернего VLAN, и коммутацию на дочерних мы будем выполнять только по дочернему VLAN. Однако в родительский VLAN уходит его MAC адрес. И если будут приходить кадры, которые мы будем относить к VLAN родительскому, они будут коммутироваться по таблице другого родительского VLAN. Соответственно, может быть такое, что у вас есть один дочерний VLAN, другой дочерний VLAN, они между собой друг друга не видят, они к разным VLAN относятся, и коммутации между ними нет. Но вы говорите, вот мы кадр какой-то принимаем от одного дочернего VLAN, мы этот кадр отправляем куда-то вот сюда. Вот этот порт, так называемый Promiscous Port, он может нести в себе трафик разных дочерних VLAN. Он относится

как бы только к родительскому VLAN, и мы говорим, что он принимает в себе трафик и желтого VLAN, и вот этого самого красного, не знаю, коричневого. Кадр приходит от пользователя, мы его отправляем в Promiscous Port. Кадр приходит обратно от Promiscous Port, мы его отправляем обратно пользователю. В этой ситуации у нас как раз будет работать логика вида, туда мы коммутировали кадры по таблице дочернего VLAN, а обратно мы коммутируем кадры по таблице родительского VLAN. То есть, вот этот вот маленький VLAN у нас будет, например, 101, вот этот маленький VLAN у нас будет 102, а родительский VLAN у нас будет 100. И Promiscous Port у нас относится и к 100 VLAN, и к 101, и 102. 101 и 102. Promiscous Port в первую очередь будет относиться к родительскому VLAN, то есть, в него коммутируются кадры все и дочерних VLAN в 101, и дочерних VLAN в 102, а кадры, которые приходят из него,

они будут, ему будут назначаться метка, не метка, VLAN ID сотов VLAN. Про Promiscous Port я просто не успел вам рассказать, но в нем как раз вся магия и кроется. Кадры дочернего VLAN коммутируются по таблице 101 VLAN. Вот этот вот роутер в 101 дочернем VLAN есть, и, соответственно, кадры на него коммутируются. И когда он отправляет ответы, этим ответом назначается VLAN ID сотый. И коммутация ответов происходит по таблице всего сотого VLAN. Когда в 102 VLAN кто-то хочет отправить кадр роутеру, он тоже отправляет этот кадр. Кадру назначается VLAN ID 102. Этот кадр коммутируется в сторону роутера. Ответы коммутируются по таблице сотого VLAN, который, опять же, в себя включает вообще всех. То есть, роутер видит всех, а эти узлы, которые разделены между собой на разные дочерние VLAN, они друг друга уже не видят. Да, в родительском VLAN таблица коммутации

нормальная, жирная, как она и должна быть, как она, условно говоря, как она и была до того, как мы эту штуку сегментировали на отдельные маленькие дочерние VLAN. А те, кто находится в дочерних VLAN, они могут видеть не все подряд, они не всю таблицу коммутации, не ко всей таблице коммутации получают доступ, а только к ее какому-то подразделу. Вот. И вот эти вот два правила, когда у нас происходит прием какого-то кадра, у нас сопоставляется какой-то VLAN ID этому кадру, так же, как и в случае с обычной процедурой коммутации, но главное здесь, да, что кадр всегда назначается только один VLAN ID. Если мы говорим про дочерние VLAN-ы, то назначается ID-шник дочернюю VLAN. Если мы говорим про Промиску Спарты, то им назначается ID-шник родительского VLAN-а. Ну и, соответственно, MacLearning. В любом случае, когда мы принимаем кадр по дочернему VLAN-у, MacLearning происходит в таблице сразу нескольких VLAN-ов и дочернего, и родительского. Естественно, что таблицы дочернего VLAN-а

всегда будут меньше, чем таблица родительского, потому что таблицу родительского идет MacLearning сразу из всех дочерних виланов вот в цисковской реализации есть три типа порту внутри типа даже не портов наверное три типа ну хорошо назовем портов в правилах это порты соответственно promiscuous это порты комьюнити это порты изолей тот если мы говорим про promiscuous порты это те порты которым должны будут получать доступы пользователи разных дочерних вилан of то есть у нас есть вот например вот это вот маленький дочерний вела желтой маленький дочерний велом зеленый маленький дочерний го daha красный и мы хотим сказать что вот пользоваться этих разных mstung взаимодействовать не могут но при этом мы хотим чтобы они все имели возможность взаимодействовать вот с вот таким вот с вот таким вот родительским портом например потому что здесь роутер у этого роутера давайте

давайте для красоты напишем айпишники 192 168 11 слэш 24 айпишник вот у этих вот твои товарищи . там 11 . 12 . 13 айпишники вот у этих товарищей . 21 . 22 . 23 ну то есть глазками видно да что вот эти вот узлы у них у всех 24 маска они в принципе должны думать что 21 22 23 находится с ними в одной сети и взаимодействия в должно быть возможно но мы это взаимодействие закрываем говорим мы разносим их по разным дочерним виланом и трафик между ними ходить напрямую не будет вот в этом вилане там . 31 . 32 . 33 у нас три разных порта будут тоже соответственно иметь разные и пишники до того как мы разбивали все это на дочерние вилана нас было как бы три отдела каждый из которых имел свою в кавычках свою айпи адресацию глазками видно да что тут как бы айпишники у всех визуально

относятся к отделам но при этом с точки зрения протокола и пи все эти айпишники относятся к одной и тоже айпи сети вот и мы хотим сказать что у всех этих айпишников есть доступ к айпишнику роутера стой нас 2 168 11 но при этом между собой они вне взаимодействуют прекрасно разносим их по разным дочерним виланом если у нас есть желание сделать так чтобы внутри дочернего вилана пользователи могли взаимодействовать между собой но чтобы вот 11 и 12 мог общаться 12 с 13 то есть чтобы у нас взаимодействие внутри вилана была ну как в обычном вилане там и такой вилан будем называть словом комьюнити вилан это дочерний вилан в пределах которого взаимодействие будет работать как обычно то есть мы просто говорим что у нас вот есть какой-то там 102 вилан или давайте 101 потому что айпишники на единицу начинаются 100 101 вилан вот и соответственно вот айпишники 11 12 13 могут взаимодействовать между собой плюс к тому мы хотим чтобы они взаимодействовали с роутером 100 у нас два 168 11 но не взаимодействовали с 22 с 32 айпишниками

вот мы хотим чтобы они были обособлены дальше мы хотим то же самое для 102 вилана сделать так чтобы 21 22 23 зачем их взаимодействию между собой и с роутером но не с первыми из третьими и function ками ну здесь то же самое 100 103 Herspiel 1 создаем вот эти комьюнить people ан и говорим вот этот комьюнити комьюнити вилан вот этот комьюнити вилан вот эта комьюнити вилан дочерний комьюнити вилан в в пределах которых взаимодействие будет нормальное. Когда у нас кадр какой-то приходит, например, из-под айпишника с 3.0.2.168.1.11, мы говорим, окей, MacLearning производим и в таблицу 101-го Вилана, и в таблицу родительского всего большого Вилана, например, сотого. Соответственно, кадры, которые будут передаваться внутри 101-го Вилана, будут коммутироваться просто как обычные 101-го Вилана, то есть ничего нового тут нет. Но если мы отправляем кадры на роутер, кадры выходят из-под порта роутерного и входят потом из-под порта роутерного,

вот этот вот порт, который роутерный, будет называться Promiscuous Port, он будет получать метку primary Вилана сотого и коммутироваться, соответственно, по таблице всего-всего-всего сотого Вилана. Promiscuous Port будут относиться и к комьюнити Виланам тоже. То есть, да. Вот. В то же время есть еще один тип портов, помимо комьюнити портов, помимо Promiscuous Port, есть порты, которые называются Isolated. Изолированные порты могут передавать трафик только в сторону Promiscuous Port и не могут передавать трафик друг к другу. То есть в каждом primary Вилане вы можете создать один Вилан, который назовете Isolated. Вот. Isolated VLAN, он будет вести себя очень странно, то есть трафик между пользователями Isolated VLAN ходить не будет. Да, у него будет свой номер, ну, например, не знаю, сто-то, сто-девять. Вот. Ну, кадры, которые будут приходить на порту одного,

на одном порту Isolated VLAN, они будут пополнять таблицу сто девятого Вилана, но они не будут пополнять таблицу портона сотого Вилана, но они не будут коммутироваться в другие порты Isolated VLAN. То есть это просто дополнительное ограничение, что если вдруг мы в таблице сто девятого Вилана пытаемся куда-то найти, куда можно выйти, то проверяется, что порт источника и порт назначения не должны принадлежать одному и тому же Isolated VLAN. Порт источника Isolated, значит, порт назначения обязан быть Promiscuous. И наоборот. Вот. Promiscuous портов, в принципе, может быть много. Если вдруг вам эта тема будет интересна, если вы там к CCI будете готовиться, вы можете разобрать ситуацию, когда у вас будет два Promiscuous порта с разными настройками. Можно будет сказать, что некоторые комьюнити Виланы могут работать с одним Promiscuous портом, некоторые с другим, но это уже такая реальная наркомания. В реальной сети предприятия PrivateVLAN, если вы будете использовать, то, скорее всего, только с одним родительским Виланом и там несколько комьюнити и Isolated.

Да, эту штуку, в принципе, можно использовать в сетях провайдерских, но для провайдеров есть другая технология, когда у вас фактически будет только вот один Isolated VLAN и все. И настраиваться она будет намного проще, чем Private. Поэтому, если вдруг вы думаете, что эту штуку прямо сейчас стоит внедрить в сети провайдера, то не спешите, для провайдеров есть кое-что попроще. Нет, не Q&Q, а так называемые Protected порты. Как настраиваются PrivateVLAN? Для начала вам нужно будет создать структуру Виланов, то есть указать, какие Виланы вы создаете, кто из них будет родительский, кто из них будет дочерний. Немножко необычно то, что один... Это неоднозначное соответствие. То есть у вас может быть не то, что один PrimaryVLAN и дальше некоторое количество Secondary только к нему. Там структура может быть более сложная. Но опять же, в сети предприятия, как правило, у вас будет один Primary, и дальше к нему несколько дочерних, и вот они будут вкладываться именно в Primary.

Названия будут следующие. PrimaryVLAN – это тот, который родительский. Community – это тот, который дочерний и разрешает коммутацию между хостами этого Вилана. Isolated – это дочерний не разрешает коммутацию между хостами внутри этого Вилана. Сами Виланы вы должны будете создать. То есть так же, как и в случае с обычной коммутацией, то, что вы пропишите на порту, к какому Вилану порт относится, не означает, что этот Вилан есть в базе. И наоборот. Поэтому отдельно создаем Виланы и отдельно указываем на портах, к каким дочерним или родительским Виланам эти порты будут относиться. Указываем, что у нас есть родительский Вилан, прописываем на нем команду PrivateVilanPrimary. Это мы указываем роль этого Вилана. И дальше указываем, какие дочерние Виланы к этому Primary будут относиться. Вы можете гипотетически сделать странную ситуацию, ввиду у вас будет два PrimaryVilan, и secondary Vilan к ним будет относиться к обоим. Но это головоломка не для средних умов, поэтому на курсе по свитчингу

мы этого даже не рассматриваем. Указываете, что у вас есть родительский Вилан, указываете, какие дочерние Виланы к нему относятся, и дальше создаете эти дочерние Виланы и указываете их роли. PrivateVilan Isolated, PrivateVilan Community. Да. Если вы создаете PrivateVilan, то вы должны будете знать ограничения этих механизмов. Во-первых, как уже говорилось, PrivateVilan хреново сочетаются с IP Source Guard. Во-вторых, если вы используете PrivateVilan, вы должны будете четко понимать, что это костыль. Костыль в ситуации, когда сеть уже задизайнена, ее уже не переделать. То есть количество сил, которое потребуется для того, чтобы переделать, оно становится неразумным. И вам надо эту сеть сегментировать какими-то любыми костылями, потому что использование любых костылей будет оправдано. В этой ситуации вы можете использовать PrivateVilan. Если вы собираетесь использовать PrivateVilan с нуля при дизайне новой сети, вы делаете что-то очень сильно не так.

То есть если вы хотите сегментировать какую-то новую сеть, вы дизайните новую сеть, вам обязательно имеет смысл задуматься о том, что вы не должны использовать PrivateVilan, вы должны использовать сегментирование нормальное с помощью протокола IP. То есть PrivateVilan – это всегда костыль. Практически в 100% случаев это костыль. Очень редкие исключения, когда в новой сети принимается решение об использовании PrivateVilan. Ну то есть это надо быть очень в себе уверенным специалистом и понимать, что вы делаете. Кроме того, PrivateVilan работают либо с VTP версии 3, и тогда надо будет выключить прунинг, потому что прунинг с PrivateVilan опять же не работает. А если вы используете VTP 1 и 2 версии, то надо его вообще выключить. То есть VTP 3 версия умеет реплицировать структуру PrivateVilan, но без прунинга. VTP 1 и 2 версии вообще сходят с ума, если вы пытаетесь их включить с PrivateVilan. Они будут реплицировать эти базы VLAN без указания флагов Primary и Community Isolated.

Вот. Дальше. После того, как вы создали сами VLAN, нужно на портах прописать соответствующие настройки. Так же, как мы прописывали SwitchPort Mode TimeAccess, SwitchPort Mode Trunk, вот это делается в режиме SwitchPort Mode. Дальше мы указываем PrivateVilan, и здесь мы указываем либо host, это значит, что порт будет относиться к дочернему VLANу, либо SwitchPort Mode PrivateVilan Promiscuous. Это будет означать, что он относится к родительскому VLANу. Но опять же, когда мы говорим дочерний и родительский, мы понимаем, что связки родительский и дочерний VLAN в разных конфигурациях могут быть разные. То есть ситуация вида «у нас есть два родительских VLANа и есть дочерние VLANы, которые как-то между ними пересекаются», ее никто не отменял. Поэтому нужно в явном виде прописывать, когда мы говорим, что это дочерний хост, к какому родительскому VLANу и к какому дочернему VLANу

этот пользователь будет относиться. Команда SwitchPort PrivateVilan Host Association, родительский VLAN и дочерний VLAN. VLAN ID будет назначаться по метке дочернего VLAN. Но если мы будем назначать только дочернего VLAN, мы не сможем этот трафик выпустить в сторону промискус портов. Поэтому MacLearning будет идти и сюда, и сюда. Трафик будет отправляться в сторону соответствующих портов дочернего VLAN, если это комьюнити VLAN, и в сторону промискус портов. Если вы хотите назначить промискус порт, то вы должны будете сказать SwitchPort Mode PrivateVilan Promiscus, и вы указываете SwitchPort PrivateVilan Mapping, родительский порт и все дочерние порты, которые получают право отправлять кадры в этот промискус порт. Знаю, что по первости может показаться очень сильно излишним

прописывание в разных местах связок дочернего VLAN, родительский VLAN, потому что мы прописали это в базе VLAN, мы прописали это в промискус порту, мы прописали это в дочернем порту. Но на самом деле, поверьте, здесь все имеет смысл. То есть, если вы где-то хотя бы что-то не укажете, оно все разломается. Для хостового VLAN мы указываем два номера, для хостового, простите, порта, мы указываем два номера VLAN, то есть, в какой VLAN будет идти learning родительский VLAN, в какой VLAN будет идти learning дочерний VLAN. Может быть ситуация, когда у нас есть какой-то порт, и мы хотим, чтобы learning шел вот в этот родительский VLAN и в этот дочерний VLAN. Может быть другая ситуация, когда у нас есть другой порт, и мы хотим, чтобы learning шел в этот дочерний VLAN и вот в этот родительский VLAN. Поэтому прописываются оба VLAN. Ну и, соответственно, если мы говорим, что у нас есть промискус порт, то мы можем сказать, что у нас есть железка, на ней есть два дочерних VLAN, и, соответственно, вот эту вот промискус порт и вот эту вот промискус порт,

ну, один имеет дело только с одним дочерним VLAN, а другой имеет дело только с другим дочерним виланом и все они вроде бы как соответственно относится к одному родительскому вилану безобразие конечно что такое такая сложная структура но вот по стандарту и поверьте мне это примерно так и выглядит поэтому мы указываем родительский вилан и дальше все дочерние виланы которые там есть на самом деле да просто указывайте вообще все если вам кажется наоборот логично то это воспринимаю как похвалу в свой адрес потому что из всех литератур из всех видеороликов всех курсов которые мне доводилось видеть из всех книг это подается всегда настолько нелогично что вот просто диво даешься кто такое придумал вообще зачем это такое придумал какой злой гений вообразил такую конфигурацию ну если мне удалось вам это донести понятным языком я просто очень рад если вы прописываете промиску спорт то маклернинг происходит в родительские и все прописаны дочерние виланы и соответственно входящим кадром назначается вела

найди родительского вилана что делать если все это дело поломалось и не работает ну да смотрите шоу-интерфейс switchport здесь про правила на показ показывается такая добрая половина этой простыни вот вот вот это вот это про какой-то порт который у нас switchport gigabit ethernet 01 private вилан здесь показывается где она есть то сабжи вот административ молот private вилан хост то есть это как администратор сказал работать правит вилан хост означает что у нас обычный пользовательский порт ему назначаются два вилана родительский и дочерний административ правит вилан хост оси си шин показывает в какие виланы будет идти маклернинг и соответственно первичный правит вилан это тоже в какие виланы идет маклернинг при этом по факту этот кадры которые будут приходить на этом порту они будут относиться естественно к дочернему вилану

в нашем случае к 101 и метка будет назначаться именно 101 вилана не метка вела найди вид то что метка я уже говорил до плохое слово будем называть тег 802 одежды и вила найди вот вела найди 101 дочернего вилана если вдруг мы будем соответственно дальше передавать кадр по транковом порту метка тег может нести в себе как кадры как указание на дочерний вилан так и кадры так и родительский вилан зависимости от настроек мы сейчас про танки будем отдельно говорить вот дальше это все про транки вот про транки видеть тут как много всякого вот вот это вот вся колбаса это все про транки транки с с правит виланами очень интересно сочетаются там можно просто сразу застрелиться если вдруг вам это надо с этим работать потому что во первых не на всех платформах транки в правит вилановский поддерживаются нормально а во вторых даже там где где они поддерживаются там они иногда бывает глючат поэтому будьте осторожны если вы хотите развернуть конфигурацию с правит виланами странками и

чтобы это все еще работало про транки можно будет заметить следующие вещи если у вас есть два свеча и эти два свеча связаны между собой транковым портом и на них есть какие-то юзеры и соответственно мы хотим чтобы между этими юзерами шло взаимодействие в пределах например комьюнити виланов в этом случае мы просто поднимаем транк обычный свеч порт маутранк кадров которые приходят из-под обычного порта назначается ему метка вилан айди вид дочернего вилана и соответственно коммутация происходит по таблице дочернего вилана и кадры которые по транковому порту уходят получают тег 101 вилана дочернего вилана также как вот собственно говоря просто в нормальной обычной ситуации приняли кадр с одного интерфейса передали кадр на другой интерфейс и для того чтобы сказать по какой таблице коммутации его надо коммутировать мы указали метку вилана если вы просто указываете switchport mode ранг то вы указываете метку дочернего вилана такую ситуацию имеет смысл рассматривать если у вас два свеча которые поддерживают private вилана у которых

так структуры private виланов сконфигурированы корректно непротиворечиво вот если вы на таком порту будете передавать кадры каких-то других виланов то они будут назначаться свои метки если мы говорим про private виланы у нас каждый кадр соответственно помечается дочерняя метка и вот мы говорим передаем дочернюю метку сосед получает метку 101 вилана и говорит я дальше коммутирует в порты которые 101 вилана если у вас есть транс каким-то узлом который не поддерживает private вилана то у нас будет следующая ситуация давайте попробовать стереть сейчас и нарисовать проблему проблема заключается вот в чем есть свеч он поддерживает private вилана у него есть несколько узлов часть из них 101 вилане часть из них 102 дочернем вилане все это дело в сотом вилане есть другой свеч который не поддерживает private виланы и у него есть какие-то абоненты и эти абоненты тоже в сотом вилане и надо обеспечить взаимодействие этим самым

абонентом сотов вилана с абонентами вот этими вот всеми в этом случае мы должны будем сказать что у нас есть сосед который который транковый соответственно должны будем поднять такой порт ранковый который мы можем поднять и метки на кадрах проставлять те которые поймет сосед метки родительского вилана или например может быть такое что у нас есть транковый порт не на соседней свечи которым есть абоненты сотов вилана просто тупо на роутер в котором мы используем роутер на палочке вот нас роутер на палочке у нас есть какие-то другие виланы там не знаю 20 200 300 вот и мы хотим сказать что у нас есть роутер на палочке который должен обрабатывать сотую метку роутеры не умеют работать с правил от виланами поэтому если вот нас такая ситуация есть то мы должны будем сказать вот это вот порт это про миску спорт в него отправляются и дочерний 101 вилан и дочерний 102 вилан и соответственно когда мы отправляем кадров с

промиску спорт мы их коммутируем по факту по таблице сотов вилана и соответственно мы отправляем кадр в танк мы вы помечаем родительской меткой делается это с помощью указания следующей штуки switchport mode дальше правил от вилан мы здесь указываем не хост мы здесь указываем не промискус мы указываем транк промискус и дальше указываем какие виланы на в этот ранг могут передаваться так же как с обычным промискус портом мы указываем соответственно какой родительский порт какой родительский вилан у нас есть какие дочерние виланы у нас есть но указываем не switchport trying private вилан association а указываем switchport private вилан маппинг тронг то есть что кадры в этом порту должны отправляться с меткой сотов вилана но коммутироваться они могут из 101 и 102 виланов и соответственно обратные кадры когда будут приходить они будут приходить с меткой сотов вилана но мы их будем отправлять по таблице коммутации до 101 и 102 дочерние виланы маклернинг будет идти туда и туда

если у нас есть соседний switch и мы хотим сказать что этот switch будет обслуживать каких-то пользователей и вот эти пользователи у нас будут относиться к некоторому вилану и мы хотим сказать что кадры которые будут приходить по по этому транку они не должны отправляться в сторону наших дочерних портов но они должны направляться на какие-то промиску спорт и которые у нас здесь есть например выход в интернет вот фактически мы должны этот порт объявить как изолей тот и в такой ситуации мы будем говорить что у нас есть изолей тот вилан например 109 и соответственно мы кадры которые будут приходить на этом порту будем назначать им вела найди не метку а виланой 109 вилана но для того чтобы сосед понимал что на самом деле никакого правил от вилана не существует что он все еще в сотом вилане как он на самом деле думает мы будем ему указывать что у него то на самом деле метка сотая кадры вы

будете маркировать родительской меткой а виланайди вы будете назначать при этом дочерней это вот как раз ситуация вида метка и виланайди не обязаны совпадать эта штука будет называть называться изолейтед ранг вы указываете switchport mode private вилан тронг секундари и указываете опять же switchport private вилан association тронг родительский вилан и дочерний изолейтед вилан до маппинг указывает куда будет идти мак лернинг и указывает соответственно с какой меткой в тронке мы будем передавать данные вот поэтому switchport private вилан association тронг сотой означает что в такой изолейтед ранг мы будем передавать кадры с сотой меткой но виланайди назначать 101 взорвался мозг ничего страшного если вы подумали что это как-то очень сложно для вас есть специальный механизм который намного проще называется private вилан edge штука упрощенная относительно полноценных private виланов по сути

своей иногда называется protected порты нету в ней комьюнити портов в ней есть только promiscuous изолейтед порты и соответственно если у вас есть только ситуация вида пользователя не надо давать передавать трафик между собой то соответственно вы включаете этот правил вилан и джи не паритесь да у правит вилан edge офигенное преимущество послали по сравнению с правит вилан полноценным это то что настраивается она очень просто она не позволяет создать ранки то есть она позволяет только работать с обычными портами ну или если у вас есть ранки вы можете их объявить как promiscuous и просто на работать с ними как есть и она не позволяет коммутировать трафик между обычными пользователями позволяет передавать трафик столько в сторону promiscuous портов вы объявляете порты protected и подмэй падон и соответственно трафик между протекли портами тупо не ходит есть

Если вы провайдер, то, скорее всего, вы захотите скорее воспользоваться этим, нежели Private VLAN. В сети предприятия, в принципе, это не самый плохой выбор. Если у вас нет штатного бизнес-сценария, пользователи должны видеть друг друга. То есть, я не знаю, если у вас там не шарит принтер, не шарит файлы напрямую между собой. Эту штуку имеет смысл включать, и тем самым вы, скорее всего, очень сильно защитите себя от всяких разных неприятных вещей. То есть, если вы знаете, что у вас пользователи друг с другом не взаимодействуют, если вы знаете, что у вас какая-то, не знаю, гостевая сетка есть, в которой могут пользователи появляться и исчезать, но они друг с другом нормально, да, не должны друг другу трафик отправлять вообще, они отправляют трафик только в сторону роутера, то вы такую вещь включаете, и она вас сразу защищает от, и от атака раппойзонинга, и от атак, вот последние, знаете, всякие актуальные тенденции, когда вирусы используют эксплойты в ошибке уязвимости в всяком программном обеспечении,

в первую очередь в операционной системе Windows, и, используя дырки, начинают распространяться вирусным образом, да. То есть, одна система заражает другую, та заражает третью и так далее. Ну, началось все это с древнего-древнего вируса MS-Blast, ну, вот пару лет назад, или сколько, это же пару лет назад было, да, вирусы типа WannaCry, Петя, они, в принципе, точно так же распространялись. Ну, смысл был в том, что система одна каким-то образом заражалась через известную дырку, например, через почту или через какой-то левый канал в интернет, дальше начинала заражать всех своих соседей. Ну, если вы включаете Protected Port, то она может сколько угодно пытаться кого-то заразить, она просто не сможет достучаться до соседей. Коммутация между соседями невозможна. Рекомендуется к использованию, но, опять же, вы должны быть уверены, что ваши пользователи не передают трафик напрямую между собой. В сети предприятия, как правило, особенно прошаренные пользователи, они знают, что есть такой инструмент, как File and Printer Sharing,

они шарят принтеры, они шарят файлы. Ну, и да, если у вас будут такие прошаренные пользователи, вы, конечно, включать эту штуку не сможете. Настраивается примитивно, просто, тупо, Switch Port Protected, все. То есть, вот оно, Protected True становится на порту, и Protected порты между собой трафиком не обмениваются. Еще одна штука, тесно связанная с безопасностью на коммутируемой сети, будет такая вещь, как SPAN. Switch Port Analyzer, если быть точным. Это механизм меркалирования портов, то есть, когда к вам какой-то трафик приходит на интерфейс, вы этот трафик отправляете также и на какой-то другой интерфейс. То есть, у других производителей это может называться, прямо по-честному, порт, мирроринг или что-то еще. Вот у CISC это называется SPAN. Есть несколько разновидностей этого самого SPAN. Самая простая разновидность это Switch Port Analyzer, просто обычный SPAN,

который будет перехватывать трафик в пределах одного свеча. У нас есть какой-то порт, который мы хотим мониторить. И, соответственно, нас интересует, например, все, что отправляется в сторону или от компьютера А. То есть, весь трафик, который узел А отправляет, он отправляется и туда, куда надо, и заворачивается также в сторону какого-то порта, на котором сидит, ну, как правило, сидит перехватчик. Ну, назовем это Wireshark. Либо, соответственно, то, что идет в сторону этого порта, вот оно также отправляется в виде копии, опять же, на Wireshark. Кадры, которые приходят на такой порт мониторинга, они отправляются и от мака узла А, и на MAC-адрис узла А. Поэтому это не обычная коммутация, это именно мониторинг, мирроринг. И, соответственно, здесь у нас вот этот вот узел, который Wireshark будет запускать, он должен работать в режиме специальном, который называется Prami-скусс режим, при котором кадры, которые этот узел будет получать, они будут отправляться на самые разные маки,

в том числе MAC, естественно, не принадлежащий самому узлу Wireshark. Настраиваться это довольно просто. Мы указываем, что у нас есть сессия мониторинга, указываем Monitor Session, дальше номер сессии. Сессии может быть одновременно на одном узле запущено несколько, но при этом есть небольшое ограничение, что один порт может принадлежать только к одной сессии. И указываем, соответственно, Source Interface и название интерфейса, откуда забираем трафик, и Monitor Session Destination Interface, куда забираем трафик. То есть здесь указываем порт, кого мирорим и куда мирорим. Потом Show Monitor Session нам покажет, какие сессии созданы и откуда и куда трафик мы забираем. На порту, на который вы выполняете отправку копии трафика, трафик отправляется в этот порт, но, соответственно, не забирается оттуда никогда, потому что там на этом порту нарушаются общие правила коммутации. Поэтому, как правило, на свечах ingress трафик, входящий трафик на порту, куда мы мониторим данные, он, соответственно, выключается.

То есть в AirShark он у вас может отправлять чего угодно, но в любом случае свечом будет просто тупо отброшено. Другой вариант – это так называемый AirSpan, Remote Span. Очень редко у вас есть возможность подключиться прямо к тому же свечу, на котором интересующий вас порт находится. Приведу пример, опять же, из жизни. У нас был узел связи. На этом узле связи стояла УПСК, и эта УПСК однажды заглючила. При этом эта УПСК была такая огромная симметра размером с полкомнаты. У нее был порт управления. И, судя по всему, этот порт управления, ну, что-то там типа заглючил или что-то еще. И вместе с всей платой, которая управляла этой УПСК, ну, в общем, УПСК высыл из строя, мы послали за инженером, который ее обслуживал. Он пришел, ну, естественно, пришел туда, где она стояла, на узел связи. И дальше он заменил плату управления, воткнул в нее все шнурки так же, как они были воткнуты раньше, и ушел.

И дальше возник вопрос, а окей, вот он ее, как бы, воткнул в новую плату, и там на IP-шник, наверное, надо прописать, да, и вот что, ехать к этому узлу связи, проверять, что, как там там строено, очень не хотелось. Ну, вот что мы сделали? Мы в итоге взяли, запустили R-SPAN. На том свече, который стоял на узле связи, в который вот был провод от УПСК, мы включили мониторинг, что весь трафик, который на этом порту, какая-то активность есть, что весь он отправляется куда-то далеко. А на том свече, к которому был подключен в офисе мой ноутбук, я, соответственно, другую точку этого самого R-SPAN-а настроил, и весь трафик, который отправляла УПСА или который принимала УПСА, он вываливался из совершенно другого свеча на порту, к которому был подключен мой ноутбук с ВАР-шарком. То есть вот узел А, это фактически была та самая УПСК, она была подключена к одному свечу, мой ВАР-шарк был подключен к другому свечу, и между этими свечами у нас передавались данные с помощью 802-денкишных транков.

R-SPAN предполагает, ну, Remote SPAN, да, предполагает, что у вас свечи, на которых сидят жертва и атакующие, они не один и тот же свеч, но они разные свечи. И поэтому кадры, которые будут отправляться от жертвы или к жертве, они будут отправляться под транковым порту, и они будут при этом каким-то образом помечаться. Опять же, там нарушены общие правила коммутации в этих кадрах, поэтому кадры могут отправляться как от узла А, так и в сторону узла А на этом порту. Ну, соответственно, надо будет сказать в этом случае, что вот этот вот товарищ не должен лернить такие кадры. То есть, если вдруг кадры приходят на узел А, то это не означает, что надо этот кадр обратно, допустим, в этот порт отправить, или не означает, что надо их выкинуть. То есть, это означает, что вот эти вот кадры, которые приходят с маркировкой, что это кадры R-SPAN, их надо по каким-то другим правилам, не по общим правилам коммутации,

а по каким-то другим отправить в сеть назначения. Поэтому вы создаете специальный VLAN, который помечаете как VLAN Airspan. И вы указываете, что трафик, передающийся в этом VLAN, Airspan, не подвергается стандартным правилам коммутации. То есть в этом VLAN вы отключаете MacLearning, и в этом VLAN у вас начинает весь трафик, который приходит разбрасываться по всем портам. Соответственно, вы на порту жертвы настраиваете, что этот порт будет называться Airspan Source. И дальше вы говорите, что все, что в этот Airspan Source попадает, все отправляется в определенный VLAN. И destination для сессии будет как раз Airspan VLAN. Ну а на свече получателя вы указываете, что у нас есть source для сессии, источник для сессии VLAN Airspan, и destination это просто обычный интерфейс. Все, что приходит с меткой в определенном VLAN, все мы отправляем дальше на VIRSHARK. Если есть какие-то транзитные свечи, на них тоже нужно будет создать указанный VLAN, и на них тоже нужно будет сказать, что этот VLAN не совсем обычный, что в нем нарушены обычные правила коммутации.

То есть везде надо создать этот VLAN, и везде надо будет указать, что VLAN там кривой. Вот. Настраивается следующим образом. В таблице VLAN создаем VLAN и указываем, что он кривой. То есть в настройках указываем слово Remote Span. А дальше создаем сессию и указываем на источнике source interface destination remote VLAN 100. Ну и, соответственно, show monitor session вам покажут, что у нас есть сессия номер один. Тип сессии, что это Remote Source. То есть мы забираем трафик с интерфейса, отправляем VLAN, забираем трафик gigabit 01 и входящий, и исходящий, и с меткой сотой отправляем куда попало. То есть на все транки, которые соты VLAN в себе несут. Destination, то есть другой конец сессии, у нас будет на вот другом свече. Тоже создаем VLAN 100, указываем, что он кривой, и указываем source remote VLAN 100, destination, интерфейс такой-то.

Номера сессии могут не совпадать на соседних свечах, они нигде не передаются, но тем не менее, да. Это просто обычные кадры, которые получают метку кривого VLAN. И эти кадры отправляются во все порты не по стандартным правилам коммутации, а просто владятся. Кадры обратно в тот же самый порт не передаются, но вы должны будете следить, что в этом VLAN у вас, соответственно, петли не получилось. Потому что правила коммутации в этом VLAN, они, соответственно, будут кривые. Ну, Spanning 3, в принципе, с этим справляется вполне. Тип сессии destination. Откуда берем трафик из сотого VLAN, куда направляем? В gigabit 02. Можно будет сказать, что вы трафик в gigabit 02 направляете, например, с метками 802.1Q. То есть, что этот порт будет обычный, на нем ингресс трафик будет работать, и кадры, которые отправляются в сторону VAR Shark, они от обычных кадров будут отличаться, например, наличием определенной метки. Но, как бы, стандартный классический способ, который рассматривается на экзамене и в курсе, предполагает, что у нас просто есть обычный VAR Shark атакующий,

и трафик на него отправляется без каких-либо меток, без каких-либо модификаций. SPAN имеет ряд ограничений. Я не уверен, что у вас будут эти ограничения спрашивать на экзамене CCNP, но теоретических могут спросить на экзамене CCIE, поэтому я про них расскажу. Во-первых, вы, если указываете, что какой-то интерфейс будет destination для сессии, можете указывать что угодно в настройке этого порта. По факту там будут применяться только настройки физики. Все, что связано с логикой, не применяется. Во-вторых, если вы указываете, что у вас есть несколько сессий, максимальное количество сессий зависит от платформы, но чаще всего до 64, то, соответственно, destination порт нельзя использовать в нескольких сессиях. То есть, если у вас есть железка, и у нее есть порты какие-то первый, там, второй, третий и там, десятый, то здесь вы получаете, что у вас есть в AirShark, и, соответственно, вы не можете сказать, что в этот в AirShark мы будем ловить трафик из сессии номер один и из сессии номер два.

То есть, нельзя сделать так, чтобы здесь была сессия номер один и здесь же была сессия номер два. Но можно использовать один и тот же порт для нескольких сессий в качестве источника. То есть, вы можете сказать, что у нас есть сессия номер один, и она будет отправлять трафик в несколько destination. Что делать, если вы хотите использовать один AirShark и ловить в него трафик из нескольких портов одновременно? Вы можете в рамках одной сессии сделать два сессии. То есть, сказать, что у нас есть сессия номер два, например, и она ловит трафик из двух разных сессий вверх. И здесь Monitor Session 2, и здесь Monitor Session 2. То есть, можно в качестве Source портов указать несколько портов в рамках одной сессии. При этом есть ограничения на то, что Source порты должны быть одинаковые. Ну да, в одной сессии может быть несколько Source, несколько destination. Что еще будет здесь нам интересно?

Есть на самом деле еще ERSPAN. Про него в курсе даже CCI нам нету, но знать про него в принципе полезно. Поддерживается он только, если не память не изменяет, на 4800-х свечах. И отличие будет от ERSPAN, у ERSPAN. Где это? Рисовалка где? ERSPAN заключается в том, что ERSPAN используют для маркировки кривого трафика 802.1 киошные виланы. А ERSPAN использует гореешный туннель. То есть, он заворачивает в гореешный туннель весь трафик, который с его точки зрения подлежит анализу. И, соответственно, вы указываете между двумя большими железками, что у вас есть порт источника, есть порт назначения. И между ними поднимается горе и туннель между железками. Весь трафик заворачивается в горе на порту источника. Весь трафик на сессии назначения выворачивается из горе и заходит прямо сразу в туннель. Эта штука работает поверх IP.

Поэтому у вас не обязательно иметь коммутируемую среду между вашими свечами. Если у вас, например, L3 Access, то ERSPAN очень полезная вещь. Но, опять же, ограничение связано с тем, что поддерживается эта штука далеко не везде. Поддерживается только на XE-шных платформах, которые меня не изменяет. Поэтому, да. Хорошо бы она была везде. Но ее по факту не везде. Стретить можно далеко не везде. Еще одна штука, которая связана с безопасностью очень тесно, это Storm Control. Шторм контролл. Механизм, с помощью которого вы можете снизить негативные последствия петли, когда она все-таки возникнет, несмотря на Spanning 3, несмотря на стекирование, несмотря на что-то еще. То есть, на самом деле, коммутация в Ethernet, механизм для Ethernet, они родной, поэтому рано или поздно оно может сломаться. И когда оно сломается, когда возникнет петля, у вас вся сеть очень быстро ложится. Чтобы она ложилась не так быстро, Storm Control может позволить вам выиграть немножко времени.

И у вас сеть будет в полудохлом состоянии, но полудохлое состояние это намного лучше, чем полностью дохлое. Что это такое? Это механизм, который позволит вам определить, что на каком-то порту приходит слишком много какого-то нездорового трафика, и тупо порт погасить. Если вы будете использовать этот механизм, то на цисках он работает следующим образом. Измеряет каждую секунду количество трафика, пришедшее за последнюю секунду. И если вдруг определяет, что за последнюю секунду пришло слишком много трафика, вырубает порт. Может дополнительно к этому посылать SNMP Trap. Может просто посылать SNMP Trap, не блокируя порт. Ну и может отдельно считать трафик разных типов. Broadcast, Multicast и Unicast. Про Unicast есть популярное заблуждение, что считается только unknown Unicast. На самом деле фигня, считается любой Unicast. Все, что не попало под определение Broadcast, все, что не попало под определение Multicast, все считается Unicast. Настраивается эта штука следующим образом.

Вы указываете для интерфейса для каждого конкретного типа трафика два пороговых значения. То есть первое пороговое значение – это верхняя граница, и второе – это нижняя граница. Каждую секунду вы измеряете количество трафика, прошедшее через интерфейс за последнюю секунду, за предыдущую секунду. И если за предыдущую секунду трафика прошло больше, чем верхняя граница, чем Rising Threshold, вы выключаете порт. Ну, соответственно, вы все равно продолжаете измерять, сколько трафика приходит на интерфейс. Если трафика по-прежнему приходит много, вы все держите порт выключенный, выключенный, выключенный, выключенный до тех пор, пока трафика не станет меньше, чем нижняя граница. И когда трафика приходит меньше, чем нижняя граница, вы порт разблокируете. Если ваш порт формировал петлю, то получится, что вы будете блокировать этот порт периодически. И если даже вы указываете, что вы блокируете порт по превышению какого-то количества, например, юнекастового трафика, то работать это будет следующим образом. Если у вас порт формирует петлю, количество трафика на порту начинает расти линейно, практически линейно.

Иногда это будет как-то криво, но рано или поздно оно просто превзойдет какую-то верхнюю границу, и вы дальше блокируете передачу трафика на порту. Немедленно после этого у вас, соответственно, количество трафика будет падать, если это действительно сформировалась петля. И дальше вы расслабляете булки, и дальше начинаете снова, снова начинает расти количество трафика на интерфейсе. И снова в какой-то момент вы блокируете временно коммутацию на порту, и у вас немножко сеть полежит, пока трафик заблокирована. Потом снова начинает расслабляться. Да, при этом у вас с маклерингом случится беда, да, при этом у вас много всяких других нехороших вещей будет происходить. Но, по крайней мере, сеть хоть сколько-то, хоть чуть-чуть будет живая. Можно будет настроить отдельно на работу с бродкастом, мультикастом и юникастом. Но чаще всего для защиты от петли используется как раз бродкаст, благо он как раз очень хорошо накапливается. И вы можете сказать, что если в какой-то момент количество бродкаста превосходит разумные пределы, то есть если вы знаете, что у вас гигабитный интерфейс, и вы знаете, что бродкаст у вас в сети, конечно, может быть много, но не может быть больше 100 мегабит.

Ну, просто не бывает такого, чтобы бродкастового трафика было больше 100 мегабит. Пришло на порту больше 100 мегабит бродкаста, порт в R-Disable и SMP-Trap админу пусть разбирается. Ну и, соответственно, да, это самый, наверное, правильный вариант, чтобы понять, что случилось такое с сетью, почему у нас возникла петля, несмотря на все наши меры, которые мы предпринимали. Можно настроить, чтобы R-Disable потом автоматически расслаблялся, но да, Storm Control на самом деле, хотя и может блокировать трафик временно, но лучше всего как раз порт, чтобы падал в R-Disable, просто практика показывает, что это наиболее надежный механизм. Если у вас сеть начала козлить из-за того, что случилась петля, вот эти все мягкие меры, типа немножко подержим порт в выключенном состоянии, а потом сразу включаем, но они не приводят к ожидаемому результату, все равно все будут недовольны, и лучше порт просто по R-Disable дропнуть, сеть будет работать стабильно.

Так, как настраивается? Есть три уровня, которые вы можете настроить. Настраиваются они на уровне интерфейса. Storm Control либо Broadcast, либо Multicast, либо Unicast. Но Unicast это все, что не Broadcast и все, что не хорошо распознанный Multicast. И, соответственно, дальше вы указываете уровни. Два уровня вы должны будете задать. Верхний и нижний. Верхняя граница, начиная с которой блокировать, нижняя граница, начиная с которой разблокировать. Можно указывать количество процентов. То есть, если вы указываете level, и дальше две цифры просто. Цифры указываются в процентах. 50 процентов, если у нас больше, чем 50 процентов трафика Broadcast на гигабитном порту, это явно какая-то нездоровая херня. Ну, соответственно, если у нас трафик начинает падать, Broadcast, падать ниже 30 процентов, то это значит, что херня уже стала здоровой, и можно снова порт включить. На мой взгляд, не стоит. Ну, да, пусть будет так.

Если вы не хотите считать, сколько там трафика у вас будет в процентах, вы можете сказать, сколько трафика будет в пакетах в секунду или в байтах в секунду. Можно задать только одно значение. Тогда, соответственно, все, что выше, будет блокироваться. Все, что ниже, будет разблокироваться. То есть это фактически вы задаете и то, и другое значение в одинаковое величину. Если вы указываете пакеты в секунду или биты в секунду, то можно указывать мультипликаторы K, M, G. То есть вы задаете, например, скорость в мегабитах или пакеты в секунду в килопакетах в секунду. Помимо того, что вы можете задать уровни, вы можете задать и поведение. Что делать, если у нас случается нарушение безопасности в Storm Control? То есть можно сказать, что надо ли гасить порт Action Shutdown или надо ли посылать trap админу. Можно делать и то, и другое. Какие точно значения должны указывать вы, это вы должны сами посчитать.

То есть хотите ли вы Unicast Storm Control включать? Я не уверен, я не включаю Storm Control Unicast, потому что на моих портах может и даже часто бывает 100% загрузка в течение длительного времени. Это в основном Unicast трафик. И с моей точки зрения, то, что порт 1, 2, 3, 10 секунд лежит 100% загрузки, это не нарушение безопасности. Поэтому Storm Control для Unicast я не включаю. Мультикаст, ну именно у меня в сети тоже бывают. И там всякие, например, WDS, Windows Deployment Services, они активно используют Multicast. И там хреново тучи этого Multicast трафика может быть. Поэтому в сети у меня тоже он случается. Поэтому я его тоже как бы не люблю включать. А вот Broadcast, по опыту могу сказать, да, что Broadcast имеет смысл включать, потому что Broadcast трафика больше, ну, 100 Мбит на Гигабитном порту, ну, никак не должно быть. Поэтому если случается такое, если мы видим, что Broadcast начал зависать, а что такое Broadcast, 100 Мбит Broadcast? Это всякие ARP, DHCP-запросы и прочая лабуда.

Начинает Broadcast ходить на порту слишком активно? R-Disable. С Unicast тут как бы сложный философский вопрос. Если вы знаете, что у вас в сети может быть много Unicast, и это не вызывает проблем, то вы можете не включать его. Но если вы знаете, что много Unicast, то у вас вызывает проблемы, что у вас в норме какой-то порт не должен падать 100% на нагрузку, а если он упадет, то будет плохо. То, значит, вы можете включить Storm Control. Для вас это нездоровая фигня, и вы должны будете с ней бороться. Поэтому это все индивидуально. Я говорю, нет никаких-то стандартных цифр. Часто бывает, люди приходят и говорят, сколько поставить мне значение Storm Control. Я не знаю, я не знаю вашу сеть, я не знаю, какие у вас стандартные нагрузки, я не знаю, что вызывает в вашей сети проблемы, что не вызывает. Я говорю, у меня бывает такое, что интерфейс целиком от Multicast в 100% нагрузки висит часами. VDS начинает разливать образы. И он, да, он с настроенным киосом может разливать это долго и упорно. Ну, а что сделать? Ничего не сделаешь.

Вот. Так что, да, никаких-то тут стандартных значений не бывает. Вы должны будете экспериментировать и подбирать самостоятельно все это. Я говорю, я вот настраиваю только Storm Control для Broadcast и настраиваю какие-то разумные цифры его. Можно посмотреть. Диагностика Storm Control покажет вообще все для Unicast трафика. Покажет все порты, на которых он включен и покажет состояние. Forwarding значит Unicast у нас... Простите, Broadcast. Broadcast. Storm Control Broadcast показывает. По умолчанию вот он говорит. Broadcast трафик у нас не блокируется. В то же время Storm Control Unicast показывает, что вот здесь у нас Unicast заблокирован, потому что сейчас пришло 37 Мбит, а у нас ограничение на 30 Мбит. Так. Если у вас интерфейс упал в R-Disable, либо по Port Security, либо по Storm Control, вы можете его снимать автоматически.

Можно сказать, что вообще в любом случае снимаем автоматически, либо снимаем автоматически по каким-то причинам. Я рекомендую, если вы это сделаете, указывать какой-то таймер разумный. То есть не надо слишком быстро пытаться снимать R-Disable, потому что иначе система, которая погасила порт, она его снова погасит через некоторое время. Поэтому указывайте причины разумного снятия R-Disable. Не надо снимать для всего подряд. Указывается это все командой R-Disable Recovery Cause. Вы указываете, какие причины для R-Disable имеет смысл снимать через некоторое время. К сожалению, нельзя сказать, что для одной причины мы снимаем статус R-Disable через одно время, а для другой через другое. Но, соответственно, можно указать только один глобальный таймер R-Disable Recovery Interval. И дальше, по-моему, в секундах это задается. То есть если порт упал в R-Disable через некоторое количество времени, по-моему, через 30 секунд или через 30 минут, там в справке покажется, сколько порт обратно вернется в рабочее состояние.

Можно посмотреть список всех портов, которые упали в R-Disable. Show Interface Status R-Disable. И если вы хотите снять статус R-Disable с порта до того, как сработает глобальный таймер, то вы можете просто шат-ноу-шат сделать. Хуже не сделать, потому что если порт уже лежит в R-Disable, на нем трафик не ходит. Поэтому, если только вы не ошибетесь с портом, ни шат-дауните какой-нибудь другой порт, хуже не будет. Если вы настроите автоснятие R-Disable, то есть команда Show R-Disable Recovery, которая покажет, какой у вас глобальный таймер настроен до 300 секунд. И покажет, какие причины для каждого конкретного типа будут легитимным, попадающим под автоматическое снятие статуса. Здесь все по умолчанию. То есть везде показано Disabled. Ну, из того, что имеет смысл включать, допустим, ARP Inspection, если мы говорим, есть ARP Inspection, которая может инспектить маки на портах. Не маки, а ARP-ответы на портах.

И если она увидит какое-то нехорошее поведение, она может либо порт заблочить, либо просто ARP неправильно пристрелить. Ну, то есть ответ ARP Inspection, который нехороший, он, конечно, не должен, наверное, вызывать R-Disable на порту целиком. Если только вы не хотите сказать, что любая нездоровая активность обязательно должна сопровождаться визитом службы безопасности. Тогда порт в R-Disable, паяльник на стол и начинаем дальше думать. BPD Guard однозначно ручками только счищает, потому что, да, если у нас есть какая-то BPD, которая прошла через интерфейс, на котором она не должна была появляться, не надо это автоматически разблокировать на мой вкус. Дальше. Что у нас там еще есть? Port Security Violation. Да, ну это очевидно, да, это Port Security сработал на ваш вкус. Можете хотите включить, хотите не включать. Storm Control, ну, тоже, как бы, я обычно включаю его для бродкаста, я обычно хочу, чтобы она автоматически не разблокировалась.

Если разблокировалась, то только через большое время. Поэтому я его автоматически не включаю. Ну и что-то здесь еще у нас бывает. Ладно, забыл. Мы с вами говорили уже про радиус, и для радиуса мы использовали 802.1Q. Кратенько напомню, что, в принципе, радиус не только для 802.1X будет работать. И, соответственно, если вы хотите, вы можете сделать, например, доступ к вашей линии управления с помощью радиуса. То есть у нас есть, например, железка, и мы хотим к ней подключаться удаленно по телнету. И вот мы говорим, что у нас те, кто будет подключаться по телнету, обязаны показать учетные данные. Эти учетные данные должны проверяться с помощью радиуса. Если вдруг у нас случится какая-то беда, и радиус отвалится, то мы хотим, чтобы на консоли можно было зайти с локальной учеткой.

Но по телнету с этой локальной учеткой зайти было нельзя. В то же время мы хотим, чтобы на консоль, в принципе, можно было зайти с учеткой радиусовской. Поэтому мы делаем два разных списка проверки методов, методов проверки учетных данных. Один будет называться RadiusLocal, второй будет называться RadiusOnly. RadiusOnly проверяет только по радиусу. RadiusLocal проверяет сначала на радиусе, а если там на радиусе не получилось проверить, радиус сломался, тогда по локальной базе пользователей. То есть в обоих случаях мы создаем два разных списка методов проверки учетных данных. AuthenticationLogin, подсистема Login. И вот здесь говорим сначала Radius просто, а потом ничего. Или здесь сначала Radius, потом локальная база. В отличие от, например, Juniper, где у вас указывается несколько методов проверки, и если один метод проверки сказал нет, это еще ничего не значит. В CISC используется другая логика,

что если вам Radius сказал, что учетные данные неправильные, прям заведомо отказ дал, то, соответственно, локальная база дальше уже проверяться не будет. Поэтому если вдруг у вас Radius живой, то он вам даст авторитативный ответ нет, и вы уже не будете проверять локальную базу. То есть если вдруг Radius работает и не пускает, то с этим ничего не сделают. Надо Radius просто тогда прибить, который неправильно работает, который не посылает вам Access Accept. То есть либо заставить Radius нормально работать, либо выключить его вообще, чтобы никакого ответа он не присылал. Если ответа от группы Radius нету, никакого ни позитивного, ни негативного, то только тогда проверяется следующий метод. Ну вот в нашем случае мы создали два списка. Один, который проверяет группу Radius, второй проверяет группу Radius, и потом локальную базу. В локальной базе мы создали пользователя с названием Local Admin и каким-то очень большим секретным паролем.

Обратите внимание на слово Secret, то есть в конфиге вот этой штуки храниться не будет, она будет храниться в виде хэша. И, соответственно, дальше мы создаем два Radius сервера, такой и такой, и объединяем их в группу Radius Group. Дальше на линии консоль мы говорим Login Authentication Radius Local, то есть сначала пробуем Radius, если он не отвечает, тогда локальную базу. И на линии управления VTI указываем Radius Only. Вот, и радуемся жизни. Так, неужели все? Закончили мы модуль про безопасность. Labu делать не будем, пожалуй, потому что как-то уже поздновато. У нас еще впереди остался последний модуль, посвященный протоколу.