По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
На сегодняшний день проблемы информационной безопасности в мире приобретают всё большую актуальность. В СМИ часто можно наткнуться на новость об очередной успешной хакерской атаке, крупной утечке критичных данных или очередном вирусе-вымогателе, который срывает работу целых компаний. Даже если Вы человек далёкий от информационной безопасности и мира информационных технологий, то Вы всё равно наверняка слышали о вирусе “WannaCry”, уязвимостях “Spectre” и “Meltdown” и может быть даже о недавней атаке на устройства компании Cisco, которая ударила по крупным провайдерам и парализовала много сервисов и сетевых сегментов.
Однако, широкой огласке обычно подвергаются новости об атаках и уязвимостях, носящие массовый характер, направленных на наиболее распространенные инфраструктурные системы. Мы же хотим рассказать о том, как обстоит ситуация с информационной безопасностью в отдельной в отдельно взятой сфере - IP телефонии и решений VoIP. Разберём наиболее важные проблемы и тренды развития данного направления.
Проблемы информационной безопасности в VoIP
Если раньше, выбирая на чём строить офисную телефонию, заказчиков больше всего волновали вопросы стоимости и надёжности, то в связи с нынешним положением, вопросы защиты и безопасности всё чаще начинают преобладать. Хотя IP телефония имеет массу преимуществ по сравнению с системами традиционной телефонии, её намного легче взломать. В случае с традиционной системой PSTN злоумышленник должен получить физический доступ к среде передачи или системам, которые задействованы в обмене голосовой информацией. IP телефония – это прежде всего сеть с коммутацией пакетов, которые передаются на ряду с другими корпоративными сервисами – Интернетом, почтой и другими. Если эта сеть недостаточно защищена, то злоумышленнику даже не обязательно находиться в одной стране с системой IP телефонии, чтобы получить доступ к критичным данным, украсть их или модифицировать.
Вот почему необходимо обеспечивать многоуровневую защиту систем корпоративной IP телефонии. Недостаточно просто поставить стойкий пароль к интерфейсу управления. Это должен быть чёткий набор определённых мер, применяемых в комплексе – межсетевое экранирование, антивирусная защита, регулярные обновления программного обеспечения, шифрование передаваемых данных и другое.
Отдельно следует уделить внимание повышению осведомлённости своих сотрудников об атаках из разряда социальной инженерии. Одним из наиболее распространённых векторов атаки данного типа на сегодняшний день является “фишинг”. Суть его заключается в том, что злоумышленник рассылает “письма счастья” с вредоносными вложениями, в надежде на то, что человек откроет это вложение и тем самым, загрузит на свой компьютер вредонос. Защититься от таких атак можно сразу на нескольких уровнях:
Межсетевой экран, на котором адрес отправителя фишинговых писем должен быть заблокирован. Автоматизировать процесс получения актуального списка адресов активных отправителей для блокировки на МСЭ, можно с помощью решений Threat Intelligence. Существуют как платные решения от таких компаний как Anomali, ThreatConnect или EclecticIQ, так и OpenSource, например, YETI и MISP.
Решение для защиты почтового сервера, которое проверяет все письма на предмет подозрительных вложений, адреса отправителя, блокирует спам. Примерами таких решений является Kaspersky Security для почтовых серверов, AVG Email Server Edition для ME, McAfee Security for Email Servers. Кстати, в этом случае также можно автоматизировать процесс блокировки с помощью решений TI.
Антивирусное ПО для защиты оконечных устройств, которое заблокирует опасное вложение, если всё-таки вредонос сможет пролезть через МСЭ и почтовый сервер. Для этого подойдёт Kaspersky Endpoint Security, Norton, Trend Micro и другие.
Но если от фишинга можно защититься с помощью специализированных программ и аппаратных решений, то от следующих видов атак, основанной на социальной инженерии, защититься гораздо труднее. Возможно, Вы не знали, но помимо традиционного email “фишинга”, существует также и телефонный. Например, сотруднику Вашей компании на голосовую почту может прийти сообщение от “банка” о том, что кто-то пытался получить доступ к его счёту и что ему необходимо срочно перезвонить по оставленному номеру. Не трудно догадаться, что на другом конце провода, его будет ждать злоумышленник, который постарается сделать всё, чтобы втереться в доверие, украсть данные его счёта, чтобы в итоге похитить денежные средства.
Существует также телефонный “вишинг”. Этот тип атаки направлен на первую линию сотрудников, которые принимают все входящие звонки в Вашей компании. На общий номер поступает звонок от какой-нибудь известной организации или персоны, а дальше с помощью методов психологического давления, доверчивого сотрудника заставляют что-либо сделать. В самом лучшем случае, позвонивший будет агрессивно требовать соединить его с руководством компании, чтобы предложить какие-нибудь услуги, в самом худшем - выдать конфиденциальную или критически важную информацию. А что, если злоумышленник узнает каким банком обслуживается Ваша компания и позвонит бухгалтеру от лица “Вашего банка”? К такому тоже нужно быть готовым.
Защититься от подобного типа атак можно было бы с помощью некоего аналога Threat Intelligence для VoIP – списка телефонных номеров, с которых поступают “фишинговые” и “вишинговые” звонки, чтобы заблокировать их на АТС. Однако, такого решения пока нет, поэтому придётся просвещать сотрудников на тему безопасности.
Безопасность облачных систем
Сейчас уже сложно обозначить чёткие границы офисной сети. С распространением облачных решений, распределённых сетей VPN и всеобщей виртуализации, корпоративная сеть уже перестала иметь чёткую географическую привязку.
Аналогично обстоят дела и в сфере VoIP. Каждый крупный провайдер IP телефонии имеет в своем наборе услуг облачную АТС, которая настраивается в считанные минуты и способна обеспечить телефонией компанию любого размера и неважно где территориально она расположена. Облачная или виртуальная АТС – это очень удобное решение, которое привлекает заказчиков тем, что не надо держать лишние сервера в здании и обслуживать их. Вместо этого, можно просто арендовать необходимые серверные мощности или сервис телефонии. Однако, с точки зрения информационной безопасности, облачные АТС – это идеальная цель для хакерских атак. Потому что, как правило, аккаунты для доступа к настройкам АТС, находятся в открытом доступе. Если владелец аккаунта не озаботится созданием стойкого пароля, то он рискует оплатить немаленький счёт за телефонные разговоры злоумышленника или предоставить доступ к записям разговоров своих сотрудников. В этой связи при выборе провайдера следует также проверить обеспечивает ли он дополнительные мероприятия по защите целостности и конфиденциальности данных. Используется шифрование при подключении к аккаунту с настройками облачной АТС, шифруются ли данные при их транспортировке.
Тренды развития направления ИБ в VoIP
Наиболее распространённым методом защиты корпоративной инфраструктуры является организация защищённой сети VPN, когда подключение извне осуществляется по зашифрованному каналу, а данные внутри сети передаются в незашифрованном виде. Это относится и к голосовому трафику. Однако, тенденции развития информационных технологий указывают на то, что в недалёком будущем голосовая информация также будет подвергаться шифрованию. Большинство VoIP вендоров уже давно имплементируют в своих решениях поддержку таких протоколов как SIP/TLS, SRTP, ZRTP и д.р, стимулируя пользователей применять внедрять ещё один уровень защиты. Например, большинство IP-телефонов и решений видеоконференцсвязи от компании Cisco, а также системы CUCM, CUBE, Cisco SBC, UCCS и д.р поддерживают TLS 1.2 и SRTP. Самое распространённое Open Source решение IP-АТС Asterisk имеет поддержку защищённых протоколов передачи медиа трафика начиная с версии 1.8. В программной Windows-based АТС 3CX версии V15, поддержка SRTP включена по умолчанию.
VoIP решения зачастую очень тесно интегрируются с другими корпоративными системами, такими как CRM, ERP, CMS, не говоря уже о таких каналах бизнес коммуникаций как email, обмен мгновенными сообщениями (чат) и социальные сети, формируя в совокупности концепцию UC (Unified Communications). Потенциальные преимущества, которые несёт данная концепция очень привлекательны, но вместе с тем, создаётся множество точек уязвимых к возможному взлому. Недостаточный уровень защиты одной из них может быть угрозой всей корпоративной сети. Поэтому разработчики, несомненно, будут усиливать безопасность каналов интеграции данных систем.
Можно также ожидать интеграцию систем корпоративной телефонии в такие средства защиты как DLP (средства защиты от утечек), адаптации метрик VoIP в SIEM системах (система управления информацией и событиями безопасности), а также появление унифицированных репутационных баз (Threat Intelligence) со списками потенциально опасных номеров или других индикаторов компрометации, относящихся к VoIP, которые будут автоматически блокироваться имеющимися средствами защиты.
В предыдущем материале мы рассмотрели, как работает Интернет на базовом уровне, включая взаимодействие между клиентом (вашим компьютером) и сервером (другим компьютером, который отвечает на запросы клиента о веб-сайтах).
В этой же части рассмотрим, как устроены клиент, сервер и веб-приложение, что мы можем удобно серфить в Интернете.
Модель клиент-сервер
Эта идея взаимодействия клиента и сервера по сети называется моделью «клиент-сервер». Это делает возможным просмотр веб-сайтов (например, сайт wiki.merionet.ru) и взаимодействие с веб-приложением (как Gmail).
На самом деле, модель клиент-сервер - это ни что иное, как способ описать отношения между клиентом и сервером в веб-приложении. Это детали того, как информация переходит от одного конца к другому, где картина усложняется.
Базовая конфигурация веб-приложения
Существует сотни способов настройки веб-приложения. При этом большинство из них следуют одной и той же базовой структуре: клиент, сервер, база данных.
Клиент
Клиент - это то, с чем взаимодействует пользователь. Так что «клиентский» код отвечает за большую часть того, что на самом деле видит пользователь. Это включает в себя:
Определение структуры веб-страницы
Настройка внешнего вида веб-страницы
Реализация механизма пользовательского взаимодействия (нажатие кнопок, ввод текста и т.д.)
Структура: Макет и содержимое веб-страницы определяются с помощью HTML (обычно HTML 5, если речь идет о современных веб-приложениях, но это другая история.)
HTML означает язык гипертекстовой разметки (Hypertext Markup Language). Он позволяет описать основную физическую структуру документа с помощью HTML-тэгов. Каждый HTML-тэг описывает определенный элемент документа.
Например:
Содержимое тега «<h1>» описывает заголовок.
Содержимое тега «<p>» описывает абзац.
Содержимое тега «<button>» описывает кнопку.
И так далее...
Веб-браузер использует эти HTML-тэги для определения способа отображения документа.
Look and Feel: Чтобы определить внешний вид веб-страницы, веб-разработчики используют CSS, который расшифровывается как каскадные таблицы стилей (Cascading Style Sheets). CSS - это язык, который позволяет описать стиль элементов, определенных в HTML, позволяя изменять шрифт, цвет, макет, простые анимации и другие поверхностные элементы.
Стили для указанной выше HTML-страницы можно задать следующим образом:
Взаимодействие с пользователем: Наконец, для реализации механизма взаимодействия с пользователем, на сцену выходит JavaScript.
Например, если вы хотите что-то сделать, когда пользователь нажимает кнопку, вы можете сделать что-то подобное:
Иногда взаимодействие с пользователем, может быть реализовано без необходимости обращения к вашему серверу - отсюда и термин "JavaScript на стороне клиента". Другие типы взаимодействия требуют отправки запросов на сервер для обработки.
Например, если пользователь публикует комментарий в потоке, может потребоваться сохранить этот комментарий в базе данных, чтобы весь материал был структурирован и собран в одном месте. Таким образом, вы отправляете запрос на сервер с новым комментарием и идентификатором пользователя, а сервер прослушивает эти запросы и обрабатывает их соответствующим образом.
Сервер
Сервер в веб-приложении прослушивает запросы, поступающие от клиента. При настройке HTTP-сервера он должен прослушивать конкретный номер порта. Номер порта всегда связан с IP-адресом компьютера.
Вы можете рассматривать порты как отдельные каналы на каждом компьютере, которые можно использовать для выполнения различных задач: один порт может быть использован для серфинга на wiki.merionet.ru, в то время как через другой получаете электронную почту. Это возможно, поскольку каждое из приложений (веб-браузер и клиент электронной почты) использует разные номера портов.
После настройки HTTP-сервера для прослушивания определенного порта сервер ожидает клиентские запросов, поступающие на этот порт, выполняет все действия, указанные в запросе, и отправляет все запрошенные данные через HTTP-ответ.
База данных
Базы данных – это подвалы веб-архитектуры - большинство из нас боятся туда спускаться, но они критически важны для прочного фундамента. База данных - это место для хранения информации, чтобы к ней можно было легко обращаться, управлять и обновлять.
Например, при создании сайта в социальных сетях можно использовать базу данных для хранения сведений о пользователях, публикациях и комментариях. Когда посетитель запрашивает страницу, данные, вставленные на страницу, поступают из базы данных сайта, что позволяет нам воспринимать взаимодействие пользователей в реальном времени как должное на таких сайтах, как Facebook или в таких приложениях, как Gmail.
Как масштабировать простое веб-приложение
Вышеописанная конфигурация отлично подходит для простых приложений. Но по мере роста приложения один сервер не сможет обрабатывать тысячи - если не миллионы - одновременных запросов от посетителей.
Чтобы выполнить масштабирование в соответствии с этими большими объемами, можно распределить входящий трафик между группой внутренних серверов.
Здесь все становится интересно. Имеется несколько серверов, каждый из которых имеет собственный IP-адрес. Итак, как сервер доменных имен (DNS) определяет, на какой экземпляр вашего приложения отправить трафик?
Ответ очевиден - никак. Управление всеми этими отдельными экземплярами приложения происходит через средство балансировки нагрузки.
Подсистема балансировки нагрузки действует как гаишник, который маршрутизирует клиентские запросы по серверам как можно быстрее и эффективнее, насколько это возможно.
Поскольку вы не можете транслировать IP-адреса всех экземпляров сервера, вы создаете виртуальный IP-адрес, который транслируется клиентам. Этот виртуальный IP-адрес указывает на подсистему балансировки нагрузки. Таким образом, когда DNS ищет ваш сайт, он указывает на балансировщик нагрузки. Затем подсистема балансировки нагрузки перескакивает для распределения трафика на различные внутренние серверы в реальном времени.
Возможно, вам интересно, как подсистема балансировки нагрузки узнаёт, на какой сервер следует отправлять трафик. Ответ: алгоритмы.
Один популярный алгоритм, Round Robin, включает равномерное распределение входящих запросов по ферме серверов (все доступные серверы). Вы обычно выбираете такой подход, если все ваши серверы имеют одинаковую скорость обработки и память.
С помощью другого алгоритма, Least Connections, следующий запрос отправляется на сервер с наименьшим количеством активных соединений.
Существует гораздо больше алгоритмов, которые вы можете реализовать, в зависимости от ваших потребностей.
Теперь поток трафика выглядит следующим образом:
Службы
Итак, мы решили проблему трафика, создав пулы серверов и балансировщик нагрузки для управления ими.
Но одной репликация серверов может быть недостаточно для обслуживания приложения по мере его роста. По мере добавления дополнительных функциональных возможностей в приложение необходимо поддерживать тот же монолитный сервер, пока он продолжает расти. Для решения этой проблемы нам нужен способ разобщить функциональные возможности сервера.
Здесь и появляется идея служб. Служба является просто другим сервером, за исключением того, что она взаимодействует только с другими серверами, в отличие от традиционного веб-сервера, который взаимодействует с клиентами.
Каждая служба имеет автономную единицу функциональности, такую как авторизация пользователей или предоставление функции поиска. Службы позволяют разбить один веб-сервер на несколько служб, каждая из которых выполняет отдельные функции.
Основное преимущество разделения одного сервера на множество сервисов заключается в том, что он позволяет масштабировать сервисы полностью независимо.
Другое преимущество здесь заключается в том, что он позволяет командам внутри компании работать независимо над конкретной услугой, а не иметь 10, 100 или даже 1000 инженеров, работающих на одном монолитном сервере, который быстро становится кошмаром для менеджера проекта.
Краткое примечание: эта концепция балансировщиков нагрузки и пулов внутренних серверов и служб становится очень сложной, поскольку вы масштабируете все больше и больше серверов в вашем приложении. Это особенно сложно с такими вещами, как, например, сохранение сеанса, обработка отправки нескольких запросов от клиента на один и тот же сервер в течение сеанса, развертывания решения для балансировки нагрузки. Такие продвинутые темы не будет затрагивать в данном материале.
Сети доставки контента (Conten Delivery Network – CDN)
Все вышеперечисленное отлично подходит для масштабирования трафика, но приложение все еще централизовано в одном месте. Когда ваши пользователи начинают посещать ваш сайт из других концов страны или с другого конца мира, они могут столкнуться с длительной задержкой из-за увеличенного расстояния между клиентом и сервером. Ведь речь идет о "всемирной паутине" - не о "местной соседней паутине".
Популярная тактика решения этой проблемы - использование сети доставки контента (CDN). CDN - это большая распределенная система «прокси» серверов, развернутая во многих центрах обработки данных. Прокси-сервер - это просто сервер, который действует как посредник между клиентом и сервером.
Компании с большим объемом распределенного трафика могут платить CDN-компаниям за доставку контента конечным пользователям с помощью серверов CDN. CDN имеет тысячи серверов, расположенных в стратегических географических точках по всему миру.
Давайте сравним, как веб-сайт работает с CDN и без него.
Как мы уже говорили в разделе 1, для типичного веб-сайта доменное имя URL преобразуется в IP-адрес сервера хоста.
Однако если клиент использует CDN, доменное имя URL преобразуется в IP-адрес пограничного сервера, принадлежащего CDN. Затем CDN доставляет веб-контент пользователям клиента, не затрагивая серверы клиента.
CDN может сделать это, сохраняя копии часто используемых элементов, таких как HTML, CSS, загрузки программного обеспечения и медиаобъектов с серверов клиентов.
Главная цель - расположить контент сайта как можно ближе к конечному пользователю. В итоге пользователь получает более быструю загрузку сайта.
В одном из прошлых статей мы рассмотрели способы фильтрации маршрутов для динамического протокола маршрутизации EIGRP. Следует отметить, что EIGRP проприетарная разработка Cisco, но уже открыта другим производителям. OSPF же протокол открытого стандарта и поддерживается всем вендорами сетевого оборудования. Предполагается, что читатель знаком с данным протоколом маршрутизации и имеет знания на уровне CCNA.
OSPF тоже поддерживает фильтрацию маршрутов, но в отличии от EIGRP, где фильтрацию можно делать на любом маршрутизаторе, здесь она возможна только на пограничных роутерах, которые называются ABR (Area Border Router) и ASBR (Autonomous System Boundary Router). Причиной этому является логика анонсирования маршрутов в протоколе OSPF. Не вдаваясь в подробности скажу, что здесь маршруты объявляются с помощью LSA (Link State Advertisement). Существует 11 типов LSA, но рассматривать их мы не будем. По ходу статьи рассмотрим только Type 3 LSA и Type 5 LSA.
LSA третьего типа создаются пограничными роутерами, которые подключены к магистральной области (backbone area) и минимум одной немагистральной. Type 3 LSA также называются Summary LSA. С помощью данного типа LSA ABR анонсирует сети из одной области в другую. В таблице базы данных OSPF они отображается как Summary Net Link States:
Фильтрация LSA третьего типа говорит маршрутизатору не анонсировать сети из одной области в другую, тем самым закрывая доступ к сетям, которые не должны отображаться в других областях.
Видео: протокол OSPF (Open Shortest Path First) за 8 минут
Для настройки фильтрации применяется команда area area-num filter-list prefix prefix-list-name {in | out} в интерфейсе конфигурации OSPF. Как видно, здесь применяются списки префиксов или prefix-list, о которых мы говорили в предыдущей статье. Маршрут не анонсируется если попадает под действие deny в списке префиксов.
Камнем преткновения в данной команде являются ключевые слова in и out. Эти параметры определяют направление фильтрации в зависимости от номера области, указанного в команде area are-num filter. А работают они следующим образом:
Если прописано слово in, то маршрутизатор предотвращает попадание указанных сетей в область, номер которого указан в команде.
Если прописано слово out, то маршрутизатор фильтрует номера сетей, исходящих из области, номер которого указан в команде.
Схематически это выглядит так:
Команда area 0 filter-list in отфильтрует все LSA третьего типа (из областей 1 и 2), и они не попадут в area 0. Но в area 2 маршруты в area 1 попадут, так как нет команд вроде area 2 filter-list in или area 1 filter-list out. Вторая же команда: area 2 filter-list out отфильтрует все маршруты из области 2. В данном примере маршрутная информация из второй области не попадёт ни в одну из областей.
В нашей топологии, показанной на рисунке, имеются две точки фильтрации, то есть два пограничных маршрутизатора:
При чем каждый из этих маршрутизаторов будет фильтровать разные сети. Также мы здесь используем обе ключевых слова in и out. На ABR1 напишем следующие prefix-list-ы:
ip prefix-list FILTER-INTO-AREA-34 seq 5 deny 10.16.3.0/24
ip prefix-list FILTER-INTO-AREA-34 seq 10 permit 0.0.0.0/0 le 32
А на ABR2
ip prefix-list FILTER-OUT-OF-AREA-0 seq 5 deny 10.16.2.0/23 ge 24 le 24
ip prefix-list FILTER-OUT-OF-AREA-0 seq 10 permit 0.0.0.0/0 le 32
Теперь проверив таблицу маршрутизации на R3, увидим, что маршрут до сети 10.16.3.0 отсутствует:
Теперь поясним, что мы сказали маршрутизатору. В конфигурации ABR1 первый prefix-list с действием deny совпадет только с маршрутом, который начинается на 10.16.3.0, а длина префикса равна 24. Второй же префикс соответствует всем остальным маршрутам. А командой area 34 filter-list prefix FILTER-INTO-AREA-34 in сказали отфильтровать все сети, которые поступают в 34 область. Поэтому в базе OSPF маршрута в сеть 10.16.3 через R1 не будет.
На втором же маршрутизаторе пошли другим путём. Первый команда ip prefix-list FILTER-OUT-OF-AREA-0 seq 5 deny 10.16.2.0/23 ge 24 le 24 совпадет с маршрутами, который начинается на 10.16.2.0 и 10.16.3.0, так как указан /23. На языке списка префиксов означает взять адреса, которые могут соответствовать маске 255.255.254.0, а длина префикса адреса равна 24. А командой area 0 out сказали отфильтровать все LSA 3 типа, которые исходят из области 0. На первый взгляд кажется сложным, но если присмотреться, то все станет ясно.
Фильтрация маршрутов в OSPF через distribute-list
Фильтрация LSA третьего типа не всегда помогает. Представим ситуацию, когда в какой-то области 50 маршрутизаторов, а нам нужно чтобы маршрутная информация не попала в таблицу только 10 роутеров. В таком случае фильтрация по LSA не поможет, так как он фильтрует маршрут исходящий или входящий в область, в нашем случае маршрут не попадёт ни на один маршрутизатор, что противоречит поставленной задаче.
Для таких случаев предусмотрена функция distribute-list. Она просто не добавляет указанный маршрут в таблицу маршрутизации, но в базе OSPF маршрут до сети будет.
В отличии от настройки distribute-list в EIGRP, в OSPF нужно учесть следующие аспекты:
Команда distribute-list требует указания параметров in | out, но только при применении in фильтрация будет работать.
Для фильтрации команда может использовать ACL, prefix-list или route-map.
Можно также добавить параметр interface interface-type-number, чтобы применить фильтрацию для конкретного интерфейса.
Внесем некоторые изменения в конфигурацию маршрутизатора R3, чтобы отфильтровать маршрут до сети 10.16.1.0:
Как видно на выводе, до применения prefix-list-а, в таблице маршрутизации есть маршрут до сети 10.16.1.0. Но после внесения изменений маршрут исчезает из таблицы, но вывод команды show ip ospf database | i 10.16.1.0 показывает, что в базе OSPF данный маршрут существует.
Фильтрация маршрутов на ASBR
Как уже было сказано в начале материала, ASBR это маршрутизатор, который стоит между двумя разными автономными системами. Именно он генерирует LSA пятого типа, которые включают в себя маршруты в сети, находящиеся вне домена OSPF.
Топология сети показана ниже:
Конфигурацию всех устройств из этой статьи можно скачать в архиве по ссылке ниже.
Скачать конфиги тестовой лаборатории
Как видно из рисунка, у нас есть два разных домена динамической маршрутизации. На роутере ASBR настроена редистрибюция маршрутов, то есть маршруты из одно домена маршрутизации попадают во второй. Нам нужно отфильтровать маршруты таким образом, чтобы сети 172.16.101.0/24 и 172.16.102.0/25 не попали в домен EIGRP. Все остальные, включая сети точка-точка, должны быть видны для пользователей в сети EIGRP.
Для фильтрации Cisco IOS нам дает всего один инструмент route-map. О них мы подробно рассказывали в статье и фильтрации маршрутов в EIGRP.
Можно пойти двумя путями. Либо запрещаем указанные маршруты, в конце добавляем route-map с действием permit, который разрешит все остальные, либо разрешаем указанным в списке префиксов маршруты, а все остальное запрещаем (имейте ввиду, что в конце любого route-map имеется явный запрет deny).
Покажем второй вариант, а первый можете протестировать сами и поделиться результатом.
Для начала создаем списки префиксов с разрешёнными сетями:
ip prefix-list match-area0-permit seq 5 permit 172.16.14.0/30
ip prefix-list match-area0-permit seq 10 permit 172.16.18.0/30
ip prefix-list match-area0-permit seq 15 permit 172.16.8.1/32
ip prefix-list match-area0-permit seq 20 permit 172.16.4.1/32
ip prefix-list match-area0-permit seq 25 permit 172.16.48.0/25
ip prefix-list match-area0-permit seq 30 permit 172.16.49.0/25
ip prefix-list match-area3-permit seq 5 permit 172.16.103.0/24 ge 26 le 26
Еще раз отметим, что фильтрация LSA Type 5 делается только на ASBR маршрутизаторе. До внесения изменений на маршрутизаторе R1 видны сети до 101.0 и 102.0:
Применим изменения на ASBR:
Проверим таблицу маршрутизации R1 еще раз:
Как видим, маршруты в сеть 101.0 и 102.0 исчезли из таблицы.
На этом, пожалуй, завершим это материал. Он и так оказался достаточно большим и сложным. Удачи в экспериментах!