По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие наши статьи:
img
В этой статье мы рассмотрим некоторые протоколы, такие как NTP, syslog и SNMP. Все они используются для мониторинга "работоспособности" вашей сети. При правильной настройке они могут быть очень полезны...если они не работают, может быть действительно трудно выяснить, когда в сети произошло определенное событие и что его вызвало. Syslog и SNMP используются для мониторинга сети, NTP используется для обеспечения того, чтобы наша регистрационная информация имела правильное время и дату. Мы начнем с NTP - это не очень сложный протокол, но есть несколько вещей, которые могут пойти не так: Фильтрация трафика NTP: списки доступа могут блокировать трафик NTP. Проблемы аутентификации NTP: NTP поддерживает аутентификацию, клиент и сервер должны использовать одинаковые настройки. Слишком большое временное смещение: если временное смещение между клиентом и сервером слишком велико, для синхронизации потребуется очень много времени. Stratum level слишком высокий: Stratum level составляет от 1 (лучший) до 15 (худший). Stratum level 16 считается непригодным. Фильтр источника NTP-сервера: NTP-серверы можно настроить так, чтобы разрешать только клиентам с определенных IP-адресов. Давайте разберем эти вопросы. Мы будем использовать два маршрутизатора для этого: Урок 1 R1 будет нашим NTP-клиентом, а R2 будет NTP-сервером. Есть две полезные команды, с которых мы должны начать: Команды говорят нам, что R1 имеет адрес 192.168.12.2, настроенный как сервер NTP, и в настоящее время он не синхронизирован. Давайте проверим, получает ли R1 пакеты NTP, это лучше всего сделать с помощью отладки: Эта отладка говорит нам, что R1 отправляет NTP-пакеты, но мы ничего не получаем от NTP-сервера. Убедитесь, что NTP-сервер разрешен для прохождения: R1 использует UDP-порт 123, убедитесь, что он не заблокирован: R1(config)#interface FastEthernet 0/0 R1(config-if)#no ip access-group NO_TIME in После удаления списка доступа, NTP сможет использовать пакеты NTP с сервера: Вот конечный результат: Часы теперь синхронизированы. Другая проблема, которую вы можете обнаружить с помощью debugging NTP, - это несоответствие аутентификации: R1(config)#ntp server 192.168.12.2 key 1 R1(config)#ntp authentication-key 1 md5 MY_KEY Мы настроим R1 так, чтобы он принимал только NTP-пакеты от NTP-сервера, которые аутентифицированы с определенным ключом. Сервер NTP, однако, не использует никакой формы аутентификации. Мы можем найти эту ошибку с помощью следующей отладки: Это расскажет нам о: Убедитесь, что ваши настройки аутентификации NTP совпадают с обеих сторон. Когда разница во времени / дате между сервером NTP и клиентом велика, синхронизация займет много времени. Прямо сейчас часы выглядят так: Установка часов на NTP-клиенте на что-то близкое к NTP-серверу значительно ускорит процесс синхронизации: R1#clock set 18:00:00 30 January 2015 Через несколько минут часы на клиенте NTP должны быть синхронизированы. Еще одна проблема с NTP заключается в том, что stratum level ограничен, мы можем использовать значения от 1 (лучший) до 15 (худший). Если у сервера NTP есть stratum level 15, то клиент NTP не сможет синхронизировать, так как 16 считается недостижимым. Отладка пакетов NTP на клиенте покажет это: R1 никогда не сможет синхронизировать себя, поскольку NTP-сервер объявляет себя как stratum -уровень 15. Вы можете исправить это, установив более низкое значение stratum - уровня NTP на своем NTP-сервере: R2(config)#ntp master 2 Мы изменяем его на значение 2 уровня. Это позволяет R1 синхронизировать себя: И последнее, но не менее важное: NTP-серверы могут быть настроены так, чтобы разрешать NTP-клиентам только с определенных IP-адресов: Например, мы настрою его, чтобы разрешить только IP-адрес 1.1.1.1: R2(config)#ntp access-group serve 1 R2(config)#access-list 1 permit 1.1.1.1 R2(config)#ip route 1.1.1.1 255.255.255.255 192.168.12.1 В этом случае нам нужно убедиться, что NTP-клиент получает свои NTP-пакеты с правильного IP-адреса: R1(config)#interface loopback 0 R1(config-if)#ip address 1.1.1.1 255.255.255.255 R1(config)#ntp source loopback0 Команда NTP source скажет R1 использовать IP-адрес 1.1.1.1 из своего loopback интерфейса в качестве источника своих пакетов NTP. Это самые распространенные ошибки NTP. Урок 2 Давайте продолжим, посмотрев на syslog. Наиболее распространенная проблема с системным журналом - это отсутствие информации о регистрации. По умолчанию ведение журнала включено только для консоли, а не для внешних серверов системного журнала. Есть одна команда, которую вы можете использовать для проверки ее конфигурации: Это говорит нам, что системный журнал включен для консоли вплоть до уровня отладки. Если вы не видите всего на консоли, то кто-то, возможно, изменил уровень ведения журнала на более низкое значение. Вот варианты: Уровень отладки - самое высокое значение (7), поэтому он покажет все сообщения системного журнала. Если вы не видите все сообщения, убедитесь, что они установлены на уровне отладки для консоли. По умолчанию информация системного журнала не отправляется на внешний сервер. Вы должны это настроить самостоятельно: R1(config)#logging host 192.168.12.2 Это приведет к отправке регистрационной информации для всех уровней серьезности на внешний сервер по адресу 192.168.12.2. Убедитесь, что этот трафик не заблокирован, syslog использует UDP-порт 514. Другая распространенная ошибка - сообщения системного журнала не отображаются в сеансах telnet или SSH. Вы можете включить это с помощью команды terminal monitor. Урок 3 Следующий протокол, который мы обсудим, - это SNMP версии 2c и 3. Перед тем, как погрузиться в конфигурацию SNMP, убедитесь, что ваш NMS (сервер сетевого управления) может связаться с вашим устройством (агент SNMP). SNMP использует UDP-порт 161 для сообщений и UDP-порт 162 для прерываний и информирования. Убедитесь, что этот трафик разрешен. Когда дело доходит до SNMPv2c, есть несколько общих проблем: Неправильная community-string: community-string похожа на пароль, который используется для того, чтобы NMS могла читать или записывать данные на сетевое устройство. Если он не совпадает, SNMP не будет работать. Ошибки списка доступа: списки доступа могут определять, какой NMS разрешено использовать community-string. Убедитесь, что вы используете правильный IP-адрес. Перемешивание индексов: при добавлении новых интерфейсов к сетевому устройству номера интерфейсов могут больше не совпадать. Ловушки не отправлены: если вы хотите отправить SNMP-ловушки (или сообщения), то вам нужно будет настроить это, это не делается автоматически. Вот соответствующие команды SNMPv2c, которые вы должны проверить в случае, если SNMP не работает: R1(config)#snmp-server community MY_COMMUNITY ro 1 R1(config)#access-list 1 permit host 192.168.1.1 Выше мы настроили сообщество под названием MY_COMMUNITY с доступом только для чтения. Мы используем access-list 1, чтобы определить, какому устройству разрешено использовать это сообщество. Убедитесь, что в списке доступа указаны правильные операторы разрешений. Следующая команда гарантирует, что индекс интерфейса остается прежним: R1(config)#snmp-server ifindex persist И если вы хотите отправлять SNMP-ловушки, настройте его следующим образом: R1(config)#snmp-server enable traps eigrp R1(config)#snmp-server host 192.168.1.1 traps version 2c MY_COMMUNITY Это активирует ловушки SNMP для EIGRP и будет отправлено в NMS на IP-адрес 192.168.1.1 с использованием сообщества "MY_COMMUNITY". Если вы не укажете, какие ловушки вы хотите, он включит все ловушки. SNMPv3 сильно отличается от версии 2, в безопасность и аутентификацию внесено много изменений. При поиске и устранении неисправностей SNMPv3 необходимо учитывать несколько моментов, связанных с SNMPv3: Вложенность: с помощью SNMPv3 мы создаем пользователей, которые вложены в группы. Группы вложены в представления, которые предоставляют доступ к определенным MIBs на сетевом устройстве. Убедитесь, что ваш пользователь находится в правильной группе и что представление имеет правильные разрешения на просмотр. Уровень безопасности: SNMPv3 поддерживает разные уровни безопасности, они должны совпадать на сетевом устройстве и NMS: noAuthNoPriv authNoPriv authPriv Параметры безопасности: SNMPv3 предлагает несколько алгоритмов хеширования и шифрования. Убедитесь, что вы настроили одинаковые алгоритмы на сетевом устройстве и NMS. Конфигурация представлений: в представлении мы настраиваем объекты, к которым NMS разрешен доступ, убедитесь, что вы настроили правильные объекты. Ниже приеден пример конфигурации того, что мы обсуждали: Router(config)#snmp-server user MY_USER MY_GROUP v3 auth md5 MY_PASSWORD priv aes 128 MY_PASSWORD Сначала мы настраиваем пользователя с именем MY_USER, который принадлежит группе с именем MY_GROUP. Мы используем версию 3 SNMP. Для аутентификации этого пользователя мы используем MD5 и пароль "MY_PASSWORD". Для шифрования мы используем 128-битный AES и тот же пароль. Убедитесь, что на сетевом устройстве и NMS все одинаково ... Теперь мы настраиваем группу: Router(config)#snmp-server group MY_GROUP v3 priv read MY_VIEW access 1 Router(config)#access-list 1 permit host 192.168.1.1 Группа называется MY_GROUP, и мы используем уровень безопасности authPriv. Мы также присоединяем группу к представлению под названием MY_VIEW. Мы также используем список доступа, только NMS, использующая IP-адрес 192.168.1.1, может использовать эту группу. Давайте настроим view: Router(config)#snmp-server view MY_VIEW system included Router(config)#snmp-server view MY_VIEW cisco included Это представление позволяет NMS получать доступ только к объектам в системной группе MIB-II и ко всем объектам в корпоративной MIB Cisco. Убедитесь, что вы добавили все объекты, к которым вам нужен доступ. Информация о пользователе не отображается в конфигурации, если вы хотите увидеть пользователей, вам нужно использовать другую команду: Эта команда показывает нам нашу учетную запись пользователя, ее алгоритмы аутентификации и шифрования и сообщает, к какой группе она принадлежит.
img
Пока не создан единый протокол маршрутизации, управляющий остальными, существует необходимость в том, чтобы несколько протоколов маршрутизации мирно сосуществовали в одной сети. К примеру, одна компания работает с OSPF, а другая компания работает с EIGRP, и эти две компании слились в одно целое предприятие. Пока вновь образованный ИТ-персонал не перейдет для использования на единый протокол маршрутизации (возможно они когда-нибудь это сделают), маршруты, известные протоколу OSPF, необходимо объявить в часть сети, работающей под управлением EIGRP, и наоборот. Упомянутый выше сценарий возможен благодаря Route redistribution, и именно этому посвящена данная статья. Другие причины, по которым вам потребуется выполнить Route redistribution, это: различные части сети конкретной компании находятся под различным административным контролем; если необходимо объявить маршруты своему поставщику услуг через BGP, или, возможно, необходимо подключиться к сети делового партнера. Рассмотрим следующую базовую топологию. В простой топологии, показанной выше, мы хотим, чтобы OSPF и EIGRP объявляли друг другу маршруты, о которых они знают. Эта концепция называется взаимным перераспределением маршрутов. Поскольку роутер CENTR имеет один интерфейс в автономной системе OSPF (AS) и один интерфейс в EIGRP AS, он несет ответственность за выполнение Route redistribution. Seed Metrics Основная проблема, с которой мы сталкиваемся при Route redistribution между различными протоколами маршрутизации, заключается в разнообразных подходах, применяемых протоколами маршрутизации для измерения своих метрик. Например, OSPF использует cost-метрику, которая основана на bandwidth, в то время как EIGRP использует метрику, основанную на bandwidth и delay, но также может учитывать надежность или (и) нагрузку (и даже использовать Maximum Transmission Unit (MTU) в качестве прерывания связи). Итак, что же нам делать? Мы, как администраторы, можем настроить метрику, назначенную маршрутам, поступающим из одной AS, которые перераспределяются в другую AS. Если нам лень вручную настраивать метрику, которая будет использоваться для Route redistribution, то используется seed metric. В следующей таблице показаны seed metrics, используемые различными протоколами маршрутизации. Основываясь на приведенной выше таблице, мы видим, что, маршрутам, которые перераспределяются в OSPF по дефолту будет назначена метрика 20, если же маршруты, перераспределяются в протокол OSPF от протокола BGP, то им будет присвоено значение метрики 1. Интересно, что и RIP, и EIGRP по умолчанию имеют seed metrics бесконечности. Это означает, что любой маршрут, перераспределенный в эти протоколы маршрутизации, будет считаться недостижимым по умолчанию и поэтому не объявляются никаким другим роутерам. BGP, однако, перераспределяет маршрут, полученный из протокола внутреннего шлюза (IGP), используя исходную метрику этого маршрута. Пример базовой настройки Конечно, есть еще много вопросов, связанных с перераспределением маршрутов, таких как циклы маршрутизации, которые могут возникнуть, когда у нас есть несколько роутеров, соединяющих наши автономные системы, или выборочная фильтрация определенных маршрутов от перераспределения. Но мы вернемся ко всему этому в следующих статьях. А пока давайте разберемся, как выполнить базовую настройку Route redistribution (перераспределения маршрутов). Рассмотрим предыдущую топологию, на этот раз с добавлением информации о сети и интерфейсе: В этой топологии роутер CENTR изучает маршруты от OFF1 через OSPF и от OFF2 через EIGRP. Это видно в выходных данных команды show ip route, отображенной на CENTR: Однако ни роутер OFF1, ни роутер OFF2 не изучили никаких маршрутов, потому что роутер CENTR еще не выполняет Route redistribution. Об этом свидетельствует вывод команды show ip route, отображенной на OFF1 и OFF2: Теперь давайте добавим конфигурацию Route redistribution к роутеру CENTR. Чтобы подтвердить предыдущее утверждение о том, что seed metric для маршрутов, перераспределяемых в EIGRP, является бесконечностью, мы изначально не будем настраивать какие-либо метрики и позволим seed metric вступить в силу. CENTR# conf term Enter configuration commands, one per line. End with CNTL/ Z CENTR(config)#router ospf 1 CENTR(config-router)#redistribute eigrp 1 CENTR(config-router)#exit CENTR(config)#router eigrp 1 CENTR(config-router)# redistribute ospf 1 CENTR(config-router)#end CENTR# Команда redistribute применена в режиме конфигурации роутера для каждого протокола маршрутизации, и метрика не была указана. Важно, что, когда мы ввели команду redistribute eigrp 1 выше, мы не включили ключевое слово subnets в команду, которая заставляет как классовые, так и бесклассовые сети перераспределяться в OSPF. Однако, как видно из приведенных ниже выходных данных, ключевое слово subnets было автоматически добавлено для нас: Данное поведение автоматического добавления ключевого слова subnets наблюдается в последних версиях Cisco IOS. Некоторые, более старые версии Cisco IOS, не включают автоматически ключевое слово subnets, и вам может потребоваться вручную добавить его в команду redistribute. Давайте теперь взглянем на таблицы IP-маршрутизации на роутерах OFF1 и OFF2, чтобы увидеть, какие маршруты они изучили (и не изучили). Приведенные выше выходные данные показывают нам, что роутер CENTR успешно перераспределил маршруты, известные EIGRP в OSPF, которые затем были изучены роутером OFF1. Обратите внимание, что перераспределенные маршруты, известные роутеру OFF1, имеют метрику 20, которая является seed metrics OSPF. Однако роутер OFF2 не изучал никаких новых маршрутов, потому что, когда роутер CENTR перераспределял маршруты в EIGRP, он использовал seed metrics EIGRP бесконечность (что означает недостижимость). В результате эти маршруты не были объявлены роутеру OFF2. Чтобы решить эту проблему, нам нужно назначить метрику маршрутам, перераспределяемым в EIGRP. Существует три основных способа присвоения не дефолтных метрик маршрутам, перераспределяемым в протокол маршрутизации.. Установите метрику по умолчанию для всех протоколов маршрутизации, перераспределяемых в определенный протокол маршрутизации. Установите метрику как часть команды redistribute. Установите метрику используя route-map Чтобы проиллюстрировать первый вариант, давайте настроим метрику для назначения всем маршрутам, перераспределяемым в EIGRP. CENTR#configuration terminal Enter configuration commands, one per line. End with CNTL/Z. CENTR (config)#router eigrp 1 CENTR (config-router)#default-metric ? 1-4294967295 Bandwidth in Kbits per second CENTR (config-router)#default-metric 1000000 ? 0-4294967295 delay metric in 10 microsecond units CENTR(config-router)#default-metric 1000000 1 ? 0-255 Reliability metric where 255 is 100% reliable CENTR (config-router)#default-metric 1000000 1 255 ? 1-255 Effective bandwidth metric (Loading) where 255 is 100% loaded CENTR (config-router)#default-metric 1000000 1 255 1 ? 1-65535 Maximum Transmission Unit metric of thenpath CENTR (config-router)#default-metric 1000000 1 255 1 1500 CENTR (config-router)#end CENTR# Контекстно-зависимая справка была использована в приведенном выше примере для отображения каждого компонента метрики, назначаемого маршрутам, перераспределяемым в EIGRP. Однако последняя команда была default-metric 1000000 1 255 1 1500. Если бы мы устанавливали default-metric для OSPF, мы могли бы использовать такую команду, как default-metric 30, чтобы назначить стоимость 30 OSPF маршрутам, перераспределяемым в OSPF. Однако в этом примере мы указали только default-metric для EIGRP. Давайте теперь проверим таблицу IP-маршрутизации на роутере OFF2, чтобы увидеть, были ли маршруты OSPF успешно объявлены в EIGRP. Прекрасно! Роутер OFF2 изучил маршруты, происходящие из OSPF AS. Мы знаем, что маршруты первоначально пришли из-за пределов EIGRP, из-за кода EX, появляющегося в каждом из этих маршрутов. Второй вариант установки метрики на Route Redistribution состоял в том, чтобы назначить метрику как часть команды redistribute, которая позволяет нам указать различные метрики для различных протоколов маршрутизации, перераспределяемых в процесс маршрутизации. Чтобы проиллюстрировать этот подход, давайте удалим предыдущие команды default-metric и redistribute из роутера CENTR и введем команду redistribute, которая определяет метрику, которая будет назначена. CENTR#configuration terminal Enter configuration commands, one per line. End with CNTL/Z. CENTR(config)#router eigrp 1 CENTR(config-router)#no default-metric 1000000 1 255 1 1500 CENTR(config-router)#no redistribute ospf 1 CENTR(config-router)#redistribute ospf 1 ? Match Redistribution of OSPF routes metric Metric for redistributed routes route-map Route map reference cr CENTR(config-router)#redistribute ospf 1 metric 1000000 1 255 1 1500 CENTR(config-router)#end CENTR# Если мы сейчас вернемся к роутеру OFF2, то получим тот же результат, что и раньше: Третьим вариантом установки метрики для Route Redistribution использовании маршрутной карты (route-map). Маршрутные карты являются супермощными и могут быть использованы для различных конфигураций. По сути, они могут соответствовать определенному трафику и устанавливать один или несколько параметров (например, IP-адрес следующего прыжка) для этого трафика. Однако в нашем контексте мы просто будем использовать route-map для указания значения метрики, а затем применим ее к команде redistribute. В следующем примере показано, как мы можем удалить нашу предыдущую команду redistribute из роутера CENTR, создать route-map, а затем ввести новую команду redistribute, которая ссылается на нашу карту маршрута (route-map): CENTR#configuration terminal Enter configuration commands, one per line. End with CNTL/Z. CENTR(config)#router eigrp 1 CENTR(config-router)#no redistribute ospf 1 metric 1000000 1 255 1 1500 CENTR(config-router)#exit CENTR(config)#route-map SET-МETRIC-DEMO CENTR(config-route-map)#set metric 1000000 1 255 1 1500 CENTR(config-route-map)#exit CENTR(config)#router eigrp 1 CENTR(config-router)#redistribute ospf 1 route-map SET-МETRIC-DEMO CENTR(config-router)#end CENTR# В приведенном выше примере, после удаления нашей команды redistribute, мы создали карту маршрута с именем SET-METRIC-DEMO. Это был очень простой route-map, которая не должна была соответствовать никакому траффику. Он был просто использован для установки метрики. Однако в следующей статье мы увидим, что route-map может быть использована, чтобы дать нам больше контроля над нашим перераспределением маршрутов. В нашем текущем примере карта маршрута была затем применена к нашей новой команде redistribute. Опять же, это дает нам тот же результат с точки зрения таблицы IP-маршрутизации роутера OFF2: OSPF E1 или E2 Routes Прежде чем мы закончим эту статью в нашей серии Route redistribution, давайте еще раз рассмотрим таблицу IP-маршрутизации на роутере OFF1: Обратите внимание, что каждый из маршрутов, перераспределенных в OSPF, отображается в таблице IP-маршрутизации роутера OFF1 с кодом E2. Однако наблюдаются также код E1, оба указывающих, что маршрут возник из-за пределов OSPF AS роутера. Итак, в чем же разница между этими двумя кодами? Код E2 указывает, что маршрут несет метрику, назначенную роутером, выполняющим перераспределение, который известен как автономный системный пограничный роутер (ASBR). Это означает, что независимо от того, сколько дополнительных роутеров в OSPF мы должны пересечь, чтобы вернуться к ASBR, метрика остается такой же, какой она была, когда ASBR перераспределил ее. Когда мы перераспределяем маршруты в OSPF, эти маршруты, по дефолту, являются этими External Type 2 (E2). Код E1 указывает, что метрика маршрута состоит из первоначальной стоимости, назначенной ASBR, плюс стоимость, необходимая для достижения ASBR. Это говорит о том, что маршрут Е1, как правило, более точен, и на самом деле это так. Хотя наличие кода E1 не дает нам никакого преимущества в простой топологии, как у нас, где роутер OFF1 имеет только один путь для достижения ASBR (т. е. CENTR), и где есть только один способ для маршрутов EIGRP быть введенными в наш OSPF AS (т. е. через роутер CENTR). Если мы хотим перераспределить маршруты E1 в OSPF вместо маршрутов E2, то это можно сделать с помощью команды redistribute. В следующем примере мы удаляем нашу команду redistribute для процесса маршрутизации OSPF на роутере CENTR, а затем повторно применяем команду redistribute, указывающую, что мы хотим, чтобы External Type 1 (E1) применялись к перераспределенным маршрутам. CENTR#configuration terminal Enter configuration commands, one per line. End with CNTL/Z. CENTR(config)#router ospf 1 CENTR(config-router)#no redistribute eigrp 1 subnets CENTR(config-router)#redistribute eigrp 1 metric-type ? 1 Set OSPF External Туре 1 metrics 2 Set OSPF External Туре 2 metrics CENTR(config-router)#redistribute eigrp 1 metric-type 1 CENTR(config-router)#end CENTR#show Давайте проверим таблицу IP-маршрутизации на роутере OFF1, чтобы увидеть, изменились ли параметры на основе этой новой команды redistribute, введенной на роутере CENTR. В приведенных выше выходных данных обратите внимание, что маршруты, перераспределенные в OSPF, имеют код E1, а не дефолтный код E2. Кроме того, обратите внимание, что это приводит к тому, что метрика этих маршрутов будет немного выше. В частности, роутер CENTR перераспределил EIGRP-изученные маршруты в OSPF, используя начальную метрику OSPF 20. Однако существует стоимость OSPF 1, чтобы добраться от роутера OFF1 до роутера CENTR. Таким образом, поскольку перераспределенные маршруты были сконфигурированы как маршруты E1, стоимость этих маршрутов с точки зрения роутера OFF1 является стоимостью, первоначально назначенной роутером OFF1, которая составляла 20, плюс стоимость для OFF1, чтобы добраться до CENTR, который равен 1, итого общей стоимости 21. Отлично, теперь вы знаете, как делать перераспределение маршрутов. Теперь почитайте, как сделать Фильтрацию маршрутов с помощью карт маршрутов.
img
Привет! В предыдущей статье, посвященной основам WLAN, вы узнали о беспроводных клиентах, формирующих ассоциации с беспроводными точками доступа (AP) и передающих данные по Wi-Fi. В сегодняшней статье мы рассмотрим анатомию защищенного соединения в беспроводных сетях. Основы защищенного соединения в беспроводных сетях. Все клиенты и точки доступа, которые соответствуют стандарту 802.11, могут сосуществовать на одном канале. Однако не всем устройствам, поддерживающим стандарт 802.11, можно доверять. Нужно понимать, что данные передаются не как в проводной сети, то есть непосредственно от отправителя к получателю, а от приемника до ближайшей точки доступа, располагаемой в зоне досягаемости. Рассмотрим случай, изображенный на рисунке ниже. Беспроводной клиент соединяется с каким-либо удаленным объектом с использованием зашифрованного пароля. В сети так же присутствуют два не доверенных пользователя. Они находятся в пределах диапазона сигнала клиента и могут легко узнать пароль клиента, перехватив данные, отправленные по каналу. Особенности беспроводной связи позволяют легко перехватывать пересылаемые пакеты злоумышленниками. Если данные передаются по беспроводным каналам, как их можно защитить от перехвата и взлома? В стандарте 802.11 предусмотрены механизмы безопасности, которые используются для обеспечения доверия, конфиденциальности и целостности беспроводной сети. Далее более подробно разберем методы беспроводной безопасности. Аутентификация. Для того чтобы начать использовать беспроводную сеть для передачи данных, клиенты сначала должны обнаружить базовый набор услуг (BSS), а затем запросить разрешение на подключение. После чего клиенты должны пройти процедуру аутентификации. Зачем это делать? Предположим, что ваша беспроводная сеть позволяет подключиться к корпоративным ресурсам, располагающим конфиденциальной информацией. В этом случае доступ должен предоставляться только тем устройствам, которые считаются надежными и доверенными. Гостевым пользователям, если они вообще разрешены, разрешается подключиться к другой гостевой WLAN, где они могут получить доступ к не конфиденциальным или общедоступным ресурсам. Не доверенным клиентам, вообще рекомендуется запретить доступ. В конце концов, они не связаны с корпоративной сетью и, скорее всего, будут неизвестными устройствами, которые окажутся в пределах досягаемости вашей сети. Чтобы контролировать доступ, WLAN могут аутентифицировать клиентские устройства, прежде чем им будет разрешено подключение. Потенциальные клиенты должны идентифицировать себя, предоставив информацию учетных данных для точки доступа. На рисунке ниже показан основной процесс аутентификации клиента. Существует много методов аутентификации по «воздуху». Есть методы, которые требуют ввода только кодового слова, которое является общим для всех доверенных клиентов и AP. Кодовое слово хранится на клиентском устройстве и при необходимости передается непосредственно в точку доступа. Что произойдет, если устройство будет утеряно или похищено? Скорее всего, любой пользователь, владеющий данным устройством, сможет аутентифицироваться в сети. Другие, более строгие методы аутентификации требуют взаимодействия с корпоративной базой данных пользователей. В таких случаях конечный пользователь должен ввести действительное имя пользователя и пароль. В обычной жизни, при подключении к любой беспроводной сети, мы неявно доверяем ближайшей точке доступа проверку подлинности нашего устройства. Например, если вы на работе, используя устройство с беспроводной связью, найдете WI-Fi, скорее всего, подключитесь к ней без колебаний. Это утверждение верно для беспроводных сетей в аэропорту, торговом центре, или дома - вы думаете, что точка доступа, которая раздает SSID, будет принадлежать и управляться организацией, в которой вы находитесь. Но как вы можете быть уверены в этом? Как правило, единственная информация, которой вы владеете- это SSID транслируемый в эфир точкой доступа. Если SSID знаком, вы, скорее всего, подключитесь к ней. Возможно, ваше устройство настроено на автоматическое подключение к знакомому SSID, так что оно подключается автоматически. В любом случае, есть вероятность невольно подключиться к тому же SSID, даже если он рассылается злоумышленником. Некоторые атаки, организованные злоумышленником, осуществляются посредством подмены точки доступа. «Поддельная» точка доступа, аналогично настоящей, так же рассылает и принимает запросы, и затем осуществляет ассоциацию клиентов с АР. Как только клиент подключается к «поддельной» AP, злоумышленник может легко перехватить все данные передаваемые от клиента к центральному узлу. Подменная точка доступа может также отправлять поддельные фреймы управления, которые деактивируют подключенных клиентов, для нарушения нормального функционирования сети. Чтобы предотвратить этот тип атаки, называемой «man-in-the-middle», клиент должен сначала идентифицировать точку доступа, и только потом подключиться, используя логин и пароль (пройти аутентификацию). На рисунке ниже показан простой пример данного защищенного подключения. Также, клиент, получая пакеты управления, должен быть уверен, что они отправлены с проверенной и доверенной точки доступа. Конфиденциальность сообщений. Предположим, что клиент изображенный на рисунке 3, должен пройти аутентификацию перед подключением к беспроводной сети. Клиент должен идентифицировать точку доступа и её фреймы управления для подключения перед аутентификацией себя на устройстве. Отношения клиента с точкой доступа могли бы быть более доверительными, но передача данных по каналу все еще подвергается опасности быть перехваченной. Чтобы защитить конфиденциальность данных в беспроводной сети, данные должны быть зашифрованы. Это возможно кодированием полезной нагрузки данных в каждом фрейме, пересылаемым по WI-Fi, непосредственно перед отправкой, а затем декодирования ее по мере поступления. Идея заключается в использование единого метода шифрования/дешифрования как на передатчике, так и на приемнике, чтобы данные могли быть успешно зашифрованы и расшифрованы. В беспроводных сетях каждый WLAN может поддерживать только одну схему аутентификации и шифрования, поэтому все клиенты должны использовать один и тот же метод шифрования при подключении. Вы можете предположить, что наличие одного общего метода шифрования позволит любому клиенту сети перехватывать пакеты других клиентов. Это не так, потому что точка доступа при подключении к клиенту высылает специальный ключ шифрования. Это уникальный ключ, который может использовать только один клиент. Таким образом точка доступа рассылает каждому клиенту свой уникальный ключ. В идеале точка доступа и клиент- это те два устройства, которые имеют общие ключи шифрования для взаимодействия. Другие устройства не могут использовать чужой ключ для подключения. На рисунке ниже конфиденциальная информация о пароле клиента была зашифрована перед передачей. Только точка доступа может успешно расшифровать его перед отправкой в проводную сеть, в то время как другие беспроводные устройства не могут. Точка доступа также поддерживает «групповой ключ» (group key), когда ей необходимо отправить зашифрованные данные всем клиентам ячейки одновременно. Каждый из подключенных клиентов использует один и тот же групповой ключ для расшифровки данных. Целостность сообщения Шифрование данных позволяет скрыть содержимое от просмотра, при их пересылке по общедоступной или ненадежной сети. Предполагаемый получатель должен быть в состоянии расшифровать сообщение и восстановить исходное содержимое, но что, если кто-то сумел изменить содержимое по пути? Получатель не сможет определить, что исходные данные были изменены. Проверка целостности сообщений (MIC)- это инструмент безопасности, который позволяет защитить от подмены данных. MIC представляет собой способ добавления секретного штампа в зашифрованный кадр перед отправкой. Штамп содержит информацию о количестве битов передаваемых данных. При получении и расшифровке фрейма устройство сравнивает секретный шифр с количеством бит полученного сообщения. Если количество бит совпадает, то соответственно данные не были изменены или подменены. На рисунке ниже изображен процесс MIC. На рисунке показано, что клиент отправляет сообщение точке доступа через WLAN. Сообщение зашифровано, «741fcb64901d». Сам процесс MIC заключается в следующем: Исходные данные –«P@ssw0rd». Затем вычисляется секретный шифр MIC (штамп). После вычисления штампа происходит шифрование данных и MIC завершается. На стороне получателя следует расшифровка, вычисление MIC и сравнение штампов.
ВЕСЕННИЕ СКИДКИ
40%
50%
60%
До конца акции: 30 дней 24 : 59 : 59