Особенности дизайна сетей c Cisco IOS

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

Безусловно, нельзя открывать никакие порты управления, никакие возможности по управлению для внешних узлов, которые в интернете сидят. Нельзя открывать SSH или Telnet на ваших свитчах, роутерах для доступа из интернета. Но это не только про интернет. Злоумышленники могут быть не только в интернете, они могут быть внутри вашей сети. И нельзя точно так же открывать протоколы управления для внутренних узлов, которые находятся у вас внутри вашей сети, для которых вы и стараетесь, для которых вы открываете все доступы. Доступ в интернет — пожалуйста, доступ до каких-то DMZ серверов, за которые отвечают админы серверов — пожалуйста. А до интерфейсов управления ваших Cisco, Telnet, SSH, любые другие протоколы, тот же самый RIP — закрывайтесь. Если вы знаете, что на ваших железках есть RIP, пристреливайте любые пакеты, которые приходят от юзеров, на 520-й порт.

Это ваша обязанность. Закрывайте трафик просто обычной пакетной фильтрацией. Это очень надёжный, очень простой механизм, который решает 99% проблем. Такой подход называется инфраструктурные access-листы. Если вы используете этот подход, то везде, где у вас есть какой-то недоверенный источник трафика, вы отбрасываете пакеты, которые заведомо оттуда приходить не должны. Если вам кажется, что это очень много возможных вариантов, чего оттуда может прийти — нет, немного. По IP-шникам можно очень легко определить, кто чего присылает. Если вы видите, что приходит трафик на IP-шники ваших собственных роутеров снаружи, это уже криминал. Ни при каких условиях те, кто внутри сети сидят, не должны посылать трафик на IP-шники управления. В принципе. Если у вас есть какая-то внутренняя сеть, которой допустимо использовать IP-шники управления, это менеджмент-сетка, то пусть она имеет возможность посылать такие пакеты,

которые идут на адреса самих железок. Обычные абоненты никогда, ни при каких условиях, не посылают трафик на IP-шники управления ваших роутеров. И то же самое из интернета. Ни при каких условиях из интернета не должно быть возможно подключиться на IP-шники управления ваших устройств. Если у вас есть роутер или свитч, или что угодно, на котором есть IP-адреса, защищайте эти IP-адреса из интернета, чтобы подключаться на эти IP-шники было нельзя. Если у вас, допустим, MikroTik, на этом MikroTik'е WinBox, не делайте так, чтобы на этом MikroTik'е можно было подключиться снаружи по WinBox. Ограничьте доступ, сделайте пакетную фильтрацию, чтобы снаружи подключиться было в принципе невозможно. Если у вас Cisco, на этой Cisco VTY, Telnet, SSH, что угодно, закрывайте доступ, фильтруйте трафик на уровне интерфейсов. Access-лист на интерфейсе — железобетонная вещь. Через неё ничего не проскочит. Если вы знаете,

что у вас есть интерфейс, на котором вы смотрите в интернет, закрывайте оттуда мультикаст. Любой. RIP, OSPF, неважно. Закрывайте любой. У мультикаста очень характерные IP-шники. Их можно пристрелить, и никогда, ни при каких условиях, снаружи на вас мультикаст валиться не будет, если только вы не знаете точно, что он там есть, например, потому что там IPTV бегает по мультикасту. С этим уже ничего не сделаешь. Вы можете в явном виде сказать, что трафик именно IPTV, по каким-то критериям его можно отобрать. Он явно не похож на RIP, явно не похож на EIGRP, на OSPF. Пример. Если у нас есть интерфейс, который смотрит в интернет, мы говорим: запрещаем подключение на IP-шник нашего роутера, запрещаем прохождение пакетов, у которых IP-шник источника 0.0.0.0. Пакеты из внешнего мира с адресом 0.0.0.0 — это заведомо левак.

Запрещаем прохождение пакетов с адресом источника 127.x.x.x. Это адреса loopback, они никогда не могут быть в качестве адреса источника или в качестве адреса получателя. Поэтому, если мы видим такие пакеты, это точно левак. Запрещаем в качестве адреса источника мультикастовый адрес. Точно левак. Никогда такого быть не может. В качестве адреса назначения тоже мультикаст у вас снаружи быть не должен. Но это уже отдельная тема. Понятное дело, что всё это настраивается примерно похожим образом. Только здесь будет уже не any, а any 224.0.0.0/31 или что-то подобное. Дальше. Говорим, что пакеты, которые приходят к нам из интернета, очень маловероятно, что будут идти из-под частных адресов. Соответственно, фильтруем. 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16. Дальше. Не может быть такого, что из интернета будут приходить пакеты из-под наших собственных белых IP-шников.

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

что мы ставим сессию на него, на его 179-й порт, а есть вариант, что он ставит сессию на нас, на 179-й порт. Поэтому мы говорим: трафик от 10.1.1.1 BGP к 10.1.1.2 тоже должен ходить. В одном случае мы подключаемся на 179-й порт, в другом случае он на наш 179-й порт подключается. Это два разных сценария. Не может быть такого, что кто-то будет подключаться на нашу сеть управления. Снаружи, на интерфейсе, в интернет смотрящем, никогда, ни при каких обстоятельствах, пакеты не могут приходить на наши адреса управления. Если мы знаем, что у нас есть какие-то IP-шники управления, отбрасываем трафик, приходящий на них снаружи, это заведомо левак. Всё остальное разрешаем, потому что этот интерфейс, которым мы смотрим наружу, это интерфейс пользовательский. Там ходит пользовательский трафик. Мы ради пользователей всё это делаем. Здесь сидят юзеры,

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

Не засланный ли он казачок случайно? Давайте вместе пойдём разберёмся, что там такое случилось. В лучшем случае юзер просто вирус подхватил, и вы его заблокируете с помощью таких инфраструктурных access-листов. В худшем случае это будет действительно засланный казачок, который хочет украсть ваши секреты и пытается подключиться к вашим железкам. Используйте SNMP. Про SNMP мы говорили с вами на курсе ICND2, но сейчас быстренько повторю. Есть устройства, которые вы можете мониторить, есть универсальный протокол, с помощью которого это можно делать, Simple Network Management Protocol, и информацию из SNMP вы можете собирать в какую-то единую базу, и дальше историческую информацию поднимать, как ваши устройства вели себя в каждый конкретный момент времени. Все данные, которые можно с помощью SNMP запрашивать или изменять, будут фактически представлять собой своего рода переменные.

Каждая переменная будет поименована, и у неё будет название, но название не случайное, а так называемый OID — Object Identifier. И эти Object Identifier будут выстраиваться в некую иерархическую структуру. Вся эта структура будет называться MIB — Management Information Base. Имея конкретный объект, с которым вы хотите работать, вы можете по этой структуре проследить, откуда у него растут ноги. Допустим, у нас есть объект ISO, который имеет дочерний объект Organisation, который имеет дочерний объект DoD, который имеет дочерний объект Internet, который имеет дочерний объект Management, который имеет дочерний объект MIB-2. И мы запрашиваем объект по пути ISO — Organization — DoD — Internet — Management — MIB-2. SNMP имеет несколько версий. Наиболее популярные версии — это первая, вторая и третья.

Первая версия достаточно простая, там есть 5 типов сообщений и очень простая система аутентификации на основе пароля. Пароль передаётся plain text'ом, поэтому он даже не пароль, а просто такая секретная строка. Вторая версия, именно оригинальная вторая версия, появилась с довольно сложной моделью аутентификации. Там придумали пользователей, пароли, какую-то систему предоставления доступа к OID'ам разным для разных пользователей. Но она оказалась достаточно сложной, индустрия её просто не приняла. И поэтому придумали версию 2c, которая работает почти так же, как первая версия. В части безопасности всё точно так же плохо, просто community string используется. Но в неё было добавлено сообщение getBulkRequest, которое позволяет одним запросом запросить сразу несколько значений объектов. Штука довольно интересной оказалась и действительно сильно упрощала работу. По сути версия 2c — это единичка с новым типом сообщений, который ускоряет работу.

Почему не взлетела оригинальная вторая версия? Потому что индустрия привыкла работать с первой версией и сказала: мы уже придумали систему безопасности, с помощью которой мы эту штуку закрываем — IPsec. Поэтому когда придумали вторую версию, индустрия сказала: мы бы хотели продолжать работать с простой системой безопасности на основе community string, но по-прежнему закрывать всё это IPsec'ом. Но эта фича нам очень сильно нравится, пожалуйста, имплементируйте её. Но в конце концов индустрия пришла к тому, что во многих странах IPsec оказался под большим вопросом, потому что он позволяет шифровать пользовательские данные, а многие страны имеют очень серьёзную политику по шифрованию, что шифрование так или иначе находится под запретом. Поэтому специально для таких особых стран придумали SNMP версию 3, в которой штатно есть защита трафика именно SNMP. Пользовательские данные шифровать нельзя, а именно SNMP служебные данные зашифровать можно. Там есть кое-какая защита.

Там есть использование учётных данных по юзерам. Вы можете создать отдельных юзеров, можете раздать им отдельные пароли. Но в этой системе защиты есть уязвимость. Уязвимость заключается в том, что при попытке подключения к системе от конкретного отдельного пользователя там нет ничего, что по смыслу называлось бы nonce — одноразовый какой-то элемент. Поэтому если вдруг у вас есть юзер, который подключается Фактически можно просто долго, упорно пытаться перебирать пароли одного и того же юзера И рано или поздно у вас это получится сделать И один раз вы получите доступ к пользователю После этого вы будете продолжать иметь доступ к системе до тех пор, пока пользователь не сменит пароль Поэтому штука сомнительная, но на экзамене будут по ней вопросы В реальности чаще всего используют SNMP версии 2C с накрытым поверх IPsec

Как включить SNMP на Cisco? Самый простой вариант — вы включаете SNMP-сервер, community Дальше называете вашу парольную строку Указываете, что доступ у вас только на чтение И указываете номер или имя access-листа Из-под которого можно подключаться по SNMP к вашей железке И access-лист у вас, например, 99-й говорит Подключаться можно только из-под сети 192.168.1.0 по 24-й маске Очень простой механизм, с помощью которого вы говорите У нас есть IP-шники системы управления, на которой работает SNMP-менеджер Он может подключаться к нашей железке Все остальные не могут Если вы это сделаете, вам фактически даже парольная строка не нужна Поэтому я вам не рекомендую использовать для SNMP какие-то хитрые парольные строки Эти community string Используйте public На самом деле это в подавляющем большинстве ситуаций не является проблемой Именно потому не является, что всё равно сколько-нибудь серьёзной защиты эти самые community string не предоставляют

Поэтому если вы настраиваете какой-то софт, он, скорее всего, преднастроен на работу с community string public Просто калорий меньше придётся потратить для того, чтобы всё настроить Если хотите, конечно же, настраивайте разные community string Но в любом случае public — это первое, что вам должно прийти в голову при настройке Дальше, когда вы начинаете перебирать объекты, которые вас будут интересовать Вы можете воспользоваться либо утилитой SNMP-get и в явном виде запросить нужный вам OID Либо вы можете перебрать дерево Сказать относительно корня дерева, который вас интересует, перебрать все возможные дочерние объекты В нашем случае мы видим, что перебираем кусок дерева начиная с вот такого узла И дальше все дочерние элементы, все branch-и нас будут интересовать И здесь видно, что у нас есть System Description, он же описание системы У нас есть HostName, он же SystemName У нас есть SystemContact — это просто какая-то текстовая строчка, в которой можно закодировать, кто настраивал эту систему Uptime — всё это действительно там есть Можно запросить только одно значение одного объекта, вот как здесь И мы видим, что у нас, например, HostName, он же SystemName, здесь показывается Если вы хотите работать с сетью, в которой могут происходить какие-то изменения

То все изменения вы хотите журналировать И самое первое, что вы захотите журналировать — это локальные журналы ваших железок Если на железке что-то произошло — там интерфейс поднялся, упал, кто-то железку проадминил, что-то ещё То всё это удобно складывать в журналы внешнего сервера Вы можете заставить вашу Cisco складывать все ваши логи на флешку Но тогда у вас очень быстро флешка как ресурс выжжется Потому что количество логов, которые она может складывать, может быть довольно большим Syslog — это универсальный формат передачи системных журналов И заголовок у этого Syslog будет очень маленький — однобайтовый Он делится на два поля: 5 бит facility и 3 бита важность, или severity Когда пробегает какое-то системное сообщение, мы видим, что это текстовое сообщение есть — просто текстовая строчка Она предваряется однобайтовым заголовком, в котором 5 бит и 3 бита будут относиться к facility и severity И отправляется на сервер в UDP на 514 порту Чаще всего Cisco работает с facility 23, так называемый local 7 журнал Вы в принципе можете заставить вашу Cisco использовать любой другой журнал Но в операционной системе Unix первые 16 журналов зарезервированы под всякие разные системные вещи И вам по факту доступно только 8 разных журналов, которые называются от local 0 до local 7 По умолчанию валится всё в local 7, пусть туда и валится А важность — это уже будет интересное поле Потому что по важности вы можете определить, насколько важное было сообщение И 3 бита дают нам 8 разных значений от 7 до 0 7 — самая неважная, 0 — самая важная На экзамене нужно знать порядок этих сообщений

Нужно знать точное наименование: Emergency, Alert, Critical, Error, Warning, Notification, Informational, Debug Debug, понятное дело, самое неважное Потом Informational — что-то, что вас может заинтересовать, но оно никаких последствий за собой нести не может Notification — что-то, что вас может заинтересовать, и может быть такое, что будут какие-то последствия, поэтому на это стоит обратить внимание Warning — важная ситуация, которая наверняка в ближайшее время повлечёт за собой какие-то последствия Error, понятное дело, ошибка — уже последствия есть, уже что-то работает неправильно Critical — какая-то большая подсистема работает неправильно, что-то пошло настолько не по плану, что изменения уже будут необратимы Alert — глобальный сбой, но система пока ещё работоспособна в каких-то хотя бы частях Emergency — система неработоспособна, Kernel Panic Я один раз видел Emergency — это именно был Kernel Panic Как-то так Если вы хотите настраивать Syslog, то делается это следующим образом Всё происходит в контексте логинга Указываете IP-шник лог-сервера и указываете, какие сообщения вы хотите посылать Logging trap — и дальше указываете уровень важности сообщений

Обычно используют informational, чтобы не отсылать debug Сообщения, которые Cisco будет генерировать для системного журнала, будут состоять из текстовой строки И у этой текстовой строки есть своего рода предсказуемый формат Там через процент указывается так называемое facility — это не facility Syslog, это facility Cisco, с какой подсистемой возникло сообщение Дальше severity — это уже совпадает с severity Syslog и по смыслу, и по всему Updown — соответственно, что случилось, краткое мнемоническое описание И дальше уже полнотекстовое описание, которое вы можете каким-то образом парсить, если захотите Если вы работаете на цисковской железке и вы посылаете сообщения на системный журнал То вы, возможно, захотите нумеровать эти сообщения Для того, чтобы, если вдруг вы посылаете вообще всё, включая debug, можно было отследить, что какие-то сообщения, возможно, не пришли Это нужно делать для расследования инцидентов Если вы видите, что у вас была Cisco, которая, возможно, скомпрометирована, на которую, возможно, заходил какой-то вражеский пользователь И вы видите, что сообщения журнала идут 23, 24, 25, а потом сразу 29 И 26, 27, 28 нету То вы понимаете, что там что-то могло произойти В то же время, если вы видите, что сообщения системного журнала идут по порядку и там нету сообщения «меня кто-то проадминил» Значит, скорее всего, эту Cisco уже никто не админил, и она осталась нескомпрометированной С некоторой ненулевой вероятностью Добавляется эта команда — service sequence numbers Если вы это делаете, то сообщения, которые будут отправляться на syslog и генерироваться на консоли, будут предваряться уникальным номером Дальше, если вы хотите, вы можете добавить в системные журналы время, когда конкретное событие было создано Service timestamps, дальше вы указываете log И здесь можно задать кучу разных параметров Если вы указываете log datetime, то у вас будет каждое сообщение предваряться временем и датой, когда оно сгенерировалось Причём это будет по универсальному координированному времени, по UTC

Если вы хотите в локальном часовом поясе показывать, то здесь datetime, по-моему, localtime-zone — параметр будет localtime-zone, что-то такое И надо ли показывать этот самый часовой пояс — по умолчанию он не показывается, но если вы хотите, можно его показывать Довольно частая штука И даже если вы не используете syslog, всё равно удобно, когда сообщения журнала будут показываться по вашему времени Ещё раз подчеркну: по умолчанию логи Cisco собирает по UTC Даже если вы настроите локальный часовой пояс на железке, всё равно логи будут по UTC Но если вы указываете, что в service timestamps log вы должны указывать время по локальному часовому поясу То вы можете переключить вашу Cisco, чтобы она вела логи по локальному часовому поясу Кстати, ещё один важный нюанс В каждом сообщении Cisco сама будет добавлять текстовую метку со временем Когда syslog-сервер будет получать сообщение, он, как правило, тоже запоминает, во сколько он получил определённое сообщение Поэтому у вас будет два времени Первое — когда Cisco сгенерировала определённое сообщение, второе — когда оно пришло на сервер Чаще всего эти метки времени будут близки друг к другу, но далеко не всегда Потому что, например, если у вас интерфейс, которым Cisco отправляла эти сообщения, упал То система отправлять сообщения не может, она сидит, ждёт и копит их А потом, когда интерфейс поднялся, она выпаливает их все одновременно И на syslog-сервер пачка сообщений придёт одновременно Syslog-сервер увидит несколько сообщений, приходящих в одну и ту же секунду Но внутри каждого сообщения у вас будет стоять метка, когда оно по факту сгенерировалось Поэтому хорошая идея будет держать на всех железках правильное время, проверенное по, например, NTP И хорошая идея будет отправлять эту метку времени в сообщениях syslog на сервер Чтобы у вас были доверенные метки времени И те, которые серверные, которые действительно доверенные, но показывают, когда сообщение было получено И метка времени, сгенерированная железкой, которая чуть менее доверенная, потому что злоумышленник, который зашёл на железку, может метку поменять

Но тем не менее она показывает лучшую информацию о том, когда произошло событие NetFlow — тоже важная штука, которую вы должны будете использовать в сети Мало собирать сообщения журнала, мало собирать статистику по SNMP Вы должны будете ввести учёт, кто куда чего ходил Эта штука собирает информацию из заголовков транзитных IP-пакетов Запоминает, какие потоки у вас были, какие пакеты в рамках этих потоков отправлялись, сколько их было, какого они были размера При этом она не анализирует содержимое Это похоже на счёт, когда вы в конце месяца получаете распечатку телефонных переговоров Вы видите, что вы разговаривали по телефону с соседним городом, вы понимаете, сколько это продлилось, вы понимаете, что вы звонили по такому-то номеру Но вы не видите, о чём вы разговаривали В распечатке телефонных переговоров, как с обычным мобильным провайдером Если вы пользуетесь мобильной телефонией, вы получаете периодически счёт в конце месяца В нём написано, куда и сколько вы звонили Там не видно содержимого Да, может быть, товарищ майор и слушает, и может быть, он и расшифровывает ваши звонки, но он, по крайней мере, об этом вам не говорит NetFlow — это как раз механизм, с помощью которого вы можете собирать статистику, кто куда отправлял пакеты, но не будет видно содержимого самих пакетов Очень полезная информация внутри сети для определения активности пользователей Если вдруг кто-то выжрал весь интернет, то NetFlow вам поможет сказать, что это был Петя Если вы провайдер, можно будет на основе NetFlow сделать биллинг, ну такой кривенький, косенький Или, если вы не провайдер, если вы хотите просто в сети предприятия в ближайшее время какие-то решения принять по модернизации сети, модификации То NetFlow может вам помочь понять, как работает ваша сеть, в какое время какие приложения чаще всего используются И на этапе дизайна определённых решений вы эту информацию сможете использовать с очень большой выгодой Я настоятельно рекомендую NetFlow вам внедрить в вашей сети, если он ещё не внедрён Просто потому что вы будете понимать, что в вашей сети происходит, кто жрёт весь трафик, какие сервисы работают

Честно сказать, когда я первый раз в сети предприятия внедрил NetFlow, я был очень удивлён Я не знал, что, оказывается, есть столько всяких левых приложений, которые в этой сети бегают Но тем не менее NetFlow позволил мне их выявить и позволил разобраться с тем, что там действительно происходит На Cisco для того, чтобы включить NetFlow, нужно будет указать, куда вы будете отправлять пакеты NetFlow NetFlow использует UDP и любой порт, который вы захотите Чаще всего используют 9996, но это не какой-то стандартный порт, потому что NetFlow — это фирменный цисковский протокол Есть стандартный протокол IPFIX, который на основе NetFlow построен, но его далеко не все коллекторы умеют поддерживать Коллектор — это то, куда вы будете отсылать вашу собранную статистику NetFlow будет состоять из того, кто собирает статистику — маршрутизатора, и коллектора, который принимает от маршрутизатора

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

тем меньше места на диске требуется, но и тем менее точные становятся отчеты. Говоря по-русски, у вас есть, например, роутер. Через этот роутер какой-нибудь, не знаю, Сережа, начинает качать трафик. Он качает это дело очень быстро. Вы настраиваете вашу циску на то, чтобы она раз, например, в 10 секунд отправляла отчеты на сервер. Мальчик Сережа быстро скачивает много-много данных за 10 секунд. Соответственно, у него статистика получается, что он скачал там условно 1 гигабайт за 10 секунд. Роутер отправляет на сервер статистику, что за 10 секунд скачено 1 гигабайт, средняя скорость получилась там условно говоря 100 мегабайт в секунду. Теперь другой момент. Когда вы указываете, что у вас есть вот эти вот самые потоки, за которые считается статистика, вы можете сказать, что срок жизни вот этого потока может быть больше. Ну, например, там, не знаю, 10 минут. Поэтому мальчик Сережа начал качать гигабайт,

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

каждые 10 секунд валится информация, что произошло за последние 10 секунд. Не просто, что за последние 10 минут был скачен гигабайт, гигабайт одна штука, а что вот отдельно сейчас было скачено 100 килобайт, отдельно сейчас было скачено 150 килобайт. Ну, короче говоря, да, это получается много-много-много данных, и хранить эти данные, может быть, не очень интересно. NetFlow будет оперировать термином поток, и поток – это совокупность пакетов с одинаковыми параметрами. Есть некоторые разные версии NetFlow. Вот, например, Cisco NetFlow пятой версии. Параметры потока считают следующим образом. У потоков, у все пакетов потоки, одинаковый входящий интерфейс, одинаковый IP-шник отправителя, одинаковый IP-шник получателя, одинаковые вложения, что внутри лежит, одинаковый порт отправителя для TCP, UDP, или если вдруг какие-то другие протоколы используются, это поле по определению считается одинаковое,

одинаковый порт получателя для TCP, UDP, тип или код для SMP, ну, если это TCP, UDP или SMP, и одинаковый Type of Service. Соответственно, если вы видите пакеты, которые проходят через ваш роутер, и у них одинаковые вот эти вот параметры, то вы их расцениваете как один поток, и в рамках потока вы считаете статистику за весь поток. У вас проходит пакет, вы говорите, я знаю, что этот пакет идет в рамках потока, я к тому потоку прибавляю счетчик, что пакетов там на единичку больше, общий размер проходящих пакетов, прибавляю размер проходящего пакета, ну, и там что-то еще можно считаться. Вот если вы будете использовать какие-то другие версии NetFlow, там, возможно, будет считаться как-то по-разному, но CISC считают вот так. Стандарт NetFlow, ну, опять же, да, стандарт плохое слово, решение NetFlow будет очень сильно зависеть от конкретной реализации конкретной железки, и для разных протоколов, соответственно,

поведение может немножко отличаться. Может быть такое, что конкретно, вот если вы включаете на CISC-ах версию, там, например, 9, то еще, например, адреса MAC, адреса должны быть одинаковые. Ну, да. То есть на экзамене вас будут спрашивать только про вот эти 7 пунктов. Опять же, они же будут фигурировать в книжке. Чтобы включить NetFlow, вы должны будете на интерфейсе сказать, что вы хотите, исходящий или входящий, или тот, а другой трафик, подсчитывать проходящий через этот интерфейс. Считается только транзитный трафик. IP Flow Ingress вы считаете входящий трафик, IP Flow Aggress вы считаете исходящий трафик. После того, как вы посчитали, вы должны будете сказать, что с полученным трафиком сделать. Можно будет указать адрес какого-то коллектора, куда вы хотите отправлять информацию о собранных потоках, собранных потоках, и сказать, в какой версии вы будете это делать. NetFlow есть разных версий, то есть их там 10 штук. Большую часть этих версий вы никогда в жизни не увидите,

они были сугубо тестовые. Первая версия поддерживает только IPv4, и она устарела, так что с ней вы, скорее всего, работать не будете, но ее поддерживают все циски. Версию 5 поддерживает только IPv4, и она есть во многих коллекторах, в том числе и бесплатных, и некоторых платных, и она только она есть. То есть вы не можете сказать, что давайте использовать более новую версию, просто потому что в коллекторе поддерживается только это. Ну, не самый плохой вариант, в конце концов. Если вы включаете версию 9, то она поддерживает и IPv6, она поддерживает MPLS, она поддерживает всякие разные другие штуки, она поддерживает указания, куда идет трафик. То есть вы можете при сборе статистики показать, на какой IPшник NextHop вы его отправляете. Но, соответственно, да, не все коллекторы его умеют. Если вдруг у вас коллектор умеет версию 9, вдруг ваши циски умеют версию 9, конечно же, имеет смысл включать V9. На основе девятки

сделан протокол IPv6, это стандартный RFC-шный протокол. Он очень похож по структуре на версию 9, но у него там в поле версии стоит 10. IPv6 умеют некоторые роутеры, продвинутые на основе операционной системы XE или XR. Но ИОСовские железки, как правило, IPv6 не умеют. Вот. Ну, вы должны будете сказать IP, FlowExport, Destination, IPшник и порт. И дальше IP, FlowExport, версию. И дальше ту версию, которая у вас поддерживается. Поддерживается отправителем и, естественно, получателем коллектором. Можно будет посмотреть, чего ваш роутер понасобирал, понаколлектил, но еще не отправил на коллектор. Show IP Cash Flow. Покажется распределение по размерам пакетов, покажется распределение по протоколам, и покажется, какие актуальные потоки через ваш роутер проходят. В нашем случае мы видим, что у нас сейчас есть активный поток, который приходит через гигабитный интерфейс, гигабит 00, идет из-под IPшника источника такого,

на IPшник получателя такой, выходит через вот такой интерфейс. Что внутри лежит? Поле протокол 0.6, это у нас TCP. Дальше. Source IP 0407, это какое-то там, чего-то там большое. 1024 плюс 7, 1029. Это в 16-ти речном выражении 0407, двоичном 1029. destination порт 0017, это 16 плюс 7, 23. TCP, 23, что-то нам это напоминает, да? TCP-Tilnet. Ну и вот 9 пакетов прошло в рамках существующего потока, и возможно пройдет еще. Ну, когда пройдет, тогда пройдет. Мы здесь это зафиксируем. И вот эта вот информация периодически сливается на коллектор. Коллектор анализирует, что вот у нас есть поток с вот такими характеристиками, прошло через это, вышло через это, прошло с такого адреса, вышло через такой, внутри лежит вот это, пакетов вот столько, порты были вот такие. И у себя накапливает, что такого-то числа, в такое-то время мне пришла статистика,

что Вася, Петя слил 9 байт, или там 9 пакетов, 115 байт. Если у вас есть CIS-ки, у них есть конфигурация, и эта конфигурация может представлять определенный интерес. Если вы хотите эту конфигурацию бэкапить, можно это бэкапить через какие-то системы типа Ansible или что-то в этом духе, а можно воспользоваться штатной фичей CIS-ок, которая позволит вам бэкапить конфиги на внешний сервер. Вот, например, здесь показан пример, как бэкапить конфигу на FTP-сервер. Мы создаем систему архивации, говорим архив, дальше указываем, куда архивировать нашу конфигурацию, прописываем путь дальше FTP, двоеточие админ, двоеточие CIS-ка-123, собака 10123, слэш, доллар, h.cfg. Это шаблон для того, чтобы именно туда сливать наши конфиги. По факту будут браться учетка админ с паролем CIS-ка-123,

дальше по FTP мы будем подключаться на IP-шник 10123, и будем туда в корень складывать файлы с названием hostname.cfg. Ну, точнее, не hostname, там будет чуть более хитро. Название файла будет содержать в себе и hostname, и номер конфига. И после этого мы указываем, что сливать надо раз в 1440 секунд, и плюс сливать надо каждый раз, когда у нас происходит обновление конфигурации. То есть, если вдруг мы чего-то проадминили, сохранили конфигу, вот сразу копия этой конфиги ушла в сторону FTP-сервера. Если вдруг мы потеряем эту железку, она сгорит, не знаю, там ее украдут, что-то еще, конфиг у нас останется на внешнем сервере. Можно посмотреть, какие конфиги были созданы. Вот здесь вот мы показываем, что мы сохранились. Копия runningconfig, startupconfig. Каждый раз, когда мы сохраняемся, у нас система сливает конфигу на внешний сервер, и вот пробегает сообщение в writing r1-1.

Вот эта штука – это hostname, подозрительный hostname, потому что у нас роутер, конечно, должен называться r1. Но, тем не менее, r1-1. Это конфиг номер 1 роутера r1. И showarchiv покажет, какие именно архивы мы по факту сохранили. Да, вот роутер 1.1, роутер 1.2, роутер 1.3, роутер 1.4. Напротив наиболее свежего показывается most recent. Там круговой буфер, поэтому… Кольцевой буфер, поэтому всего этих слотов будет 9, 10. И, соответственно, вот там 5, 6, 7, 8, 9, 10, потом 0, 1, 2, 3, 4 и так далее. Они будут перезаписываться постоянно. То есть одни и те же имена файлов, и напротив какого-то из них будет показываться, что это наиболее актуальная версия. Опять же, имеет смысл эту штуку сделать, если она у вас еще не сделана. Если вдруг у вас цисок много, и какой-то системы управления конфигурациями нету, то бэкапьте ваши конфиги. Выключайте ненужные сервисы.

Очевидная подсказка. Да, мы на ACND 2 еще повторяли ее. Что нужно будет очевидно отключать? No CDPRan. Отключайте CDPRan, если только у вас нету циска телефонов. Выключайте BootPi-сервер, если он у вас не используется, если вы нигде не загружаетесь в бездисковых рабочих конфигурациях. Выключайте DHCP-сервер, если он у вас не используется. Выключайте SourceRoot-опцию, чтобы нельзя было на отправителе пакета указать опцию, как маршрутизировать ваши пакеты. Вот, естественно, это будет вредительство. Выключайте HTTP, HTTP-секюр-сервера, HTTPS. Выключайте ProxyARP. Выключайте IP-редиректы, обработку на интерфейсе IP-редиректов, чтобы если вдруг кто-то вам присылает указание, что ходи, пожалуйста, в интернет через меня, ну вот чтобы вы такие штуки не обрабатывали. Ну да, то есть здравый смысл должен вами руководить.

Некоторые вещи в цисках небезопасны и включены по умолчанию, ну как, например, тот же самый CDP. Их надо выключать в явном виде. Некоторые вещи включены по умолчанию, но вы можете их выключить, если вы их не используете. Это как, например, DHCP-сервер. Некоторые вещи могут быть включены по умолчанию, но они видны в конфиге, как тот же HTTP-сервер. Если он включен, то вы в конфиге такую строчку увидите. Тогда вы выключаете её. ProxyARP и редиректы в конфиге не видны, но всё равно их выключать надо, потому что это угроза безопасности или угроза нормальной работоспособности сети. Если у нас есть протокол, который подвержен проблеме обратной редистрибуции маршрутов, то при работе с двойной редистрибуцией вы столкнётесь с такой ситуацией. Представьте себе, что у вас есть RIP. Фактически из всех протоколов, которые мы с вами прошли, только он будет подвержен этой проблеме, потому что и OSPF, и EIGRP имеют очевидное различие

между маршрутами нативными и маршрутами редистрибученными. Поэтому если какой-то маршрут из OSPF уйдёт в какой-то другой протокол, а потом вернётся, то нормальный роутер OSPF никогда не выберет этот маршрут в качестве хорошего. Но RIP не различает маршруты, которые нативные и которые редистрибучены. И смотрите, какая штука. У вас, например, может быть ситуация, когда есть некая сетка на роутере R1. Роутер R1 анонсирует эту сеть за одну копейку. R2 говорит: я знаю, как добраться до этой сети за 2 копейки. Дальше. R3 выполняет редистрибуцию из RIP в OSPF и говорит: я знаю, как добраться до этой сети. И указывает там метрику второго типа, 20 копеек, 20 долларов. Это LSA-5 распространяется на все роутеры. И роутер R5 говорит: я знаю, как добраться до такой сети в OSPF. Дальше он выполняет обратную редистрибуцию в RIP и говорит: я знаю, как добраться в RIP до этой сети. И он анонсирует эту сетку и говорит:

я знаю, как добраться за одну копейку. Если вы поставите метрику в одну копейку, он будет говорить: я знаю, как добраться за одну копейку. И получается, на роутере R3 у вас приходит маршрут за 2 копейки, и приходит маршрут за одну копейку. Как вы думаете, кому будет доверять R3, через кого он будет говорить, что знает, как добраться до этой сети? Естественно, он будет доверять тому, кто присылает этот маршрут за одну копейку. Он маршрут через R2 будет игнорировать. И он в таблице маршрутизации поставит маршрут RIP в сторону R5. Но тем не менее он его всё равно будет редистрибутить. И у вас получится петля маршрутизации. Эти роутеры будут друг на друга смотреть. И трафик в сторону оригинальной сети А из OSPF ходить не будет. Поэтому, если вы такие штуки делаете с двойной редистрибуцией, то вам нужно будет убедиться, что те маршруты RIP, которые попали в условный OSPF или EIGRP, или BGP, или что-либо ещё, и потом обратно редистрибутнулись, что они не формируют петлю внутри сети. Это можно сделать, либо сделав так, что маршруты OSPF в RIP редистрибутятся с какой-то очень большой метрикой,

например, не единичку вбрасывать, а десятку, тогда нативные RIP-овские маршруты будут иметь метрику заведомо меньше, чем 10, и они будут всегда выбираться внутри сети. Либо вы можете сказать, что в OSPF из RIP мы анонсируем все маршруты, но мы их покрасим каким-то образом. Мы скажем, например, что метка у этих исходящих маршрутов будет какая-нибудь 520. У RIP порт 520, поэтому мы как раз 520 метку ставим, что это маршруты из RIP прибежавшие. И когда мы на второй точке редистрибуции перекладываем маршруты из OSPF обратно в RIP, то мы маршруты с 520 меткой не принимаем для обратной редистрибуции. Вот пример. У нас есть OSPF и RIP. Мы хотим сделать так, чтобы маршруты OSPF-овские не попадали в RIP, а RIP-овские не попадали в OSPF, если это обратная редистрибуция. Для этого мы можем использовать команду redistribute по route-map или distribute-list.

Что мы делаем? Мы создаём route-map, говорим: route-map, который будет перекладывать маршруты из OSPF в RIP, не будет перекладывать маршруты, у которых будет метка 120. Но в то же время, если он перекладывает какие-то другие маршруты, если он видит, что маршрут не 120 меткой помечен, то он говорит: я перекладываю такой маршрут, пермичу его и проставляю метку 110. Всё, что мы не зарубили, мы редистрибутим, но выставляем метку 110. То же самое в обратную сторону. Если мы берём route-map RIP-to-OSPF, мы говорим: всё, что имеет метку 110, мы блокируем, а всё, что не имеет метку 110, мы проставляем метку 120. И в настройке роутера RIP мы говорим: перекладываем маршруты из OSPF и используем назначение меток и фильтрацию по меткам с помощью route-map RMOSPF-to-RIP.

И в обратную сторону redistribute RIP subnets, route-map RIP-to-OSPF. В этом случае то, что приходит из RIP, попадает в OSPF. Это у нас RIP. Это у нас OSPF. И то, что из RIP в OSPF попадает, попадает с меткой 120. Не с метрикой, а с меткой 120. И обратно метка 120 не проходит. А то, что мы перекладываем из OSPF в RIP, мы перекладываем с меткой 110. И то, что обратно из RIP в OSPF забирается, 110 метка не проходит. Такой очень простой способ, как можно защититься от проблемы с двойной редистрибуцией в двух точках. Что ещё нужно будет сделать в совершенно любой сети? Нужно будет защититься от того, что вашу конфигурацию утащат, или ваш пароль потеряют, или что-то ещё. Короче говоря, вам нужно будет использовать схему с авторизацией, аутентификацией и аккаунтингом.

Различайте, пожалуйста, эти явления. Аутентификация — это про то, кто. Это ответ на вопрос: с кем мы имеем дело, кто ты. Авторизация — это что ты имеешь право делать. И аккаунтинг — это что ты сделал по факту. Например, вы входите в Сбербанк Онлайн. Вы вводите логин-пароль. Вы тем самым подтверждаете, что это вы. Что это действительно вы, а не кто-то ещё. Потому что только вы знаете свой логин-пароль. И никто, кроме вас, этот логин-пароль ввести не может. Дальше вы входите в Сбербанк Онлайн. Вам говорят: хотите заплатить куда-нибудь денег. Вы говорите: да, я хочу заплатить денег. Я хочу перевести деньги по определённым реквизитам. И вы вводите, кому вы хотите отправить деньги. И вам приходит СМС-ка. Эта СМС-ка — это на самом деле ваша авторизация банку. Вы говорите: банк имеет право провести эту транзакцию. Это не просто кто-то получает запрос «имею ли я право провести эту транзакцию».

Это именно вы, как владелец счёта, получаете СМС-ку. Вы говорите: да, я подтверждаю тебе, дорогой банк. Ты действительно имеешь право провести эту транзакцию. Я тебе даю своё разрешение. Это не то, что кто-то украл мой логин-пароль, представился мной и пытается провести эту транзакцию. Это действительно я тебе подтверждаю, что даю право выполнить такую транзакцию. Это у нас авторизация. И аккаунтинг — когда вы в Сбербанк Онлайне видите, какие операции кто где совершил. В случае с цисками информация AAA может храниться в разных местах. Самый простой способ, который по умолчанию у всех используется, — это локальная база. У вас там и учётки лежат, и указания, кто куда чего может делать, всё там же в одном месте. Намного удобнее, когда у вас база учёток и база указаний, кто может выполнять какие-то задачи, хранится централизованно на едином сервере. Если у вас там 100–500 цисок в организации используются, то у вас всего один или два сервера хранят учётные данные, и любая циска при подключении к ней администратора говорит «скажи, кто ты»,

и проверяет введённые учётные данные на центральном сервере AAA. И если вдруг у кого-то украдут пароль, то поменять пароль надо будет не на 100–500 цисках, которые у вас в сети используются, а только в одном месте на центральном сервере. Если у вас добавляется новый юзер, то вы не на 150 цисках добавляете нового юзера, а только в одном месте. Если у вас увольняется кто-то, вы блокируете учётную запись в одном месте, а опять же не на 150 цисках. Чем хороша локальная база? Самый простой способ. Чем плоха она? Нет поддержки аккаунтинга, не масштабируется совершенно. Если у вас много узлов, то локальная база становится очень большой проблемой. Плюс к тому хранение данных на локальном устройстве создаёт проблему безопасности. Если у вас небольшая сеть, то локальная база в принципе достаточно неплохой вариант. Если у вас устройств много, то надо смотреть централизованный вариант, где учётные данные создаются, изменяются, удаляются, хранятся централизованно в одном и том же месте.

Можно применять политики доступа, можно использовать авторизацию. Вы скажете, что у нас есть Вася, которому даётся разрешение на администрирование устройства совершенно любыми параметрами. Есть Петя, которому даётся доступ только, допустим, на show version. Централизованная база позволит вам использовать аккаунтинг, по сути аудит. Вы можете вести логи, кто чего где делал. Естественно, это может гипотетически повлиять на то, что у вас будет единая точка отказа. Но если вы правильно всё сделаете, то по идее этого произойти не должно. Про IP SLA мы уже с вами говорили. Тоже хорошая идея мониторить, что у вас в сети происходит. В случае с policy-based routing SLA может вам позволить переключиться на запасной канал. И плюс, если вы хотите, вы можете сделать что-то типа того, что на слайде нарисовано — добавление так называемого floating route,

условное добавление маршрута. У нас ситуация, что есть основной канал в интернет, есть запасной канал в интернет. Мы хотим штатно пользоваться основным, но если он перестаёт, допустим, пинговаться, переключаемся на запасной. Можно сделать это с policy-based routing, а можно сделать просто со статическими маршрутами. Создаём маршрут 0.0.0.0 0.0.0.0 через IP-адрес 10.1.1.1, 10.2.2.2, 10.1.1.1. Даём ему административное расстояние — вот это 10, это AD. И говорим, что track 10 — этот маршрут добавляется в таблицу только если у нас объект трекинга номер 10 живёт. Объект трекинга номер 10 связан с зондом IP SLA 1. IP SLA 1 пингает внешний узел 1.1.1.1 где-то здесь. Покуда пинги здесь ходят, у нас этот маршрут посылает весь трафик через первый канал. Если пинги перестают ходить, циска перестаёт пинговать соседа,

зонд падает, объект трекинга падает, маршрут из таблицы маршрутизации уходит. И у нас начинает работать маршрут с административным расстоянием 20, который мы добавили. И он будет смотреть в ту же самую сетку, но через другой next hop. У нас трафик начинает ходить через нижнего провайдера. Это такая штука, как можно очень легко и без всяких policy-based routing обойтись для выхода в интернет через двух провайдеров. Можно с динамикой. С динамикой вы не можете сделать легко отслеживание по трекингу. Эта штука хорошо работает со статикой, именно потому что вы можете сделать статическую запись ip route и указать: добавлять этот маршрут, только если выполняются определённые условия. Как в OSPF сказать, что если у нас есть динамический маршрут? Тоже через объект трекинга. Вы можете трекинг сделать, объект трекинга, и сказать: объект трекинга живёт только тогда, когда у вас есть маршрут в таблице маршрутизации.

А вы знаете, что этот маршрут приходит только по OSPF. Через объект трекинга вы можете это сделать. Всё, господа, всё. Мы завершили наш курс по роутингу. Он занял аж на три дня больше, чем планировалось, но тем не менее мы молодцы, мы его завершили. Как обычно, те, кто досидел до конца, те молодцы. Те, кто не досидел до конца, те сами себе злобные буратины. Но если вдруг что, вы всегда можете мне написать и задать вопрос по теме курса, я всегда на него отвечу. Если вы ещё не подписались на наш Telegram-чатик, то я рекомендую вам это сделать. Плюс к тому, если у вас есть какие-то пожелания, предложения по курсу, напишите мне, пожалуйста, письмо по электронной почте или любым другим образом со мной свяжитесь и расскажите мне, что нужно сделать для того, чтобы этот курс стал лучше. Если вы пойдёте сдавать экзамен, а я надеюсь, что вы пойдёте сдавать экзамен, то напишите мне, пожалуйста, опять же об этом, как вы сходили.

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

Субтитры сделал DimaTorzok