Эмулятору GNS3 на хабре была посвящена не одна статья, и думаю, что многие, кто работает с оборудованием Cisco, сталкивались с необходимостью запуска сетевого оборудования в виртуальной среде для проверки интересующих топологий и решений, при отладке неработающих конфигураций, либо просто при подготовке к сертификации или изучении той или иной технологии.
В последних версиях GNS3 появилась возможность эмуляции такого устройства, как Cisco ASA. Это устройство является многофункциональным межсетевым экраном, может работать в различных режимах (routed/transparent; single/multiple context), применяться в отказоустойчивых конфигурациях (active/standby; active/active) и т.д. В статье приводятся результаты тестирования и выводы, насколько полно поддерживается данный функционал при виртуализации этого устройства в GNS3.
Надеюсь, что данная статья поможет вам определиться с тем, стоит ли эмулировать ту или иную топологию в GNS3, а также сэкономит время при отладке вашего решения в виртуальной среде.
Исходные данные
Тестирование проводилось с использованием следующих средств:
1. Виртуальная машина Windows Server 2003 R2 Standard (Intel Xeon E5420 2,50GHz, 4Gb RAM);
2. Эмулятор GNS3 v.0.7.4;
3. Образ ОС Cisco ASA 8.0(2);
4. Средство графического управления и мониторинга Cisco ASDM 6.4(5);
5. Образ ОС Cisco IOS для маршрутизаторов 3725 (c3725-adventerprisek9-mz.124-25d);
6. Сервер управления доступом Cisco ACS 4.2;
7. FTP-, TFTP-, syslog-сервер на базе 3CDaemon.
Тестовые топологии и методики проверки брались из первого воркбука (WB) Internetwork Expert (INE) для подготовки к CCIE Security. Сами задачи и описание проверяемых технологий я опущу, оставлю только результаты.
Описание того, как запустить Cisco ASA в GNS3, можно найти по ссылкам – на английском, и даже на русском языках.
В первом тесте межсетевой экран (далее – МЭ) Cisco ASA запускался в режимах routed и single (без поддержки виртуальных контекстов).
Топология приведена на рисунке:
В рамках этих проверок проверялась работа протоколов динамической маршрутизации (RIP, OSPF, EIGRP), редистрибьюция, IP SLA трекинг.
В случаях, когда возникала необходимость в управляемом коммутаторе, использовался маршрутизатор Cisco 3725 с модулем NM-16ESW.
Список неподдерживаемых L2-функций при использовании модуля NM-16ESW приведен на официальном сайте.
Интерфейс командной строки немного отличается от коммутаторов Cisco Catalyst. Будьте внимательны.
Собственно с задачами, приведенными в WB1 INE, при эмуляции Cisco ASA проблем не возникло. Да и в целом, забегая вперед, скажу, что только режимы routed/single работают более-менее полноценно в GNS3 в данный момент.
Однако уже на этом этапе появился ряд вспомогательных багов. Возможно слово «баг» не совсем корректно отражает сложности и ошибки, возникшие при эмуляции, однако в целях единства классификации буду использовать именно его.
Баг №1. Необходимость перезагрузки Cisco ASA после задания базовой конфигурации в случае, если коммутация проводилась после старта устройства. В противном случае связность не устанавливалась, устройства друг друга не видели.
Баг №2. В целом это не баг, а особенность базовых настроек GNS3. Т.к. на машине, где запускался GNS3, был установлен Cisco ACS4.2, то порты 2000-2002 слушались непосредственно самим ACS. А GNS3 в качестве консольных портов для маршрутизаторов по умолчанию использует порты, начиная с 2000. Поэтому будьте внимательны, необходимо эти порты сменить при добавлении маршрутизатора.
Баг №3. Не сохраняется конфигурация маршрутизаторов после выключения и включения GNS3. Данный баг наблюдался в старых версиях GNS3 на некоторых образах IOS, в частности при работе с маршрутизаторами серии 3700. В текущей версии у меня проблем при работе с 3725 не возникало, однако есть информация о том, что с 3745 проблема сохраняется… Хотя возможно здесь все зависит от эмулируемого образа. В общем, если кто-то столкнется, то можно попробовать решить эту проблему таким образом.
Во втором тесте МЭ Cisco ASA также запускался в режимах routed, single.
В данном тесте проверялась работа списков доступа (ACL), различные варианты NAT (dynamic NAT, PAT; static NAT, PAT; dynamic policy NAT, static policy NAT, PAT; Identity NAT; NAT Exemption; Outside Dynamic NAT), возможность управления с помощью ASDM, функция DNS Doctoring, обработка фрагментированного трафика, пропуск BGP-соединений сквозь МЭ, мультикастинг, работа протокола NTP, протоколирование событий (syslog, SNMP), работа МЭ в качестве DHCP-сервера, трафик-полисинг и шейпинг.
Небольшие сложности возникли с управлением с помощью ASDM (о том, как настроить работу ASDM в GNS3, можете посмотреть в видеоинструкции). После включения ASDM лог устройства заваливается следующими сообщениями:
что несколько осложняет отладку. Вы можете использовать фильтры, либо вообще отключить протоколирование данного сообщения (
Из критичных недостатков:
Баг №4. МЭ Cisco ASA в качестве DHCP-сервера в среде GNS3 не работает.
В третьем тесте проверялась работа МЭ в прозрачном режиме. ASA в режиме transparent может использовать только два интерфейса (в single mode) для передачи данных (и один выделенный интерфейс для управляющего трафика), несмотря на то, что у неё может быть большее количество интерфейсов.
В этом режиме полноценная работа Cisco ASA в среде GNS3 не поддерживается. Mgmt-интерфейс доступен при проверке с маршрутизаторов, однако трафик через межсетевой экран не проходит, несмотря на то, что попытки установки соединения на межсетевом экране отображаются.
Собственно из-за этого не удалось проверить работу таких механизмов, как ARP Inspection, Ethertype ACL, Transparent Firewall NAT.
Баг №5. Transparent режим в Cisco ASA в среде GNS3 не поддерживается.
В данном режиме создавалось два виртуальных контекста: CustomerA, CustomerB.
Интерфейсы, используемые контекстом CustomerA: E0/1.121 (InsideA), E0/2 (DMZ), E0/0 (Outside)
Интерфейсы, используемые контекстом CustomerB: E0/1.122 (InsideB), E0/2 (DMZ), E0/0 (Outside)
Интерфейсы DMZ и Outside разделяются между контекстами.
В среде GNS3 данный режим будет поддерживаться только при отключенной команде
В случае если ваш сценарий не предусматривает использование трансляции сетевых адресов, то вы не сможете использовать один и тот же IP и MAC на разделяемом интерфейсе в нескольких контекстах.
Баг №6. Использование виртуальных контекстов возможно только при отключенной команде
В этом режиме активно только одно устройство, второе находится в пассивном состоянии. Устройства синхронизируют друг с другом конфигурацию, а также таблицу состояний соединений, что позволяет в случае отказа активной части не разрывать уже установленные соединения.
При проведении теста маршрутизатор R1 устанавливал telnet-соединение на маршрутизатор R2, после чего имитировался отказ (путем выключения порта коммутатора SW1, подключенного к активному МЭ). По логике должно было произойти переключение отказоустойчивой пары, telnet-соединение должно было продолжить работать, т.к. между МЭ настроен statefull-линк.
Однако в виртуальной среде GNS3 результат оказался иным. Переключение отказоустойчивой пары произошло, но telnet-сессия прервалась. Более того, трафик через межсетевые экраны перестал ходить вообще. Связано это с тем, что, несмотря на то, что активная часть сменилась, кластер продолжал отвечать на ARP-запросы MAC-адресом первого межсетевого экрана (хотя тот уже перешел в пассивный режим). После полной перезагрузки кластерной пары ситуация не изменилась.
Баг №7. Cisco ASA в failover-режиме Active/Standby после переключения активного устройства на пассивное перестает пропускать через себя трафик по причине некорректных ответов на ARP-запросы.
Насколько мне известно, при эмуляции Cisco PIX 7версии такая проблема не возникает. Поэтому при необходимости используйте это решение.
В этом режиме активны оба устройства. Достигается это использованием нескольких виртуальных контекстов, часть из которых активны на одной части кластера, часть – на другой.
Проверка планировалась аналогичной той, что описана в предыдущем пункте. Однако закончилась несколько раньше. Причина следующая: устройства объединились в кластер, однако трафик через него не проходит, т.к. в отказоустойчивой конфигурации Active/Active используются виртуальные mac-адреса.
Баг №8. Трафик не проходит через кластер Cisco ASA в failover-режиме Active/Active.
В последнем тесте собиралась схема с redundant-интерфейсами на Cisco ASA, которые позволяют объединить несколько физических интерфейсов в логический. При этом активен только один интерфейс, второй активируется только после отказа первого.
В проверке проводилось отключение порта коммутатора, подключенного к активному интерфейсу ASA. После обнаружения отказа должен был стать активным второй интерфейс МЭ. Однако в среде GNS3 МЭ не обнаружил со своей стороны отключение порта на коммутаторе, и соответственно в активном состоянии продолжал находиться нерабочий интерфейс.
Баг №9. Переключение redundant-интерфейса не происходит при отказе физического соединения на соседнем с МЭ устройством.
Тесты показали, что не все режимы работы Cisco ASA в среде GNS3 поддерживаются полностью. Меньше всего проблемы возникло при использовании routed, single mode режимов. В целом именно этот режим является наиболее популярным и наиболее полным с точки зрения функционала. В прозрачном режиме добиться корректной работы межсетевого экрана не удалось.
Режим с использованием виртуальных контекстов возможен в GNS3, но при условии отключения функции генерации виртуальных mac-адресов, что не позволит реализовать ряд сценариев при работе с Cisco ASA.
Если вашей целью является проверка объединения двух устройств ASA в отказоустойчивый кластер, то вы можете использовать GNS3. Однако в случае с режимом Active/Standby трафик не будет проходить через кластерную пару при переключении (в случае отказа), а в случае с Active/Active во всех случаях.
Аналогичная варианту с режимом Active/Standby ситуация происходит при использовании redundant-интерфейсов. В случае отказа активного интерфейса трафик через ASA проходить не будет.
Отмечу, что все используемые в тестах конфигурации были проверены на реальном оборудовании и отработали без нареканий.
Возможно есть способы полноценного запуска того или иного режима работы Cisco ASA в GNS3, в этом случае вы можете устроить сеанс разоблачения и поделиться этими знаниями в комментариях.
Если для кого-то это решение является новым, то знакомство с ним вы можете начать на официальном сайте -, и также посмотрев «небольшой» 40-минутный ролик от известного автора учебных пособий CBT Nuggets для подготовки к экзаменам Cisco – Jeremy Cioara.
В последних версиях GNS3 появилась возможность эмуляции такого устройства, как Cisco ASA. Это устройство является многофункциональным межсетевым экраном, может работать в различных режимах (routed/transparent; single/multiple context), применяться в отказоустойчивых конфигурациях (active/standby; active/active) и т.д. В статье приводятся результаты тестирования и выводы, насколько полно поддерживается данный функционал при виртуализации этого устройства в GNS3.
Надеюсь, что данная статья поможет вам определиться с тем, стоит ли эмулировать ту или иную топологию в GNS3, а также сэкономит время при отладке вашего решения в виртуальной среде.
Исходные данные
Тестирование проводилось с использованием следующих средств:
1. Виртуальная машина Windows Server 2003 R2 Standard (Intel Xeon E5420 2,50GHz, 4Gb RAM);
2. Эмулятор GNS3 v.0.7.4;
3. Образ ОС Cisco ASA 8.0(2);
4. Средство графического управления и мониторинга Cisco ASDM 6.4(5);
5. Образ ОС Cisco IOS для маршрутизаторов 3725 (c3725-adventerprisek9-mz.124-25d);
6. Сервер управления доступом Cisco ACS 4.2;
7. FTP-, TFTP-, syslog-сервер на базе 3CDaemon.
Тестовые топологии и методики проверки брались из первого воркбука (WB) Internetwork Expert (INE) для подготовки к CCIE Security. Сами задачи и описание проверяемых технологий я опущу, оставлю только результаты.
Описание того, как запустить Cisco ASA в GNS3, можно найти по ссылкам – на английском, и даже на русском языках.
Тестовые топологии и проверки
1. Динамическая маршрутизация
В первом тесте межсетевой экран (далее – МЭ) Cisco ASA запускался в режимах routed и single (без поддержки виртуальных контекстов).
Топология приведена на рисунке:
В рамках этих проверок проверялась работа протоколов динамической маршрутизации (RIP, OSPF, EIGRP), редистрибьюция, IP SLA трекинг.
В случаях, когда возникала необходимость в управляемом коммутаторе, использовался маршрутизатор Cisco 3725 с модулем NM-16ESW.
Список неподдерживаемых L2-функций при использовании модуля NM-16ESW приведен на официальном сайте.
Интерфейс командной строки немного отличается от коммутаторов Cisco Catalyst. Будьте внимательны.
Собственно с задачами, приведенными в WB1 INE, при эмуляции Cisco ASA проблем не возникло. Да и в целом, забегая вперед, скажу, что только режимы routed/single работают более-менее полноценно в GNS3 в данный момент.
Однако уже на этом этапе появился ряд вспомогательных багов. Возможно слово «баг» не совсем корректно отражает сложности и ошибки, возникшие при эмуляции, однако в целях единства классификации буду использовать именно его.
Баг №1. Необходимость перезагрузки Cisco ASA после задания базовой конфигурации в случае, если коммутация проводилась после старта устройства. В противном случае связность не устанавливалась, устройства друг друга не видели.
Баг №2. В целом это не баг, а особенность базовых настроек GNS3. Т.к. на машине, где запускался GNS3, был установлен Cisco ACS4.2, то порты 2000-2002 слушались непосредственно самим ACS. А GNS3 в качестве консольных портов для маршрутизаторов по умолчанию использует порты, начиная с 2000. Поэтому будьте внимательны, необходимо эти порты сменить при добавлении маршрутизатора.
Баг №3. Не сохраняется конфигурация маршрутизаторов после выключения и включения GNS3. Данный баг наблюдался в старых версиях GNS3 на некоторых образах IOS, в частности при работе с маршрутизаторами серии 3700. В текущей версии у меня проблем при работе с 3725 не возникало, однако есть информация о том, что с 3745 проблема сохраняется… Хотя возможно здесь все зависит от эмулируемого образа. В общем, если кто-то столкнется, то можно попробовать решить эту проблему таким образом.
2. Сетевые настройки
Во втором тесте МЭ Cisco ASA также запускался в режимах routed, single.
В данном тесте проверялась работа списков доступа (ACL), различные варианты NAT (dynamic NAT, PAT; static NAT, PAT; dynamic policy NAT, static policy NAT, PAT; Identity NAT; NAT Exemption; Outside Dynamic NAT), возможность управления с помощью ASDM, функция DNS Doctoring, обработка фрагментированного трафика, пропуск BGP-соединений сквозь МЭ, мультикастинг, работа протокола NTP, протоколирование событий (syslog, SNMP), работа МЭ в качестве DHCP-сервера, трафик-полисинг и шейпинг.
Небольшие сложности возникли с управлением с помощью ASDM (о том, как настроить работу ASDM в GNS3, можете посмотреть в видеоинструкции). После включения ASDM лог устройства заваливается следующими сообщениями:
%ASA-5-402128: CRYPTO: An attempt to allocate a large memory block
failed, size: size, limit: limitчто несколько осложняет отладку. Вы можете использовать фильтры, либо вообще отключить протоколирование данного сообщения (
no logging message 402128).Из критичных недостатков:
Баг №4. МЭ Cisco ASA в качестве DHCP-сервера в среде GNS3 не работает.
3. Cisco ASA в режиме Transparent
В третьем тесте проверялась работа МЭ в прозрачном режиме. ASA в режиме transparent может использовать только два интерфейса (в single mode) для передачи данных (и один выделенный интерфейс для управляющего трафика), несмотря на то, что у неё может быть большее количество интерфейсов.
В этом режиме полноценная работа Cisco ASA в среде GNS3 не поддерживается. Mgmt-интерфейс доступен при проверке с маршрутизаторов, однако трафик через межсетевой экран не проходит, несмотря на то, что попытки установки соединения на межсетевом экране отображаются.
Собственно из-за этого не удалось проверить работу таких механизмов, как ARP Inspection, Ethertype ACL, Transparent Firewall NAT.
Баг №5. Transparent режим в Cisco ASA в среде GNS3 не поддерживается.
4. Cisco ASA в режиме виртуальных контекстов
В данном режиме создавалось два виртуальных контекста: CustomerA, CustomerB.
Интерфейсы, используемые контекстом CustomerA: E0/1.121 (InsideA), E0/2 (DMZ), E0/0 (Outside)
Интерфейсы, используемые контекстом CustomerB: E0/1.122 (InsideB), E0/2 (DMZ), E0/0 (Outside)
Интерфейсы DMZ и Outside разделяются между контекстами.
В среде GNS3 данный режим будет поддерживаться только при отключенной команде
mac-address auto (no mac-address auto). Данная команда обеспечивает генерацию виртуального mac-адреса на разделяемом интерфейсе для каждого контекста. Виртуальный mac является одним из критериев при классификации пакета для доставки в нужный контекст. Поэтому при отключении будут использоваться другие критерии для классификации (записи в активных NAT-трансляциях). В случае если ваш сценарий не предусматривает использование трансляции сетевых адресов, то вы не сможете использовать один и тот же IP и MAC на разделяемом интерфейсе в нескольких контекстах.
Баг №6. Использование виртуальных контекстов возможно только при отключенной команде
mac-address auto, что накладывает ограничения на возможные сценария развертывания МЭ Cisco ASA.5. Отказоустойчивая конфигурация в режиме Active/Standby
В этом режиме активно только одно устройство, второе находится в пассивном состоянии. Устройства синхронизируют друг с другом конфигурацию, а также таблицу состояний соединений, что позволяет в случае отказа активной части не разрывать уже установленные соединения.
При проведении теста маршрутизатор R1 устанавливал telnet-соединение на маршрутизатор R2, после чего имитировался отказ (путем выключения порта коммутатора SW1, подключенного к активному МЭ). По логике должно было произойти переключение отказоустойчивой пары, telnet-соединение должно было продолжить работать, т.к. между МЭ настроен statefull-линк.
Однако в виртуальной среде GNS3 результат оказался иным. Переключение отказоустойчивой пары произошло, но telnet-сессия прервалась. Более того, трафик через межсетевые экраны перестал ходить вообще. Связано это с тем, что, несмотря на то, что активная часть сменилась, кластер продолжал отвечать на ARP-запросы MAC-адресом первого межсетевого экрана (хотя тот уже перешел в пассивный режим). После полной перезагрузки кластерной пары ситуация не изменилась.
Баг №7. Cisco ASA в failover-режиме Active/Standby после переключения активного устройства на пассивное перестает пропускать через себя трафик по причине некорректных ответов на ARP-запросы.
Насколько мне известно, при эмуляции Cisco PIX 7версии такая проблема не возникает. Поэтому при необходимости используйте это решение.
6. Отказоустойчивая конфигурация в режиме Active/Active
В этом режиме активны оба устройства. Достигается это использованием нескольких виртуальных контекстов, часть из которых активны на одной части кластера, часть – на другой.
Проверка планировалась аналогичной той, что описана в предыдущем пункте. Однако закончилась несколько раньше. Причина следующая: устройства объединились в кластер, однако трафик через него не проходит, т.к. в отказоустойчивой конфигурации Active/Active используются виртуальные mac-адреса.
Баг №8. Трафик не проходит через кластер Cisco ASA в failover-режиме Active/Active.
7. Redundant-интерфейсы
В последнем тесте собиралась схема с redundant-интерфейсами на Cisco ASA, которые позволяют объединить несколько физических интерфейсов в логический. При этом активен только один интерфейс, второй активируется только после отказа первого.
В проверке проводилось отключение порта коммутатора, подключенного к активному интерфейсу ASA. После обнаружения отказа должен был стать активным второй интерфейс МЭ. Однако в среде GNS3 МЭ не обнаружил со своей стороны отключение порта на коммутаторе, и соответственно в активном состоянии продолжал находиться нерабочий интерфейс.
Баг №9. Переключение redundant-интерфейса не происходит при отказе физического соединения на соседнем с МЭ устройством.
Выводы
Тесты показали, что не все режимы работы Cisco ASA в среде GNS3 поддерживаются полностью. Меньше всего проблемы возникло при использовании routed, single mode режимов. В целом именно этот режим является наиболее популярным и наиболее полным с точки зрения функционала. В прозрачном режиме добиться корректной работы межсетевого экрана не удалось.
Режим с использованием виртуальных контекстов возможен в GNS3, но при условии отключения функции генерации виртуальных mac-адресов, что не позволит реализовать ряд сценариев при работе с Cisco ASA.
Если вашей целью является проверка объединения двух устройств ASA в отказоустойчивый кластер, то вы можете использовать GNS3. Однако в случае с режимом Active/Standby трафик не будет проходить через кластерную пару при переключении (в случае отказа), а в случае с Active/Active во всех случаях.
Аналогичная варианту с режимом Active/Standby ситуация происходит при использовании redundant-интерфейсов. В случае отказа активного интерфейса трафик через ASA проходить не будет.
Отмечу, что все используемые в тестах конфигурации были проверены на реальном оборудовании и отработали без нареканий.
Возможно есть способы полноценного запуска того или иного режима работы Cisco ASA в GNS3, в этом случае вы можете устроить сеанс разоблачения и поделиться этими знаниями в комментариях.
Если для кого-то это решение является новым, то знакомство с ним вы можете начать на официальном сайте -, и также посмотрев «небольшой» 40-минутный ролик от известного автора учебных пособий CBT Nuggets для подготовки к экзаменам Cisco – Jeremy Cioara.
