По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
Безопасность транспортного уровня (TLS), также известная как Secure Socket Layer (SSL), является протоколом безопасного транспортного уровня, развернутым по умолчанию в большинстве веб-браузеров. Когда пользователи видят маленький зеленый замок, указывающую на то, что веб-сайт "безопасен", это означает, что SSL-сертификат действителен, а трафик между хостом (на котором работает браузер) и сервером (на котором работает веб-сервер) шифруется. TLS-это сложный протокол с большим количеством различных опций; в этом разделе будет представлен приблизительный обзор его работы. На рисунке 3 показаны компоненты пакета TLS.
На рисунке 3:
Протокол рукопожатия отвечает за инициализацию сеансов и настройку параметров сеанса, включая начальный обмен закрытыми ключами.
Протокол предупреждений отвечает за обработку ошибок.
Изменение спецификации шифра отвечает за запуск шифрования.
Протокол записи разбивает блоки данных, представленные для транспортировки, на фрагменты, (необязательно) сжимает данные, добавляет Message Authentication Code (MAC), шифрует данные с помощью симметричного ключа, добавляет исходную информацию в блок, а затем отправляет блок в Transmission Control Protocol (TCP) для транспортировки по сети.
Приложения, работающие поверх TLS, используют специальный номер порта для доступа к службе через TLS. Например, веб-службы, использующие протокол передачи гипертекста (HTTP), обычно доступны через TCP-порт 80. Протокол HTTP с шифрованием TLS обычно доступен через порт 443. Хотя служба остается той же, изменение номера порта позволяет процессу TCP направлять трафик, который должен быть незашифрован, чтобы конечное приложение могло его прочитать.
MAC, который в этом контексте будет означать код аутентификации сообщения, используется для обеспечения аутентификации отправителя. В то время как некоторые криптографические системы предполагают, что успешное шифрование данных с помощью ключа, известного получателю, доказывает, что отправитель действительно тот, за кого он себя выдает, TLS этого не делает.
Вместо этого TLS включает MAC, который проверяет отправителя отдельно от ключей, используемых для шифрования сообщений в сети. Это помогает предотвратить атаки MitM на потоки данных, зашифрованные с помощью TLS.
На рисунке 4 показано рукопожатие запуска TLS, которое управляется протоколом рукопожатия.
На рисунке 4:
Приветствие клиента отправляется в виде открытого текста и содержит информацию о версии TLS, которую использует клиент, 32 случайных октета (nonce), идентификатор сеанса (который позволяет восстановить или восстановить предыдущий сеанс), список алгоритмов шифрования (наборов шифров), поддерживаемых клиентом, и список алгоритмов сжатия данных, поддерживаемых клиентом.
Приветствие сервера также отправляется в виде открытого текста и содержит ту же информацию, что и выше, с точки зрения сервера. В приветственном сообщении сервера поле алгоритма шифрования указывает тип шифрования, который будет использоваться для этого сеанса. Обычно это "лучший" алгоритм шифрования, доступный как на клиенте, так и на сервере (хотя он не всегда "лучший").
Сервер отправляет свой открытый ключ (сертификат) вместе с nonce, который клиент отправил на сервер, где nonce теперь шифруется с помощью закрытого ключа сервера.
Сообщение сервера hello done (принятие приветствия) указывает, что теперь у клиента есть информация, необходимая для завершения настройки сеанса.
Клиент генерирует закрытый ключ и использует открытый ключ сервера для его шифрования. Это передается в сообщении обмена ключами клиента на сервер.
После того, как это было передано, клиент должен подписать что-то, что известно, как серверу, так и клиенту, чтобы убедиться, что отправитель является правильным устройством. Обычно до этого момента подпись присутствует во всех сообщениях обмена. Как правило, криптографический хеш используется для генерации проверки.
Сообщение об изменении спецификации шифра по существу подтверждает, что сеанс запущен и работает.
Готовое сообщение (завершение) еще раз аутентифицирует все предыдущие сообщения рукопожатия до этого момента.
Затем сервер подтверждает, что сеанс шифрования установлен, отправив сообщение изменения спецификации шифра.
Затем сервер отправляет готовое сообщение, которое аутентифицирует предыдущие сообщения, отправленные в рукопожатии таким же образом, как и выше.
Примечание. Дополнительные шаги в рукопожатии TLS были исключены из этого объяснения для ясности.
После того, как сеанс запущен, приложения могут отправлять информацию принимающему хосту по правильному номеру порта. Эти данные будут зашифрованы с использованием предварительно согласованного закрытого ключа и затем переданы TCP для доставки.
Предыдущая статья из цикла про устранение неисправностей DHCP на Cisco доступна по ссылке.
Последняя статья будет посвящена некоторым проблемам с FHRP, мы начнем с VRRP!
Урок 1
В сценарии выше у нас есть проблема с HSRP. Сначала разберем топологию. С левой стороны находится клиент (мы используем маршрутизатор, чтобы иметь возможность воссоздать его в GNS3), который использует виртуальный IP-адрес в качестве шлюза по умолчанию. R2 и R3 настроены для HSRP. На правой стороне есть маршрутизатор с IP-адресом 4.4.4.4 на интерфейсе loopback0. К сожалению, наш клиент не может пропинговать 4.4.4.4. Что здесь происходит?
Сначала мы отправим эхо-запрос от клиента на IP-адрес 4.4.4.4. Вы видите символ U (недостижимый), поэтому мы знаем, что получаем ответ от шлюза по умолчанию.
Таблица маршрутизации была отключена на этом клиентском маршрутизаторе (нет ip-маршрутизации), но вы можете видеть, что шлюз по умолчанию был настроен. Давайте посмотрим, доступен ли этот IP-адрес.
Достигнуть шлюза по умолчанию не проблема, поэтому мы можем перенести фокус на R2 или R3.
Мы можем использовать команду show standby, чтобы убедиться, что R3 является активным маршрутизатором HSRP. Давайте проверим, может ли он достичь IP-адреса 4.4.4.4.
Увы ...пинг не проходит.
Его нет в таблице маршрутизации, и если вы посмотрите внимательно, то увидите, что FastEthernet1/0 не находится в таблице маршрутизации как непосредственно подключенный, это указывает на то, что что-то не так с этим интерфейсом.
Ну вот...интерфейс отключен.
R3(config)#interface fastEthernet 1/0
R3(config-if)#no shutdown
Включим его!
Ну вот, теперь он работает.
Проблема устранена ... теперь клиент может пинговать 4.4.4.4! Есть еще одна вещь, хотя ... мы используем HSRP, так что наш шлюз по умолчанию не является единственной точкой отказа, но в этом случае R3 имел сбой соединения...разве R2 не должен взять на себя управление?
interface tracking было включено, и вы можете видеть, что приоритет должен уменьшиться на 10, если интерфейс FastEthernet1/0 перейдет в состояние down. Это означает, что обычно R2 должен взять на себя управление, но preemption is disabled по умолчанию для HSRP.
R2(config)#interface fastEthernet 0/0
R2(config-if)#standby 1 preempt
R3(config)#interface fastEthernet 0/0
R3(config-if)#standby 1 preempt
Прежде чем отпраздновать нашу победу в устранении неполадок, мы должны убедиться, что эта проблема больше не возникнет в будущем. Мы включим приоритет на обоих маршрутизаторах. Теперь все готово!
Итог урока: убедитесь, что preemption включена для HSRP, если вы используете interface tracking
Урок 2
Вот та же топология, но на этот раз мы используем VRRP вместо HSRP. Однако проблема заключается в другом: клиент жалуется, что не все IP-пакеты попадают в 4.4.4.4.
Некоторые из IP-пакетов не поступают в 4.4.4.4.
IP-адрес шлюза: 192.168.123.254.
Шлюз пингуется без проблем.
R2 не может достичь 4.4.4.4, но у R3 нет никаких проблем. Прежде чем мы продолжим проверять, почему R2 не может достичь 4.4.4.4, мы взглянем на конфигурацию VRRP, чтобы увидеть, какой маршрутизатор является главным.
Вывод show vrrp интересен. Оба маршрутизатора считают, что они активны, и, если вы посмотрите внимательно, вы поймете, почему. Аутентификация включена, и в key-string имеется несоответствие. Поскольку оба маршрутизатора активны, половина пакетов окажется в R2, а остальные в R3. Вот почему наш клиент видит, что некоторые пакеты приходят, а другие нет. Давайте исправим нашу аутентификацию:
R2(config)#interface fa0/0
R2(config-if)#vrrp 1 authentication md5 key-string SECRET
Мы сделаем key-string одинаковыми.
Это сообщение в консоли R2 является многообещающим.
R3 был выбран в качестве главного маршрутизатора. Теперь давайте выясним, почему R2 не смог достичь 4.4.4.4, поскольку эта проблема устранена.
Странно, R2 показывает только одну запись в таблице маршрутизации, что-то не так с FastEthernet 1/0.
Кажется, кому-то нравится команда shutdown Имейте в виду, что это может быть что-то еще списки доступа, blocking traffic между R2 и R4, port-security (если был коммутатор в середине), интерфейсы в режиме err-disabled, неправильные IP-адреса и другое. Проверьте все!
R2(config)#interface fastEthernet 1/0
R2(config-if)#no shutdown
Включим интерфейс!
Проблема устранена!
Итог урока: убедитесь, что маршрутизаторы VRRP могут связаться друг с другом.
Всем привет! Сегодня мы поговорим про то, каким образом можно управлять телефонной станцией Cisco Call Manager Express (CME) , подробнее о которой можно прочитать в нашей статье. Сейчас это решение называется Cisco Unified Communications Manager Express (CUCME) .
Есть два метода конфигурации CME – при помощи графического интерфейса GUI и при помощи интерфейса командной строки CLI. Поэтому CME исключаетu споры по поводу того, какой вид интерфейса лучше – графический или командной строки, ведь можно использовать какой больше приходится по душе. Конфигурация при помощи командной строки по-прежнему остается наиболее гибкой и поддерживает все функции CME, однако утилиты на основе графического интерфейса, в частности, Cisco Configuration Professional (CCP) , развились достаточно для поддержки простой конфигурации и устранения неполадок для подавляющего большинства функций CME.
Для траблшутинга удобно использовать командную строку, где представлены команды show или debug, которые можно использовать для проверки или поиска неполадок маршрутизатора CME.
CLI
Для доступа к интерфейсу командной строки можно использовать один из трех способов:
Консольный порт (console) – подключиться при помощи serial интерфейса на компьютере и кабеля rollover;
Telnet – издавна использовался для управления различными системами командной строки. В настоящее время Telnet считается небезопасным протоколом, потому что он передает данные в виде чистого текста;
SSH - Secure Shell (SSH) выполняет ту же функцию, что и Telnet, но обеспечивает связь с большой дозой шифрования;
Стоит напомнить, что для работы с CLI используются команды IOS, про которые можно почитать тут, тут и тут.
Чтобы поддерживать большинство VoIP функций Cisco создали специальный режим telephony-service. Попасть в него можно из глобального режима конфигурации
CME#conf t
CME(config)# telephony-service
CME(config-telephony)#
Как мы уже говорили большинство команд для траблшутинга выполняются из CLI. Одна из наиболее используемых команд – show ephone registered, которая показывает телефоны, зарегистрированные на CME и состояние их линий.
GUI
В качестве графического интерфейса используются два основных инструмента: интегрированный графический интерфейс CME (CME Integrated GUI) и Cisco Configuration Professional (CCP) . Интегрированный графический интерфейс CME работает под управлением HTML и JAR (Java) файлов, которые загружены во flash память маршрутизатора CME. Как правило, маршрутизаторы CME поставляется с этими файлами, однако также можно загрузить пакет TAR с веб-сайта Cisco, и извлечь его во flash память. При помощи минимальной конфигурации командной строки (назначение IP-адреса и включение HTTP-сервера), можно быстро включить интегрированный графический интерфейс CME. Хотя интегрированный графический интерфейс CME может показаться не красивым по сегодняшним стандартам, он имеет функционал, который позволяет обрабатывать большинство основных функций CME: добавление и изменение конфигурации телефона, изменение набора номера, настройка групп и т.д.
Встроенный интерфейс CME сфокусирован в основном для настройки аспектов телефонии. Для расширенной настройки маршрутизаторов CME используется Cisco Configuration Professional (CCP) . С его помощью можно настроить маршрутизатор, фаерволл, систему предотвращения вторжений (IPS), VPN, функции Unified Communications и общие функции WAN и LAN. CCP можно скачать с сайта Cisco и установить на локальном компьютере.
По умолчанию CCP пытается подключиться к маршрутизатору с использованием Telnet и HTTP, которые оба clear-text протоколы. Конечно, безопасные соединения всегда лучше. Поэтому можно изменить настройки и выбрать опцию «Connect securely» , после чего CCP будет использовать SSH и HTTPS для подключения и настройки маршрутизатора CME.
После подключения к маршрутизатору CME CCP запускает процесс обнаружения, который идентифицирует устройтво, программное обеспечение, интерфейсы и модули. По завершении этого процесса можно начинать настройку.
Также у Cisco есть утилита Cisco Configuration Professional Express (CCP Express) , которая является аналогичной утилитой GUI, загружаемой во flash память маршрутизатора. CCP Express фокусируется только на настройке базовых соединений LAN и WAN, NAT и фаервола. С ее помощью нельзя настроить функции Unified Communications.