Как настроить IPSec в Windows

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

Тем не менее, операционная система Microsoft может также реализовать это через конфигурацию IPSEC. В этой статье мы рассмотрим, что такое IPSEC, и простой пример реализации.

Что такое IPSEC?

Internet Protocol Security или IPSEC — это протокол, используемый для аутентификации и шифрования IP-коммуникаций. Это достигается путем взаимной аутентификации между агентами, а также обмена криптографическими ключами в начале сеанса.

IPSEC также позволит добавлять ограничения IP и шифрование на уровне TCP / UDP к приложениям, которые иначе не могут его поддерживать. IPSEC использует IP-протокол 50 (ESP), IP-протокол 51 (AH) и UDP-порт 500.

Внедрение IPSEC

В этом примере мы настроим IPSEC для шифрования связи между двумя компьютерами Windows. Первый компьютер, сервер Windows 2012 будет выступать в качестве сервера VPN.

Второй компьютер, клиент Windows 10, будет действовать как клиент VPN. LT2P IPSEC VPN может обмениваться либо предварительным общим ключом, либо сертификатом. В этом примере мы будем обмениваться предварительным общим ключом.

Настройка VPN-сервера

На компьютере с Windows 2012 нам потребуется установить функции маршрутизации и удаленного доступа. Для этого перейдите в диспетчер серверов и добавьте роли и компоненты . Выберите установку на основе ролей или функций . Выберите локальный сервер. Выберите для установки следующие роли сервера.

Сетевая политика и службы доступа

Сервер сетевой политики

Удаленный доступ

Прямой доступ и VPN (RAS)

После установки этих новых функций вам потребуется оснастка для управления ими. Откройте mmc.exe с правами администратора. Перейти к файлу | Добавить / удалить оснастку. Добавьте оснастку маршрутизации и удаленного доступа .

Эта оснастка позволяет настраивать многопротокольные службы маршрутизации LAN-to-LAN, LAN-to-WAN, виртуальная частная сеть (VPN) и трансляция сетевых адресов (NAT).

В консоли MMC щелкните правой кнопкой мыши на маршрутизации и удаленного доступа и выберите, чтобы добавить сервер. Выберите локальную машину. Затем щелкните правой кнопкой мыши на только что созданном компьютере и выберите «Настроить и включить маршрутизацию и удаленный доступ» . Выберите Удаленный доступ (Dial Up или VPN).

Затем проверьте параметр VPN . У вас должно быть как минимум две сетевые карты, чтобы это работало. Одним из них может быть петля. Укажите диапазон адресов, которые будут предоставлены для входящего соединения. Убедитесь, что они не конфликтуют с другими адресами, выделенными в вашей существующей сети. В этом примере мы не будем использовать радиус-сервер.

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

В консоли mmc.exe щелкните правой кнопкой мыши на имени компьютера и перейдите в Свойства. Измените эти свойства на вкладке безопасности.

Выберите методы аутентификации, как показано ниже.

Установите флажок, чтобы разрешить настраиваемую политику IPSEC для соединения L2TP / IKEv2. Добавьте предварительный общий ключ.

Наконец, вам нужно будет изменить пользователя, чтобы получить доступ к VPN. Откройте compmgmt.msc, перейдите в раздел «Локальные пользователи и группы» и выберите свойства пользователя, которого вы хотите использовать для VPN.

Перейдите на вкладку Dial Up. Выберите Разрешить доступ и нажмите Применить . На вашем компьютере потребуется перезагрузка. После перезагрузки вы будете готовы протестировать свой первый клиент.

Настройка машины с Windows 10

На компьютере с Windows 10 откройте «Настройки сети и Интернета». Выберите VPN на левой панели и добавьте VPN-соединение. Отредактируйте дополнительные параметры.

Разместите IP-адрес вашего VPN-сервера под именем или адресом сервера. Выберите L2TP/IPSEC с параметром предварительного общего ключа в разделе Тип VPN. Добавьте предварительно общий ключ и имя пользователя и пароль.

Свойства безопасности для VPN должны быть изменены под сетевым адаптером. На адаптере VPN выберите «Свойства» и перейдите на вкладку «Безопасность». Установите переключатель EAP и выберите Microsoft: защищенный пароль (EAP-MSCHAPv2) (шифрование включено).

Наконец, снова щелкните правой кнопкой на адаптере для подключения. Поздравляем! Вы создали VPN-туннель IPSEC.

ИТ База знаний

Курс по Asterisk

Полезно

— Узнать IP — адрес компьютера в интернете

— Онлайн генератор устойчивых паролей

— Онлайн калькулятор подсетей

— Калькулятор инсталляции IP — АТС Asterisk

— Руководство администратора FreePBX на русском языке

— Руководство администратора Cisco UCM/CME на русском языке

— Руководство администратора по Linux/Unix

Навигация

Серверные решения

Телефония

FreePBX и Asterisk

Настройка программных телефонов

Корпоративные сети

Протоколы и стандарты

Популярное и похожее

Курс по сетям

Cisco ASA 5506-X: интерфейс BVI

Настройка GRE туннеля на Cisco

Настройка Router-on-a-Stick на Cisco

Фильтрация маршрутов в EIGRP

Настройка voice vlan на Cisco

Настройка Cisco Embedded Packet Capture

Траблшутинг Network Management Protocols

Еженедельный дайджест

Настройка Site-To-Site IPSec VPN на Cisco

Защищенный туннель между офисами

Привет! Сегодня мы расскажем про то как настроить Site-To-Site IPSec VPN туннель между роутерами Cisco. Такие VPN туннели используются обеспечения безопасной передачи данных, голоса и видео между двумя площадками (например, офисами или филиалами). Туннель VPN создается через общедоступную сеть интернет и шифруется с использованием ряда продвинутых алгоритмов шифрования, чтобы обеспечить конфиденциальность данных, передаваемых между двумя площадками.

Обучайся в Merion Academy

Пройди курс по сетевым технологиям

Начать

В этой статье будет показано, как настроить и настроить два маршрутизатора Cisco для создания постоянного безопасного туннеля VPN типа «сеть-сеть» через Интернет с использованием протокола IP Security (IPSec) . В рамках статьи мы предполагаем, что оба маршрутизатора Cisco имеют статический публичный IP-адрес.

ISAKMP (Internet Security Association and and Key Management Protocol) и IPSec необходимы для построения и шифрования VPN-туннеля. ISAKMP, также называемый IKE (Internet Key Exchange) , является протоколом согласования (negotiation protocol), который позволяет двум хостам договариваться о том, как создать сопоставление безопасности IPsec. Согласование ISAKMP состоит из двух этапов: фаза 1 и фаза 2.

Во время фазы 1 создается первый туннель, который защищает последующие сообщения согласования ISAKMP. Во время фазы 2 создается туннель, который защищает данные. Затем в игру вступает IPSec для шифрования данных с использованием алгоритмов шифрования и предоставляющий аутентификацию, шифрование и защиту от повторного воспроизведения.

Требования к IPSec VPN

Чтобы упростить понимание настройки разделим его на две части:

1. Настройка ISAKMP (Фаза 1 ISAKMP)
2. Настройка IPSec (Фаза 2 ISAKMP, ACL, Crypto MAP)

Делать будем на примере, который показан на схеме – два филиала, оба маршрутизатора филиалов подключаются к Интернету и имеют статический IP-адрес, назначенный их провайдером. Площадка №1 имеет внутреннею подсеть 10.10.10.0/24, а площадка №2 имеет подсеть 20.20.20.0/24. Цель состоит в том, чтобы безопасно соединить обе сети LAN и обеспечить полную связь между ними без каких-либо ограничений.

Настройка ISAKMP (IKE) — ISAKMP Phase 1

IKE нужен только для установления SA (Security Association) для IPsec. Прежде чем он сможет это сделать, IKE должен согласовать отношение SA (ISAKMP SA) с одноранговым узлом (peer).

Начнем с настройки маршрутизатора R1 первой площадки. Первым шагом является настройка политики ISAKMP Phase 1:

Приведенные выше команды означают следующее:

• 3DES — метод шифрования, который будет использоваться на этапе 1
• MD5 — алгоритм хеширования
• Pre-Share — использование предварительного общего ключа (PSK) в качестве метода проверки подлинности
• Group 2 — группа Диффи-Хеллмана, которая будет использоваться
• 86400 — время жизни ключа сеанса. Выражается либо в килобайтах (сколько трафика должно пройти до смены ключа), либо в секундах. Значение установлено по умолчанию.

Мы должны отметить, что политика ISAKMP Phase 1 определяется глобально. Это означает, что если у нас есть пять разных удаленных площадок и настроено пять разных политик ISAKMP Phase 1 (по одной для каждого удаленного маршрутизатора), то, когда наш маршрутизатор пытается согласовать VPN-туннель с каждой площадкой, он отправит все пять политик и будет использовать первое совпадение, которое принято обоими сторонами.

Далее мы собираемся определить Pre-Shared ключ для аутентификации с нашим партнером (маршрутизатором R2) с помощью следующей команды:

Pre-Shared ключ партнера установлен на merionet, а его публичный IP-адрес — 1.1.1.2. Каждый раз, когда R1 пытается установить VPN-туннель с R2 (1.1.1.2), будет использоваться этот ключ.

Настройка IPSec – 4 простых шага

Для настройки IPSec нам нужно сделать следующее:

• Создать расширенный ACL
• Создать IPSec Transform
• Создать криптографическую карту (Crypto Map)
• Применить криптографическую карту к общедоступному (public) интерфейсу

Давайте рассмотрим каждый из вышеперечисленных шагов.

Шаг 1: Создаем расширенный ACL

Нам нужно создать расширенный access-list (про настройку Extended ACL можно прочесть в этой статье) и в нем определить какой траффик мы хотим пропускать через VPN-туннель. В этом примере это будет трафик из одной сети в другую с 10.10.10.0/24 по 20.20.20.0/24. Иногда такие списки называют crypto access-list или interesting traffic access-list.

Шаг 2: Создаем IPSec Transform

Следующим шагом является создание набора преобразования (Transform Set), используемого для защиты наших данных. Мы назвали его TS.

Приведенная выше команда определяет следующее:

• ESP-3DES — метод шифрования
• MD5 — алгоритм хеширования

Шаг 3: Создаем Crypto Map

Crypto Map является последнем этапом нашей настройки и объединяет ранее заданные конфигурации ISAKMP и IPSec:

Мы назвали нашу криптографическую карту CMAP. Тег ipsec-isakmp сообщает маршрутизатору, что эта криптографическая карта является криптографической картой IPsec. Хотя в этой карте (1.1.1.2) объявлен только один пир, существует возможность иметь несколько пиров.

Шаг 4: Применяем криптографическую карту к общедоступному интерфейсу

Последний шаг — применить криптографическую карту к интерфейсу маршрутизатора, через который выходит траффик. Здесь исходящим интерфейсом является FastEthernet 0/1.

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

Как только мы применим криптографическую карту к интерфейсу, мы получаем сообщение от маршрутизатора, подтверждающее, что isakmp включен: “ISAKMP is ON”.

На этом этапе мы завершили настройку IPSec VPN на маршрутизаторе Площадки 1.

Теперь перейдем к маршрутизатору Площадки 2 для завершения настройки VPN. Настройки для R2 идентичны, с отличиями лишь в IP-адресах пиров и ACL.

Трансляция сетевых адресов (NAT) и VPN-туннели IPSec

В реальной схеме трансляция сетевых адресов (NAT), скорее всего, будет настроена для предоставления доступа в интернет внутренним хостам. При настройке VPN-туннеля типа «Site-To-Site» обязательно нужно указать маршрутизатору не выполнять NAT (deny NAT) для пакетов, предназначенных для удаленной сети VPN.

Это легко сделать, вставив оператор deny в начало списков доступа NAT, как показано ниже:

Для первого маршрутизатора:

Для второго маршрутизатора:

Инициализация и проверка VPN-туннеля IPSec

К этому моменту мы завершили нашу настройку, и VPN-туннель готов к запуску. Чтобы инициировать VPN-туннель, нам нужно заставить один пакет пройти через VPN, и этого можно достичь, отправив эхо-запрос от одного маршрутизатора к другому:

Первое эхо-сообщение icmp (ping) получило тайм-аут, но остальные получили ответ, как и ожидалось. Время, необходимое для запуска VPN-туннеля, иногда превышает 2 секунды, что приводит к истечению времени ожидания первого пинга.

Чтобы проверить VPN-туннель, используйте команду show crypto session:

Готово! Мы только что успешно подняли Site-To-Site IPSEC VPN туннель между двумя маршрутизаторами Cisco!

Сайт ARNY.RU

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:

Для R2 аналогично. Далее уже не буду каждый раз это писать. Подразумевается, что на R2 симметричные настройки.

Кроме этого для защиты со стороны «интернета» на интерфейсах далее будет настроен ACL, в котором разрешены на вход в роутер лишь несколько протоколов. Такой ACL скорее всего понадобится в продакшене, если настроен CBAC-файрвол.

Много букв про IPsec

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

IPsec — не 1 протокол, это набор протоколов (Framework), работа IPsec — согласованная работа этих протоколов. Набор протоколов в IPsec неоднозначный, нужно выбрать, какие именно протоколы будут использоваться.

С использованием IPsec достигается концепция безопасности CIA Triad: Confidentiality, Integrity, Availability

• Конфиденциальность данных — никто посторонний не сможет их просмотреть;
• Целостность данных — данные не были изменены при передаче;
• Доступность данных — постороннее лицо не может уничтожить пересылаемые данные или причинить им ущерб.

Кроме этого IPsec обеспечивает Antireplay (все пакеты нумеруются и если пакет уже приходил, то второй пакет с таким же номером будет отброшен).

Рассмотрим используемые протоколы:

Шифрование

Применяется симметричное шифрование, то есть такое, где ключ для шифрования и расшифровки один и тот же. Оно менее устойчиво ко взлому чем ассиметричное, но только симметричное шифрование технически доступно для большим объёмов передаваемых пользовательских данных, так как использует относительно низкую утилизацию CPU устройства. Рекомендуется AES.

Целостность

Для каждого сообщения вычисляется хеш, который прикладывается к сообщению. Хеш очень короткий, всегда одинаковой длины (определяется алгоритмом), он однозначно определяет исходное сообщение. При получении высчитывается хеш полученного сообщения, он сравнивается с приложенным хешем. Если значения 2 хешей совпадают, значит сообщение не было изменено. Такой метод уязвим к атаке «человек посередине» (Man-In-The-Middle): сообщение перехватывается по пути следования, изменяется, прикладывается новый хеш. Для принимающей стороны всё ok. Чтобы этого не могло произойти, применяется технология HMAC (Hash-Based Message Authentication Code): перед созданием хеша к сообщению прикладывается ключ, который есть только у отправляющей и принимающей стороны. В результате, атакующий после изменения сообщения не сможет вычислить нужный хеш, так как у него нет ключа. А вычислить ключ по исходному сообщению и хешу для сообщение+ключ он тоже не сможет. Точнее, на это нужно время, чем устойчивее алгоритм хеширования, тем больше времени нужно на взлом. Рекомендуется SHA256 и выше.

Обмен ключами

Для создания туннеля обе стороны должны совместно вычислить общий секретный ключ для симметричного шифрования данных в туннеле (не путать с PSK, который нужен для аутентификации). Всё это надо сделать через публичную сеть Интернета. Как это выполнить? На пустом месте через небезопасную сеть договорится о ключе для шифрования? Для этого используется специальный ассиметричный алгоритм Диффи-Хеллмана (DH). Степень защиты при расчёте общего ключа для шифрования определяется группой DH. Рекомендуется: Если в алгоритмах шифрования или аутентификации используется 128-битовый ключ, группа 14, 19, 20 или 24, а для 256-битового ключа группа 21 или 24.

Аутентификация

Каждый роутер должен подтвердить другому роутеру (и наоборот, то есть для 2 роутеров процедура выполняется 2 раза, сначала в одну, потом в обратную сторону) свою подлинность для участия в IPsec туннеле. Возможности: Общий, вводимый вручную, секретный ключ PSK (Pre Shared Key), Сертификаты RSA. Рекомендуется: Сертификаты RSA.

Аутентификация на основе общего ключа PSK происходит так: к ключу прикладывается определённая несекретная информация, известная и общая для обоих роутеров, высчитывается хеш, отправляется второму роутеру. Второй роутер повторяет процедуру для своего ключа и сравнивает хеши. Совпадение хешей означает совпадение общих ключей и как результат — подлинность, приславшего сообщение роутера. Потом второй роутер повторяет процедуру. В результате оба роутера подтвердили свою подлинность друг-другу.

Аутентификация RSA в рамках данной заметки рассматриваться не будет, поэтому разговора про неё нет. По факту повсеместно используется PSK, он не то чтобы проще, а глобально проще.

Плюс у RSA есть заморочки по поводу времени: мало того что оба роутера должны быть настроены на получение точного времени и время обязательно должно быть синхронизировано уже при загрузке, но ещё есть и связанные баги. Кроме этого настройка самих сертификатов тоже трудоёмкая задача. Возможно, как-нибудь.. выложу статью с примером.

Загрузка CPU

Пару слов: рекомендации это конечно хорошо, но чем сильнее алгоритмы, тем больше накладных расходов на их обсчёт. Туннелей может быть много. Конечно при большом числе туннелей предпочтителен DMVPN, а не IPsec туннель, но как мы знаем, не всегда всё в продакшене гладко и пушисто.

Кроме непосредственно туннелей на роутере есть и другие сервисы: файрвол, возможно IOS IPS, возможно NetFlow, возможно через этот роутер в интернете сидит огромное число народу с помощью NAT, возможно часто идёт потоковое видео или даже несколько потоков одновременно (видео-конференции, к примеру). Каждый подобный сервис грузит CPU роутера обсчётом.

Всё это нужно учитывать и алгоритмы подбирать такие, чтобы они совместно со всем вышеперечисленным не положили роутер. Для этого мониторить загрузку CPU:

При высокой нагрузке алгоритмы брать попроще. В примере буду использовать сильные алгоритмы. В продакшене видел люди не парятся, используют 56-битный DES и MD5 🙂 Пример реализации, тут рассказанный, он для изучения возможностей IPsec, не калька для продакшена. Это важно.

Чистый IPsec

«Чистый» — это моё название, официально туннель называется просто IPsec VPN tunnel.

Туннель возможен между CISCO ISR (Integrated Services Routers), ASA в любом сочетании. В CISCO ASA настройки могут быть выполнены через графическое средство — ASDM. Там всё понятно и пошагово, поэтому для определённости будем считать, что туннель пробрасывается между двумя ISR. Настройка в этом случае сложнее, ведь она производится через CLI и нужно понимать в каком порядке вводить команды, а также что значит каждая команда.

Фазы IPsec

Процесс установки IPsec VPN туннеля состоит из 2ух последовательных стадий-фаз (Phases):

• IKE Phase 1 — Создаётся 1 двунаправленный туннель, необходимый для согласования Phase 2. По этому туннелю передаётся только управляющая информация, пользовательские данные не передаются. Называется ISAKMP туннель;
• IKE Phase 2 — С помощью туннеля фазы 1 создаются дополнительно ещё 2 однонаправленных туннеля, от первого роутера ко второму и от второго к первому, по которым передаётся пользовательская информация. Туннели второй фазы и есть то, что называется IPsec туннель.

Важно отметить, что туннель не поднимается сразу после выполнения настроек. Согласования фазы 1, затем 2 начинается после того, как на роутер попадают данные, предназначенные для туннеля («интересный» трафик). Данные эти отбираются с помощью ACL (называется Crypto ACL, хотя по факту это самый обычный ACL).

Также важно то, что туннель не существует сколь угодно долго после создания, у него есть время жизни (Lifetime). После истечения Lifetime туннель гасится и пересоздаётся снова (с помощью фаз 1 и 2, при наличии интересного трафика). Если интересного трафика нет, туннель лежит, но постоянно готов к созданию сразу при появлении такого трафика.

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

Встречал в разных материалах, что по истечении Lifetime «обновляются ключи шифрования», открываю официальный гайд, о котором сказано в начале статьи:

Впрочем, никто мне не мешает проверить (будет далее).

Необходимые понятия

• IKE — Самый, пожалуй, центровой протокол в IPsec Framework это IKE (Internet Key Exchange). Остальные протоколы работают под его управлением;
• ISAKMP — Реализация IKE для первой фазы (Security Association and Key Management Protocol);
• SA — В ходе фазы 1 и фазы 2 роутеры обмениваются и утверждают набор параметров IPsec Framework: хеширование, шифрование и так далее. Каждый набор или коллекция и есть SA (Security Association). Для создания IPsec туннеля требуется 2 SA: для первой и для второй фазы. На роутере уже есть предустановленные SA, но пользоваться ими не рекомендуется (по крайней мере предустановленные SA 1 фазы используют устаревшие, нестойкие алгоритмы). Для успешного поднятия туннеля параметры SA на одном роутере должны полностью совпадать с параметрами SA на другом роутере (для каждой фазы).

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

Чистый IPsec используется когда проброс информации динамических протоколов маршрутизации через туннель не нужен.

Настройка IPsec

• Настраиваем фазу 1;
• Задаём PSK;
• Создаём Crypto ACL для отбора интересного трафика;
• Настраиваем фазу 2: Transform Set;
• Создаём Crypto Map, в Crypto Map используем созданные Crypto ACL, Transform Set;
• Затем вешаем Crypto Map на нужный интерфейс;
• Разрешаем входящий трафик ISAKMP, ESP.

Фаза 1

Начинаем настраивать SA первой фазы. Создаётся политика ISAKMP. HAGLE — удобная мнемоника для запоминания этой SA:

• Hash — хеширование SHA256;
• Autentification — аутентификация PSK;
• Group — группа DH 21;
• Lifetime — время жизни туннеля 3600 (по умолчанию 1 день = 86400);
• Encryption — шифрование AES 256 (по умолчанию для AES значение 128).

Как уже говорилось параметры SA для обоих роутеров должны совпадать. Исключение составляет параметр Lifetime: если он не совпадает, то взят будет наименьший.

Важно отметить, что цифра политики означает приоритет её использования:

Использовал цифру 3, приоритет третий, но поскольку политики с номерами 1 и 2 не определены, то наша третья будет использоваться первой. Также необязательно чтобы номера политик с двух сторон совпадали.

Дефолтные SA первой фазы

Их 8, начиная с самой устойчивой, затем постепенно устойчивость ко взлому снижается. При отсутствии вручную заданной SA первой фазы роутер попытается использовать дефолтные SA в порядке приоритетов. Сначала саму стойкую 65507, согласование окончилось ошибкой, тогда 65508. И так далее.

Указывается ключ PSK и IP роутера с другой стороны туннеля (IP пира):

Crypto ACL

Самый обычный ACL, нам нужно отобрать трафик с PC1 на PC2 для R1 и с PC2 на PC1 для R2:

Фаза 2

SA второй фазы несколько отличается от первой. IPsec может использовать протокол AH или протокол ESP:

• AH — Authentication Header, IP протокол 51, обеспечивает аутентификацию и целостность данных, но не применяет шифрование, поэтому в реальной жизни его ценность минимальна;
• ESP — Encapsulation Security Protocol, IP протокол 50, обеспечивает аутентификацию, целостность данных и шифрование. Для туннеля через Интернет интересен только этот протокол.

IPsec работает или в туннельном режиме, или в транспортном режиме:

• Туннельный режим — добавляется новый IP заголовок, исходный пакет полностью упаковывается, используется при создании туннеля между роутерами (site-to-site). Для нас подходит только этот режим;
• Транспортный режим — используется IP заголовок исходного пакета, применяется или при подключении клиентов к серверу (VPN client), или когда уже есть сетевая доступность между устройствами (GRE over IPsec).

Transform Set

Настраиваем набор алгоритмов для фазы 2:

Здесь R1-R2 имя набора, оно будет далее использоваться в Crypto MAP и выбирать его нужно таким, чтобы потом не запутаться, то есть одинаковым для обоих роутеров. Выбираем далее esp-aes 256:

И esp-sha256-hmac, туннельный режим:

Поскольку туннельный режим идёт по умолчанию, то вводить команду mode tunnel для сета не нужно (она добавится автоматически).

Дефолтный SA второй фазы

Единственный дефолтный сет имеет транспортный режим. Он в нашем туннеле не заработает, поэтому SA второй фазы нужно обязательно набивать руками.

Crypto Map

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

Указывается имя, номер:

Номер имеет важное значение. На 1 интерфейс можно повесить только 1 мапу. А как быть если нужно к этому интерфейсу привязать 2, 3.. туннеля? Мапа обычно состоит из нескольких последовательных правил (как и ACL), у каждого правила свой номер. Каждое правило с новым номером и будет соответствовать новому туннелю.Таким образом, теоретически на 1 интерфейс можно повесить 65535 туннелей. В нашей Crypto Map 1 правило.

Тут небольшое лирическое отступление. А вообще сколько туннелей норма при вот таком режиме IPsec, как сейчас разбирается, чтобы полносвязное соединение было (всё на всё)? Два пира — всего 1 туннель (1 на роутер), 3 пира — всего 3 туннеля (1 на роутер), 4 пира — уже 6 туннелей (3 на роутер).. Моё скромное мнение: 1-3 пира, используем IPsec туннели, 4 и более, используем DMVPN.

В явном вид говорится, что мапа останется неактивной пока не будет добавлен пир и валидный Crypto ACL для отбора трафика.

Привязываем ACL, сет алгоритмов и адрес удалённого роутера.

Дополнительные возможности Crypto Map

При согласовании фазы 2 будет ещё раз выполнен алгоритм Диффи-Хеллмана для создания нового симметричного ключа шифрования. В результате у туннелей второй фазы будет собственный ключ шифрования, иначе используется ключ из первой фазы.

Для второй фазы можно задать отдельное время жизни в днях, килобайтах или секундах, иначе вторая фаза будет проходить (после первой, разумеется) при истечении Lifetime первой фазы и пересоздании туннеля.

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

Добавление Crypto Map на интерфейс

Добавляем мапу к интерфейсу, никаких ошибок быть не должно:

Если после вылезли вот такие ошибки:

То тут 2 варианта: сам что-то накосячил или глюк vIOS при полностью правильных настройках. В первом случае работать скорее не будет, во втором случае работает нормально, проверял.

Важный момент: чтобы Crypto Map отработала, пакет должен попасть на интерфейс, где мапа висит. У нас это достигается маршрутом по умолчанию:

Если бы не было этого маршрута, то пакет от 192.168.1.2 к 192.168.2.2 был бы отброшен. Мапа сама его не подтянет. Попаданий в Crypto ACL пакетов не будет, туннель не поднимется.

Ещё важный момент: Crypto Map имеет направление, то есть действует только на исходящий (outbound) трафик:

Изменение NAT

В том виде как он есть, NAT не даст работать туннелю. Пакеты будут просто проваливаться в него и всё. Нужно исключить пакеты для туннеля из NAT:

Ещё раз краткий алгоритм работы IPsec:

Разрешение трафика ISAKMP и ESP

Последний момент в настройке IPsec. Туннель настраивается всегда на граничных роутерах, Crypto Map вешается на интерфейс, смотрящий в Интернет. Но такой роутер защищён от нежелательного входящего со стороны интернет-трафика (CBAC firewall, ACL). А нам надо чтобы прошло согласование 2 фаз IKE. Поэтому нужно в явном виде «пропилить дырки» для входящего трафика IKE и ESP:

На всякий пожарный ещё раз: ISAKMP это UDP порт 500, ESP это IP протокол 50.

Разрешение Ping

И даже такой ACL недостаточен для нормальной работы. Туда нужно много чего добавить (как минимум SSH). Добавим правило чтобы возвращались проходил пинг:

И «лепим» этот ACL на внешний интерфейс во входящем направлении:

Кроме CBAC может быть Zone-based firewall, там ACL не используется, а для трафик разрешается правилами для пары зон. Про ZBF как-нибудь выложу отдельную статью, если получится её дописать.

Проверка IPsec

Сначала посмотрим чего понастраивали:

Сет уже просмотрели, когда выводилась инфа о дефолтном сете. Смотрим мапу:

А что это такое? Что за NiStTeSt1? Это баг данной версии IOS (требуется регистрация, нет если учётной записи в CISCO, то пора создать). Смотреть состояние SAs рано, там всё пусто и по нулям.

Тест туннеля

Для начала включим дебаг:

Запустим трафик с PC1 на PC2, например пинг:

Первый пинг пропадает, так как нужно время для поднятия туннеля. Вывод дебага огромен, приводить нет смысла. Тут надо только отметить, что фаза 1 согласовывается в основном режиме (Main) или в агрессивном (Aggressive). По умолчанию основной режим, агрессивный чуть быстрее (обмен между роутерами на пару пакетов меньше), непринципиально чтобы заморачиваться на выяснение его настройки:

Пакеты бегают, PFS работает. Также полезная команда show crypto session [ brief | detail ].

Теперь посмотрим на передаваемые пакеты с помощью WareShark:

Нагрузка зашифрована, всё в порядке.

К вопросу о Lifetime

Самому даже интересно. Никто не мешает мне мучить виртуальные (реальные тоже) железки, вводить правильные и неправильные параметры, как захочу. Сделаем время жизни 60 секунд (возможный минимум), дебаг включён, запускаем инициализацию туннеля по пингу (5 пакетов) и ждём 1 минуту:

Нету туннеля. Вопрос закрыт. Полные конфы R1 и R2.

GRE over IPsec

Смысл туннеля: пакеты GRE зашифрованы IPsec. Поскольку сам GRE (Generic Routing Encapsulation) передаётся в виде юникастовых пакетов, то его возможно помещать внутрь IPsec (точнее внутрь ESP). Таким образом GRE over IPsec решает проблему как GRE (шифрование), так и IPsec (поддержка мультикаста). Подробнее о GRE и чем он хорош.

Схема подключения та же самая. Роутеры в начальной конфигурации (без IPsec туннелей, всё, что настраивалось в 1 части статьи — этого нет).

Настройка GRE over IPsec

Чтобы всё было понятно, нужно разобрать первую часть статьи.

GRE туннель

Сначала настраиваем GRE туннель:

Делаем маршрут, чтобы трафик в удалённую подсеть заворачивал в туннель:

Проверяем работу GRE:

NAT в данном случае не мешает работе туннеля, проверяем:

Почему это так чуть далее.

Просмотр через 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:

Список управления доступом: отбираем трафик GRE, идущий в туннель:

Как уже подчёркивал выше, IP заголовок GRE использует не IP адреса туннеля с двух сторон, а IP адреса физических интерфейсов двух роутеров. Поэтому такой ACL.

Сет возьмём дефолтный, он как раз подходит: нет смысла засовывать туннель (он уже есть), в ещё 1 туннель, поэтому транспортный режим дефолтного сета то, что нужно. Зашифруется только нагрузка (это у нас GRE и всё, что в него инкапсулировано), заголовок IP останется от исходного GRE. Теперь мапа:

А где сет? Дело в том, что привязка Transform Set не является обязательной для Crypto Map:

Достаточно пира и ACL. Как раз не привязывая сет мы даём понять, что хотим использовать дефолтный сет. Если пир или ACL не указан для мапы, то она имеет следующий вид в конфигурации:

Дополнительные возможности мапы использовать не будем.

Вешаем мапу на интерфейс:

Обработка пакета

Резонный вопрос: а почему интерфейс для мапы GigabitEthernet 0/0, а не Tunnel 1? Во-первых, можно вешать только определённые мапы на туннельный интерфейс:

Во-вторых, потому что 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 проход). Далее по таблице маршрутизации роутер будет искать через какой интерфейс отправить пакет для 10.10.100.2 (2 проход) и выберет строку:

Связанный интерфейс Tunnel 1, пакет будет отправлен на этот интерфейс. Далее будет произведена упаковка нашего пакета в GRE. После будет просмотрена конфигурация туннеля:

и отправка пакета уже на GigabitEthernet 0/0. Далее пакет отбирается мапой, так как он удовлетворяет Crypto ACL, шифруется. В IP заголовке, в поле Protocol заменяется протокол с 47 (GRE) на 50 (ESP). Шифрованный пакет выстреливается через GigabitEthernet 0/0.

На самом тут были сделаны некоторые допущения ради наглядности: ничего роутер в таблице маршрутизации искать не будет, да ещё в несколько проходов. Активен и работает CEF, все возможные маршруты просчитаны и роутер сразу знает, что делать с пакетом:

Как уже говорилось 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 туннеля (10.10.100.1 для R1) нужен только для для инкапсуляции пакета в GRE. На него завязана некоторая маршрутизация, но всё это для выполнения основной задачи — передать пакет для инкапсуляции.

Разрешение трафика IPsec

Берём ACL из первой части:

Разрешение трафика GRE не нужно, так как поверху обёрнут ESP и что там у него внутри неважно. Вешаем на интерфейс:

Проверка GRE over IPsec

Основные настройки и состояния после установления IPsec туннеля рассматривались в первой части. Здесь всё тоже самое. Повторяться нет смыла. Лучше проверим, что GRE действительно запаковывается в ESP:

Все нормально, нагрузка шифрованная.

Проверим работоспособность протокола маршрутизации. Для этого создадим интерфейсы Loopback:

Теперь настроим OSPF:

Роутеры R1 и R2 сформировали отношения смежности через туннель, мультикаст работает:

Проверим работу маршрутизации:

Работает, на этом всё. Полные конфы R1 и R2.

Keepalive

Механизм работы GRE Keepalive рассказан в статье CISCO GRE. Оставил Keepalive напоследок. Проверяем:

Ждём 15 секунд, если есть проблемы, то за это время Line Protocol интерфейса Tunnel 1 должен перейти в Down. Смотрим:

Почему так происходит? Да потому что у нас любые пакеты, пересылаемые по туннелю захватываются Crypto ACL 101, шифруются, включая пакеты Keepalive (незашифрованного трафика через туннель нет). Соответственно последние нормально доходят:

Вывод: наша реализация GRE over IPsec на Crypto Map лучше, чем реализация на Crypro IPsec Profile.

Ещё одна интересная особенность, поскольку сразу после загрузки роутера пакеты Keepalive начинают пуляться в туннель GRE, то срабатывает ACL отбора интересного трафика для IPsec. Если в случае чистого IPsec первый пинг между компьютерами пропадал, так как нужно было время на отработку фаз 1 и 2, то в случае GRE over IPsec + Keepalive всё сразу готово к работе после загрузки роутера.

Фрагментация

Известная практика ограничивать MTU до 1400 байт при использовании GRE over IPsec для устранения фрагментации пакетов:

Кроме это нужно определить максимальный размер сегмента TCP (MSS). Это необходимо сделать, потому что: «TCP требует явного указания максимального размера сегмента (MSS) в случае, если виртуальное соединение осуществляется через сегмент сети, где максимальный размер блока (MTU) менее, чем стандартный MTU Ethernet (1500 байт)». Мы уменьшили MTU до 1400, поэтому MSS = MTU — 40 = 1360 (два заголовка — IP и TCP внутри пакета GRE, каждый заголовок 20 байт, значит чистая максимальная нагрузка TCP это 1360).