CISCO IPsec — в статье рассказаны варианты развёртывания VPN туннеля: «чистый» IPsec, GRE over IPsec в виртуальной среде EVE-NG.
Тестовая среда
Использовалась IOSv Software (VIOS-ADVENTERPRISEK9-M), Version 15.6(2)T, RELEASE SOFTWARE (fc2).
Туннель туннель будет прокидываться между интерфейсами GigabitEthernet0/0 роутеров.
Попробуем симулировать среду 2 граничных роутеров, между которыми Интернет. Поэтому на роутерах настроен NAT. Компьютеры PC1 и PC2 друг-друга напрямую не видят, так как они за натом. Начальная конфигурация R1:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 |
<em>... interface GigabitEthernet0/0 <strong>ip address 10.10.10.1 255.255.255.252 ip nat outside</strong> ip virtual-reassembly in duplex auto speed auto media-type rj45 ! interface GigabitEthernet0/1 <strong>ip address 192.168.1.1 255.255.255.0 ip nat inside</strong> ip virtual-reassembly in duplex auto speed auto media-type rj45 ... <strong>ip nat inside source list 1 interface GigabitEthernet0/0 overload ip route 0.0.0.0 0.0.0.0 10.10.10.2 </strong>— маршрут по умолчанию на адрес следующего перехода (адрес интерфейса GigabitEthernet0/0 роутера R2) ! <strong>access-list 1 permit 192.168.1.0 0.0.0.255</strong> ...</em> |
Для R2 аналогично. Далее уже не буду каждый раз это писать. Подразумевается, что на R2 симметричные настройки.
Кроме этого для защиты со стороны «интернета» на интерфейсах далее будет настроен ACL, в котором разрешены на вход в роутер лишь несколько протоколов. Такой ACL скорее всего понадобится в продакшене, если настроен CBAC-файрвол.
Много букв про IPsec
Да, можно заучить команды, но очень важно понимать нюансы настройки и работы IPsec. А тут их как никогда много. Причём в разных источниках информация об IPsec немного различается. Достаточно таких источников пересмотрел. Скорее всего мой рассказ тоже будет немного отличаться от других. Постараюсь, тем не менее, обращать внимание на важные особенности.
|
1 2 3 |
<em>Про IPsec хорошо и очень подробно рассказывалось в курсе CCNA Security (210-260 IINS). Сейчас этот курс</em> <em>устарел, но к нему как и к другим, есть официальный</em> <em>гайд в формате PDF: CCNA Security 210-260 Official</em> <em>Cert Guide. Найти его несложно.</em> |
IPsec не один протокол, как можно было бы подумать. Это набор протоколов (Framework), работа IPsec — согласованная работа этих протоколов. Набор протоколов в IPsec неоднозначный, нужно выбрать, какие именно протоколы будут использоваться.
С использованием IPsec достигается концепция безопасности CIA Triad: Confidentiality, Integrity, Availability.
- Конфиденциальность данных — никто посторонний не сможет их просмотреть;
- Целостность данных — данные не были изменены при передаче;
- Доступность данных — постороннее лицо не может уничтожить пересылаемые данные или причинить им ущерб.
Кроме этого IPsec обеспечивает Antireplay (все пакеты нумеруются и если пакет уже приходил, то второй пакет с таким же номером будет отброшен).
Рассмотрим используемые протоколы:
IKE
- IKE — Самый центровой протокол в IPsec Framework это IKE (Internet Key Exchange). Остальные протоколы работают под его управлением;
Самое первое, IKE должен быть включен для реализации функционала IPsec. Он включен по умолчанию в IOS, но его можно и отключить:
|
1 2 |
Router(config)# no crypto isakmp enable <em>*Aug 8 10:11:16.283: %CRYPTO-6-ISAKMP_ON_OFF: ISAKMP is OF</em> |
Надо проверить и при необходимости включить:
|
1 2 3 |
Router# show crypto isakmp policy <em>ISAKMP is turned off</em> Router(config)# crypto isakmp enable - <em>эта команда также проверяет поддержку IKE со стороны роутера, если при выполнении возникает ошибка, IOS нужно апгрейдить</em> |
Существует две версии IKE: IKEv1 (RFC 2409) and IKEv2 (RFC 7296), IKEv2 реализован чтобы обойти ограничения IKEv1 и имеет существенные улучшения по сравнению с первой версией:
- EAP (certificate-based authentication);
- Anti-DoS capabilities;
- Needs fewer messages to establish an IPsec SA
Но сегодня рассматриваем только IKEv1, он до сих пор широко используется и не требует какого-то специально оборудования.
Иногда в литературе термины IKE и ISAKMP взаимозаменяемы:
|
1 |
<em>For Cisco platforms, IKE is analogous to ISAKMP, and the two terms are used interchangeably.</em> |
Это не меняет сказанного и никакой путаницы не вносит.
Аутентификация
Данное действо производится перед всеми другими.
Роутер должен подтвердить другому роутеру (и наоборот, то есть для 2 роутеров процедура выполняется 2 раза, сначала в одну, потом в обратную сторону) свою подлинность для участия в IPsec туннеле. Возможности: Общий, вводимый вручную, секретный ключ PSK (Pre Shared Key), Сертификаты RSA. Рекомендуется: Сертификаты RSA.
Аутентификация на основе общего ключа PSK происходит так: к ключу прикладывается определённая несекретная информация, известная и общая для обоих роутеров, высчитывается хеш, отправляется второму роутеру. Второй роутер повторяет процедуру для своего ключа и сравнивает хеши. Совпадение хешей означает совпадение общих ключей и как результат — подлинность, приславшего сообщение роутера. Потом второй роутер повторяет процедуру. В результате оба роутера подтвердили свою подлинность друг-другу.
Аутентификация RSA в рамках данной заметки рассматриваться не будет, поэтому разговора про неё нет. По факту повсеместно используется PSK, он не то чтобы проще, а глобально проще.
Плюс у RSA есть заморочки по поводу времени: мало того что оба роутера должны быть настроены на получение точного времени и время обязательно должно быть синхронизировано уже при загрузке, но ещё есть и связанные баги. Кроме этого настройка самих сертификатов тоже трудоёмкая задача. Возможно, как-нибудь.. выложу статью с примером.
|
1 2 3 4 5 |
R1(config-isakmp)# authentication ? <em>pre-share Pre-Shared Key</em> <em>rsa-encr Rivest-Shamir-Adleman Encryption</em> <em>rsa-sig Rivest-Shamir-Adleman Signature</em> |
Шифрование
Применяется симметричное шифрование, то есть такое, где ключ для шифрования и расшифровки один и тот же. Оно менее устойчиво ко взлому чем ассиметричное, но только симметричное шифрование технически доступно для больших объёмов передаваемых пользовательских данных, так как использует относительно низкую утилизацию CPU устройства. Рекомендуется AES.
|
1 2 3 4 5 |
R1(config-isakmp)# encryption ? <em>3des Three key triple DES</em> <em>aes AES - Advanced Encryption Standard.</em> <em>des DES - Data Encryption Standard (56 bit keys).</em> |
Обмен ключами
Хорошо, роутеры друг друга аутентифицировали, теперь им нужен ключ для шифрования потока данных. Этого ключа нет в конфигурации, он генерируется, как говорится, «налету».
Для создания туннеля обе стороны должны совместно вычислить общий секретный ключ для симметричного шифрования данных в туннеле (не путать с PSK, который нужен для аутентификации). Всё это надо сделать через публичную сеть Интернета. Как это выполнить? На пустом месте, через небезопасную сеть, договорится о ключе для шифрования?
Для этого используется специальный ассиметричный алгоритм Диффи-Хеллмана (DH). Степень защиты при расчёте общего ключа для шифрования определяется группой DH. Рекомендуется: Если в алгоритмах шифрования или аутентификации используется 128-битовый ключ, группа 14, 19, 20 или 24, а для 256-битового ключа группа 21 или 24.
|
1 2 3 4 5 6 7 8 9 10 11 12 |
R1(config-isakmp)# group ? <em>1 Diffie-Hellman group 1 (768 bit)</em> <em>14 Diffie-Hellman group 14 (2048 bit)</em> <em>15 Diffie-Hellman group 15 (3072 bit)</em> <em>16 Diffie-Hellman group 16 (4096 bit)</em> <em>19 Diffie-Hellman group 19 (256 bit ecp)</em> <em>2 Diffie-Hellman group 2 (1024 bit)</em> <em>20 Diffie-Hellman group 20 (384 bit ecp)</em> <em>21 Diffie-Hellman group 21 (521 bit ecp)</em> <em>24 Diffie-Hellman group 24 (2048 bit, 256 bit subgroup)</em> <em>5 Diffie-Hellman group 5 (1536 bit)</em> |
Целостность
Для каждого сообщения вычисляется хеш, который прикладывается к сообщению. Хеш очень короткий, всегда одинаковой длины (определяется алгоритмом), он однозначно определяет исходное сообщение. При получении высчитывается хеш полученного сообщения, он сравнивается с приложенным хешем. Если значения 2 хешей совпадают, значит сообщение не было изменено.
Такой метод уязвим к атаке «человек посередине» (Man-In-The-Middle, MITM): сообщение перехватывается по пути следования, изменяется, прикладывается новый хеш. Для принимающей стороны всё ok. Чтобы этого не могло произойти, применяется технология HMAC (Hash-Based Message Authentication Code): перед созданием хеша к сообщению прикладывается ключ, который есть только у отправляющей и принимающей стороны.
В результате, атакующий после изменения сообщения не сможет вычислить нужный хеш, так как у него нет ключа. А вычислить ключ по исходному сообщению и хешу для сообщение+ключ он тоже не сможет. Точнее, на это нужно время, чем устойчивее алгоритм хеширования, тем больше времени нужно на взлом. Рекомендуется SHA256 и выше.
|
1 2 3 4 5 6 7 |
R1(config-isakmp)# hash ? <em>md5 Message Digest 5</em> <em>sha Secure Hash Standard</em> <em>sha256 Secure Hash Standard 2 (256 bit)</em> <em>sha384 Secure Hash Standard 2 (384 bit)</em> <em>sha512 Secure Hash Standard 2 (512 bit)</em> |
Загрузка CPU
Пару слов: рекомендации это конечно хорошо, но чем сильнее алгоритмы, тем больше накладных расходов на их обсчёт. Туннелей может быть много. Конечно для большого числа туннелей предпочтителен DMVPN, где туннели между спицами поднимаются при наличии трафика. А не полносвязная сеть постоянных IPsec туннель. Но как мы знаем, не всегда всё в продакшене гладко и пушисто.
Кроме непосредственно туннелей на роутере есть и другие сервисы: файрвол (CBAC, ZBF), возможно IOS IPS (не знаю пользует его хоть кто-то или нет, но допустим), возможно NetFlow (оно пригружает прилично), возможно через этот роутер в интернете сидит огромное число народу с помощью NAT, возможно часто идёт несколько потоков видео-конференций. Возможно роутер время от времени атакуют DDoS’ом и на нём нет политики ограничения служебного трафика. Ещё что-то.
Особенно тема актуальна для старых моделей роутеров со слабым CPU. Всё это нужно учитывать и алгоритмы подбирать такие, чтобы они совместно со всем вышеперечисленным не положили роутер. Для этого мониторить загрузку CPU:
|
1 |
R1# show processes cpu history |
При высокой нагрузке алгоритмы брать попроще. В примере буду использовать сильные алгоритмы. В продакшене видел люди не парятся, используют 56-битный DES и MD5. 🙂 Пример реализации, тут рассказанный, он для изучения возможностей IPsec, не калька для продакшена. Это важно.
Настройка IPsec
Существует несколько вариантов настройки IPsec.
Разбираться будем последовательно и начнем с классического варианта Policy Based, основанного на Crypto Map. А во второй части статьи подпихнём туда GRE, Crypto Map при этом остаётся. В таком варианте трафик в туннель отбирается с помощью ACL. Остальные варианты будут рассмотрены далее в других частях статьи.
Порядок следующий:
- Настраиваем фазу 1;
- Задаём PSK;
- Создаём Crypto ACL для отбора интересного трафика;
- Настраиваем фазу 2: Transform Set;
- Создаём Crypto Map, в Crypto Map используем созданные Crypto ACL, Transform Set;
- Затем вешаем Crypto Map на нужный интерфейс;
- Разрешаем входящий трафик ISAKMP, ESP.
Чистый IPsec
«Чистый» — это моё название, официально туннель называется просто IPsec VPN tunnel.
Туннель возможен между CISCO Router, ASA в любом сочетании. Умеют даже самые старые железки, но в разном объёме (IKEv1, IKEv2). Об этом поговорим в следующих частях статей про IPsec.
В CISCO ASA настройки могут быть выполнены через графическое средство — ASDM. Там всё понятно и пошагово, поэтому для определённости будем считать, что туннель пробрасывается между двумя ISRs (Integrated Services Routers). Настройка в этом случае сложнее, ведь она производится через CLI и нужно понимать в каком порядке вводить команды, а также что значит каждая команда.
|
1 |
<strong>Важно</strong>. Недостатком чистого IPsec туннеля является то, что он может передавать <em>только юникастовые</em> пакеты. Мультикаст передаваться не может, это является препятствием для обмена информацией динамическими протоколами маршрутизации. |
Чистый IPsec используется когда проброс информации динамических протоколов маршрутизации и передача потокового видео через туннель не нужны. Такие ситуации бывают редко, поэтому настройка чистого IPsec скорее больше умозрительный пример, чем боевой. Но разобрать настройку обязательно надо, так как это самая основа основ. Именно из этой настройки растёт понимание IPsec в целом.
Необходимые понятия
- ISAKMP — Реализация IKE для первой фазы (Security Association and Key Management Protocol);
- SA — В ходе фазы 1 и фазы 2 роутеры обмениваются и утверждают набор параметров IPsec Framework: хеширование, шифрование и так далее. Каждый набор или коллекция и есть SA (Security Association).
Для создания IPsec туннеля требуется 2 SA: для первой и для второй фазы. На роутере уже есть предустановленные SA, но пользоваться ими не рекомендуется (по крайней мере предустановленные SA 1 фазы используют устаревшие, нестойкие алгоритмы).
Для успешного поднятия туннеля параметры SA на одном роутере должны полностью совпадать с параметрами SA на другом роутере (для каждой фазы). Роутеры будут перебирать имеющиеся SA пока не подберут совпадающие.
Фазы IPsec
Процесс установки IPsec VPN туннеля состоит из 2ух последовательных стадий-фаз (Phases):
- IKE Phase 1 — Создаётся 1 двунаправленный туннель, необходимый для согласования Phase 2. По этому туннелю передаётся только управляющая информация (are used to carry control plane and data plane traffic for IPsec), пользовательские данные не передаются. Называется ISAKMP туннель;
- IKE Phase 2 — С помощью туннеля фазы 1 создаются дополнительно ещё 2 однонаправленных туннеля, от первого роутера ко второму и от второго к первому, по которым передаётся пользовательская информация. Туннели второй фазы и есть то, что называется IPsec туннель.
Это сильно упрощённая история. На самом деле не совсем однонаправленные. И туннелей второй фазы может быть много. Но для простоты понимания лучше так. Главное запомнить что SA второй фазы имеют направление.
Важно отметить, что туннель не поднимается сразу после выполнения настроек. Согласования фазы 1, затем 2 начинается после того, как на роутер попадают данные, предназначенные для туннеля ( «интересный» трафик). Данные эти отбираются с помощью ACL (называется Crypto ACL, хотя по факту это самый обычный ACL).
Также важно то, что туннель не существует сколь угодно долго после создания, у него есть время жизни (Lifetime). После истечения Lifetime туннель гасится и пересоздаётся снова (с помощью фаз 1 и 2, при наличии интересного трафика). Если интересного трафика нет, туннель лежит, но постоянно готов к созданию сразу при появлении такого трафика.
Lifetime выбирается достаточно большим, чтобы туннель слишком часто не пересоздавался. И достаточно маленьким, чтобы туннель не был взломан. При использовании стойких ко взлому алгоритмов актуальность малого Lifetime туннеля снижается.
|
1 2 3 |
R1(config-isakmp)# lifetime ? <em><60-86400> lifetime in seconds</em> |
Встречал в разных материалах, что по истечении Lifetime «обновляются ключи шифрования», открываю официальный гайд, о котором сказано в начале статьи:
Впрочем, никто мне не мешает проверить (будет далее).
Фаза 1
Начинаем настраивать SA первой фазы. Создаётся политика ISAKMP. HAGLE — удобная мнемоника для запоминания этой SA:
- Hash — хеширование SHA256;
- Autentification — аутентификация PSK;
- Group — группа DH 21;
- Lifetime — время жизни туннеля 3600 (по умолчанию 1 день = 86400);
- Encryption — шифрование AES 256 (по умолчанию для AES значение 128).
Как уже говорилось параметры SA для обоих роутеров должны совпадать. Исключение составляет параметр Lifetime: если он не совпадает, то взят будет наименьший.
|
1 2 3 4 5 6 7 8 9 10 11 12 13 |
R1(config)# crypto isakmp policy <strong>3</strong> R1(config-isakmp)# hash sha256 R1(config-isakmp)# authentication pre-share R1(config-isakmp)# group 21 R1(config-isakmp)# lifetime 3600 R1(config-isakmp)# encryption aes 256 R2(config)# crypto isakmp policy <strong>3</strong> R2(config-isakmp)# hash sha256 R2(config-isakmp)# authentication pre-share R2(config-isakmp)# group 21 R2(config-isakmp)# lifetime 3600 R2(config-isakmp)# encryption aes 256 |
Важно отметить, что номер политики означает приоритет её использования:
|
1 2 3 |
R1(config)# crypto isakmp policy ? <em><1-10000> Priority of protection suite</em> |
Использовал номер 3, приоритет третий, но поскольку политики с номерами 1 и 2 не определены, то наша третья будет использоваться первой. Также необязательно чтобы номера политик с двух сторон совпадали.
Дефолтные SA первой фазы
Посмотрим их:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 |
R1# show crypto isakmp default policy <em>Default IKE policy</em> <strong><em>Default protection suite of priority 65507</em></strong> <em>encryption algorithm: AES - Advanced Encryption Standard (128 bit keys).</em> <em>hash algorithm: Secure Hash Standard</em> <em>authentication method: Rivest-Shamir-Adleman Signature</em> <em>Diffie-Hellman group: #5 (1536 bit)</em> <em>lifetime: 86400 seconds, no volume limit</em> <strong><em>Default protection suite of priority 65508</em></strong> <em>encryption algorithm: AES - Advanced Encryption Standard (128 bit keys).</em> <em>hash algorithm: Secure Hash Standard</em> <em>authentication method: Pre-Shared Key</em> <em>Diffie-Hellman group: #5 (1536 bit)</em> <em>lifetime: 86400 seconds, no volume limit</em> <strong><em>Default protection suite of priority 65509</em></strong> <em>encryption algorithm: AES - Advanced Encryption Standard (128 bit keys).</em> <em>hash algorithm: Message Digest 5</em> <em>authentication method: Rivest-Shamir-Adleman Signature</em> <em>Diffie-Hellman group: #5 (1536 bit)</em> <em>lifetime: 86400 seconds, no volume limit</em> <strong><em>Default protection suite of priority 65510</em></strong> <em>encryption algorithm: AES - Advanced Encryption Standard (128 bit keys).</em> <em>hash algorithm: Message Digest 5</em> <em>authentication method: Pre-Shared Key</em> <em>Diffie-Hellman group: #5 (1536 bit)</em> <em>lifetime: 86400 seconds, no volume limit</em> <strong><em>Default protection suite of priority 65511</em></strong> <em>encryption algorithm: Three key triple DES</em> <em>hash algorithm: Secure Hash Standard</em> <em>authentication method: Rivest-Shamir-Adleman Signature</em> <em>Diffie-Hellman group: #2 (1024 bit)</em> <em>lifetime: 86400 seconds, no volume limit</em> <strong><em>Default protection suite of priority 65512</em></strong> <em>encryption algorithm: Three key triple DES</em> <em>hash algorithm: Secure Hash Standard</em> <em>authentication method: Pre-Shared Key</em> <em>Diffie-Hellman group: #2 (1024 bit)</em> <em>lifetime: 86400 seconds, no volume limit</em> <strong><em>Default protection suite of priority 65513</em></strong> <em>encryption algorithm: Three key triple DES</em> <em>hash algorithm: Message Digest 5</em> <em>authentication method: Rivest-Shamir-Adleman Signature</em> <em>Diffie-Hellman group: #2 (1024 bit)</em> <em>lifetime: 86400 seconds, no volume limit</em> <strong><em>Default protection suite of priority 65514</em></strong> <em>encryption algorithm: Three key triple DES</em> <em>hash algorithm: Message Digest 5</em> <em>authentication method: Pre-Shared Key</em> <em>Diffie-Hellman group: #2 (1024 bit)</em> <em>lifetime: 86400 seconds, no volume limit</em> R1# |
Их 8, начиная с самой устойчивой, затем постепенно устойчивость ко взлому снижается. При отсутствии вручную заданной SA первой фазы роутер попытается использовать дефолтные SA в порядке приоритетов (номеров). Сначала саму стойкую 65507, согласование окончилось ошибкой, тогда 65508. И так далее.
PSK
Указывается ключ PSK и IP роутера с другой стороны туннеля (IP пира):
|
1 2 3 |
R1(config)# crypto isakmp key <strong>IPsecVPNtunnel</strong> address 10.10.10.2 R2(config)# crypto isakmp key <strong>IPsecVPNtunnel</strong> address 10.10.10.1 |
Формат команды тут:
|
1 |
<strong>crypto isakmp key</strong> <em>keystring</em> <strong>address</strong> <em>peer-address [mask]</em> |
Значение для адреса 0.0.0.0 0.0.0.0 может быть использовано чтобы матчить с любым пиром.
Crypto ACL
Самый обычный ACL, нам нужно отобрать трафик с PC1 на PC2 для R1 и с PC2 на PC1 для R2:
|
1 2 3 |
R1(config)# access-list 101 permit ip 192.168.1.0 0.0.0.255 192.168.2.0 0.0.0.255 R2(config)# access-list 101 permit ip 192.168.2.0 0.0.0.255 192.168.1.0 0.0.0.255 |
Этот ACL ничего не разрешает и ничего не запрещает, у него другие функции. Он только для отбора трафика. Трафик, который удовлетворяет строкам permit (у нас тут одна строка), будет зашифрован и передан через туннель. А трафик, который удовлетворяет строкам deny (у нас неявный запрет в конце списка), будет передан как обычно.
Неплохо будет добавить пояснение что это за ACL, повышает читаемость конфигурации:
|
1 |
<em>remark ACL identifies interesting traffic for IPsec tunnel</em> |
Фаза 2
SA второй фазы несколько отличается от первой. IPsec может использовать протокол AH или протокол ESP:
- AH — Authentication Header, IP протокол 51, обеспечивает аутентификацию и целостность данных, но не поддерживает шифрование и обход NAT (NAT-T), поэтому в реальной жизни его ценность минимальна;
- ESP — Encapsulation Security Protocol, IP протокол 50, обеспечивает аутентификацию, целостность данных и шифрование, поддерживает NAT-T. Для туннеля через Интернет интересен только этот протокол.
IPsec работает или в туннельном режиме, или в транспортном режиме:
- Туннельный режим — добавляется новый IP заголовок, исходный пакет полностью упаковывается, используется при создании туннеля между роутерами (site-to-site). Для нас подходит только этот режим;
- Транспортный режим — используется IP заголовок исходного пакета, применяется или при подключении клиентов к серверу (VPN client), или когда уже есть сетевая доступность между устройствами (GRE over IPsec).
Transform Set
Настраиваем набор алгоритмов для фазы 2:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 |
R1(config)# crypto IPsec transform-set R1-R2 ? <em>ah-md5-hmac AH-HMAC-MD5 transform</em> <em>ah-sha-hmac AH-HMAC-SHA transform</em> <em>ah-sha256-hmac AH-HMAC-SHA256 transform</em> <em>ah-sha384-hmac AH-HMAC-SHA384 transform</em> <em>ah-sha512-hmac AH-HMAC-SHA512 transform</em> <em>comp-lzs IP Compression using the LZS compression algorithm</em> <em>esp-3des ESP transform using 3DES(EDE) cipher (168 bits)</em> <em>esp-aes ESP transform using AES cipher</em> <em>esp-des ESP transform using DES cipher (56 bits)</em> <em>esp-gcm ESP transform using GCM cipher</em> <em>esp-gmac ESP transform using GMAC cipher</em> <em>esp-md5-hmac ESP transform using HMAC-MD5 auth</em> <em>esp-null ESP transform w/o cipher</em> <em>esp-seal ESP transform using SEAL cipher (160 bits)</em> <em>esp-sha-hmac ESP transform using HMAC-SHA auth</em> <em>esp-sha256-hmac ESP transform using HMAC-SHA256 auth</em> <em>esp-sha384-hmac ESP transform using HMAC-SHA384 auth</em> <em>esp-sha512-hmac ESP transform using HMAC-SHA512 auth</em> |
Здесь R1-R2 имя набора, оно будет далее использоваться в Crypto MAP и выбирать его нужно таким, чтобы потом не запутаться, то есть одинаковым для обоих роутеров. Выбираем далее esp-aes 256:
|
1 2 3 4 5 |
R1(config)# crypto IPsec transform-set R1-R2 esp-aes ? <em>128 128 bit keys. — по умолчанию</em> <em>192 192 bit keys.</em> <em>256 256 bit keys.</em> |
И esp-sha256-hmac, туннельный режим:
|
1 2 3 |
R1(config)# crypto IPsec transform-set R1-R2 esp-aes 256 esp-sha256-hmac R2(config)# crypto IPsec transform-set R1-R2 esp-aes 256 esp-sha256-hmac |
Поскольку туннельный режим идёт по умолчанию, то вводить команду mode tunnel для сета не нужно (она добавится автоматически).
Ещё тут можно настроить дополнительные параметры IPsec SA:
|
1 2 3 4 5 6 7 8 9 10 11 |
Router(config)# crypto ipsec security-association ? <em>dummy Enable transmitting dummy packets ecn Handling of ECN bit idle-time Automatically delete IPSec SAs after a given idle period. <span class="has-inline-color">lifetime security association lifetime</span> replay Set replay checking.</em> Router(config)# crypto ipsec security-association lifetime seconds ? <em><120-2592000> Security association duration in seconds</em> |
Выделено цветом глобально заданное время жизни для SA второй фазы. Это значение можно переопределить в Crypto Map. Дополнительные параметры оставляю по умолчанию.
Дефолтный SA второй фазы
Смотрим:
|
1 2 3 4 5 6 7 |
R1# show crypto IPsec transform-set <em><strong>Transform set default</strong>: { esp-aes esp-sha-hmac }</em> <em>will negotiate = { <strong>Transport</strong>, },</em> <em>Transform set R1-R2: { esp-256-aes esp-sha256-hmac }</em> <em>will negotiate = { Tunnel, },</em> |
Единственный дефолтный сет имеет транспортный режим. Он в нашем туннеле не заработает, поэтому SA второй фазы нужно обязательно набивать руками.
Crypto Map
Создаётся Crypto Map, которая вещается на внешний интерфейс в сторону пира. Crypto Map ассоциирует интересный трафик с настройками IKE/IPsec. Трафик исключается из глобальной маршрутизации и принудительно «засовывается» в туннель.
Указывается имя, номер:
|
1 2 3 4 |
R1(config)# crypto map R1-R2-MAP ? <em><strong><1-65535> Sequence to insert into crypto map entry</strong></em> ... |
Номер имеет важное значение. На 1 интерфейс можно повесить только 1 мапу. А как быть если нужно к этому интерфейсу привязать 2, 3.. туннеля? Мапа обычно состоит из нескольких последовательных правил (как и ACL), у каждого правила свой номер. Каждое правило с новым номером и будет соответствовать новому туннелю.Таким образом, теоретически на 1 интерфейс можно повесить 65535 туннелей. В нашей Crypto Map 1 правило.
Тут небольшое лирическое отступление. А вообще сколько туннелей норма при вот таком режиме IPsec, как сейчас разбирается, чтобы полносвязное соединение было (всё на всё)? Два пира — всего 1 туннель (1 на роутер), 3 пира — всего 3 туннеля (2 на роутер), 4 пира — уже 6 туннелей (3 на роутер).. Моё скромное мнение: 1-3 пира, используем IPsec туннели, 4 и более, используем DMVPN. Тут конечно есть варианты, но 4-5-6.. пиров это хорошая причина задуматься о переходе на DMVPN.
Продолжаем:
|
1 2 3 |
R1(config)# crypto map R1-R2-MAP 1 ipsec-isakmp <em>% NOTE: This new crypto map will remain disabled until a <strong>peer</strong> and a <strong>valid access list</strong> have been configured.</em> |
В явном вид говорится, что мапа останется неактивной пока не будет добавлен пир и валидный Crypto ACL для отбора трафика.
|
1 2 3 4 5 6 7 8 9 |
... R1(config-crypto-map)# match address 101 R1(config-crypto-map)# set transform-set R1-R2 R1(config-crypto-map)# set peer 10.10.10.2 R2(config)# crypto map R1-R2-MAP 1 IPsec-isakmp R2(config-crypto-map)# match address 101 R2(config-crypto-map)# set transform-set R1-R2 R2(config-crypto-map)# set peer 10.10.10.1 |
Привязываем ACL, сет алгоритмов и адрес удалённого роутера. Тут строку set peer можно повторить несколько раз, чтобы указать несколько возможных значений. Предпочитаемый пир можно обозначить параметром default после IP адреса.
Команда для трансформ сет имеет формат:
|
1 |
<strong>set transform-set</strong> <em>transform-set-name1 [transform-setname2…transform-set-name6]</em> |
Можно указать несколько сетов, они будут перебираться согласно своего порядка, пока один из них не сматчит и туннель не установится.
Дополнительные возможности Crypto Map
|
1 |
R1(config-crypto-map)# set pfs group24 |
При согласовании фазы 2 будет ещё раз выполнен алгоритм Диффи-Хеллмана для создания нового симметричного ключа шифрования. В результате у туннелей второй фазы будет собственный ключ шифрования, иначе используется ключ из первой фазы.
|
1 2 3 4 5 |
R1(config-crypto-map)# set security-association lifetime ? <em>days Time-based key duration in days</em> <em>kilobytes Volume-based key duration</em> <em><span class="has-inline-color">seconds Time-based key duration in seconds</span></em> |
Для второй фазы можно задать отдельное время жизни в днях, килобайтах или секундах, иначе вторая фаза будет проходить (после первой, разумеется) при истечении Lifetime первой фазы и пересоздании туннеля. Заданное тут значение заменяет глобальную настройку для этой конкретной мапы.
|
1 2 |
... R1(config-crypto-map)# set security-association lifetime seconds 900 |
Интересный момент: при истечении времени жизни туннеля второй фазы, его пересоздание с обновлением ключей происходит бесшовно, то есть никаких перерывов в работе туннеля и никакой потери трафика нет.
Добавление Crypto Map на интерфейс
Добавляем мапу к интерфейсу, никаких ошибок быть не должно:
|
1 2 3 4 5 6 7 8 |
R1(config)# interface GigabitEthernet 0/0 R1(config-if)# crypto map R1-R2-MAP R1(config-if)# end <strong><em>*Aug 12 17:02:14.382: %CRYPTO-6-ISAKMP_ON_OFF: ISAKMP is ON </em></strong>R2(config)# interface GigabitEthernet 0/0 R2(config-if)# crypto map R1-R2-MAP |
Если после вылезли вот такие ошибки:
|
1 2 3 4 5 6 |
R1(config-if)# crypto map R1-R2-MAP <em>*Aug 15 09:35:39.216: <strong>IPsec: Expand action denied, discard or forward packet</strong>.</em> <em>...</em> <em>*Aug 15 09:35:39.218: IPsec: Expand action denied, discard or forward packet.</em> <em>*Aug 15 09:35:39.225: %CRYPTO-6-ISAKMP_ON_OFF: ISAKMP is ON</em> |
То тут 2 варианта: сам что-то накосячил или глюк vIOS при полностью правильных настройках. В первом случае работать скорее не будет, во втором случае работает нормально, проверял.
Важный момент: чтобы Crypto Map отработала, пакет должен попасть на интерфейс, где мапа висит. У нас это достигается маршрутом по умолчанию:
|
1 |
ip route 0.0.0.0 0.0.0.0 10.10.10.2 |
Если бы не было этого маршрута, то пакет от 192.168.1.2 к 192.168.2.2 был бы отброшен. Мапа сама его не подтянет. Попаданий в Crypto ACL пакетов не будет, туннель не поднимется.
Ещё важный момент: Crypto Map имеет направление, то есть действует только на исходящий (outbound) трафик:
|
1 2 3 4 |
<em>The crypto map is a big "if-then" statement. It is applied to the outside (Internet facing) interface, and then it watches for traffic. If outbound traffic matches the ACL, then the router knows the packet</em> <em>should be encrypted, encapsulated into an IPsec header (usually protocol 50, which is ESP and stands for Encapsulating Security Payload), and then sent to the IP address of the peer on the other side </em>Omar Santos, John Stuppi - CCNA Security 210-260 Official Cert Guide |
Изменение NAT
В том виде как он есть, NAT не даст работать туннелю. Пакеты будут просто проваливаться в него и всё. Нужно исключить пакеты для туннеля из NAT:
|
1 2 3 4 5 |
R1(config)# no ip nat inside source list 1 interface GigabitEthernet0/0 overload R1(config)# no access-list 1 R1(config)# ip nat inside source list 100 interface GigabitEthernet0/0 overload R1(config)# access-list 100 <strong>deny ip 192.168.1.0 0.0.0.255 192.168.2.0 0.0.0.255</strong> R1(config)# access-list 100 permit ip 192.168.1.0 0.0.0.255 any |
Ещё раз краткий алгоритм работы IPsec:
Разрешение трафика ISAKMP и ESP
Последний момент в настройке IPsec. Туннель настраивается всегда на граничных роутерах, Crypto Map вешается на интерфейс, смотрящий в Интернет. Но такой роутер защищён от нежелательного входящего со стороны интернет-трафика (CBAC firewall, ACL). А нам надо чтобы прошло согласование 2 фаз IKE. Поэтому нужно в явном виде «пропилить дырки» для входящего трафика IKE и ESP:
|
1 2 3 |
R1(config)# ip access-list extended firewall_acl R1(config-ext-nacl)# permit <strong>udp</strong> host 10.10.10.2 host 10.10.10.1 <strong>eq isakmp</strong> R1(config-ext-nacl)# permit <strong>esp</strong> host 10.10.10.2 host 10.10.10.1 |
На всякий пожарный ещё раз: ISAKMP это UDP порт 500, ESP это IP протокол 50.
Разрешение ICMP
И даже такой ACL недостаточен для нормальной работы. Туда нужно много чего добавить (как минимум SSH). Добавим правило чтобы проходил пинг:
|
1 2 |
R1(config-ext-nacl)# permit icmp any host 10.10.10.1 echo R1(config-ext-nacl)# permit icmp any host 10.10.10.1 echo-replay |
И «лепим» этот ACL на внешний интерфейс во входящем направлении:
|
1 2 |
R1(config)# interface GigabitEthernet 0/0 R1(config-if)# ip access-group firewall_acl <strong>in</strong> |
Кроме CBAC может быть Zone Based Firewall (ZBF), там ACL не используется, а для трафик разрешается правилами для пары зон. Про ZBF как-нибудь выложу отдельную статью.
Проверка IPsec
Сначала посмотрим чего понастраивали:
|
1 2 3 4 5 6 7 8 9 |
R1# show crypto isakmp policy <em>Global IKE policy</em> <em>Protection suite of priority 3</em> <em> encryption algorithm: AES - Advanced Encryption Standard (256 bit keys).</em> <em> hash algorithm: Secure Hash Standard 2 (256 bit)</em> <em> authentication method: Pre-Shared Key</em> <em> Diffie-Hellman group: #21 (521 bit)</em> <em> lifetime: 3600 seconds, no volume limit</em> |
Сет уже просмотрели, когда выводилась инфа о дефолтном сете. Смотрим мапу:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 |
R1# show crypto map <em> Interfaces using crypto map <strong>NiStTeSt1</strong>:</em> <em>Crypto Map IPv4 "R1-R2-MAP" 1 IPsec-isakmp</em> <em> Peer = 10.10.10.2</em> <em> Extended IP access list 101</em> <em> access-list 101 permit ip 192.168.1.0 0.0.0.255 192.168.2.0 0.0.0.255</em> <em> Current peer: 10.10.10.2</em> <em> Security association lifetime: 4608000 kilobytes/900 seconds</em> <em> Responder-Only (Y/N): N</em> <em> PFS (Y/N): Y</em> <em> DH group: group24</em> <em> Mixed-mode : Disabled</em> <em> Transform sets={</em> <em> R1-R2: { esp-256-aes esp-sha256-hmac } ,</em> <em> }</em> <em> Interfaces using crypto map R1-R2-MAP:</em> <em> GigabitEthernet0/0</em> |
А что это такое? Что за NiStTeSt1? Это баг данной версии IOS (требуется регистрация, нет если учётной записи в CISCO, то пора создать). Смотреть состояние SAs рано, там всё пусто и по нулям.
Тест туннеля
Для начала включим дебаг:
|
1 2 3 |
R1# debug crypto isakmp <em>— так же полезная команда debug crypto IPsec</em> <em>Crypto ISAKMP debugging is on</em> |
Запустим трафик с PC1 на PC2, например пинг:
|
1 2 3 4 5 6 |
PC1> ping 192.168.2.2 <strong><em>192.168.2.2 icmp_seq=1 timeout</em></strong> <em>84 bytes from 192.168.2.2 icmp_seq=2 ttl=62 time=15.281 ms</em> <em>84 bytes from 192.168.2.2 icmp_seq=3 ttl=62 time=5.101 ms</em> <i>...</i> |
Первый пинг пропадает, так как нужно время для поднятия туннеля. Вывод дебага огромен, приводить нет смысла. Тут надо только отметить, что фаза 1 согласовывается в основном режиме (Main mode, MM) или в агрессивном (Aggressive mode, AM). По умолчанию основной режим, агрессивный чуть быстрее (MM 6 сообщений, AM 3 сообщения), непринципиально чтобы заморачиваться на выяснение его настройки:
|
1 2 3 |
<em>*Aug 15 22:30:53.733: ISAKMP: (0):<strong>Can not start Aggressive mode, trying Main mode.</strong></em> <em>...</em> <em>*Aug 15 22:30:53.735: ISAKMP: (0):<strong>beginning Main Mode exchange</strong></em> |
Посмотрим 1 SA:
|
1 2 3 4 5 6 7 |
R1# show crypto isakmp sa <em>IPv4 Crypto ISAKMP SA</em> <em>dst src state conn-id status</em> <em>10.10.10.2 10.10.10.1 QM_IDLE 1001 <strong>ACTIVE</strong></em> <em>IPv6 Crypto ISAKMP SA</em> |
Смотрим 2 SA:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 |
R1# show crypto IPsec sa <em>interface: GigabitEthernet0/0</em> <em>Crypto map tag: R1-R2-MAP, local addr 10.10.10.1</em> <em>protected vrf: (none)</em> <span class="has-inline-color"><em>local ident (addr/mask/prot/port): (192.168.1.0/255.255.255.0/0/0)</em> <em>remote ident (addr/mask/prot/port): (192.168.2.0/255.255.255.0/0/0)</em></span> <em>current_peer 10.10.10.2 port 500</em> <em>PERMIT, flags={origin_is_acl,}</em> <em><strong># pkts encaps: 4, # pkts encrypt: 4, # pkts digest: 4</strong></em> <em><strong># pkts decaps: 4, # pkts decrypt: 4, # pkts verify: 4</strong></em> <em># pkts compressed: 0, # pkts decompressed: 0</em> <em># pkts not compressed: 0, # pkts compr. failed: 0</em> <em># pkts not decompressed: 0, # pkts decompress failed: 0</em> <em># send errors 0, # recv errors 0</em> <em>local crypto endpt.: 10.10.10.1, remote crypto endpt.: 10.10.10.2</em> <em>plaintext mtu 1438, path mtu 1500, ip mtu 1500, ip mtu idb GigabitEthernet0/0</em> <em>current outbound spi: 0x2A87F66D(713553517)</em> <em><strong>PFS (Y/N): Y, DH group: group24 </strong></em>... |
Тут надо заметить что эта команда выводит результат для каждой строчки (ACE) из Crypto ACL. Поскольку у нас 1 ACE, вывод такой, было бы 2 ACE, вывод был бы в два раза длиннее. По результатам: пакеты бегают, PFS работает. Также полезная команда show crypto session [ brief | detail ].
Теперь посмотрим на передаваемые пакеты с помощью WareShark:
Нагрузка зашифрована, всё в порядке.
К вопросу о Lifetime
Самому даже интересно. Никто не мешает мне мучить виртуальные (реальные тоже) железки, вводить правильные и неправильные параметры, как захочу. Сделаем время жизни 60 секунд (возможный минимум), дебаг включён, запускаем инициализацию туннеля по пингу (5 пакетов) и ждём 1 минуту:
|
1 2 3 4 5 |
<em>... *Aug 16 20:06:56.855: ISAKMP: (1001):processing <strong>DELETE_WITH_REASON payload</strong>, mess age ID = 62935538, reason: Unknown delete reason!</em> <em>*Aug 16 20:06:56.855: ISAKMP: (1001):peer does not do paranoid keepalives.</em> <em>*Aug 16 20:06:56.855: ISAKMP: (1001):<strong>deleting SA reason "IKE SA Lifetime Exceeded"</strong> state (I) QM_IDLE (peer 10.10.10.2) </em>... |
Смотрим SA:
|
1 2 3 4 5 6 |
R1# show crypto isakmp sa <em>IPv4 Crypto ISAKMP SA</em> <em>dst src state conn-id status</em> <em>IPv6 Crypto ISAKMP SA</em> |
Нету туннеля. Вопрос закрыт. Полные конфы R1 и R2.
Crypto Isakmp Keepalive
При вводе в глобальной конфигурации команды crypto isakmp keepalive sec, роутеры начинают обмениваться сообщениями IKE Keepalive. По умолчанию данная функция выключена, sec — время между сообщениями.
Никогда на CISCO такой командой не пользовался. Почему? Потому что в чистом виде IPsec малоинтересен, интересен GRE over IPsec. А там более продвинутая возможность GRE Keepalive (будет ниже).
С GRE Keepalive есть свои нюансы, о них расскажу в следующих частях статей про IPsec. Да, crypto isakmp keepalive используется на S-Terra, об этом говорил в этой статье. Для наших роутеров получится примерно так:
|
1 2 3 |
R1(config)# crypto isakmp keepalive 15 R2(config)# crypto isakmp keepalive 15 |
GRE over IPsec
Вторая часть статьи, в ней мы перенастроим чистый IPsec с помощью GRE. Такой вариант вполне уже можно использовать в продакшене.
Смысл туннеля, пакеты GRE зашифрованы IPsec. Поскольку сам GRE (Generic Routing Encapsulation) передаётся в виде юникастовых пакетов, то его возможно помещать внутрь IPsec (точнее внутрь ESP). Таким образом GRE over IPsec решает проблему как GRE (шифрование), так и IPsec (поддержка мультикаста). Подробнее о GRE и чем он хорош.
Схема подключения та же самая. Роутеры в начальной конфигурации (без IPsec туннелей, всё, что настраивалось в 1 части статьи — этого нет).
Настройка GRE over IPsec
Чтобы всё было понятно, нужно разобрать теорию первой части статьи.
GRE туннель
Сначала настраиваем GRE туннель:
|
1 2 3 4 5 6 7 8 9 |
R1(config)# interface tunnel 1 R1(config-if)# ip address 10.10.100.1 255.255.255.252 R1(config-if)# tunnel source GigabitEthernet 0/0 R1(config-if)# tunnel destination 10.10.10.2 R2(config)# interface tunnel 1 R2(config-if)# ip address 10.10.100.2 255.255.255.252 R2(config-if)# tunnel source GigabitEthernet 0/0 R2(config-if)# tunnel destination 10.10.10.1 |
Делаем маршрут, чтобы трафик в удалённую подсеть заворачивал в туннель:
|
1 2 3 |
R1(config)# ip route 192.168.2.0 255.255.255.0 10.10.100.2 R2(config)# ip route 192.168.1.0 255.255.255.0 10.10.100.1 |
Проверяем работу GRE:
|
1 2 3 4 5 6 |
R1# ping 10.10.100.2 <em>Type escape sequence to abort.</em> <em>Sending 5, 100-byte ICMP Echos to 10.10.100.2, timeout is 2 seconds:</em> <strong><em>!!!!!</em></strong> <em>Success rate is 100 percent (5/5), round-trip min/avg/max = 2/3/6 ms</em> |
NAT в данном случае не мешает работе туннеля, проверяем:
|
1 2 3 4 |
PC1> ping 192.168.2.2 <em>84 bytes from 192.168.2.2 icmp_seq=1 ttl=62 time=9.278 ms</em> <em>...</em> |
Почему это так чуть далее.
Просмотр через WireShark
Если просмотреть пинги со 192.168.1.2 на 192.168.2.2, то видно, что пакет ICMP запакован в пакет GRE, 2 IP заголовка (выделено рамкой): внешний IP заголовок GRE пакета и IP заголовок инкапсулированной нагрузки. Прошу обратить внимание (подчёркнуто), что IP адрес отправителя и получателя для пакета GRE это IP адреса физических интерфейсов GigabitEthernet 0/0 роутеров. Возможно очевидно, но сам по себе это важный факт.
В первом IP заголовке: протокол GRE, IP 47:
Добавляем IPsec
Теперь добавим IPsec:
|
1 2 3 4 5 6 |
R1(config)# crypto isakmp policy <strong>3</strong> R1(config-isakmp)# hash sha256 R1(config-isakmp)# authentication pre-share R1(config-isakmp)# group 21 R1(config-isakmp)# lifetime 3600 R1(config-isakmp)# encryption aes 256 |
Далее PSK:
|
1 |
R1(config)# crypto isakmp key <strong>IPsecVPNtunnel</strong> address 10.10.10.2 |
Список управления доступом: отбираем трафик GRE, идущий в туннель:
|
1 |
R1(config)# access-list 101 permit <strong>gre</strong> host <strong>10.10.10.1</strong> host <strong>10.10.10.2</strong> |
Как уже подчёркивал выше, IP заголовок GRE использует не IP адреса туннеля с двух сторон, а IP адреса физических интерфейсов двух роутеров. Поэтому такой ACL.
Сокращение накладных расходов
Чем меньше будет служебных заголовков, тем больше места под полезную нагрузку.
| Tunnel Type | Tunnel Header Size |
|---|---|
| GRE without IPsec | 24 bytes |
| DES/3DES IPsec (transport mode) | 18–25 bytes |
| DES/3DES IPsec (tunnel mode) | 38–45 bytes |
| GRE + DES/3DES | 42–49 bytes |
| GRE + AES + SHA-1 | 62–77 bytes |
Тут у нас есть две возможности:
- Зашифровать весь пакет, добавив новый IP заголовок;
- Зашифровать только нагрузку (это у нас GRE и всё, что в него инкапсулировано), оставив IP заголовок от GRE. После шифрования нагрузки в этом заголовке поменяется номер протокола с 47 (GRE) на 50 (ESP).
Только второй вариант используется в продакшене, нет смысла засовывать туннель (он уже есть), в ещё 1 туннель, повышая накладные расходы. Поэтому транспортный режим дефолтного сета то, что нужно. Берём дефолтный сет. Но можно конечно создать и свой сет. Как создать трансформ сет показал выше, тут хочу продемонстрировать возможности дефолтного сета. Теперь мапа:
|
1 2 3 |
R1(config)# crypto map R1-R2-MAP 1 IPsec-isakmp R1(config-crypto-map)# match address 101 R1(config-crypto-map)# set peer 10.10.10.2 |
А где сет? Дело в том, что привязка Transform Set не является обязательной для Crypto Map:
|
1 |
<em>% NOTE: This new crypto map will remain disabled until a <strong>peer</strong> and a <strong>valid access list</strong> have been configured.</em> |
Достаточно пира и ACL. Как раз не привязывая сет мы даём понять, что хотим использовать дефолтный сет. Если пир или ACL не указан для мапы, то она имеет следующий вид в конфигурации:
|
1 2 3 4 5 |
<em>crypto map R1-R2-MAP 1 IPsec-isakmp</em> <strong><em>! Incomplete</em></strong> <em>set peer 10.10.10.2</em> <strong><em>! access-list has not been configured yet</em></strong> <em>match address 101</em> |
Дополнительные возможности мапы использовать не будем. Вешаем мапу на интерфейс:
|
1 2 |
R1(config)# interface GigabitEthernet 0/0 R1(config-if)# crypto map R1-R2-MAP |
Обработка пакета
Резонный вопрос: а почему интерфейс для мапы GigabitEthernet 0/0, а не Tunnel 1? Во-первых, можно вешать только определённые мапы на туннельный интерфейс:
|
1 2 3 4 5 |
R2(config)# interface Tunnel1 R2(config-if)# crypto map R1-R2-MAP <em>% NOTE: crypto map is configured on tunnel interface.</em> <em>Currently <strong>only GDOI crypto map is supported on tunnel interface</strong>.</em> |
Во-вторых, потому что Tunnel 1 это логический интерфейс, который занимается упаковкой обычного IP пакета в пакет GRE, а далее пакет GRE пересылается уже через физический интерфейс. Этот интерфейс GigabitEthernet 0/0. Там мы этот пакет мы и ловим мапой.
На логический интерфейс можно повесить для тех же целей IPsec Profile, так делается, допустим, в DMVPN (применение IPsec Profile за рамками этой статьи).
Тут чуть подробнее, так как это важно. Рассмотрим классическую схему с рекурсивным просмотром таблицы маршрутизации. Пакет от 192.168.1.2 к 192.168.2.2 отправляется компьютером PC1 сначала на шлюз по умолчанию 192.168.1.1. Это наш роутер R1. Роутер начинает просматривать таблицу маршрутизации:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 |
R1# show ip route <em>Gateway of last resort is 10.10.10.2 to network 0.0.0.0</em> <em>S* 0.0.0.0/0 [1/0] via 10.10.10.2</em> <em>10.0.0.0/8 is variably subnetted, 4 subnets, 2 masks</em> <em>C 10.10.10.0/30 is directly connected, GigabitEthernet0/0</em> <em>L 10.10.10.1/32 is directly connected, GigabitEthernet0/0</em> <em>C 10.10.100.0/30 is directly connected, Tunnel1</em> <em>L 10.10.100.1/32 is directly connected, Tunnel1</em> <em>192.168.1.0/24 is variably subnetted, 2 subnets, 2 masks</em> <em>C 192.168.1.0/24 is directly connected, GigabitEthernet0/1</em> <em>L 192.168.1.1/32 is directly connected, GigabitEthernet0/1</em> <em><strong>S 192.168.2.0/24 [1/0] via 10.10.100.2</strong></em> |
После просмотра таблицы выделенный маршрут будет признан оптимальным для пересылки пакета (1 проход). Далее по таблице маршрутизации роутер будет искать через какой интерфейс отправить пакет для 10.10.100.2 (2 проход) и выберет строку:
|
1 |
<em>C 10.10.100.0/30 is directly connected, Tunnel1</em> |
Связанный интерфейс Tunnel 1, пакет будет отправлен на этот интерфейс. Далее будет произведена упаковка нашего пакета в GRE. После будет просмотрена конфигурация туннеля:
|
1 |
R1(config-if)# tunnel source GigabitEthernet 0/0 |
и отправка пакета уже на GigabitEthernet 0/0. Далее пакет отбирается мапой, так как он удовлетворяет Crypto ACL, шифруется. В IP заголовке, в поле Protocol заменяется протокол с 47 (GRE) на 50 (ESP). Шифрованный пакет выстреливается через GigabitEthernet 0/0.
На самом тут были сделаны некоторые допущения ради наглядности: ничего роутер в таблице маршрутизации искать не будет, да ещё в несколько проходов. Активен и работает CEF, все возможные маршруты просчитаны и роутер сразу знает, что делать с пакетом:
|
1 2 3 4 5 |
R1# show ip cef .. <em>192.168.2.0/24 10.10.100.2 Tunnel1</em> ... |
NAT
Как уже говорилось NAT не мешает работе туннеля. Почему так происходит? NAT применяется к пакету во время прохождения им GigabitEthernet 0/0 (до отработки привязанной мапы). Поскольку до прибытия на GigabitEthernet 0/0 пакет инкапсулируется в GRE, где у него меняется IP заголовок и соответственно IP отправителя и IP получателя в заголовке (на 10.10.10.1 и 10.10.10.2 для R1), то ACL 1, привязанный к нату, отбросит пакет. Пакет будет отправлен через GigabitEthernet 0/0 без натирования. Захватывание пакета мапой с помощью ACL 101 и упаковка в ESP происходит позже и уже никак не влияет.
Вывод
Интерфейс IP туннеля (для R1 это 10.10.100.1) нужен только для для инкапсуляции пакета в GRE. На него завязана некоторая маршрутизация, но всё это для выполнения основной задачи — передать пакет для инкапсуляции.
Разрешение трафика IPsec
Берём ACL из первой части:
|
1 2 3 4 5 |
R1(config)# ip access-list extended firewall_acl R1(config-ext-nacl)# permit <strong>udp</strong> host 10.10.10.2 host 10.10.10.1 <strong>eq isakmp</strong> R1(config-ext-nacl)# permit <strong>esp</strong> host 10.10.10.2 host 10.10.10.1 R1(config-ext-nacl)# permit icmp any host 10.10.10.1 echo R1(config-ext-nacl)# permit icmp any host 10.10.10.1 echo-replay |
Разрешение трафика GRE не нужно, так как поверху обёрнут ESP и что там у него внутри неважно. Вешаем на интерфейс:
|
1 2 |
R1(config)# interface GigabitEthernet 0/0 R1(config-if)# ip access-group firewall_acl <strong>in</strong> |
Проверка GRE over IPsec
Основные настройки и состояния после установления IPsec туннеля рассматривались в первой части. Здесь всё тоже самое. Повторяться нет смысла. Лучше проверим, что GRE действительно запаковывается в ESP:
Все нормально, нагрузка шифрованная.
OSPF
Проверим работоспособность протокола маршрутизации. Для этого создадим интерфейсы Loopback:
|
1 2 3 4 5 |
R1(config)# interface loopback 0 R1(config-if)# ip address 172.16.10.1 255.255.255.0 R2(config)# interface loopback 0 R2(config-if)# ip address 172.16.20.1 255.255.255.0 |
Теперь настроим OSPF:
|
1 2 3 4 5 6 7 |
R1(config)# router ospf 1 R1(config-router)# network 172.16.10.0 0.0.0.255 area 0 R1(config-router)# network 10.10.100.0 0.0.0.3 area 0 R2(config)# router ospf 101 R2(config-router)# network 172.16.20.0 0.0.0.255 area 0 R2(config-router)# network 10.10.100.0 0.0.0.3 area 0 |
Роутеры R1 и R2 сформировали отношения смежности через туннель, мультикаст работает:
|
1 |
<em>*Aug 17 15:11:20.514: %OSPF-5-ADJCHG: Process 1, Nbr 172.16.20.1 on Tunnel1 from LOADING to FULL, Loading Done</em> |
Проверим работу маршрутизации:
|
1 2 3 4 5 6 7 |
R1# ping 172.16.20.1 source 172.16.10.1 <em>Type escape sequence to abort.</em> <em>Sending 5, 100-byte ICMP Echos to 172.16.20.1, timeout is 2 seconds:</em> <em>Packet sent with a source address of 172.16.10.1</em> <em>!!!!!</em> <em>Success rate is 100 percent (5/5), round-trip min/avg/max = 5/6/7 ms</em> |
Работает, на этом всё. Полные конфы R1 и R2.
GRE Keepalive
Поскольку у нас туннель GRE, мы можем как вариант пользоваться Keepalive именно для GRE (о Crypto Isakmp Keepalive сказано выше). Механизм работы GRE Keepalive рассказан в статье CISCO GRE. Проверяем:
|
1 2 3 4 5 |
R1(config)# interface tunnel 1 R1(config-if)# keepalive 5 2 R2(config)# interface tunnel 1 R2(config-if)# keepalive 5 2 |
Ждём 15 секунд, если есть проблемы, то за это время Line Protocol интерфейса Tunnel 1 должен перейти в Down. Смотрим:
|
1 2 3 4 5 6 7 8 9 |
R1# show interfaces Tunnel 1 <em>Tunnel1 is up, <strong>line protocol is up</strong></em> <em>Hardware is Tunnel</em> <em>Internet address is 10.10.100.1/30</em> <em>MTU 17916 bytes, BW 100 Kbit/sec, DLY 50000 usec,</em> <em>reliability 255/255, txload 1/255, rxload 1/255</em> <em>Encapsulation TUNNEL, loopback not set</em> <strong><em>Keepalive set (5 sec), retries 2</em></strong> |
Почему так происходит? Да потому что у нас любые пакеты, пересылаемые по туннелю захватываются Crypto ACL 101, шифруются, включая пакеты Keepalive (незашифрованного трафика через туннель нет). Соответственно последние нормально доходят:
Ещё одна интересная особенность, поскольку сразу после загрузки роутера пакеты GRE Keepalive начинают пуляться в туннель GRE, то срабатывает ACL отбора интересного трафика для IPsec. Если в случае чистого IPsec первый пинг между компьютерами пропадал, так как нужно было время на отработку фаз 1 и 2, то в случае GRE over IPsec + GRE Keepalive всё сразу готово к работе после загрузки роутера.
Фрагментация
Известная практика ограничивать MTU до 1400 байт при использовании GRE over IPsec для устранения фрагментации пакетов:
|
1 2 3 4 5 |
R1(config)# interface Tunnel1 R1(config-if)# ip mtu 1400 R2(config)# interface Tunnel1 R2(config-if)# ip mtu 1400 |
Кроме это нужно определить максимальный размер сегмента TCP (MSS). Это необходимо сделать, потому что: «TCP требует явного указания максимального размера сегмента (MSS) в случае, если виртуальное соединение осуществляется через сегмент сети, где максимальный размер блока (MTU) менее, чем стандартный MTU Ethernet (1500 байт)». Мы уменьшили MTU до 1400, поэтому MSS = MTU — 40 = 1360 (два заголовка — IP и TCP внутри пакета GRE, каждый заголовок 20 байт, значит чистая максимальная нагрузка TCP это 1360).
|
1 2 3 4 5 |
R1(config)# interface Tunnel1 R1(config-if)# ip tcp adjust-mss 1360 R2(config)# interface Tunnel1 R2(config-if)# ip tcp adjust-mss 1360 |
|
1 |
<em>Используйте команду <strong>ip tcp adjust-mss</strong> для туннельных интерфейсов для того, чтобы маршрутизатор уменьшил значение TCP MSS в пакете TCP SYN</em> |
На пути следования пакета в туннеле может попасться роутер, у которого на интерфейсе MTU < 1400. В этом случае, хотя всё настроено правильно, будет фрагментация. Для такого случая нужно чтобы туннель автоматически проверял MTU по всему пути:
|
1 2 3 4 5 |
R1(config)# interface Tunnel1 R1(config-if)# tunnel path-mtu-discovery R2(config)# interface Tunnel1 R2(config-if)# tunnel path-mtu-discovery |
Это общие рекомендации, они могут не подойти для каких-то конкретных случаев. Различные аспекты устранения фрагментации (с примерами) рассказаны тут.