Меню

get vpn cisco настройка

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

Полезно

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

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

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

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

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

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

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

Навигация

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

Телефония

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

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

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

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

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

Поднимаем OSPF на оборудовании Cisco

Траблшутинг DHCP на оборудовании Cisco

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

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

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

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

Читайте также:  настройка bios pci pnp
Шаг 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!

Полезна ли Вам эта статья?

Пожалуйста, расскажите почему?

😪 Нам жаль, что статья не была полезна для вас 🙁 Пожалуйста, если не затруднит, укажите по какой причине? Мы будем очень благодарны за подробный ответ. Спасибо, что помогаете нам стать лучше!

😍 Подпишитесь на нашу еженедельную рассылку, и мы будем присылать самые интересные публикации 🙂 Просто оставьте свои данные в форме ниже.

источник

Cisco Group Encrypted Transport Virtual Private Network (GET VPN)

Cisco GET VPN — новая технология от Cisco, призванная обеспечить безопасность туннелей через провайдерские соединения, обладающая рядом полезных особенностей. Ее описанию, особенностям и настройке и посвящена эта статья.

Начнем по традиции с постановки задачи. Классическая топология представляет собой несколько филиалов, соединенных с помощью провайдерской сети.

Требуется соединить сети за филиалами между собой. Наиболее распространенное решение — IPSec и в частности — DMVPN. Который кроме всего прочего, является туннельной технологией и позволяет использовать публичные Internet каналы. Недостатком такого решения является то, что сеть строится по принципу hub-n-spoke, а туннели spoke-to-spoke устанавливаются по необходимости, что не совсем удобно.

Другим распространенным вариантом является MPLS VPN, который хотя и позволяет построить легко масштабируемую сеть, не обеспечивает требуемую в некоторых случаях конфиденциальность. Cisco GET VPN разработана в большей степени именно для MPLS VPN сетей, позволяя обеспечить шифрование передаваемых данных без ущерба для масштабируемости и достижимости spoke-to-spoke.

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

Читайте также:  настройка кинект с фрибутом

Общие понятия.
В дальнейшем я предполагаю, что читатель знаком с технологией и терминологией IPSec.

Новшеством GET VPN является введение понятия «доверенной группы«, все члены которой разделяют одну и ту же IPSec SA (security association). Это позволяет любому члену группы (GM, group member) расшифровать трафик, зашифрованный любым другим GM. Кроме того, поскольку расшифровать наше сообщение может каждый GM, мы можем рассылать мультикасты.

Для всех GM определяются одни и те же ключи шифрования. Реализуется это с помощью протокола GDOI (Group Domain of Interpretation). Используется два различных ключа: один для шифрования данных, другой для шифрования контрольных сообщений. Пакет, который требуется передать, инкапсулируется ESP с помощью полученного общего ключа.

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

За синхронизацию и обновление ключей отвечают сервера ключей (KS, key servers). Все политики шифрования, используемые протоколы, «интересный» трафик, таймеры и т.п. настраиваются на KS и распространяются по всем GM. GM сначала аутентифицируются в IKE Phase 1, а затем получают необходимые данные от KS во время регистрации. Другими словами, на GM настраиваются только параметры IKE Phase 1 и KS. Остальное он получает автоматически.

Кроме того, поскольку KS фактически становится точкой отказа для всей сети, предусмотрена возможность создания нескольких KS, называемые COOP KS (cooperative KS), с возможностью подхватывать функции в режиме холодного резерва.

Переходим от терминологии к собственно настройке GET VPN на Cisco IOS.

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

Конфигурацию GET VPN можно разбить на несколько этапов:

  1. Конфигурация PKI (опционально)
  2. Конфигурация IKE Phase 1
  3. Конфигурация GDOI группы
  4. Конфигурация IPSec profile на KS и crypto map на GM
  5. Конфигурация COOP KS (опционально)

Этап 1. Общий для KS и GM.
Настраиваем роутеры на получение сертификатов от CA. Это тема для отдельной небольшой статьи, поэтому в дальнейшем я буду считать, что сертификаты мы получили. Единственным замечанием будет необходимость делать ключи на KS как exportable, поскольку они должны быть одинаковы для всех COOP KS.

Этап 2. Привычным образом настраиваем crypto isakmp policy. Я опишу политику с использованием PKI, для pre-shared все аналогично.

crypto isakmp policy 10
encr aes
lifetime 1200
group 2

Несколько замечаний.
1) Cisco рекомендует использовать AES, как наилучший по соотношению криптостойкость/ресурсы процессора. Напомню, что по умолчанию, для isakmp policy аутентификация rsa-sig, поэтому строчка с ней не появляется в конфиге.
2) Рекомендованное значение для rekey — 1200 с. Cisco рекомендует делать его в диапазоне 15-30 минут, с дефолтом в 20.

Этап 3. Самая серьезная часть.
3.1. Настройка KS
Создаем gdoi — группу.
crypto gdoi group getvpn

Далее, задаем идентификатор группы. Должен быть одинаковый у всех KS и GM
identity number 1234

Идентифицируем наш роутер как KS
server local

Настраиваем смену IPSec ключей (именно их, а не ISAKMP) раз в сутки
rekey lifetime seconds 86400

Задаем схему повторной передачи при смене ключей (бывают двух видов: два раза с интервалом 60с или три раза с интервалом 40с)
rekey retransmit 40 number 3

Настраиваем аутентификацию.
rekey authentication mypubkey rsa getvpn-export-general
Здесь getvpn-export-general — наши ключи, полученные от CA.

Далее задаем, каким способом обновлять ключи, unicast или multicast.
rekey transport unicast

Далее собственно настраиваем group IPSec SA:
sa ipsec 1

Привязываем профиль IPSec
profile GETVPN_PROFILE

Определяем, что шифровать
match address ipv4 199

Здесь я позволю себе остановиться подробнее. Дело в том, что для традиционных p2p IPSec -туннелей принято описывать интересный трафик наиболее конкретным образом. например, для туннеля между R1 и R2 мы бы написали на R1:
access-list 199 permit ip 10.0.1.0 0.0.0.255 10.0.2.0 0.0.0.255

Читайте также:  nikon d5000 заводские настройки

Поскольку в GET VPN концов туннелей множество, то и таких записей получится очень много. Поэтому Cisco рекомендует максимально суммаризовать ACE. Например в нашем случае лучше всего записать ACL 199 так:
access-list 199 permit ip 10.0.0.0 0.0.255.255 10.0.0.0 0.0.255.255
Это приведет к значительному сокращению числа SA.

Далее настраиваем TBAR (защита от повторов, основанная на временном окне)
replay time window-size 5
И задаем адрес, с которого будем управлять сменой ключей.
address ipv4 192.168.1.1

3.2. Настройка GM.
Здесь все значительно проще, фактически нам нужно указать, какой группе мы принадлежим (с помощью identity number) и KS этой группы.
crypto gdoi group getvpn
identity number 1234
server address ipv4 192.168.1.1

Этап 4.
4.1. Настройка KS.
На KS необходимо создать настройки, которые будут спущены GM.
crypto ipsec transform-set GETVPN_SET esp-aes esp-sha-hmac
crypto ipsec profile GETVPN_PROFILE
set security-association lifetime seconds 7200
set transform-set GETVPN_SET

4.2 Настройка GM
Надо привязать группу GET VPN к криптокарте.
crypto map getvpn-map 10 gdoi
set group getvpn

Этап 5. Оставим для еще одной статьи, если тема заинтересует 🙂 Раз заинтересовала — давайте рассмотрим. Как уже упоминалось, мы можем сконфигурировать несколько KS, один из которых будет основным, а другие — подхватывать его функции при падении.
Итак, чтобы настроить COOP KS нужно следующее:

  1. Необходимо сконфигурировать RSA ключи на основном KS и экспортировать оба ключа (частный и публичный) на все COOP KSs.
  2. Необходимо настроить собственно redundancy

С ключами, я думаю все знакомы.
Генерируем exportable ключи:
Primary_KS(config)#crypto key generate rsa general-keys label getvpn-keys modulus 1024 exportable

Экспортируем их:
Primary_KS(config)#crypto key export rsa getvpn-keys pem terminal 3des Ci$co

И импортируем на всех COOP KS:
COOP_KS(config)# crypto key import rsa getvpn-keys pem exportable terminal Ci$co

Обязательно включаем ISAKMP keepalive, чтобы они могли обнаружить смерть друг друга
сrypto isakmp keepalive 15 periodic

Заходим в нашу группу
crypto gdoi group getvpn
server local

Включаем избыточность:
redundancy

Назначаем приоритет (сервер с высшим приоритетом будет primary, если приоритеты равные — primary будет KS c наибольшим IP адресом)
local priority 100

И указываем ему всех остальных KS
peer address ipv4 192.168.2.1
peer address ipv4 192.168.3.1

И настроим таймеры:
protocol timeout refresh 20
protocol timeout periodic 30
protocol retransmit 2

Timeout refresh — интервал, с которым primary KS шлет сообщения остальным. По умолчанию, 20с
Timeout periodic — если в течение этого времени secondary KS не получает refresh сообщения, он информирует все остальные KS о проблемах с primary.
Retransmit — количество сообщений от secondary KS всем остальным KS при не получении сообщения от primary. По умолчанию, отправляется 2 сообщения, после чего KS переопределяют свои роли.

По традиции, несколько замечаний.

  1. COOP KS рассылают свои сообщения на порт UDP 848, при этом в сообщениях содержится информация о всех GM и политиках. Сообщение растет с увеличением числа GM и потребует фрагментации. Для того, чтобы KS нормально обрабатывали такие сообщения, возможно придется увеличить системный буфер:
    buffers huge size 65535
  2. COOP KS должны иметь одинаковую конфигурацию GET VPN. Это не происходит автоматически.
  3. COOP KS могут регистрироваться друг на друге еще и как GM.

В заключение остается только повесить наш crypto map на интерфейс и учесть дополнительные затраты на заголовок:
ip tcp adjust-mss 1360

Таким образом, подводя итоги:

  1. Мы имеем новую технологию, позволяющую шифровать соединения между офисами.
  2. Основная область применения — повышение конфиденциальности MPLS VPN.
  3. Достоинства — нативная поддержка spoke-to-spoke соединений, высокая масштабируемость и поддержка мультикастов.
  4. Недостатки — прямое следствие из отсутствия туннелей — ограниченная до невозможности работа через public Internet.
  5. Особенностью является наличие общих IPSec ключей, позволяющих всем членам группы расшифровывать сообщения, посланные другими членами этой группы.

Опять-таки не претендую на полноту изложения. За кадром остались и настройка COOP KS, и поддерживаемые модели роутеров и много еще чего. Если тема заинтересует — рассмотрим глубже, а пока разрешите на этом откланяться 🙂

UPD 1. Спасибо за ценные замечания quickshooter и Fedia

источник

Добавить комментарий

Adblock
detector