Cisco *

В процессе написания продолжения к первой части темы по настройке телефонии на Cisco необходимо было привязать к СМЕ два телефона, но я столкнулся с одной проблемой. Телефоны оказались прошиты под SIP а на данном этапе хотелось сделать все на Skinny. И если с прошивкой Skinny-телефона в SIP особых проблем нет (данный процесс уже был описан на Хабре), то обратная процедура оказалась весьма нетривиальной.

Начав изучать CVoice (642-436) я решил выкладывать некоторые лабы в виде статей. Первая часть — такой себе «Hello World», звонок с одного телефона на другой.

Недавно наткнулся на ресурс (осторожно, в названии сайта нижнее подчеркивание!), создатели которого достаточно успешно перенесли функционал Cisco ASA 5500 на обычный PC.

Не секрет, что Cisco ASA по своей сути linux-based и вполне x86-совместима. Видимо, этот факт вызывал буйные фантазии об открывающихся возможностях у многих гиков, и вот, наконец, в 2008 году группа энтузиастов подарила миру первый установочный образ Cisco ASA. С тех пор проект продолжает существовать и выпускает новые релизы.
Краткое описание возможностей получившегося продукта под катом.

Друзья!

Мы обкатываем на нашем сайте новую идею, а именно проверку конфигурационных файлов cisco IOS на согласованность и непротиворечивость. На данный момент мы реализовали функционал для выявления «мусорных» списков доступа, а также выявление таких опасных «хвостов», как привязка списка доступа без самого списка.

Вкратце расскажу, зачем это может быть нужно:

В данной статье я рассмотрю несколько примеров использования Cisco EEM (Embedded Event Manager) совместно с Cisco IP SLA и TCL-скриптами.

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

В статье я хочу рассмотреть использование DHCP-сервера на базе маршрутизатора Cisco в корпоративной сети…

В последнее время приходится часто настраивать с нуля маршрутизаторы Cisco (в основном 800-1800 серии) для филиалов моей компании и дабы не набирать одни и теже команды третий десяток раз составил для себя небольшой шаблон настроек на разные случаи жизни. Сразу скажу что сертификаты от Cisco не получал, книжек по данным роутерам особо не читал, весь свой опыт приобрел методом научного тыка, курением мануалов на cisco.com и кое каким вдумчивым заимствованием кусков чужих конфигов…

11 марта 2010 в московском офисе cisco состоялся увлекательный семинар Миши Кадера про новые таможенные правила на территории таможенного союза России, Белоруссии и Казахстана. И про то, что cisco делает для того, чтобы ввоз нового оборудования наконец стал снова радовать и продавцов и покупателей.

Статья была опубликована 11.03 здесь, но по просьбе докладчика была направлена на доработку. Миша внес ряд нужнейших ссылок и комментариев, поправив меня в тех моментах, которые были изложены не точно. За что ему огромное спасибо!
Сейчас публикуется поправленный вариант.

Для начала экскурс в историю:
1. Таможенные правила ввоза на территорию РФ впервые были написаны аж в 1995 году и там было и про шифрование и про согласование с ФАПСИ (ныне ФСБ) и МинПромТоргом. Просто их никто не выполнял. Вот ссылка на указ для интересующихся
2. В 2006, для вступления в ВТО, был разработан новый, более гибкий документ, выводящий часть криптографии из-под лицензирования ввоза. Документ так и не был согласован
3. В конце 2009 году, приняв за основу документ 2006г, ФСБ быстренько согласовала новые правила ввоза на территорию единого таможенного союза. Так что с 01.01.2010 года мы просто получили то, что должно было работать давным-давно. Вот опять же ссылка на эти правила

По новым правилам часть шифровательных функций выводится из-под лицензирования (полный список можно найти в нормативных документах):
1.«Слабое» шифрование (симметричное шифрование с длиной ключа меньше либо равным 56 битам, асимметричное – 128 битам)
2.Шифрование каналов для управления (ssh, https для управления)
3.Шифрование беспроводными точками доступа (со встроенными антеннами) трафика, передаваемого на расстояние до 400 м.
4.Если шифрование является неотъемлемой частью программного продукта (операционной системы).

С радостью для себя обнаружил на Хабре некоторое количество статей на тему весьма мне близкую — IPTV.
Решил внести свой небольшой вклад написанием этой статьи.

Небольшое введение

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

Постановка задачи

Оператор в месте агрегации контента имеет:
1. Серверную ферму предоставления услуги IPTV;
2. Стык фермы с региональной сетью филиала;
3. Стык фермы с МСПД (межрегиональная сеть передачи данных);
4. МСПД от региональной сети на серверной ферме отделена с использованием VRF.
Необходимо на одном из серверов фермы шифровать мультикаст и передавать его в таком виде в МСПД и региональную сеть, не используя никаких дополнительных устройств видеомультиплексирования. Сервер шифрования выступает здесь в качестве стримера, на который наложены определенные ограничения:
1. Один телеканал — одна лицензия, одна мультикастовая группа.
2. Стримить сервер может только с одного интерфейса (один адрес источника мультикаста — это основная проблема).
ОС сервера шифрования — RHEL5.4, сетевое оборудование фермы — Cisco серии 7600.

Продолжая серию статей о VPN, хочу поделиться подробностями о реализации технологии DMVPN, изложенными на Cisco Live 2009. Осторожно, много букв :)

По советам уважаемых хабрачитателей я несколько изменю формат своих публикаций по ASA. Сюда буду писать самое интересное, не утомляя подробным описанием. Полную статью «ASA. Перехватывающая аутентификация» читайте в нашем свежеиспеченном блоге

А здесь я расскажу, как используя ASA, напрямую аутентифицироваться в AD

На МСЭ часто возникает задача проверить пользователя до предоставления ему доступа к определенным ресурсам. На ASA такая проверка называется «перехватывающая аутентификация» (cut-through proxy).

Этот сервис использует инфраструктуру ААА (Authentication, Authorization, Accounting).

Примечание: в английском слове authentication нет слога «фи», который появился в русском «аутентификация» скорее всего из-за созвучия слову «идентификация». Причем, в нашем могучем языке есть и «аутентичность». Без всякого «фи» :) Не попадитесь!

Аутентификация.
Отвечает на вопрос «есть ли такой пользователь». Поиск этого пользователя может производиться как в локальной (LOCAL) базе данных, так и во внешних (TACACS+, RADIUS, AD по протоколу LDAP).

Статические трансляции

Статические трансляции, в отличие от динамических, жестко связывают адреса (или адреса с портами). Именно эта их особенность позволяет инициировать сессии как изнутри, так и снаружи МСЭ. Но для того, чтобы раз и навсегда не путаться в написании статических трансляций, я научу вас их «читать» правильно. Итак, формат команды довольно прост:

static ({source_int},{dest_int}) {translated_address} {real_addess}

где
source_int – интерфейс на который приходит пакет
dest_int – интерфейс, с которого пакет пойдёт дальше
real_address – реальный адрес хоста
translated_address – странслированный адрес хоста

И читается трансляция так:
Когда пакет бежит с интерфейса source_int на интерфейс dest_int его адрес ИСТОЧНИКА подменяется с real_address на translated_address.
Когда же пакет бежит в обратном направлении, т.е. приходит на интерфейс dest_int и идет далее через интерфейс source_int его адрес НАЗНАЧЕНИЯ меняется с translated_address на real_address

Cisco GET VPN — новая технология от Cisco, призванная обеспечить безопасность туннелей через провайдерские соединения, обладающая рядом полезных особенностей. Ее описанию, особенностям и настройке и посвящена эта статья.

По просьбе коллеги (Fedia) я собрался с мыслями и решился написать статью про NAT NVI. Надо сказать, что вообще сама по себе трансляция адресов на роутере многократно рассматривалась, в т.ч. в статье «По просьбам трудящихся: Dual ISP на маршрутизаторах cisco без BGP». Тем не менее, описанный в ней механизм inside source и outside source NAT имеет некоторые ограничения.

Трансляция сетевых адресов (Network Address Translation, NAT) — это подмена какого-либо адреса или порта в пакете. Она, как правило, требуется на границе между сетью компании и провайдером Интернет. Однако, это далеко не единственная задача. Рассмотрим несколько типичных задач и способы решения при помощи межсетевого экрана ASA.

Для начала определимся с терминами. Как вы уже знаете, на ASA при помощи сравнения уровней безопасности интерфейса-источника и интерфейса-назначения легко определяется направление «наружу» и «внутрь» межсетевого экрана (ситуацию с одинаковыми уровнями безопасности рассмотрим отдельно).
Обычно разделяют внутреннюю (inside) и внешнюю (outside) трансляции. Внутренняя трансляция подменяет адрес источника при выходе «наружу» межсетевого экрана, а внешняя трансляция подменяет адрес источника при проходе «внутрь» МЭ.

Прочитал две статьи «Dual ISP на маршрутизаторах cisco без BGP» и «Одновременное использование двух провайдеров на маршрутизаторах cisco». На ум пришла мысль попробовать нарисовать и описать решение к ещё одной, немного нестандартной задаче.
Итак, рассмотрим простой пример. Есть клиент и имеется два провайдера (аплинка). Автономной системы для построения BGP-peer'ов у нас нет, а работать, при падении одного каналов как-то надо. При этом у нас есть внутренний клиент нашей сети который работает не как все, а с точностью до наоборот. В нормальной (оба канала работают) этот клиент всё-равно ходит через резервный канал (Dialer1), в то время как все работают по основному (Dialer0) и переключается он на основной канал только в том случае если резервный(!) падает (бывает и такое).

Довольно простая глава. Списки доступа (ACL, Access Control List) – это правила проверки заголовка ip пакета до уровня 4 модели OSI. Списки доступа – это просто конструкции, состоящие из строчек. В каждой строчке – правило разрешить (permit) или запретить (deny). Строчки просматриваются сверху вниз на предмет точного совпадения заголовка пакета со строкой списка доступа. Списки доступа на ASA могут выполнять несколько ролей:

1. Фильтрация на интерфейсе входящего или исходящего трафика
2. Описание правил NAT (Policy NAT)
3. Описание правил редистрибуции маршрутов (в route-map)
4. Критерий попадания в класс трафика для дальнейшей обработки (Modular Policy Framework, MPF)
5. Описание «интересного трафика» для шифрования. Применяется список доступа в crypto map
6. Описание прав удаленного пользователя при подключении через IPSec или SSL VPN
Важно: в конце любого списка доступа стоит невидимое «запретить все» (implicit deny any), поэтому «мимо» списка доступа ни один пакет не пройдет.

У операторов нашего call-центра есть программа, которой они пользуются для учета звонков, тем разговоров, результатов консультаций клиентов и других вспомогательных целей. В программе есть телефонная книга сотрудников, которая используется для учета перевода звонков клиентов на сотрудников компании. То есть если клиент просит перевести его на сотрудника или отдел, оператор открывает телефонную книгу, нажимает кнопку «перевод» напротив нужного сотрудника, потом набирает на телефоне внутренний номер и переводит звонок. То есть переводит оператор вручную, а в телефонном справочнике нажимает только для учета статистики, указания темы звонка результата перевода, то есть того что получить можно только из разговора с клиентом.

Хочется что бы перевод осуществлялся из самого телефонного справочника, при нажатии на кнопку «перевод». Так как это web-приложение, мне видится это следующим образом: при нажатии на кнопку, на сервере запускается приложение, которое дает команду сиське перевести звонок.

Естественно я начал с чтения документации. На данный момент смотрю в сторону JTAPI, которое по идее позволяет реализовать то что мне нужно. Но так как с cisco я ранее сталкивался только в форме телефона на моем рабочем месте, хочется спросить совета у профи, может быть я что-то упустил, есть более простые решения?

В компании используется вот этот продукт: Cisco Unified Contact Center Express

Одновременное использование двух провайдеров

Если в первом случае все понятно и однозначно, то в случае с одновременным использованием двух провайдеров возникают проблемы.
Для начала: нам надо обоих провайдеров проверять на «живость» и переключать все потоки на одного в случае, если кто то «упал». Это делается полностью аналогично проверке ISP1 в главе про Резервирование. С тем лишь отличием, что оба маршрута по умолчанию имеют одинаковую административную дистанцию

  ip route 0.0.0.0 0.0.0.0 Gate(ISP1) track 11
  ip route 0.0.0.0 0.0.0.0 Gate(ISP2) track 22