Какой ipsec используется для настройки vpn

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

VPN, или Virtual Private Network, что в переводе означает Виртуальная Частная Сеть — это криптосистема, позволяющая защитить данные при передаче их по незащищенной сети, такой как Интернет. Несмотря на то, что данное описание подходит и для криптосистемы SSH, VPN имеет другое предназначение. SSH разрабатывался как средство, позволяющее пользователю безопасно зайти и удалённо управлять другим компьютером. Цель VPN — прозрачный доступ к ресурсам сети, где пользователь может делать всё то, что он делает обычно независимо от того, насколько он удалён. По этой причине VPN приобрёл популярность среди дистанционных работников и офисов, которые нуждаются в совместном использовании ресурсов территориально разделённых сетей.

VPN Туннели

Прежде чем приступить к настройке VPN, необходимо познакомится с общепринятой терминологией и с некоторыми проблемами настройки. Начнём с терминологии. VPN соединение всегда состоит из канала типа точка-точка, также известного под названием туннель. Туннель создаётся в незащищённой сети, в качестве которой чаще всего выступает Интернет. Соединение точка-точка подразумевает, что оно всегда устанавливается между двумя компьютерами, которые называются узлами или peers. Каждый peer отвечает за шифрование данных до того, как они попадут в туннель и расшифровке этих данных после того, как они туннель покинут.

Хотя VPN туннель всегда устанавливается между двумя точками, каждый peer может устанавливать дополнительные туннели с другими узлами. Для примера, когда трём удалённым станциям необходимо связаться с одним и тем же офисом, будет создано три отдельных VPN туннеля к этому офису. Для всех туннелей peer на стороне офиса может быть одним и тем же. Это возможно благодаря тому, что узел может шифровать и расшифровывать данные от имени всей сети, как это показано на рисунке 1:

Рисунок 1 — VPN шлюз к сети

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

Интересно отметить, что внутри домена шифрования самого шифрования не происходит. Причина в том, что эта часть сети считается безопасной и находящейся под непосредственным контролем в противоположность Интернет. Это справедливо и при соединении офисов с помощью VPN шлюзов. Таким образом гарантируется шифрование только той информации, которая передаётся по небезопасному каналу между офисами. Рисунок 2 показывает VPN соединяющую два офиса:

Рисунок 2 — защищённая сеть на основе незащищённой сети

Сеть A считается доменом шифрования VPN шлюза A, а сеть B доменом шифрования VPN шлюза B, соответственно. Когда пользователь сети A изъявляет желание отправить данные в сеть B, VPN шлюз A зашифрует их и отошлёт через VPN туннель. VPN шлюз B расшифрует информацию и передаст получателю в сети B.

Помните режим транспорта и режим туннеля в Терминологии Криптографии 101? Всякий раз, когда соединение сетей обслуживают два VPN шлюза, они используют режим туннеля. Это означает, что шифруется весь пакет IP, после чего к нему добавляется новый IP заголовок. Новый заголовок содержит IP адреса двух VPN шлюзов, которые и увидит пакетный сниффер при перехвате. Невозможно определить компьютер-источник в первом домене шифрования и компьютер-получатель во втором домене.

Посмотрите на рисунок 1, иллюстрирующий типичное использование VPN, которая позволяет удалённым пользователям с переносыми компьютерами и пользователям, работающим из дома, иметь доступ к офисной сети. Чтобы эта схема заработала, пользователь должен иметь установленное ПО — VPN клиент, который обеспечит создание VPN туннеля к удалённому VPN шлюзу. По сценарию используется режим туннеля, т.к. пользователь хочет получить доступ к ресурсам домена, а не самого шлюза. Единственной случай, когда включается режим транспорта — это если одному компьютеру нужно получить доступ к другому непосредственно.

Существует много вариантов VPN шлюзов и VPN клиентов. Это может быть аппаратное VPN устройство или программное VPN обеспечение, которое устанавливается на маршрутизаторах или на ПК. ОС FreeBSD поставляется вместе с ПО для создания VPN шлюза и для настройки VPN клиента. В коллекции портов существуют и другие приложения, позволяющие соединяться со станциями под управлением других ОС.

К счастью, в Интернет есть много источников информации о VPN, FAQ и варианты настроек. Я могу порекомендовать Tina Bird’s VPN Information, VPN Labs, и Virtual Private Network Consortium (VPNC).

Назависимо от используемого ПО, все VPN работают по следующим принципам:

Каждый из узлов идентифицирует друг друга перед созданием туннеля, чтобы удостовериться, что шифрованные данные будут отправлены на нужный узел
Оба узла требуют заранее настроеной политики, указывающей какие протоколы могут использоваться для шифрования и обеспечения целостности данных
Узлы сверяют политики, чтобы договориться об используемых алгоритмах; если это не получается, то туннель не устанавливается
Как только достигнуто соглашение по алгоритмам, создаётся ключ, который будет использован в симметричном алгоритме для шифрования/расшифровки данных

Есть несколько стандартов регламентирующих вышеописанное взаимодействие. Вы, должно быть, слышали о некоторых из них: L2TP, PPTP, и IPSec. Т.к. IPSec — наиболее широко поддерживаемый стандарт, который имеет в арсенале наибольшее количество сокращений, оставшуюся часть статьи стоит посвятить именно ему.

IPSec

Стандарт IPSec был разработан для повышения безопасности IP протокола. Это достигается за счёт дополнительных протоколов, добавляющих к IP пакету собственные заголовки, которые называются инкапсуляциями. Т.к. IPSec — стандарт Интернет, то для него существуют RFC (Requests For Comments). Если есть интерес покопаться во внутренностях IPSec, то следующие RFC с http://www.rfc-editor.org/ могут оказаться полезными:

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

AH (Authentication Header) — протокол заголовка идентификации. Обеспечивает целостность путём проверки того, что ни один бит в защищаемой части пакета не был изменён во время передачи. Не будем вдаваться в подробности, какая часть пакета защищается и где находятся данные AH заголовка, т.к. это зависит от используемого типа шифрования и в деталях, с диаграммами описывается в соответствующем RFC. Отметим лишь, что использование AH может вызвать проблемы, например, при прохождении пакета через NAT устройство. NAT меняет IP адрес пакета, чтобы разрешить доступ в Интернет с закрытого локального адреса. Т.к. пакет в таком случае изменится, то контрольная сумма AH станет неверной. Также стоит отметить, что AH разрабатывался только для обеспечения целостности. Он не гарантирует конфиденциальности путём шифрования содержимого пакета.

ESP (Encapsulating Security Protocol) — инкапсулирующий протокол безопасности, который обеспечивает и целостность и конфиденциальность. В режиме транспорта ESP заголовок находится между оригинальным IP заголовком и заголовком TCP или UDP. В режиме туннеля заголовок ESP размещается между новым IP заголовком и полностью зашифрованным оригинальным IP пакетом.

Т.к. оба протокола — AH и ESP добавляют собственные заголовки, они имеют свой ID протокола, по которому можно определить что последует за заголовком IP. Если вспомнить статью TCP Protocol Layers Explained, то в ней сказано, что каждый тип заголовка имеет собственный номер. Например, для TCP это 6, а для UDP — 17. При работе через firewall важно не забыть настроить фильтры, чтобы пропускать пакеты с ID AH и/или ESP протокола. Для AH номер ID — 51, а ESP имеет ID протокола равный 50. При создании правила не забывайте, что ID протокола не то же самое, что номер порта.

Третий протокол, используемый IPSec — это IKE или Internet Key Exchange protocol. Как следует из названия, он предназначен для обмена ключами между двумя узлами VPN. Насмотря на то, что генерировать ключи можно вручную, лучшим и более масштабируемым вариантом будет автоматизация этого процесса с помощью IKE. Помните, что ключи должны часто меняться, и вам наверняка не хочется полагаться на свою память, чтобы найти время для совершения этой операции вручную. Главное — не забудьте настроить правило на файрволе для UPD порта с номером 500, т.к. именно этот порт используется IKE.

SA (Security Association), что можно приближённо перевести как «связь или ассоциация безопасности» — это термин IPSec для обозначения соединения. При настроенном VPN, для каждого используемого протокола создаётся одна SA пара (т.е. одна для AH и одна для ESP). SA создаются парами, т.к. каждая SA — это однонаправленное соединение, а данные необходимо передавать в двух направлениях. Полученные SA пары хранятся на каждом узле. Если ваш узел имеет SA, значит VPN туннель был установлен успешно.

Т.к. каждый узел способен устанавливать несколько туннелей с другими узлами, каждый SA имеет уникальный номер, позволяющий определить к какому узлу он относится. Это номер называется SPI (Security Parameter Index) или индекс параметра безопасности.

SA храняться в базе данных c названием, кто бы подумал — SAD (Security Association Database) или БД ассоциаций безопасности. Мы встретимся с ней ещё раз при настройке IPSec VPN.

Каждый узел IPSec также имеет вторую БД — SPD или Security Policy Database (БД политики безопасности). Она содержит настроенную вами политику узла. Большинство VPN решений разрешают создание нескольких политик с комбинациями подходящих алгоритмов для каждого узла, с которым нужно установить соединение.

Какие настройки включает в себя политика?

Симметричные алгоритмы для шифрования/расшифровки данных
Криптографические контрольные суммы для проверки целостности данных
Способ идентификации узла. Самые распространнённые способы — это предустановленные ключи (pre-shared secrets) или RSA сертификаты.
Использовать ли режим туннеля или режим транспорта
Какую использовать группу Diffie Hellman
Как часто проводить переидентификацию узла
Как часто менять ключ для шифрования данных
Использовать ли PFS
Использовать ли AH, ESP, или оба вместе

При создании политики, как правило, возможно создание упорядоченного списка алгоритмов и Diffie Hellman групп. В таком случае будет использована первая совпавшая на обоих узлах позиция. Запомните, очень важно, чтобы всё в политике безопасности позволяло добиться этого совпадения. Если за исключением одной части политики всё остальное совпадает, узлы всё равно не смогут установить VPN соединение. При настройе VPN между различными системами уделите время изучению того, какие алгоритмы поддерживаются каждой стороной, чтобы иметь выбор наиболее безопасной политики из возможных.

Фаза Один и Фаза Два

Теперь давайте посмотрим как всё это работает вместе. Установка и поддержка VPN туннеля происходит в два этапа. На первом этапе (фазе) два узла договариваются о методе идентификации, алгоритме шифрования, хэш алгоритме и группе Diffie Hellman. Они также идентифицируют друг друга. Всё это может пройти в результате обмена тремя нешифрованными пакетами (т.н. агрессивный режим) или через обмен шестью нешифрованными пакетами (стандартный режим — main mode). Предполагая, что операция завершилась успешно, создаётся SA первой Фазы — Phase 1 SA (также называемый IKE SA) и процесс переходит к Фазе Два.

На втором этапе генерируются данные ключей, узлы договариваются насчёт используемой политики. Этот режим, также называемый быстрым режимом (quick mode), отличается от первой фазы тем, что может установиться только после первого этапа, когда все пакеты второй фазы шифруются. Такое положение дел усложняет решение проблем в случае неполадок на второй фазе при успешном завершении первой. Правильное завершение второй фазы приводит к появлению Phase 2 SA или IPSec SA, и на этом установка туннеля считается завершённой.

Когда же это всё происходит? Сначала на узел прибывает пакет с адресом назначения в другом домене шифрования, и узел инициирует Фазу Один с тем узлом, который отвечает за другой домен. Допустим, туннель между узлами был успешно установлен и ожидает пакетов. Однако, узлам необходимо переидентифицировать друг друга и сравнить политику через определённое время. Это время известно как время жизни Phase One или IKE SA lifetime.

Узлы также должны сменить ключ для шифрования данных через другой отрезок времени, который называется временем жизни Phase Two или IPSec SA lifetime. Phase Two lifetime короче, чем у первой фазы, т.к. ключ необходимо менять чаще. Типичное время жизни Phase Two — 60 минут. Для Phase One оно равно 24 часам.

Ваша задача заключается в том, чтобы сконфигурировать оба узла с одинаковыми параметрами времени жизни. Если этого не произойдёт, то возможен вариант, когда изначально туннель будет установлен успешно, но по истечении первого несогласованного промежутка времени жизни связь прервётся. Странные проблемы могут возникнуть и в том случае, когда время жизни Фазы Один меньше аналогичного параметра Фазы Два. Если настроенный ранее туннель виснет, то первая вещь, которая нуждается в проверке — это время жизни на обоих узлах. В заключение стоит упомянуть, что при смене политики на одном из узлов, изменения вступят в силу только при следующем наступлении Фазы Один. Чтобы изменения вступили в силу немедленно, надо убрать SA для этого туннеля из SAD. Это вызовёт пересмотр соглашения между узлами с новыми настройками политики безопасности.

Теперь у нас есть достаточно информации для создания IPSec VPN на вашей FreeBSD машине. Демонстрация необходимых настроек — тема следующей статьи.

Dru Lavigne — инструктор Marketbridge Technologies в Оттаве и администратор Open Protocol Resource.

Как настроить VPN IPsec

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

Введение

Технология IPsec VPN позволяет построить туннель для передачи трафика серых (приватных) сетей через публичный интернет. При этом используется шифрование данных для их защиты, за счет чего и достигается безопасность. Чаще всего VPN на базе IPsec используют для site-to-site подключений, когда необходимо соединить две географически разнесенных сети, например, в двух разных дата-центрах, и нет возможности построить VPN по выделенным каналам связи.

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

Исходные данные

виртуальная машина запущенная на образе Ubuntu 20.04 с двумя портами,
первый порт виртуальной машины подключен к публичной сети (и используется как default route),
второй порт подключен к приватной сети, которую необходимо маршрутизировать,

Облачный сервер

Разверните виртуальную машину в пару кликов.

Предполагаемая схема настройки и адресация выглядит следующим образом:

Эта схема без отказоустойчивости, так как инстанс VPN один и в случае его отказа сеть перестанет работать. В этой статье предполагается что у вас уже есть левая часть схемы, то есть VPN инстанс в другом облаке с настроенной виртуальной машиной или инстансом IPsec.

На стороне Selectel у вашей виртуальной машины для IPsec настроено два порта с адресами 188.68.206.154 и 192.168.10.10 для публичной и приватной сети соответственно.

Настройка VPN с одним инстансом

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

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

Эти команды создают конфигурационный файл sysctl и применяют его.

Далее нам необходимо создать основной конфигурационный файл IPsec для strongSwan:

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

leftid — публичный адрес самой виртуальной машины IPsec, в нашем случае это 188.68.206.154, в другом окружении адрес будет другим;
leftsubnet — приватная сеть. Это сеть, которая создана в облаке Selectel для других виртуальных машин. Из нее необходимо иметь доступ к виртуальным машинам в другом облаке;
right — публичный адрес удаленной виртуальной машины, то есть в нашем случае 51.250.46.166;
rightsubnet — удаленная приватная сеть. Это сеть, которая была создана в другом облаке и используется там для виртуальных машин.

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

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

Где <SECRET> — пароль, указанный с обеих сторон тоннеля, то есть на обеих виртуальных машинах VPN IPsec.

Перезагружаем IPsec демон и проверяем статус подключения:

Настройка отказоустойчивой схемы

Так выглядит отказоустойчивая схема.

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

Чтобы настроить отказоустойчивую схему, необходимо запустить еще одну такую же виртуальную машину для VPN. Будем ее называть vpn2, а первую виртуальную машину — vpn1.

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

Перед IPsec необходимо настроить VRRP с помощью демона keepalived. Устанавливаем эту службу:

Настраиваем VRRP-конфигурацию так, чтобы:

оба VIP перемещались одновременно, были в одной группе;
при смене статуса инстанса с MASTER на BACKUP и обратно необходимо, чтобы IPsec выключался и включался соответственно, так как туннель должен быть построен только от одной виртуальной машины в один момент времени.

Настраиваем VRRP на виртуальной машине vpn2:

Эти команды создают два файла:

/usr/local/sbin/notify-ipsec.sh — скрипт, который будет вызываться при смене статуса VRRP и будет выключать/включать IPsec;
/etc/keepalived/keepalived.conf — файл конфигурации keepalived для двух групп.

Далее необходимо перезагрузить keepalived и включить его в автозапуске:

После этого можно приступать к настройке IPsec на vpn2. Конфигурационный файл теперь будет немного другим, так как туннель должен строиться с VIP-адреса, а не с адреса на интерфейсе.

Файл с секретом создается тоже с VIP-адресом:

Настройка vpn2 окончена. Приступаем к настройке vpn1, так как на первой виртуальной машине тоже надо запустить VRRP и подправить конфигурацию IPsec.

Так как эта схема строится для отказоустойчивости, большинство конфигурационных файлов будут точно такими же как и на vpn2. Исключение — роль VRRP у этого инстанса будет MASTER. Устанавливаем keepalived, создаем конфигурацию и скрипт контроля IPsec:

Пароль <SECRET>, указанный в конфигурации, должен быть одинаковым на обеих виртуальных машинах VPN.

Далее нам надо обновить IPsec-конфигурацию и конфигурацию секрета IPsec так, чтобы там был указан VIP вместо основного адреса. То есть конфигурация IPsec и конфигурация секрета будет идентична на vpn1 и vpn2.

Перезагружаем keepalived и проверяем статус IPsec:

Заключение

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

Зарегистрируйтесь в панели управления

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

Записки IT специалиста

Настраиваем IPsec-туннель между офисами на оборудовании Mikrotik

Автор: Уваров А.С.
15.01.2022

Задача объединения нескольких сетей в разных офисах одна из наиболее часто встречающихся у системных администраторов. Для ее решения могут использоваться различные виды VPN и туннельных соединений, выбор которых может зависеть от множества требований и условий. Одной из альтернатив туннелям и VPN может служить «чистое» IPsec-соединение, которое имеет как свои достоинства, так и недостатки. В данном материале мы рассмотрим реализацию подобного соединения между сетями офисов (site-to-site) c использованием оборудования Mikrotik.

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

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

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

Далее мы рассмотрим объединение двух офисных сетей по представленной ниже схеме:

Где LAN 1 с диапазоном 192.168.111.0/24 и LAN 2 — 192.168.186.0/24 — это сети двух офисов, которые мы будем объединять, а 192.168.3.107 и 192.168.3.111 — выполняют роль внешних белых адресов в сети интернет. Наша задача обеспечить прозрачный доступ устройств одной сети в другую через защищенный канал связи.

Настройка IPsec соединения

Соединение IPsec имеет отличия как от предусматривающего клиент-серверную схему VPN, так и от stateless туннелей. В отличие от последних мы всегда можем проверить состояние соединения, но понятие клиента и сервера здесь отсутствует, в IPsec одно из устройств выступает в качестве инициатора (initiator), а второе в качестве ответчика (responder). Эти роли не являются жестко закрепленными и могут меняться между устройствами, хотя при необходимости мы можем закрепить за определенным устройством постоянную роль.

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

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

Так популярный RB750Gr3 (hEX) поддерживает аппаратное ускорение только SHA1/SHA256 — AES-CBC, а более новый RB3011 уже поддерживает SHA1/SHA256 — AES-CBC и SHA1/SHA256 — AES-CTR. Желание использовать сильные шифры безусловно похвально, но оно не должно опережать возможности имеющегося оборудования.

Первая фаза — обмен ключами и взаимная идентификация устройств, за ее настройки отвечает раздел IP — IPsec — Profiles, перейдем в него и создадим новый профиль. Для него укажем: Hash Algorithms — sha1, Encryption Algorithm — aes-256, DH Group — ecp384. В поле Name укажем имя профиля, в нашем случае ipsec-sts (site-to-site).

В терминале для выполнения этого же действия выполните:

Это достаточно сильные настройки шифров, для устройств без аппаратного ускорения мы бы посоветовали ограничиться aes-128 и modp1024, хотя никто не мешает протестировать желаемые варианты и остановиться на наиболее оптимальном.

Вторая фаза — установление защищённого соединения и передача данных, настройки шифров для нее задаются в IP — IPsec — Proposal, перейдем в данный раздел и создадим новое предложение. Укажем Auth. Algorithms — sha1, Encr. Algorithms — aes-256-cbc, PFS Group — ecp384.

Это же действие в терминале:

В данном примере мы использовали не самые сильные шифры, так режим шифрования CBC является наиболее слабым и при наличии аппаратной поддержки стоит использовать CTR или GCM. Но не забывайте о достаточной разумности, если нагрузка на устройство велика — понижайте уровень шифрования.

Теперь перейдем в IP — IPsec — Peer и создадим новое подключение. В поле Address указываем внешний адрес второго роутера, в Profile выбираем созданный нами на предыдущем этапе профиль, в нашем случае ipsec-sts, а в поле Exchange Mode указываем IKE2.

В терминале:

В целом того, что мы уже настроили достаточно для установления защищенного соединения, но IPsec не VPN и работает по-другому. Для того, чтобы трафик начал шифроваться он должен соответствовать одной из политик IPsec, поэтому перейдем в IP — IPsec — Policies и создадим новую политику. В поле Peer укажем созданное ранее соединение, ниже установим флаг Tunnel для работы соединения в туннельном режиме, в поле Src. Address укажем диапазон собственной сети — 192.168.111.0/24, а в поле Dst. Address — диапазон удаленной сети — 192.168.186.0/24.

Затем на закладке Action установите Proposal — ipsec-sts, предложение которое мы создали ранее.

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

Ну и осталось совсем немного — научить узлы идентифицировать друг друга, так как оба роутера контролируются администратором и настроены принимать подключения только от другого узла, то мы будем использовать аутентификацию по предварительному ключу. Перейдем в IP — IPsec — Identities и создадим новую настройку идентификации. Здесь нам нужно заполнить поля: Peer — указываем созданное нами соединение, в нашем случае ipsec-sts, Auth. Method — pre shared key, Secret — предварительный ключ. В качестве предварительного ключа рекомендуется использовать строку с использованием цифр, букв в разных регистрах и специальных символов, сформированных в случайном порядке и с длинной не менее 16-32 символов. Не следует использовать в качестве ключа словарные слова и фразы. Предупреждения внизу окна можно проигнорировать.

В терминале:

На втором узле следует выполнить аналогичные настройки, только в качестве адреса в Peer указав внешний адрес первого роутера, а в Policy поменяв местами сеть источника и сеть назначения.

Настройка брандмауэра

Будем считать, что вы используете нормально закрытый брандмауэр настроенный в соответствии с нашими рекомендациями. Для того, чтобы разрешить входящее IPsec-соединение перейдем в IP — Firewall — Filter Rules и добавим следующие правила. Первое из них разрешает работу протокола обмена ключами IKE: Chain — input, Protocol — udp, Dst. Port — 500,4500, In. Interface — внешний интерфейс, в нашем случае ether1.

Второе правило разрешает протокол шифрования полезной нагрузки Encapsulating Security Payload (ESP): Chain — input, Protocol — 50 (ipsec-esp), In. Interface — внешний интерфейс — ether1.

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

Эти же действия можно быстро выполнить в терминале:

Для того, чтобы пакеты из одной сети могли попасть в другую, следует разрешить их транзит. Создадим еще одно правило: Chain — forward, In. Interface — внешний интерфейс — ether1, затем на закладке Advanced укажем IPsec Policy — in:ipsec. Это разрешит транзит любых входящих пакетов, которые попадают под любую установленную политику IPsec.

В терминале:

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

Обход NAT и Fasttrack

Как мы уже говорили, IPsec не использует интерфейсы, а следовательно, обрабатываемый им трафик, хоть и уходит в защищенный туннель, но продолжает использовать в качестве исходящего внешний интерфейс, что может привести к ряду коллизий. Прежде всего нужно исключить обработку такого трафика правилами snat или masquerade. Для этого перейдем в IP — Firewall — NAT и создадим новое правило: Chain — srcnat, Src. Address — 192.168.111.0/24 — диапазон локальной сети, Dst. Address — 192.168.186.0/24 — диапазон удаленной сети, так как действие по умолчанию accept, то явно его не указываем. Данное правило поднимаем в самый верх, одно должно быть первым в цепочке srcnat.

Через терминал добавить его можно следующей командой:

Опция place-before=0 позволяет поставить правило в самое начало цепочки.

Если вы используете Fasttrack, то также следует исключить обработку проходящего через IPsec трафика этим механизмом, для этого следует добавить два правила. Первое для трафика из локальной сети в удаленную: Chain — forward, Src. Address — 192.168.111.0/24 — диапазон локальной сети, Dst. Address — 192.168.186.0/24 — диапазон удаленной сети, Сonnection State — established, related.

Второе правило для трафика из удаленной сети в локальную, оно полностью повторяет первое, только меняем местами сеть источника (Src. Address) и сеть назначения (Dst. Address).

Аналогичные настройки, с учетом адресов, следует выполнить и на втором узле.

Заключение

После того, как мы завершили процесс настройки перейдем в IP — IPsec — Active Peers и убедимся, что соединение между двумя узлами установлено. Если это не так — еще раз проверяем все настройки и изучаем файл лога, скорее всего у вас не совпадают параметры шифрования или идентификации.

Теперь откроем IP — IPsec — Installed SAs. В терминах IPsec — SA (Security Association) — ассоциация безопасности, обозначает установленное защищенное соединение. Для каждого соединения создается отдельная пара SA, так как каждая SA — это однонаправленное соединение, а данные нужно передавать по двум направлениям. Если запустить обмен данными между сетями, скажем пропинговать с узла одной сети узел другой сети, то мы увидим, что данные счетчика Current Bytes начинают меняться, а следовательно, шифрование работает и данные передаются внутри защищенного соединения.

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

Дополнительные материалы:

Mikrotik

The Dude

Помогла статья? Поддержи автора и новые статьи будут выходить чаще:

Или подпишись на наш Телеграм-канал:

CISCO IPsec

Туннель туннель будет прокидываться между интерфейсами GigabitEthernet0/0 роутеров.

Попробуем симулировать среду 2 граничных роутеров, между которыми Интернет. Поэтому на роутерах настроен NAT. Компьютеры PC1 и PC2 друг-друга напрямую не видят, так как они за натом. Начальная конфигурация R1:

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

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

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

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

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

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

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

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

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

CISCO IPsec

IKE — Самый центровой протокол в IPsec Framework это IKE (Internet Key Exchange). Остальные протоколы работают под его управлением;

Самое первое, IKE должен быть включен для реализации функционала IPsec. Он включен по умолчанию в IOS, но его можно и отключить:

Надо проверить и при необходимости включить:

Существует две версии 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 взаимозаменяемы:

Это не меняет сказанного и никакой путаницы не вносит.

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

Данное действо производится перед всеми другими.

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

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

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

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

Шифрование

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

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

Хорошо, роутеры друг друга аутентифицировали, теперь им нужен ключ для шифрования потока данных. Этого ключа нет в конфигурации, он генерируется, как говорится, «налету».

Для создания туннеля обе стороны должны совместно вычислить общий секретный ключ для симметричного шифрования данных в туннеле (не путать с PSK, который нужен для аутентификации). Всё это надо сделать через публичную сеть Интернета. Как это выполнить? На пустом месте, через небезопасную сеть, договорится о ключе для шифрования?

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

Целостность

Для каждого сообщения вычисляется хеш, который прикладывается к сообщению. Хеш очень короткий, всегда одинаковой длины (определяется алгоритмом), он однозначно определяет исходное сообщение. При получении высчитывается хеш полученного сообщения, он сравнивается с приложенным хешем. Если значения 2 хешей совпадают, значит сообщение не было изменено.

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

В результате, атакующий после изменения сообщения не сможет вычислить нужный хеш, так как у него нет ключа. А вычислить ключ по исходному сообщению и хешу для сообщение+ключ он тоже не сможет. Точнее, на это нужно время, чем устойчивее алгоритм хеширования, тем больше времени нужно на взлом. Рекомендуется SHA256 и выше.

Загрузка CPU

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

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

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

При высокой нагрузке алгоритмы брать попроще. В примере буду использовать сильные алгоритмы. В продакшене видел люди не парятся, используют 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 и нужно понимать в каком порядке вводить команды, а также что значит каждая команда.

Чистый 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 туннеля снижается.

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

CISCO IPsec

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

Фаза 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 пира):

Формат команды тут:

Значение для адреса 0.0.0.0 0.0.0.0 может быть использовано чтобы матчить с любым пиром.

Crypto ACL

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

Этот ACL ничего не разрешает и ничего не запрещает, у него другие функции. Он только для отбора трафика. Трафик, который удовлетворяет строкам permit (у нас тут одна строка), будет зашифрован и передан через туннель. А трафик, который удовлетворяет строкам deny (у нас неявный запрет в конце списка), будет передан как обычно.

Неплохо будет добавить пояснение что это за ACL, повышает читаемость конфигурации:

Фаза 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:

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

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

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

Ещё тут можно настроить дополнительные параметры IPsec SA:

Выделено цветом глобально заданное время жизни для SA второй фазы. Это значение можно переопределить в Crypto Map. Дополнительные параметры оставляю по умолчанию.

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

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

Crypto Map

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

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

Номер имеет важное значение. На 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.

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

Привязываем ACL, сет алгоритмов и адрес удалённого роутера. Тут строку set peer можно повторить несколько раз, чтобы указать несколько возможных значений. Предпочитаемый пир можно обозначить параметром default после IP адреса.

Команда для трансформ сет имеет формат:

Можно указать несколько сетов, они будут перебираться согласно своего порядка, пока один из них не сматчит и туннель не установится.

Дополнительные возможности 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:

CISCO IPsec

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

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

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

Разрешение ICMP

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

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

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

Проверка IPsec

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

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

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

Тест туннеля

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

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

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

Тут надо заметить что эта команда выводит результат для каждой строчки (ACE) из Crypto ACL. Поскольку у нас 1 ACE, вывод такой, было бы 2 ACE, вывод был бы в два раза длиннее. По результатам: пакеты бегают, PFS работает. Также полезная команда show crypto session [ brief | detail ].

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

CISCO IPsec

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

К вопросу о Lifetime

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

Нету туннеля. Вопрос закрыт. Полные конфы 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, об этом говорил в этой статье. Для наших роутеров получится примерно так:

GRE over IPsec

Вторая часть статьи, в ней мы перенастроим чистый IPsec с помощью GRE. Такой вариант вполне уже можно использовать в продакшене.

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

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

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

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

CISCO 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 роутеров. Возможно очевидно, но сам по себе это важный факт.

CISCO IPsec

В первом IP заголовке: протокол GRE, IP 47:

CISCO IPsec

Добавляем IPsec

Теперь добавим IPsec:

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

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

Сокращение накладных расходов

Чем меньше будет служебных заголовков, тем больше места под полезную нагрузку.

CISCO IPsec

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

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

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

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

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

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

GRE Keepalive

Поскольку у нас туннель GRE, мы можем как вариант пользоваться Keepalive именно для GRE (о Crypto Isakmp Keepalive сказано выше). Механизм работы GRE Keepalive рассказан в статье CISCO GRE. Проверяем:

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

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

CISCO IPsec

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

На пути следования пакета в туннеле может попасться роутер, у которого на интерфейсе MTU < 1400. В этом случае, хотя всё настроено правильно, будет фрагментация. Для такого случая нужно чтобы туннель автоматически проверял MTU по всему пути:

Это общие рекомендации, они могут не подойти для каких-то конкретных случаев. Различные аспекты устранения фрагментации (с примерами) рассказаны тут.

Какой ipsec используется для настройки vpn