Cisco Support Community
отмена
Отображаются результаты для 
Вместо этого искать 
Вы имели в виду: 
Объявления
Добро пожаловать в Сообщество Технической поддержки Cisco. Мы рады получить обратную связь .

Безопасность Блоги (Security)

9 просмотров
0 Комментариев

Многие компании предоставляют пользователям возможность удаленно работать с внутренними ресурсами, например при помощи решения Cisco AnyConnect.

Это удобно, но при этом растет риск взлома, утечки информации и прочих негативных факторов.

Опыт показывает, что об утечке информации, руководство узнает парой через несколько месяцев.

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

Есть разные решения данной проблемы, но на наш взгляд, самое удачное решение, это сбор информации с того узла сети, через который неминуемо пройдет трафик удаленных пользователей - Cisco ASA.

Поскольку мы ориентированы на небольшие компании, мы не будем поддерживать ничего другого кроме Cisco ASA и AnyConnect. Но зато ПО крайне простое и понятное каждому.

Более того, мы готовим простую бесплатную версию. Она будет распространяться в виде образа виртуальной машины.

Вам потребуется развернуть образ, указать IP адреса, и настроить на Cisco ASA syslog сервер и еще некоторые простые настройки.

Вот так примерно выглядит пользовательский интерфейс.

Очень ждем комментарии.

Спасибо за внимание.

15 просмотров
0 Комментариев

Добрый день.

Мы с коллегами, создали, пока еще глубоко сырое но уже работающее ПО, для учета AnyConnect подключений. Скажу сразу, будет свободная версия в виде OVA для ESXi.

Концепция ПО такова:

1. Очень простой и понятный пользовательский интерфейс (WEB).

2. Учет следующих данных: Имя пользователя, время подключения и отключения, длительность сессии, количество переданных данных,внешний и внутренний IP адрес, и причина отключения.

3. Есть интеграция с NetFlow коллектором для просмотра детальных данных.

На Cisco ASA требуется указать Syslog сервер и еще некоторые настройки.

Скоро все будет расписано и доступно.

Хочется узнать у сообщества, есть ли потребность в таком ПО и пожелания.

Вот так выглядит пользовательский интерфейс:

28 просмотров
0 Комментариев

Добрый день, столкнулся с такой проблемой на ASA 5525-X что после загрузки загорается Alarm, смотрел температуру и напряжение все нормально, а вот sh controllers pci выдает "System is not fully operational – The PCI device with vendor ID: 0x1000 (LSI) device ID: 0x0a05 (Accelerator) could not be found in the system", не подскажете в чем причина того что загорается светодиод Alarm и что это за устройства которых ASA 5525-x не хватает?

412 просмотров
4 коммент.

Добрый день!

К сожалению, на Cisco ASA нет таких механизмов резервирования конфигурации, как на коммутаторах и маршрутизаторах, но есть call-home.

Можно использовать snapshot и команду copy, как показано в примере ниже.

В качестве Mail сервера, я использую Cisco IronPort ESA - но можно использовать любой внутренний почтовый сервер (SMTP без авторизации).

service call-home
no call-home reporting anonymous
call-home
 alert-group-config snapshot
  add-command "copy /noconfirm running-config tftp://10.10.10.10/ASA;int=inside"
 contact-email-addr ASA@mail.com
 mail-server 210.210.210.210 priority 1

 profile COPYCONFIG
  destination address email super@user.com
  destination transport-method email
  subscribe-to-alert-group snapshot periodic daily

242 просмотров
0 Комментариев

Всем привет! И всем успехов в работе по построению замечательных сетей совместно с компанией Cisco!

Собирался долго и решил написать немного об опыте внедрения DMVPN phase 3  (spoke-to-spoke)технологии наших российских реалиях. Решил написать в основном ради того, что если кто будет эту технологию внедрять меньше встретил проблем и предостеречь от бесполезной траты сил и времени.

Кто-то уже это давно сделал и я для Вас ничего нового не скажу. Респект вам   и рад за Вас, но эта статья для тех, кто еще на подступах к этому непростому делу.  Надеюсь, что она поможет в особенности тем, кто собирается мигрировать с DMVPN Phase1 (Hub-to-Spoke) на Spoke-to-Spoke (Phase3) .

Итак, что мы имеем:

Сеть с 60- 70 локациями, разбросанными по нашей широкой стране от Магадана, Хабаровска до Мурманска и Калининграда и пара DMVPN  Hub-центров. Говоря техническим языком: Два Single DMVPN cloud, каждое со своим Single- Hub и Single mGRE tunnel. А на spoke получалось соответственно по 2 туннеля и каждый Spoke участвовал в 2-ух DMVPN cloud-ах.

Мотивация и задача: почему решили переходить на Spoke-to-Spoke модель? 

  1. 20-25% транзитного трафика шло через Hub – дополнительная ненужная  нагрузка на Hub.
  2.  Задержки передачи пакетов сильно увеличивались из-за  имеющейся топологии. Так, например, траффик из г. Белово Кемеровской области в г. Кемерово через Hub (Москва) шел в среднем (RTT) 150мс., конечно это не оптимально.

Итак  мы решили перейти на модель, такую, чтобы spoke между собой могли строить туннели. Что нам рекомендуется Cisco  вначале – prepare- приготовиться, спланировать, разработать дизайн, а потом уже внедрять. Вот я и начал искать документацию по этому вопросу.

Документация:

Сразу скажу, что с документацией, которая нужна для внедрения –  а не общетеоретического познания принципов работы DMVPN  -есть проблемы.  Что я нашел:

  1. Чтобы понять, что такое DMVPN? Как это работает? Чем отличается Phase 3 от Phase 1 – имеются отличные презентации на www.ciscolive365.com. Заходим в «Solution center», набираем «DMVPN phase3»  и получаем список авторов и сессий. Мне друг рекомендовал смотреть Mike Sullenberger, он как бы deepest diving person в этом вопросе. Берем, например DMVPN Deployment Models презентацию и смотрим, а можно и слушать.  Вообще, www.ciscolive365.com ; в этом смысле отличный ресурс. Проблема: пример конфига для IPv6 есть, а для IPv4 – нет. Есть какие-то кусочки, отдельные строки про разные фичи, а цельного примера в части DMVPN – для IPv4 – нет.
  2. Google нас выведет еще на несколько полезных ссылок на сайте Cisco:

Итак,  я все просмотрел (конечно по - диагонали – времени –то нет читать все подробно) и кое-какое представление приобрел. Не  все так уж мне понятно было- вроде- все просто – пару команд добавил, одну убрал и наслаждайся новым дизайном. Но с другой стороны я тогда даже четко и не видел различия между Phase 2 и Phase 3.  Но как говорил Наполеон- «Главное ввязаться в бой, а там …»  и я ввязался.

Стартовый дизайн:

Итак,  до начала внедрения мы имели стройную структуру состоящую из Dual DMVPN Single Hub Single tunnel on Hub, two on spokes- точно соответствует правой картинке на слайде 65 DMVPN Deployment Models – презентации. Т.е.DMVPN Phase1 – Hub-to-Spoke topology.  Это нормальный рекомендованный Cisco дизайн и его смело можно внедрять. Обычно больших проблем при этом нет.

Отказоустойчивость - обеспечивалась наличием 2-х  Hub в дата-центрах, 2-х туннелей на Spoke и работой EIGRP.

Балансировка и распределение трафика поддерживались за счет регулировки метрики (delay) для EIGRP и offset-list, если нужно было поменять что-то для отдельной локации.

Конфигурация туннелей была примерно следующей: 

Hub1:
interface Tunnel501
description DMVPN MSK1
ip address 10.50.1.1 255.255.255.0
no ip redirects
ip mtu 1438
no ip split-horizon eigrp 100
ip flow ingress
ip flow egress
ip nhrp authentication Cle
ip nhrp map multicast dynamic
ip nhrp network-id 501
ip tcp adjust-mss 1398
ip summary-address eigrp 100 10.50.0.0 255.255.0.0
load-interval 60
delay 10000
qos pre-classify
tunnel source GigabitEthernet0/1
tunnel mode gre multipoint
tunnel key 501
tunnel protection ipsec profile VPN-3DES
 
router eigrp 100
network 10.50.1.0 0.0.0.255
passive-interface default
no passive-interface Tunnel501
 
2-й Hub c аналогичной конфигурацией Tunnel, только другое имя туннеля, key, subnet
 
 Spoke:
interface Tunnel501
 description TUNNEL TO MSK1
 ip address 10.50.1.58 255.255.255.0
 ip mtu 1438
 ip flow ingress
 ip flow egress
 ip nhrp authentication Cle
 ip nhrp map 10.50.1.1 217.x.x.237
 ip nhrp map multicast 217.x.x.237
 ip nhrp network-id 501
 ip nhrp holdtime 15
 ip nhrp nhs 10.50.1.1
 ip tcp adjust-mss 1398
 ip summary-address eigrp 100 10.58.0.0 255.255.0.0 5
 delay 10000
 qos pre-classify
 tunnel source GigabitEthernet0/1
 tunnel destination 217.x.x.237
 tunnel key 501
 tunnel protection ipsec profile VPN-3DES
 
На этом же маршрутизаторе Spoke - аналогичный 2-й tunnel только с соответствующими:  key, subnet, NHS,  destination IP, NHRP map.
 
router eigrp 100
 network 10.50.1.0 0.0.0.255
network 10.10.1.0 0.0.0.255
 network 10.58.0.0 0.0.255.255
 passive-interface default
 no passive-interface Tunnel501
no passive-interface Tunnel502
 eigrp stub summary
 

Step-by-step или «Подводные камни»:

Опишу мои шаги и переходы для лучшего понимания того, к чему стоит быть готовым при внедрении данного решения, какие могут быть ошибки, траблы.

1-й шаг – перевел один из хабов (тот что был backup и трафик через него обычно не ходил) на phase2 и несколько споков вначале, все вроде работает. Перевел все туннели данного хаба на споках в режим tunnel mode gre multipoint вместо  tunnel destination x.x.x.x и на части споках перевел трафик на этот туннель – вроде все работает – туннели между ними строятся, трафик по ним идет.

1-й подводный камень: внезапно начали несколько роутеров, не из тех на которых были активными туннели с режимом gre multipoint. Крашились роутеры так скоро, что после перезагрузки я только успевал на них зайти и начать смотреть -5 сек  ивсе снова падало. Поменял один из них на запасной с таким же IOS и этот почти сразу начал падать как и предыдущий- это был день кошмара. Потом как-то логически у меня связалось это с новым DMVPN туннелем – я отключил его на споке и он перестал крашиться. Нашел баг по этому поводу, который разрешался заменой IOS на более новый или переведением всех туннелей в режим mGRE. Проблема происходила тогда, когда спок с mGRE строил (пытался) туннель к туннелю, у которого только один tunnel destination.  

Решение: Перевел оба Hub и все spokes в режим gre multipoint.

2-й подводный камень. Когда я перевел оба туннеля, в вышеназванный режим, то через некоторое время заметил, что на споках у меня почему-то по одну соседству EIGRP. Или через один или через другой, но по одному. Проблема заключалась в том, что я сделал на разных туннелях (и хабах соответсвенно) разное время ip nhrp holdtime.

Решение: выставил одинаковое время ip nhrp holdtime – везде.

3-й подводный камень вылез где-то здесь тоже когда переводил туннели на новый режим. У меня они оба использовали один и тот же profile для шифрования и никакого shared не требовалось, а тут IOS закапризничал – нет и все, только с shared давай.

Решение: Сделал на второй интерфейс новый profile с тем-же абсолютно методом шифрования, прописал на туннеле с shared на всякий случай –

 tunnel protection ipsec profile VPN-3DES2 shared  - все прошло нормально.

4-подводный камень обнаружился на следующий день.

 Появилась black hole для начала передачи трафика между Spokes. Выглядело это так – кто-то из spoke  звонил в другой spoke не слышал его, перезванивает через пару минут – все слышно нормально. Проблема заключалась в том, что в Phase 2  после открытия туннеля (с помощью NHRP) – EIGRP устанавливает новое соседство и получает через него маршруты стоящие за новым соседом. Пока он все это проворачивает – для трафика получается black hole и он теряется (скорее всего это связано с каким-то багом, т.к. по дизайну DMVPN, пока трафик не переключится на другой туннель, он должен идти по через Hub). Когда все построено- трафик будет идти нормально.

Решение – workaround: подняли ip nhrp holdtime 600 до максимума 65500. Теперь у нас туннели как построились с утра, так и стояли 18 часов. Не красивое, конечно, решение. Но временно работало.

5-й шаг. Тут я стал эксперта из московского Cisco TAC расспрашивать – что-то говорю технология у Cisco не продуманная какая-то, работает с задержками и вообще, если она так работает – лучше обратно откачусь. Я уже стал получать от пользователей заявки на плохую телефонию и т.д. А эксперт мне говорит не должно так быть – это что-то не то. Есть там у тебя на туннелях ip nhrp redirect, ip nhrp shortcut? Я говорю – нет. Так значит у тебя там не Phase3, а Phase2. Читай документацию снова, говорит, смотри презентации – тебе надо Phase3- это более функциональное и производительное решение. Пришлось глубже вникать в документацию и готовиться к следующему рывку.

5-й подводный камень. Тут пока я все это проходил, я помнил, что баг у меня был с crash – вот я и решил обновлять IOS потихоньку на будущее. Но здесь оказалось не один подводный камень, а целые рифы какие-то. Короче, обновляю IOS на  29xx на 154-2.T2 и на 155-1.T – одни из последних и на 9 роутерах все проходит хорошо. Обновляю на 10-м на нем EIGRP neighbors поднимаются на 15 сек и падают, через некоторое время опять поднимаются и снова падают. Cisco phones зарегистрироваться с CUCM не могут – ушли в бесконечный цикл. На 11-м роутере 29xx – интернет трафик приблизился к 4Mbps – роутер по CPU ушел 90%, трафик к 4,5Mbps- CPU -100%. Все висит- кое-как отправил в reload.

Решение: откатился на предыдущий IOS. Будет время поисследую еще и обновлю. Тут мне и коллеги стали говорить – Николай, хорош сеть портить – мы хотим на Новогодних дома посидеть спокойно.

6-й шаг. Перевел оба Hub-а и все туннели на Phase 3, у него NHRP еще больше на себя берет чем в phase2. NHRP здесь и  в таблице маршрутизации прописывает сети на другие споки и в FIB-е проставляет физический интернет адрес – куда туннель строить.  В общем- красивая технология. И главное black hole у него нет- если туннель еще не построился (или по каким-то причинам на другой спок в принципе не строится), то трафик идет через hub. А если туннель уже построился, то через него. И сбоев в этом я пока не видел ни разу- или так или так, но ничего не пропадает. Пользователи про телефоны жаловаться перестали.

6-й подводный камень. Продолжая свое внедрение этой технологии решил я испытать-  как тут у меня отказоустойчивость будет работать, т.е. если один из Hub станет недоступен. Положил я его, а пинги запустил и до сети в Hub и до другого спока. И тут я был разочарован кое в чем. До hub и из Hub все работало красиво- потерялось может -1-2 пакета и все. Проверяю как строятся туннели между споками. Не все так просто. DMVPN облака- то у меня разные и получались разные проблемы связанные с этим обстоятельством. Описывать их сложно и утомительно будет читать. Поэтому подробно это делать не буду. Скажу лишь что появлялась опять black hole между споками, они наблюдались при определенной ситуации – после возврата основного hub в работу. И заканчивались только когда «протухала» crypto сессия между этими споками- она все равно не работала нормально в это время и трафика по ней не шло.

Решение-workaround: вот тут мы воспользовались crypto ipsec security-association idle-time – параметром – занизили его до 60сек. И он честно отрабатывал – удалял сессию и новый туннель строился вполне работоспособным.

7-й шаг. Пришлось снова читать и смотреть презентации про DMVPN – понял, что нигде так не рекомендуется внедрять Phase3 – c двумя не зависимыми облаками и hub, а рекомендуется делать Dual-hub. Так мы и сделали – перевели оба Hub в одно облако (одна подсеть для адресации всех туннелей). На spoke получился только один туннель в конфиге, а Neighboring у EIGRP по 2 – т.е. на каждый hub, т.е. все честно. Отказоустойчивость работает при этом нормально. Туннели между spokes строятся при наличии двух или одного hub одинаково быстро и вполне функциональны. Потери пакетов в сеть за hub могут появляться только на время перестроения EIGRP, но это не связано с работой DMVPN уже никак.

7-й подводный камень, с которым я столкнулся – как управлять трафиком со стороны spoke- на какой хаб ему идти со spoke. Так как теперь, если мы меняем delay на туннеле, то это распространяется на оба туннеля. Более того было интересное наблюдением, что не смотря на то что, она одинаковая для обоих – один все же имел чуть лучшую метрику чем другой. 

Решение: Посмотрел еще один интересный ресурс: от LabMinutes на youtube и воспользовались увеличением administrative distance для определенного hub. Ну и все заработало. Выбирается тот, который нужно туннель для передачи трафика. В результате получилось вот так:

Hub
interface Tunnel501
 description DMVPN MSK8
 ip address 10.50.1.2 255.255.255.0
 no ip redirects
 ip mtu 1438
 ip pim dense-mode
 no ip split-horizon eigrp 100
 ip flow ingress
 ip flow egress
 ip nhrp authentication Cle
 ip nhrp map multicast dynamic
 ip nhrp network-id 501
 ip nhrp holdtime 65500
 ip nhrp redirect
 ip tcp adjust-mss 1398
 ip summary-address eigrp 100 10.0.0.0 255.0.0.0
 ip igmp join-group 239.255.255.250
 delay 10000
 qos pre-classify
 tunnel source Loopback3
 tunnel mode gre multipoint
 tunnel key 501
 tunnel protection ipsec profile VPN-3DES
 
Spoke:
interface Tunnel501
 description TUNNEL TO MSK
 ip address 10.50.1.58 255.255.255.0
 no ip redirects
 ip mtu 1438
 ip flow ingress
 ip flow egress
 ip nhrp authentication Cle#11
 ip nhrp map multicast dynamic
 ip nhrp map 10.50.1.2 130.x.z.37
 ip nhrp map multicast 130.x.z.37
 ip nhrp map multicast 217.x.y.237
 ip nhrp map 10.50.1.1 217.x.y.237
 ip nhrp network-id 501
 ip nhrp holdtime 65500
 ip nhrp nhs 10.50.1.1
 ip nhrp nhs 10.50.1.2
 ip nhrp shortcut
 ip nhrp redirect
 ip summary-address eigrp 100 10.58.0.0 255.255.0.0
 ip tcp adjust-mss 1398
 delay 9800
 qos pre-classify
 tunnel source GigabitEthernet0/1
 tunnel mode gre multipoint
 tunnel key 501
 tunnel protection ipsec profile DMVPN-3DES shared
 
Второй (Tunnel 502) теперь не нужен - его удаляем.
 
router eigrp 100
 network 10.50.1.0 0.0.0.255
 network 10.58.0.0 0.0.255.255
 distance 90 10.50.1.1 0.0.0.0
 passive-interface default
 no passive-interface Tunnel501
 eigrp stub summary
 
Результаты:
  1. Сейчас через hub проходит порядка около 5% транзитного трафика.
  2. RTT между близкими spokes уменьшился существенно: траффик из г. Белово Кемеровской области в г. Кемерово через spoke-to-spoke туннель идет в среднем (RTT) 25мс, т.е. на 125 мс. меньше.  Красивый результат, хотя и не везде будет такой, так как у некоторых провайдеров каналы пересекаются физически не близко – тогда это не будет так наглядно

Выводы по поводу внедрения новых технологий Cisco:

  1. Убедись, что это действительно необходимо и даст полезный эффект, а то быстро вернешься назад.
  2. Подробно рассмотри – как предлагает внедрять технологию тот кто ее придумал и внедряй только так, все остальное будет иметь много подводных камней и неожиданных результатов.
  3. Не стоит внедрять что-то новое не имея поддержки вендора, хотя бы для того чтобы скачать новый IOS (без Bugs обнаруженных в процессе внедрения). Потому что Bugs  скорее всего всплывут.
  4. Одна голова – хорошо, а с Cisco TAC – лучше.  Заручись поддержкой Cisco TAC или кого-то из экспертов, скорее всего понадобится обсудить с кем-то промежуточные результаты, с кем–то надо будет рассматривать Bugs и просто хорошо когда кто-то может подсказать тебе, что почитать и где посмотреть.
  5. То, что красиво работает у другого в сети – не факт, что будет так работать у тебя. Все сети и все роутеры – разные в каком-то смысле. Не только по версии IOS, но и по config и по нагрузке, модулям, контенту трафика и тогда.
  6. Хорошо, когда новую технолдогию ты можешь проверить сначала где-то в лаборатории, чтобы понять как это должно работать. Меньше будет подводных камней. Но они все равно могут быть потому что лаборатория и большая сеть – это разные условия.
  7. Заручись поддержкой руководства и коллег, потому что могут быть всякие black hole – и на тебя будут жаловаться твоему начальнику. Лучше, чтобы он был к этому готов.

Всем успехов и удовлетворения от внедрения новых решений! 

522 просмотров
0 Комментариев

Можно бесплатно.

Регистрируемся например на сайте StartSSL.
Просим сертификат для удостоверения сайта.
 

С Cisco ASA нужен запрос на сертификат:
Делаем:

crypto key generate vpn.mysite.net modulus 20148

crypto ca trustpoint vpn.mysite.net
 fqdn trustpoint vpn.mysite.net
 subject-name CN=vpn.mysite.net
 keypair  vpn.mysite.net
 enrollment terminal
 

crypto ca enroll vpn.mysite.net
 
Видим чтото типа:
WARNING: The certificate enrollment is configured with an fqdn
that differs from the system fqdn. If this certificate will be
used for VPN authentication this may cause connection problems.
 Would you like to continue with this enrollment? [yes/no]: 
говорим Y
потом еще раз Y
Display Certificate Request to terminal? [yes/no]: 
и еще раз Y
 
Видим запрос:
-----BEGIN CERTIFICATE REQUEST-----
тут всякое....
-----END CERTIFICATE REQUEST-----
 
Его нужно будет ввести например в специальном окошке на StartSSL.
В ответ вам сделают сертификат, который нужно будет оттуда забрать.
 
Но сначала нужно авторизовать нашу trustpoint либо корневым, либо промежуточным сертификатом того кто вам его предоставляет - например все тот же StartSSL.
Качаем их сертификат (промежуточный (intermediate) например).
Затем на Cisco делаем:
 
crypto ca authenticate vpn.mysite.net
Видим:
Enter the base 64 encoded CA certificate.
End with the word "quit" on a line by itself
Тут все в принципе понятно - вводим в BASE 64, intermediate или root сертификат
-----BEGIN CERTIFICATE-----
Много всего.....
-----END CERTIFICATE-----
quit
 
Ну и последнее:
Импортируем наш сертификат (забираем его у того, кто его предоставил):
 
crypto ca import vpn.mysite.net certificate
Тут можем увидеть:
WARNING: The certificate enrollment is configured with an fqdn
that differs from the system fqdn. If this certificate will be
used for VPN authentication this may cause connection problems.
 Would you like to continue with this enrollment? [yes/no]:
Жмем Y
% The fully-qualified domain name in the certificate will be: vpn.mysite.net
 
 
Enter the base 64 encoded certificate.
End with the word "quit" on a line by itself
Ну наконец вводим наш сертификат:
 
-----BEGIN CERTIFICATE-----
Опять много букв и циферок....
-----END CERTIFICATE-----
quit
 
Все.
 
Теперь:
 
ssl trust-point vpn.mysite.net
 
Ну и проверяем:
 
sh crypto ca certificates
 
Certificate
  Status: Available
  Certificate Serial Number: 9999999777
  Certificate Usage: General Purpose
  Public Key Type: RSA (2048 bits)
  Signature Algorithm: SHA256 with RSA Encryption
  Issuer Name:
    cn=StartCom Class 1 Primary Intermediate Server CA
    ou=Secure Digital Certificate Signing
    o=StartCom Ltd.
    c=IL
  Subject Name:
    ea=adminnn@mysite.net
    cn=vpn.mysite.net
    c=RU
  OCSP AIA:
    URL: http://ocsp.startssl.com/sub/class1/server/ca
  CRL Distribution Points:
    [1]  http://crl.startssl.com/crt1-crl.crl
  Validity Date:
    start date: 02:53:53 MSK Apr 1 1899
    end   date: 05:43:23 MSK Apr 1 2099
  Associated Trustpoints: vpn.mysite.net
 
CA Certificate
  Status: Available
  Certificate Serial Number: 17153d9eab3fbf
  Certificate Usage: General Purpose
  Public Key Type: RSA (2048 bits)
  Signature Algorithm: SHA256 with RSA Encryption
  Issuer Name:
    cn=StartCom Certification Authority
    ou=Secure Digital Certificate Signing
    o=StartCom Ltd.
    c=IL
  Subject Name:
    cn=StartCom Class 1 Primary Intermediate Server CA
    ou=Secure Digital Certificate Signing
    o=StartCom Ltd.
    c=IL
  OCSP AIA:
    URL: http://ocsp.startssl.com/ca
  CRL Distribution Points:
    [1]  http://crl.startssl.com/sfsca.crl
  Validity Date:
    start date: 23:54:17 MSK Oct 14 2007
    end   date: 23:54:17 MSK Oct 14 2022
  Associated Trustpoints: vpn.mysite.net

134 просмотров
0 Комментариев

Итак, предположим что WSA уже настроен, так же на ASA и WSA настроено перенаправление WEB трафика по WCCP.

Внутренние пользователи работают через прокси сервер, а вот пользователи, подключенные через AnyConnect работают без прокси.

Вы решили внедрить концепцию BYOD - то есть, все пользователи, как локальные так и удаленные, работают по одним и тем же правилам.
Одна из составляющих этого - WEB безопасность.

Как же нам быть? как пустить удаленных пользователей через прокси?
Сделать это можно несколькими способами:
1. Использовать явное указание прокси сервера в групповой политике удаленных пользователей.
2. Использовать WCCP перенаправление не на ASA, а на другом маршрутизаторе.
3. Отправить весь трафик AnyConnect пользователей на маршрутизатор за Cisco ASA, и вернуть его обратно (U-Turn), после чего он уже будет аналогичен трафику от локальных машин.

Мы рассмотрим именно третий вариант.
Итак есть сеть, похожая на то что изображено ниже:

anyconnect.png

Есть некое ядро, выполняющее маршрутизацию между VLAN'ами внутри сети.
Пользователи, подключенные по AnyConnect, уже имеют доступ к локальным ресурсам.
Теперь нам требуется пустить их в сеть интернет, причем через устройство защиты - Cisco WSA (ну или любой прокси сервер, поддерживающий WCCP).

Конечно нам нужно, в групповой политике указать split-tunnel-policy tunnelall,
настроить необходимые фильтры.

Теперь о том как же нам завернуть трафик "туда - обратно"?
На Cisco ASA нужно указать маршрут по умолчанию на внутренний маршрутизатор, для трафика, пришедшего от удаленных пользователей, делается это так:

route inside 0.0.0.0 0.0.0.0 192.168.2.2 tunneled

Включить NAT для них, но не (outside,outside) а (inside,outside), так как трафик придет уже через inside интерфейс:

object network ANYCONNECT_NET
 subnet 192.168.3.0 255.255.255.0
 nat (inside,outside) dynamic interface

Маршрут на самом WSA на эту сеть, должен быть через Cisco ASA а не через ваш маршрутизатор.
В итоге трафик пойдет примерно так как на рисунке ниже:

anyconnect1.png

Коротко напомню про перенаправление с Cisco ASA (90 - идентификатор - у вас может быть другой):

access-list WCCP_REDIRECT_ACL1 remark Block spoof 1
access-list WCCP_REDIRECT_ACL1 extended deny ip any 10.0.0.0 255.0.0.0
access-list WCCP_REDIRECT_ACL1 remark Block spoof 2
access-list WCCP_REDIRECT_ACL1 extended deny ip any 192.168.0.0 255.255.0.0
access-list WCCP_REDIRECT_ACL1 remark Block spoof 3
access-list WCCP_REDIRECT_ACL1 extended deny ip any 172.16.0.0 255.240.0.0
access-list WCCP_REDIRECT_ACL1 extended permit ip any any log disable

wccp 90 redirect-list WCCP_REDIRECT_ACL1
wccp interface inside 90 redirect in

 

Ну и традиционно, данная статья так же размещена на моем личном блоге на сервисе blogspot.

Спасибо за внимание!

431 просмотров
1 Комментарии

Никогда не думал, что дойду до жизни такой и начну писать блоги. Как говорится, довели. Просто в последнее время заметил у себя постоянное выражение недоумения на лице. Недоумения от того, как иной раз работают некоторые общеизвестные протоколы и приложения.

В связи с этим появилась идея найти научные доказательства ряда разрабатываемых нашими лучшими умами теорий, например, теории саморганизующихся информационных систем, теории Всемирного Футурологического Конгресса (она же Теория Всеобщего Прояснения Разума) и многих других.

Но, впрочем, об этих знаменитых теориях как-нибудь в другой раз и не здесь ;). Сегодня наша задача в другом. Сегодня наша задача доказать Теорию о том, что самым сложным протоколом для траблшутинга является TCP и в особенности TCP 3WHS. Конечно после ARP. Этот паразит ясное дело на первом месте.

Вот полюбуйтесь на следующие выводы, первый из которых собран на транзитной системе, а второй - на конечной. Инициатор TCP-соединения находится с др. стороны, т.е. имеем "инициатор" -> "транзитная-система" -> "конечная-система". Все просто. Время не синхронизировано, но по временному смещению сопоставить выдачи нетрудно.

Вопросы: a) кто все эти люди, b) что происходит, c) как такое может быть и d) а как должно быть на самом деле?

Не знаю, будет ли награжден самый пытливый читатель бубном, но респект ему гарантирован. Если активность будет высокая, то рубрику продолжим во второй части!

1-й вывод:

10 packets captured

   1: 21:31:31.664043       802.1Q vlan#76 P0 192.0.2.28.22776 > 192.0.2.2.23: S 2171771838:2171771838(0) win 4128 <mss 536>

   2: 21:31:33.661769       802.1Q vlan#76 P0 192.0.2.28.22776 > 192.0.2.2.23: S 2171771838:2171771838(0) win 4128 <mss 536>

   3: 21:31:33.663585       802.1Q vlan#76 P0 192.0.2.2.23 > 192.0.2.28.22776: . ack 2171771839 win 4128

   4: 21:31:33.669032       802.1Q vlan#76 P0 192.0.2.2.23 > 192.0.2.28.22776: S 973912199:973912199(0) ack 2171771839 win 4128 <mss 536>

   5: 21:31:37.661739       802.1Q vlan#76 P0 192.0.2.28.22776 > 192.0.2.2.23: S 2171771838:2171771838(0) win 4128 <mss 536>

   6: 21:31:37.663555       802.1Q vlan#76 P0 192.0.2.2.23 > 192.0.2.28.22776: . ack 2171771839 win 4128

   7: 21:31:37.668697       802.1Q vlan#76 P0 192.0.2.2.23 > 192.0.2.28.22776: S 973912199:973912199(0) ack 2171771839 win 4128 <mss 536>

   8: 21:31:45.661327       802.1Q vlan#76 P0 192.0.2.28.22776 > 192.0.2.2.23: S 2171771838:2171771838(0) win 4128 <mss 536>

   9: 21:31:45.663143       802.1Q vlan#76 P0 192.0.2.2.23 > 192.0.2.28.22776: . ack 2171771839 win 4128

  10: 21:31:45.668559       802.1Q vlan#76 P0 192.0.2.2.23 > 192.0.2.28.22776: S 973912199:973912199(0) ack 2171771839 win 4128 <mss 536>

10 packets shown

2-й вывод:

Jan  8 17:44:57.211: Reserved port 0 in Transport Port Agent for TCP IP type 0

Jan  8 17:44:57.211: tcp0: I LISTEN 192.0.2.28:22776 192.0.2.2:23 seq 2171771838

        OPTS 4 SYN  WIN 4128

Jan  8 17:44:57.211: TCP0: state was LISTEN -> SYNRCVD [23 -> 192.0.2.28(22776)]

Jan  8 17:44:57.211: TCP: tcb 6833EA20 connection to 192.0.2.28:22776, peer MSS 536, MSS is 516

Jan  8 17:44:57.211: TCP: sending SYN, seq 973912199, ack 2171771839

Jan  8 17:44:57.211: TCP0: Connection to 192.0.2.28:22776, advertising MSS 536

Jan  8 17:44:57.211: tcp0: O SYNRCVD 192.0.2.28:22776 192.0.2.2:23 seq 973912199

        OPTS 4 ACK 2171771839 SYN  WIN 4128

Jan  8 17:44:57.215: IP ARP: creating incomplete entry for IP address: 192.0.2.28 interface FastEthernet0/1

Jan  8 17:44:57.215: IP ARP: sent req src 192.0.2.2 0013.7f3d.bd01,

                 dst 192.0.2.28 0000.0000.0000 FastEthernet0/1

Jan  8 17:44:57.215: IP ARP: rcvd rep src 192.0.2.28 503d.e59d.8997, dst 192.0.2.2 FastEthernet0/1

Jan  8 17:44:59.207: tcp0: I SYNRCVD 192.0.2.28:22776 192.0.2.2:23 seq 2171771838

        OPTS 4 SYN  WIN 4128

Jan  8 17:44:59.207: tcp0: O SYNRCVD 192.0.2.28:22776 192.0.2.2:23 seq 973912199

        ACK 2171771839  WIN 4128

Jan  8 17:44:59.207: TCP0: bad seg from 192.0.2.28 -- bad sequence number: port 23 seq 2171771838 ack 0 rcvnxt 2171771839 rcvwnd 4128 len 0

Jan  8 17:44:59.215: 192.0.2.2:23 <---> 192.0.2.28:22776   congestion window changes

Jan  8 17:44:59.215: cwnd from 536 to 536, ssthresh from 65535 to 1072

Jan  8 17:44:59.215: tcp0: R SYNRCVD 192.0.2.28:22776 192.0.2.2:23 seq 973912199

        OPTS 4 ACK 2171771839 SYN  WIN 4128

Jan  8 17:44:59.215: TCP0: timeout #1 - timeout is 4000 ms, seq 973912199

Jan  8 17:45:03.207: tcp0: I SYNRCVD 192.0.2.28:22776 192.0.2.2:23 seq 2171771838

        OPTS 4 SYN  WIN 4128

Jan  8 17:45:03.207: tcp0: O SYNRCVD 192.0.2.28:22776 192.0.2.2:23 seq 973912199

        ACK 2171771839  WIN 4128

Jan  8 17:45:03.211: TCP0: bad seg from 192.0.2.28 -- bad sequence number: port 23 seq 2171771838 ack 0 rcvnxt 2171771839 rcvwnd 4128 len 0

Jan  8 17:45:03.215: tcp0: R SYNRCVD 192.0.2.28:22776 192.0.2.2:23 seq 973912199

        OPTS 4 ACK 2171771839 SYN  WIN 4128

Jan  8 17:45:03.215: TCP0: timeout #2 - timeout is 8000 ms, seq 973912199

Jan  8 17:45:11.207: tcp0: I SYNRCVD 192.0.2.28:22776 192.0.2.2:23 seq 2171771838

        OPTS 4 SYN  WIN 4128

Jan  8 17:45:11.207: tcp0: O SYNRCVD 192.0.2.28:22776 192.0.2.2:23 seq 973912199

        ACK 2171771839  WIN 4128

Jan  8 17:45:11.207: TCP0: bad seg from 192.0.2.28 -- bad sequence number: port 23 seq 2171771838 ack 0 rcvnxt 2171771839 rcvwnd 4128 len 0

Jan  8 17:45:11.215: tcp0: R SYNRCVD 192.0.2.28:22776 192.0.2.2:23 seq 973912199

        OPTS 4 ACK 2171771839 SYN  WIN 4128

Jan  8 17:45:11.215: TCP0: timeout #3 - timeout is 15996 ms, seq 973912199

Jan  8 17:45:27.211: TCP0: state was SYNRCVD -> CLOSED [23 -> 192.0.2.28(22776)]

Jan  8 17:45:27.211: tcp0: T CLOSED 192.0.2.28:22776 192.0.2.2:23 early close

Jan  8 17:45:27.211: TCB 0x6833EA20 destroyed


		
	

657 просмотров
0 Комментариев

Есть забавная проблемка, которой подвержены многие использующиеся сейчас версии ISE

Неожиданно становятся недоступны логи Live Auth. Илиапплеты не главной странице, или и то, и другое. Также могут перестать показываться страницы с репортами - полностью или частично.

 

Этому предшествует появление алармов но мониторинговом устройстве:

"Database purging"

"Database Purge for Tables failed"

 

В alarm details:

ORA-00604: error occurred at recursive SQL level 1перейти на в
ORA-01000: maximum open cursors exceeded

 

Однако как правило эти алармы замечают уже после того, как пропадает часть интерфейса:-)

 

Есть несколько багов, связанных с этой ошибкой.

CSCud12095 - Purge job fails to complete in ISE 1.1.1

CSCud85806 - ISE: Purge Operation Fails Intermittently

CSCuh70984 - Database purging alarms on ISE due to open cursors exceeded

 

Описание в целом похожее - по различным причинам purge не отрабатывает, записей в таблице становится слишком много, и она не отображается. Хочу отметить что данные при этом не пропадают.

 

И как же избавиться от этой досадной проблемы?

 

workaround очень простой - нужно перезагружить мониторинговую ноду. Но, во-первых, это неудобно, а во-вторых, в случае большого переполнения таблицы, может и не помочь.

solution: перейти на версию, в корой проблема исправлена: 1.1.3 или 1.1.4 patch 4 (или более поздний).

 

Английская версия этого блог-поста: https://supportforums.cisco.com/blogs/iron/2013/09/12/database-purge-for-tables-failed--common-issue

СоздатьДля создания публикации, пожалуйста в систему