Сертификации R&S больше нет, но данная информация по-прежнему полезна.
CCNA R&S 6.0 Bridging Course часть 3, содержит урок 4 (первая половина урока) - для тех, кто готовился на сертификацию версии 3 и будет сдавать экзамены:
- Interconnecting Cisco Networking Devices Part 2 exam (ICND2 200-105), which is associated with the CCNA Routing and Switching certification;
- CCNA Routing and Switching composite exam (200-125), which can be taken instead of the ICND1 and ICND2 exams.
Третья часть предпоследняя, урок 4 самый большой в курсе, но 3 - про VTP - для меня интересней. В 4 уроке много воды (как и в 4 части CCNA, впрочем): PPPoE, которое лет 6-8 уже как не используется, BGP с постоянными отсылками, что вот это мы в этом курсе изучать не будем и прочие теоретические вещи, но для экзамена знать всё это нужно.
Общая схема для курса:
Урок 4 Connecting Networks (CN)
4.1: WAN Technologies Overview
WAN Topologies
Соединение нескольких сайтов через WAN может задействовать различные технологии сервисов провайдеров и различные топологии. Наиболее распространенные WAN топологии:
- Point-to-Point;
- Hub-and-Spoke;
- Full Mesh;
- Dual-Homed.
Точка-точка
Топология точка-точка, как понятно из названия, использует линию между двумя конечными точками. Обычно используются выделенные линии типа E1/T1. Такое соединение задействует уровень 2 для транспорта пакетов через сеть провайдера. Пакеты, отправленные из одного сайта, доставляются на другой и наоборот. Технология прозрачна для пользовательской сети, хотя могут использоваться различные типы физических соединений между двумя конечными точками.
Hub-and-Spoke
Когда требуется приватное соединение между множественными сайтами, топология точка-точка может быть одним из выборов. Каждое соединение точка-точка требует собственный выделенный аппаратный интерфейс, в совокупности потребуется множество маршрутизаторов с большим количеством WAN-интерфейсов. Это может быть затратно. Менее затратная опция это топология point-to-multipoint, также известная как веерная (hub and spoke). При этой топологии один интерфейс хаба (hub) разделяется между интерфейсами всех спиц spoke's. Эта топология является также примером single-homed топологии. Топология звезды - тоже вариант hub and spoke, только для на хабе используется не один интерфейс для всех спиц, а отдельный на каждую спицу. Пример, spoke сайты могут быть взаимосвязаны через hub сайт, используя маршрутизируемые подынтерфейсы интерфейса хаба.
Full Mesh
Недостатком hub and spoke топологии является то, что всё взаимодействие происходит через hub. При полносвязной (Full Mesh) топологии любые два сайта связаны непосредственно друг-с-другом. Недостатком является множество соединений, которые могут быть как физическими так и логическими, которые должны быть сконфигурированы и в последствии требуют обслуживания.
Dual-homed
Dual-homed топология предоставляет избыточность. Недостатком является более высокая стоимость, чем у single-homed топологии. Это потому, что такая топология требует дополнительного оборудования - коммутаторов, маршрутизаторов. Такая топология также более сложна в настройке. Преимуществом является - избыточность, балансировка нагрузки, распределённые вычисления и способность осуществлять резервное подключение к провайдеру.
4.2: DMVPN
Dynamic Multipoint VPN это программное решение CISCO для построения множественных VPN легко, динамично и масштабируемо. Цель - упростить настройки при подключении центрального офиса к филиалам:
При DMVPN сайты филиалов могут взаимодействовать и напрямую:
DMVPN построено на использовании следующих компонентов:
- Next Hop Resolution Protocol (NHRP);
- Multipoint Generic Routing Encapsulation (mGRE) tunnels;
- IP Security (IPsec) encryption.
NHRP - это протокол уровня 2 для разрешения и кеширования, похожий на ARP. NHRP создает распределенную базу данных для всех публичных IP сайтов спиц (spokes). Это клиент-серверный протокол, состоящий из хаба-сервера (Next Hop Server (NHS)) и спиц-клиентов (Next Hop Clients (NHC)).
Generic Routing Encapsulation (GRE) - это туннелирующий протокол, разработанный CISCO, который инкапсулирует широкое множество других протоколов внутрь IP туннеля. mGRE туннельный интерфейс, позволяет одному GRE интерфейсу поддерживать множественные IPSec туннели. C mGRE динамические туннели создаются через постоянный туннель-источник на хабе и динамические точки назначения на спицах, если необходимо. Это упрощает и облегчает конфигурирование туннелей.
Как и остальные типы VPN, DMVPN полагается на IPSec для предоставления шифрованного транспорта для частной информации поверх публичных сетей, таких как Internet.
4.3: PPPoE
Описание и настройка PPPoE описывались в 4 части курса CCNA. А перед эти/education/materialyi-kursa-cisco-ccna-4-chast-2/м там же полезно посмотреть протокол PPP.
Пользовательский маршрутизатор подключен к маршрутизатору ISP, используя PPPoE. Оба маршрутизатора должны быть настроены на использование PPPoE.
Команда show ip interface brief, выполненная на R1, покажет, что IP адрес был автоматически присвоен dialer interface провайдером:
Команда show interface dialer проверяет на R1 как сконфигурированы MTU и PPP encapsulation на dialer interface:
Таблица маршрутизации:
Следует отметить, что два /32 маршрута узлов для 10.0.0.0 были добавлены в таблицу маршрутизации на R1. Первый это адрес присвоенный для dialer interface, второй это IP адрес ISP. Установка этих двух маршрутов - поведение по умолчанию для PPPoE.
Команда show pppoe session показывает информацию о текущих активных сессиях PPPoE, информацию о MAC адресе для локального и удалённого маршрутизатора. MAC может быть просмотрен на каждом из маршрутизаторов с помощью команды show interfaces.
Траблшутинг PPPoE
После того как маршрутизатор и DSL модем соединены правильными кабелями, следующие самые распространённые причины того, что PPPoE не функционирует корректно:
- Failure in the PPP negotiation process;
- Failure in the PPP authentication process;
- Failure to adjust the TCP maximum segment size.
PPP negotiation
Проверить установление соединения PPPoE можно с помощью команды debug ppp negotiation:
Основные 4 причины сбоя при установке соединения PPPoE:
- No response from the remote device (the ISP);
- Link Control Protocol (LCP) not open;
- Authentication failure;
- IP Control Protocol (IPCP) failure.
PPPoE Authentication
После подтверждения от ISP, что они используют CHAP, нужно проверить логин и пароль для CHAP на правильность:
Просматривая снова вывод команды debug ppp negotiation, убеждаемся, что CHAP логин и пароль верны:
Если же в логине или в пароле есть ошибка, то вывод будет такой:
PPPoE MTU Size
Доступ к некоторым веб страницам может быть проблемой с PPPoE. Когда веб клиенту требуется веб страница, трехстороннее рукопожатие TCP происходит между веб клиентом и веб сервером. В процессе установки соединения веб клиент указывает значение его MSS - максимальный размер сегмента TCP (maximum segment size). TCP MSS это максимальный размер данных в TCP сегменте. Хост определяет значение MSS вычитанием размера IP и TCP заголовков из MTU (maximum transmission unit). На интерфейсах Ethernet значение MTU по умолчанию 1500 байт. Вычитание IP заголовка, равного 20 байт и TCP заголовка, равного тоже 20 байт, даёт MSS равный 1460.
MSS по умолчанию 1460, тогда как MTU по умолчанию 1500 байт. Однако, PPPoE поддерживает MTU только 1492 для того чтобы разместить дополнительные 8 байт заголовка PPPoE.
Можно также проверить MTU в текущей конфигурации:
Это несоответствие между MTU хоста и PPPoE может стать причиной того, что маршрутизатор начнёт отбрасывать пакеты с MTU 1500 и прерывать сессию PPPoE.
Команда интерфейса:
ip tcp adjust-mss max-segment-size
помогает предотвратить завершение TCP сессии при установке значения MSS в ходе трехстороннего пожатия TCP. В большинстве случаев, значение MSS 1452 байта является оптимальным.
Значение MSS в 1452 байта, плюс заголовок IP 20 байт, плюс заголовок TCP 20 байт - даёт MTU 1492 байта и 8 байтовый заголовок PPPoE.
4.4: eBGP
BGP Overview
RIP, EIGRP и OSPF - внутренние протоколы маршрутизации, Interior Gateway Protocols (IGP). Провайдеры интернета (ISPs) и их корпоративные клиенты обычно используют IGP для маршрутизации трафика внутри своих сетей. IGPs используются для обмена информацией внутри сети компании или внутри Автономной системы (AS).
Протокол граничного шлюза - Border Gateway Protocol (BGP) это внешний протокол маршрутизации, Exterior Gateway Protocol (EGP) и используется он для обмена информацией между AS. В BGP каждой AS присвоен уникальный 16-bit или 32-bit AS number - номер автономной системы, который однозначно идентифицирует её в интернете. На рисунке приведен пример, на нём только приватные AS номера, но рассмотрение приватных AS номеров находится за пределами этого курса:
Внутренние протоколы маршрутизации используют специфические метрики, например стоимость OSPF (OSPF's cost), для определения наилучшего маршрута к сети назначения. BGP не использует метрики подобно IGPs. Маршрутизаторы BGP обмениваются некоторыми атрибутами маршрутов, включая список AS номеров (переход за переходом), необходимых чтобы достигнуть сети назначения. Например, возвращаясь к рисунку, AS 65002 может использовать AS-путь 65003, 65005 для достижения сети контент-провайдера AS 65005. BGP также известен как протокол вектора маршрута.
Примечание. AS-путь (AS-path) - один из нескольких атрибутов, которые могут использоваться для определения лучшего маршрута BGP. Однако рассмотрение таких атрибутов как и само определение лучшего маршрута BGP, находится за рамками этого курса.
Обновления BGP инкапсулированы поверх TCP по порту 179. Поэтому BGP наследует свойства протокола TCP, который гарантирует, что обновления BGP передаются надёжно.
IGP используется для маршрутизации внутри одной организации и администрируется одной организацией. BGP, наоборот, используется для маршрутизации между сетями, администрируемыми разными организациями. BGP используется AS чтобы рассылать анонсы о своих сетях и в некоторых случаях о сетях, изученных от других AS, оставшейся части интернета.
eBGP и iBGP
Два маршрутизатора, обменивающихся информацией о BGP маршрутах, известны как BGP peers. Существует 2 типа BGP:
- External BGP (eBGP) – External BGP is the routing protocol used between routers in different autonomous systems;
- Internal BGP (iBGP) - Internal BGP is the routing protocol used between routers in the same AS.
В этом курсе информация только о eBGP.
Примечание. Есть некоторое различие в работе BGP между eBGP peers и iBGP peers, но в этом курсе это не рассматривается.
BGP Design Considerations
Когда нужно использовать BGP
BGP наиболее подходит, когда AS подключена к множеству других AS. Это известно как multi-homed. На рисунке каждая AS является multi-homed потому, что она подключена как минимум к двум другим AS.
Прежде чем настраивать BGP, очень важно чтобы администратор имел хорошее понимание BGP. Неточности и ошибки в конфигурации BGP могут иметь негативное влияние на Интернет в целом.
Когда не нужно использовать BGP
BGP не нужно использовать, если выполняется хотя бы одно из условий:
- Существует единственное подключение к другой AS или Интернету. Это известно как single-homed. В этом случае Компания А может запустить IGP вместе с ISP или же Компания А и ISP могут использовать статические маршруты (хотя на практике это рекомендовано только в очень редких ситуациях, в целях данного курса, будет показан пример конфигурирования именно single-homed BGP);
- Присутствует недостаточное понимание BGP. Ошибки конфигурирования BGP маршрутизатора могут иметь далеко идущие последствия, выходящие за пределы локальной AS и негативно влияющие на весь Интернет.
Примечание. Существует несколько single-homed ситуаций, где использование BGP может быть оправдано, таких как потребность для специфической политики маршрутизации. Политики маршрутизации (routing policies) вне диапазона этого курса.
BGP Options
BGP используется AS чтобы анонсировать сети внутри AS или в случае ISP - сети из других AS. Например, компания анонсирует сети внутри своей AS своему ISP, ISP анонсирует эти сети другим ISPs (BGP peers). В конечном итоге все AS в интернете изучат сети изначально анонсированные компанией.
Существует 3 распространённых способа, которые организация может выбрать чтобы внедрить у себя multi-homed среду BGP:
- Default Route Only. ISPs анонсируют Компании А только маршрут по умолчанию. Стрелки показывают что маршрут по умолчанию сконфигурирован на ISPs, не в Компании А. Это простейший метод внедрить BGP. Однако, поскольку Компания А получает от обоих ISPs маршрут по умолчанию, маршрутизация может быть неоптимальной. Например, Компания А может использовать маршрут по умолчанию к ISP-1, тогда как сеть назначения находится внутри AS ISP-2.
- Default Route and ISP Routes. ISPs анонсируют свой маршрут по умолчанию и свои сети Компании А. Эта опция позволяет Компании А форвардить трафик к подходящему ISP для сетей анонсируемых этим ISP. Для остальных сетей один из двух маршрутов по умолчанию может быть использован. Это означает потенциальную возможность неоптимальной маршрутизацию для остальных маршрутов интернета.
- All Internet Routes. ISPs анонсируют все маршруты интернета Компании А. Поскольку Компания А получает все маршруты интернета от ISPs, она может определять каким ISP лучше воспользоваться чтобы отправить трафик в определенную сеть интернета. Хотя проблема неоптимальной маршрутизации решена, BGP маршрутизатор компании должен содержать все маршруты интернета, которые включают в себя на данный момент маршруты к более чем 550 000 сетей.
eBGP Configuration
Шаги по конфигурированию BGP
- Step 1: Enable BGP routing;
- Step 2: Configure BGP neighbor(s) (peering);
- Step 3: Advertise network(s) originating from this AS.
Пример конфигурирования
Используется single-homed BGP топология. Используя eBGP, Компания А с AS 65000 будет анонсировать свою сеть 198.133.219.0/24 провайдеру ISP-1 с AS 65001. ISP-1 будет анонсировать маршрут по умолчанию в своих eBGP обновлениях Компании А.
Примечание. BGP обычно не требуется в single-homed топологиях и используется тут только для простоты конфигурационного примера.
Клиенты обычно используют приватные IPv4 адреса внутри своих сетей. Используя NAT, маршрутизатор Компании А может транслировать эти приватные адреса в один из своих публичных IPv4 адресов, анонсируемых с помощью BGP провайдеру ISP-1.
Проверка конфигурирования
Проверка производится в следующей топологии:
Вывод команды show ip route:
Буквой B обозначаются маршруты, выученные через BGP.
Вывод команды show ip bgp:
Выводится таблица BGP (verify BGP table). Первая строка - это маршрут рекламируемый ISP-1, в графе Path стоит значение 65001 - номер AS для ISP-1. Вторая строка - маршрут рекламируемый роутером компании Company-A, поэтому в графе Next Hop для этого маршрута стоит 0.0.0.0.
Вывод команды show ip bgp summary:
Выводятся пиры (verify BGP neighbors). Выводится IPv4 адрес для локального BGP пира и локальный номер AS, а также IPv4 адрес удалённого пира и AS удалённой системы.
4.5:Troubleshoot ACLs
Common ACLs Errors
Следует помнить различие ACL для IPv4 и для IPv6:
- Первым отличием является команда ipv6 traffic-filter для выполнения аналогичной функции на интерфейсах IPv6, вместо ip access-group для IPv4;
- Отсутствие шаблонных масок - используется длина префикса;
- В конце каждого ACL списка для IPv6 находится похожее правило — deny ipv6 any any. Различие заключается в том, что IPv6 также включает два других косвенных условия по умолчанию:
- permit icmp any any nd-na
- permit icmp any any nd-ns
После того как вы протестируете ACL и выясните, что они работают не так как задумано - самое время выявить и исправить общие ошибки. Используя команды show, такие как show ipv6 access-list и show running-config, можно выявить типичные ошибки ACL. Хотя большинство общих ошибок это введение ACEs в неправильном порядке и не определение адекватных ситуации правил ACL, другие общие ошибки связаны с применением ACL с неверным именем, на неверном интерфейсе или в неправильном направлении.
Сценарий 1
R1 сконфигурирован с IPV6 ACL для того чтобы запретить FTP доступ из :10 подсети в :11 подсеть. Однако, после конфигурирования ACL, PC1 всё ещё способен подсоединиться к FTP серверу, запущенному на PC2. Обращаясь к выводу команды show ipv6 access-list, совпадения есть для утверждающего утверждения и их нет для запрещающих утверждений.
Решение: ACEs в ACL показывают отсутствие ошибок в своём порядке и в критериях правил. Следующий шаг это рассмотреть как ACL применяется к интерфейсу, используя ipv6traffic-filter. Использует ли ACL правильное имя, правильный интерфейс и правильное направление? Для того чтобы проверить конфигурацию на ошибки отобразим текущую конфигурацию.
ACL применяется используя корректное имя, но в неправильном направлении. Направление, in или out, с точки зрения маршрутизатора, означает что ACL сейчас применяется к трафику до его перенаправления через интерфейс G0/0 наружу в подсеть :10. Чтобы решить проблему нужно удалить ipv6 traffic-filter NO-FTP-TO-11 out и заменить его на ipv6 traffic-filter NO-FTP-TO-11 in.
Теперь попытки PC1 получить доступ к FTP отклоняются.
Сценарий 2
R3 сконфигурирован с IPv6 ACL названным RESTRICTED-ACCESS, который должен выполнять следующую политику для R3 LAN:
- Разрешить доступ к :10 подсети;
- Запретить доступ к :11 подсети;
- Разрешить SSH доступ к PC2 с IPv6 адресом 2001:DB8:CAFE:11::11.
Однако, после конфигурирования ACL, PC3 не может получить доступ к подсети :10 или :11 подсети, не может получить доступ SSH к хосту 2001:DB8:CAFE:11::11.
Решение: В этой ситуации проблема не в том как ACL применён. В конфигурации, в секции интерфейса ACL не имеет ошибок в написании, направление и положение ACL верные, как видно на картинке.
При ближайшем рассмотрении IPv6 ACL открывается проблема в порядке и критериях ACE правил.
Первое разрешающее правило должно предоставить доступ к :10 подсети. Однако, администратор сконфигурировал правило, но не указал префикс. В этом случае разрешён доступ только к хосту 2001:DB8:CAFE:10:: Для исправления этого утверждения нужно указать префикс /64. Это можно сделать без удаления ACL заменой ACE, используя его порядковый номер 10.
Вторая ошибка в ACL это ошибка в порядке следующих 2 утверждений. Политика определяет, что хост в подсети маршрутизатора R3 должен иметь способность устанавливать SSH соединение с хостом 2001:DB8:CAFE:11::11. Однако, запрещающее утверждение для :11 подсети идёт до разрешающего утверждения. Таким образом, все попытки получить доступ к :11 подсети отвергаются до того, как разрешающее SSH утверждение может быть применено. После того как соответствие пакета и утверждения установлено, дальнейшие утверждения не анализируются. Для исправления этой ошибки, сначала нужно удалить запрещающее утверждение и затем поместить его в правильном порядке, как показано на рисунке.
Сценарий 3
R1 сконфигурирован с ACL с именем DENY-ACCESS, который должен выполнять следующую политику для подсети R3:
- Разрешить доступ к :11 подсети из :30 подсети;
- Запретить доступ к :10 подсети.
Для DENY-ACCESS ACL предполагается что будет разрешен доступ в :11 подсеть из :30 подсети, в то время как доступ в :10 подсеть из :30 будет запрещен. Однако, после применения ACL на интерфейсе :10 подсеть по прежнему доступна из :30.
Решение: В этой ситуации проблема не в тем, как утверждения ACL были написаны, но с размещением ACL. По той причине что утверждения IPv6 ACL должны быть написаны с указанием как источника трафика так и назначения (в IPv6 только аналог расширенных списков IPv4), то как расширенный список он должен быть помещен как можно ближе к источнику трафика. DENY-ACCESS ACL был применён в исходящем направлении на R1 G0/1 интерфейсе, то есть как можно ближе к точке назначения. Как результат трафик в :10 подсеть остаётся незатронутым, потому что он достигает :10 подсети через другой интерфейс, G0/0. Можно было бы применить ACL на интерфейсе S0/0/0 R1. Однако, поскольку мы можем управлять маршрутизатором R3, лучшем местоположением для ACL будет расположение его на R3. Удаляем ACL с R1 И помещаем его на G0/1 R3.
4.6: LAN Security Best Practices
DHCP Snooping
Атака DHCP spoofing случается когда пиратский DHCP сервер подключён к сети и предоставляет ложные параметры конфигурации IP для легитимных клиентов. DHCP spoofing опасен, так как клиенты могут арендовать заведомо ложную IP информацию: ложные DNS сервера, ложный сервер по умолчанию и ложное присвоение IP.
Security best practices рекомендуют использовать технологию DHCP snooping для уменьшения возможности DHCP spoofing атак (вне рамок курса - есть компактная программа DHCP RogueChecker, для определения всех DHCP в сети).
DHCP snooping собирает и поддерживает базу данных называемую DHCP Snooping Binding Database (также известную как DHCP Snooping Binding Table). Эта база данных включает включает в себя клиентский MAC адрес, IP адрес, время аренды DHCP, тип привязки (binding type), номер VLAN и информацию интерфейса для каждого недоверенного (untrusted) порта коммутатора или интерфейса. Администратор сети должен определить какой порт будет доверенным. С помощью комбинирования информации из DHCP Snooping Binding Database с доверенными портами, коммутатор способен отфильтровать DHCP сообщения от недоверенных источников.
Механизм DHCP Snooping
Когда DHCP Snooping включен на интерфейсе или VLAN и коммутатор получает DHCP пакеты на untrusted порт, коммутатор сравнивает информацию пакета источника с содержавшейся в HCP Snooping Binding Database. Коммутатор будет отбрасывать пакеты содержащие любую следующую информацию:
- Сообщения неавторизованного DHCP сервера, поступающие из untrusted порта;
- Сообщения неавторизованного DHCP клиента, не соответствующие DHCP Snooping Binding Database или превышающие лимиты;
- Пакеты DHCP relay агента, которые содержат option-82 информацию поступающую из untrusted порта.
Примечание. Option-82 предоставляет дополнительную безопасность и используется чтобы посылать информацию о DHCP клиентах DHCP серверу. Однако untrusted порт не должен получать option-82 пакеты.
В больших сетях DHCP Snooping Binding Database может потребовать время для своего построения после того, как она включена. Например, это могло бы занять 2 дня для DHCP snooping чтобы заполнить базу данных, если аренда DHCP составляет 4 дня.
DHCP snooping распознаёт 2 типа портов:
- Trusted DHCP ports - Только порты подключенные к вышестоящим DHCP серверам должны быть trusted. Эти порты должны вести к легитимным DHCP серверам, отвечающим DHCP offer и DHCP Ack сообщениями. Trusted порты должны быть явно определены в конфигурации.
- Untrusted ports - Эти порты подключены к хостам, которые не должны распространять сообщения DHCP сервера. По умолчанию, все порты коммутатора untrusted.
Обратите внимание, как trusted порты всегда ведут к легитимным DHCP серверам, в то время как все остальные порты (то есть порты доступа для конечных точек) untrusted по умолчанию.
Примечание. Конфигурирование DHCP Snooping вне рамок этого курса (кратко рассмотрено в основном курсе, в части 2).
AAA with RADIUS and TACACS+
Для того чтобы избежать получения злоумышленником доступа к чувствительным сервисам и сетевому оборудованию, администратор должен включить контроль доступа. Контроль доступа определяет кто или что может использовать специфичные ресурсы.
Базовый контроль доступа на сетевых устройствах включается используя аутентификацию. Существуют различные методы применения аутентификации в устройствах CISCO и каждый метод предлагает различные уровни безопасности. Два наиболее распространённых метода:
- Simple password authentication – Получается при использовании консольных команд password и login для того чтобы защитить консоль, линии VTY и AUX порты. К сожалению этот метод самый слабый и наименее безопасный метод, потому что он не предоставляет отчетности кто производил вход. Любой, кто обладает паролем, может получить доступ к устройству и вносить изменения в конфигурацию. Ну а пользователь как правило один со стандартным именем по умолчанию - admin (administrator, администратор);
- Local database authentication – Получается при создании локального пользовательского аккаунта с помощью команды username name secret password глобальной конфигурации и затем выполнения login local консольной команды для консоли, VTY и AUX портов. Это предоставляет дополнительную безопасность, потому что хакер должен знать уникальную связку: имя пользователя/пароль. Это также предоставляет дополнительную отчётность, потому что имя пользователя фиксируется в момент логина.
Однако, метод локальной базы данных не масштабируется более чем на несколько сетевых устройств потому что пользовательский аккаунт должен быть сконфигурирован вручную на каждом устройстве. Это не подходит в большой корпоративной среде с множеством маршрутизаторов и коммутаторов для управления. Дополнительно, локальная база не предоставляет запасного метода аутентификации. Например, что если администратор забудет имя пользователя или пароль для устройства? Если нет бекапа, тогда восстановление пароля - единственный метод.
AAA
Лучшее и более масштабируемое решение - хранить всё в центральной базе данных, размещённой на центральном сервере. Для поддержки этого, устройства CISCO поддерживают Authentication, Authorization, and Accounting (AAA) framework для обеспечения безопасного доступа к устройствам. 2 AAA протокола аутентификации поддерживаются устройствами CISCO:
- Terminal Access Controller Access-Control System Plus (TACACS+, произносится как “tack-axe plus”);
- Remote Authentication Dial-In User Service (RADIUS).
Устройства с включённым AAA могут могут быть сконфигурированы на использование внешней базы данных для аутентификации пользователей (для authentication, authorization and accounting). Устройства общающиеся с AAA сервером могут использовать или TACACS+, или RADIUS протокол. Каждый протокол поддерживает разные возможности и функциональность. Протокол выбирается из потребностей организации. Например, большой ISP может выбрать RADIUS, потому что он поддерживает детальную отчётность (accounting), требуемую для биллинга. Организация с различными пользовательскими группами может выбрать TACACS+, потому что он требует политик авторизации применяемых отдельно для каждого пользователя или для каждой группы пользователей.
Различия TACACS+ и RADIUS
Очень важно понимать основные различия между 2 протоколами.
Существует 3 фактора для TACACS+:
- Separates authentication and authorization;
- Encrypts all communication;
- Utilizes TCP port 49.
И 4 фактора для RADIUS:
- Combines RADIUS authentication and authorization as one process;
- Encrypts only the password;
- Utilizes UDP;
- Supports remote-access technologies, 802.1X, and Session Initiation Protocol (SIP).
Хотя оба протокола могут использоваться для взаимодействия между маршрутизаторами и AAA сервером, TACACS+ рассматривается как более безопасный протокол. Это потому что весь обмен по протоколу TACACS+ зашифрован, в то время как RADIUS шифрует только пользовательский пароль. RADIUS не шифрует имя пользователя, информацию по отчетности или любую другую информацию содержащуюся в сообщениях RADIUS.
Примечание. Конфигурирование AAA вне рамок этого курса.
802.1X
IEEE 802.1X стандарт определяет port-based контроль доступа и протокол аутентификации, который ограничивает неавторизованные рабочие станции от подключения в локальную сеть через доступные публично порты коммутатора. Сервер аутентификации авторизует каждую рабочую станцию, подключенную к порту коммутатора, прежде чем какие либо сервисы, предлагаемые коммутатором или сетью, станут доступны.
С 802.1X протоколом устройства в сети имеют специфичные роли, показанные на рисунке.
- Client (Supplicant) - Обычно это порт с включённым 802.1X на устройстве, которому требуется доступ в сеть и к сервисам коммутатора и которое отвечает на запросы от коммутатора. На рисунке это устройство - PC с запущенным 802.1X совместимым клиентским программным обеспечением;
- Switch (Authenticator) - Контролирует физический доступ к сети, основанный на текущем статусе аутентификации клиента. Коммутатор выступает как посредник (proxy) между клиентом и сервером аутентификации. Он требует аутентификационную информацию от клиента, проверяет эту информацию с помощью сервера и передаёт ответ клиенту. Коммутатор использует программного клиента RADIUS, который отвечает за инкапсуляцию и де-инкапсуляцию EAP (Extensible Authentication Protocol) фреймов и взаимодействие с сервером аутентификации;
- Authentication server - Выполняет текущую аутентификацию клиента. Сервер аутентификации подтверждает подлинность клиента и извещает коммутатор о том, что клиент авторизован для доступа к сервисам сети и коммутатора. Так как коммутатор выступает как прокси, сервис аутентификации прозрачен для клиента. Система безопасности RADIUS с EAP расширениями поддерживается только сервером аутентификации.