1. Поддерживается набор команд, определенный в документе «Cisco-like команды».
2. В Cisco используется примерно следующая логика работы с access list:
<interface_acl> -> <crypto_map_acl> -> <interface_acl>,
где <interface_acl> – access list в интерфейсе,
а <crypto_map_acl> – access list в crypto map.
В конверторе используется логика разворачивания access list-ов в сквозную модель правил. При этом возможны некоторые несоответствия и несовместимости (подробнее см .«Описание обработки интерфейсов»).
· В правилах в access list в маске подсети допускается указание только непрерывной линейки из установленных битов в конце (т.е. 00…01…1, например 0.0.0.255 0.0.0.63 и т.п.). Не допускается разрывов в полях установленных и сброшенных битов (например, маски вида 0.255.0.255). В случае появления запрещенной маски, конвертация завершается с ошибкой [3.8].
3. Ряд ограничений на ca trustpoint:
· enrollment игнорируется (только ручное задание сертификатов).
· Читаются только CA-сертификаты, локальные сертификаты игнорируются.
· Небольшое пояснение: в Cisco по команде crypro ca certificate chain показываются CA сертификаты и локальные сертификаты. Через эту команду все сертификаты можно посмотреть, удалить и ввести CA сертификаты. Однако, локальные сертификаты нельзя ввести таким образом (они будут неработоспособны без секретного ключа). В cs_console данная команда используется только для работы с CA сертификатами.
· Под обозначением RSA-сертификатов (другие в Cisco не используются) могут использоваться RSA, ГОСТ и DSA-сертификаты.
· В Cisco в пределах одного trustpoint могут вписываться только сертификаты из одной цепочки. В cs_converter допускаются любые CA сертификаты.
· Задается строгое соответствие: RSA CA сертификат подписывает только RSA-сертификаты, ГОСТ CA сертификат подписывает только ГОСТ сертификаты, DSA CA сертификат подписывает только DSA-сертификаты.
· Следует учитывать, что в конфигурации не задается точных критериев выбора локального сертификата (в терминах Native LSP задается USER_SPECIFIC_DATA). В связи с этим возможны ситуации, при которых не установится соединение, если присутствуют больше одного локального сертификата, подписанного разными CA.
· Пример подобной ситуации: у партнера не прописана посылка Certificate Request, и партнер ожидает от агента конкретный сертификат (который действительно присутствует), но агент по своим критериям выбирает другой сертификат, который не подходит партнеру.
· Как правило, таких проблем не возникает, если соблюдаются следующие условия:
· У обоих партнеров прописана отсылка Certificate Request. По умолчанию конвертер именно так и делает. Cisco в большинстве случаев поступает также.
· Не используется Aggressive Mode при работе с сертификатами (экзотический случай).
· У партнера должны быть явно указаны CA-сертификаты, которыми может быть подписан локальный сертификат агента. В Native LSP агента – атрибут AcceptCredentialFrom (cs_converter вписывает все CA-сертификаты, лежащие в базе). В Cisco – должен быть прописан подходящий trustpoint.
4. Ограничение на LDAP url: допускается только задание IP-адреса и, возможно, порта. Если задано DNS-name – данный url игнорируется.
5. Допускается только одно ISAKMP правило для одного IPsec-правила.
6. Если для данного crypto-map удалось подобрать несколько ISAKMP policy с разными Transform и методами аутентификации, то формируется одна IKERule, в которой пишутся ВСЕ трансформы и методы аутентификации, что приводит к несколько иной логике (т.е. теряется связь между трансформами и методами аутентификации).
Пример
#Фрагмент исходной конфигурации:
crypto isakmp policy 1
encr des
hash md5
authentication rsa-sig
crypto isakmp policy 2
encr 3des
hash sha
authentication pre-share
group 2
crypto isakmp policy 3
encr aes 128
hash md5
authentication rsa-sig
#Фрагмент Native-LSP (в ситуации, когда подходят все три policy):
AuthMethodRSASign auth_ca(
...
)
AuthMethodPreshared IKE_auth_key_192_168_11_110(
...
)
IKERule IKE_router_mc_fastethernet0_0_crypto_1(
Transform* = IKETransform(
CipherAlg *= "DES-CBC"
HashAlg *= "MD5"
GroupID *= MODP_768
LifetimeSeconds = 86400
),
IKETransform(
CipherAlg *= "DES3-K168-CBC"
HashAlg *= "SHA1"
GroupID *= MODP_1024
LifetimeSeconds = 86400
),
IKETransform(
CipherAlg *= "AES-K128-CBC-7"
HashAlg *= "MD5"
GroupID *= MODP_768
LifetimeSeconds = 86400
)
MainModeAuthMethod *= auth_ca, IKE_auth_key_192_168_11_110
AggrModeAuthMethod *= auth_ca, IKE_auth_key_192_168_11_110
DoAutopass = TRUE
)
7. В фильтрах, в которых прописан локальный адрес ANY, в Native-LSP соответствующий атрибут не прописывается.
8. В IKERule может прописываться параметр IKEPeerIPFilter. Используются следующие правила:
· Источник информации выбирается по приоритетам: если удается получить фильтр на основе информации из очередного пункта, следующие пункты игнорируются (например, если есть set peer, другие пункты игнорируются).
· Источники информации для IKEPeerIPFilter:
· Команда set peer, если она присутствует в crypto map (всегда для статических crypto map; редко для динамических crypto map).
· Только для структур IKERule, не имеющих ссылок на AuthMethod...Sign (используются только preshared keys; без сертификатов): адрес из команды crypto isakmp key ... address (или ...hostname в случае, когда мы можем связать указанный hostname с IP-адресом через команду ip host).
· Только при использовании транспортного режима: permit-записи в crypto ACL.
9. Если в crypto map прописаны несколько peer, каждый из которых аутентифицируется по preshared key, то используется следующий подход:
· прописывается туннель и аутентификация для первого по счету peer
· для остальных peer-ов проверяются preshared keys:
· если preshared key совпадает с ключом для первого peer, то этот peer прописывается в качестве туннеля;
· если preshared key не совпадает с ключом для первого peer, то для данного peer формируется отдельный AuthMethodPreshared, IKERule и IPsecAction.
Следует учитывать, что подобная конфигурация приведет к тому, что работа со вторым peer будет возможна только в качестве ответчика. В качестве инициатора работа возможна только с первым peer.
Рекомендуется по возможности избегать таких ситуаций. Для этого, в случае указания в crypto map нескольких peers, следует либо использовать аутентификацию по сертификатам либо, в случае использования аутентификации на preshared keys, использовать одинаковый ключ для всех peers, перечисленных в одной crypto map.
В подобной ситуации выдается сообщение [2.10].
Если присутствует подобная конфигурация с несовпадающими preshared ключами и, кроме того, существует аутентификация на сертификатах; тогда к вышеперечисленным наборам AuthMethodPreshared, IKERule и IPsecAction добавится еще один, описывающий аутентификацию на сертификатах. При этом в IPsecAction будут прописаны все peers.
10. Существует специфический подход в случае, если в crypto map set присутствует несколько crypto maps, а в их crypto-map-acls существуют пересечения по адресам, причем в части правил присутствует permit, а в других правилах – deny. Подробнее логика конвертирования для данной ситуации описана в разделе «Описание обработки интерфейсов».
11. Существуют особенности в настройке маршрутизации:
Если добавить из консоли routing, который уже присутствует в системной таблице маршрутизации, то он будет добавлен в текущую конфигурацию с диагностикой в файле лога.
При отгрузке сконвертированной конфигурации (по любой причине), из системной таблицы маршрутизации будут удалены все записи, добавленные из консоли, которые также могли существовавать и до запуска консоли (например, добавленные с помощью команды route add).
12. Существуют дополнительные команды, которые отсутствуют у Cisco:
· команда set pool – задает IKE-CFG pool, привязанный к конкретной crypto map. Работает в конфигурационном режиме crypto map и crypto dynamic-map.
особый случай – команда set pool <none> – убирает для конкретной crypto map или crypto dynamic-map настройки IKE-CFG, которые, возможно, выставлены с помощью команды crypto map client configuration address или crypto dynamic-map client configuration address (они работают для crypto map set).
· команда crypto dynamic-map client configuration address. Работает аналогично команде crypto map client configuration address, но для dynamic map set.
13. Команды для задания ограничений по трафику и времени имеют больший диапазон, чем в Cisco:
· security-association lifetime kilobytes: в Cisco 2560-536870912, у нас – 1-4294967295.
· security-association lifetime seconds: в Cisco 120-86400, у нас – 1-4294967295.
· IKE lifetime (seconds): в Cisco 60-86400, у нас – 1-4294967295.
Примечание: Cisco-like консоли как и в Cisco отсутствует возможность убрать ограничения по трафику и времени (unlimited).
14. Существуют особенности при настройке шлюза для работы с мобильным клиентом. Можно использовать один из двух подходов:
· c точки зрения логики настройки S-Terra Gate, в acl, привязанном к crypto dynamic map, в качестве remote-адресов для мобильных клиентов необходимо указывать any. Таким образом указывается, что допускается любой физический адрес мобильного клиента.
· с точки зрения логики настройки Cisco, в acl, привязанном к crypto dynamic map, в качестве remote-адресов для мобильных клиентов указывается пул, из которого роутер раздает адреса мобильным клиентам. Таким образом указывается, что область действия этой crypto dynamic map распространяется только для мобильных клиентов из пула:
В сконвертированной LSP, в структуре IPsecAction в атрибуте TunnelEntry отсутствует поле PeerIPAddress, и в качестве IKE-партнера для шлюза может выступать мобильный клиент с любым физическим адресом.
В тоже время, если мобильный клиент является пассивным IKE-CFG клиентом (IKECFGRequestAddress=FALSE – не инициирует посылку запроса на получение адреса из пула), то защищенное соединение построено не будет. Присылаемый мобильным клиентом его физический адрес в качестве identity QM не подходит под соответствующее правило фильтрации и QM шлюзом отвергается.
Для успешного создания соединения при такой конфигурации шлюза мобильный клиент должен выступать в качестве активного IKE-CFG клиента (IKECFGRequestAddress=TRUE). В этом случае в качестве identity QM используется выданный клиенту адрес из пула и соответствующее правило фильтрации на шлюзе срабатывает.
15. Если задается dynamic map без указания set peer (обычная ситуация), то формируются цепочки правил для всех возможных вариантов аутентификации. Например, если заданы несколько preshared keys для разных хостов, то будут сформированы правила для всех этих preshared keys и соответствующих им хостов.
Если задается dynamic map с указанием set peer (экзотический, но допустимый вариант), то данная dynamic map конвертируется аналогично static map.
16. В TunnelingParameters прописывается значение DFHandling:
· используется значение crypto ipsec df-bit для интерфейса, если оно присутствует в конфигурации
· в противном случае используется глобальное значение crypto ipsec df-bit.
17. Может генерироваться несколько структур IKERule, каждая из которых подходит по присланным партнером параметрам.
Для выбора конкретного IKE-правила используется параметр Priority. Особенности его формирования:
· У каждой структуры IKERule уникальное значение параметра.
· Если структура IKERule порождена только из динамических криптокарт, значение параметра Priority гарантировано будет больше, чем у любой из структур, порожденных из статических криптокарт.
· Присутствуют два диапазона значений: для IKERule, порожденных от динамических криптокарт; и для IKERule, порожденных от статичсеких криптокарт.
· Если структура IKERule порождена из нескольких криптокарт (происходит объединение правил), значение параметра Priority будет минимально возможным среди указанных криптокарт.
· В частности: если данная структура IKERule порождена как из статической, так и из динамической криптокарты, то параметр Priority будет задан из диапазона значений, предназначенных для статических криптокарт.
· В описании последующих правил для простоты предполагается, что каждая криптокарта порождает отдельную структуру IKERule (не происходит объединение правил):
· если две статические криптокарты входят в один набор, привязанный к данному сетевому интерфейсу, значение Priority криптокарты с меньшим номером будет также меньшим
· если две статические криптокарты привязаны к разным сетевым интерфейсам, значение Priority будет меньше у криптокарты, привязанной к интерфейсу, который описан раньше в файле ifaliases.cf
· аналогичная ситуация с двумя динамическими криптокартами.
18. Возможна конфликтная ситуация при выставлении aggressive mode:
· Имеется криптокарта, в которой прописаны два peer, для одного из которых выставлена aggressive mode, а для другого – нет. Например:
crypto map cmap 10 ipsec-isakmp
! ...
set peer 192.168.10.11
set peer 192.168.10.12
! ...
crypto isakmp peer address 192.168.10.11
set aggressive-mode client-endpoint ipv4-address 192.168.10.11
· Конвертирование такой конфигурации может прерываться с ошибкой MSG_ID_CSCONV_CRYPTO_MAP_PH1_MODE_MISMATCH (0x00733108).
· Примечание: ошибка не появляется, если в результате конвертирования для каждого из peer-ов генерируются отдельные структуры IKERule.
· Следует учесть, что данное поведение отличается от поведения конвертора версии 3.1: там в подобной ситуации выставлялся параметр AggrModePriority = TRUE.