Hard: Cisco 1800/2800/3800 (лично протестировано на указанных маршрутизаторах).
Предположим, перед нами задача соединения удалённых сегментов "IP-сети" используя стороннего провайдера в качестве опоры (транспорта) для построения инфраструктуры. Провайдеру мы не доверяем; хотя бы и потому, что не доверяем никому. Нужно шифровать трафик проходящий через стороннее оборудование. Ранее я описывал простой способ избирательного шифрования трафика проходящего через интерфейс с помощью IPSec, но после появления комментариев с благодарностью за предоставленные инструкции от сотрудников банков и компаний средних размеров решил, во избежание приумножения количества низкопробных конфигураций, описать методику создания шифрованных туннелей, более подходящую для создания разветвлённых географически разнесённых сетевых инфраструктур.
Учитывая то, что все подведомственные мне магистрали управляются исключительно с помощью оборудования Cisco (унификация и простое масштабирование в производстве важнее мелких фишек, которые можно получить от "PC-стайл" или просто разномастных решений), туннели делать будем на комбинации технологий, объединённых в единый инструмент "Cisco IPSec VTI" (где VTI раскрывается как "Virtual Tunnel Interface"), сильно облегчающий туннелирование с шифрованием. "Cisco IPSec VTI" - это инструмент создания интерфейсов с возможностями маршрутизации, служащий для настройки туннелей зашифрованных IPSec и упрощения конфигурации "Site-to-Site VPN". Туннели "Cisco IPSec VTI" обеспечивают выделенный путь следования по опорным точкам сторонних провайдеров (совместно используемой WAN) и инкапсуляцию трафика с новыми заголовками пакетов.
Примем за данность следующее:
Адресация опорных точек сети провайдера: 10.168.{10,20}.0/30;
Адресация связующего сегменты туннеля: 10.172.5.0/30;
Адресация сегментов сетей: 192.168.{10,20}.0/24.
Адресация связующего сегменты туннеля: 10.172.5.0/30;
Адресация сегментов сетей: 192.168.{10,20}.0/24.
Схема соединений, в самом простом отображении, такова:
+-----------------+
| network: |
| 192.168.10.0/24 |
+-------+---------+
|
+-------+-------+
| tunnel: |
| 10.172.5.1/30 |
+-------+-------+
|
+-------+--------+
| provider gate: |
| 10.168.10.2/30 |
+-------+--------+
|
+-------+-----------+
| provider network: |
| 10.168.10.1/30 |
| .... |
| 10.168.20.1/30 |
+-------+-----------+
|
+-------+--------+
| provider gate: |
| 10.168.20.2/30 |
+-------+--------+
|
+-------+-------+
| tunnel: |
| 10.172.5.2/30 |
+-------+-------+
|
+-------+---------+
| network: |
| 192.168.20.0/24 |
+-----------------+
| network: |
| 192.168.10.0/24 |
+-------+---------+
|
+-------+-------+
| tunnel: |
| 10.172.5.1/30 |
+-------+-------+
|
+-------+--------+
| provider gate: |
| 10.168.10.2/30 |
+-------+--------+
|
+-------+-----------+
| provider network: |
| 10.168.10.1/30 |
| .... |
| 10.168.20.1/30 |
+-------+-----------+
|
+-------+--------+
| provider gate: |
| 10.168.20.2/30 |
+-------+--------+
|
+-------+-------+
| tunnel: |
| 10.172.5.2/30 |
+-------+-------+
|
+-------+---------+
| network: |
| 192.168.20.0/24 |
+-----------------+
Туннелирование в нашем случае симметричное, то есть настройки полностью идентичны на обеих сторонах, за исключением, разумеется, точек отправления, назначения и маршрутизации трафика, потому приведу пример обобщённой конфигурации, воссоздать из которой пару зеркальных вариантов не составит труда.
Прежде всего обеспечиваем маршрутизацию по всем опорным точкам провайдера, указывая на расположение диапазонов выделенных для магистрального оборудования:
!* Reference-points
ip route 10.168.{10,20}.0 255.255.255.252 "next hop to destination"
ip route 10.168.{10,20}.0 255.255.255.252 "next hop to destination"
Включаем и описываем общие параметры политики шифрования IKE (ISAKMP) (так называемая "первая фаза" IPSec):
!* IKE (ISAKMP) encryption profile (first phase of IPSec encryption)
crypto isakmp enable
crypto isakmp policy 1
encryption aes 256
hash sha
authentication pre-share
group 2
exit
crypto isakmp enable
crypto isakmp policy 1
encryption aes 256
hash sha
authentication pre-share
group 2
exit
Выше определением "группы" Diffie-Hellman (DH) задаём "силу" ключа шифрования, который используется в процедуре обмена ключами (group 1: 768-bit key, group 2: 1024-bit key, group 5: 1536-bit key).
Определяем общие параметры туннелирования и протокола шифрования для направлений (так называемая "вторая фаза" IPSec). Учитывая то, что каналы однотипные, создаём единый для всех направлений профиль. В нашем случае ничего, кроме определения контекста как такового, мы не делаем:
!* Transform-set crypto peers profile (second phase of IPSec encryption)
crypto ipsec transform-set CryptoPeersProfile esp-aes esp-sha-hmac
exit
crypto ipsec transform-set CryptoPeersProfile esp-aes esp-sha-hmac
exit
Описываем профиль политики IPsec, единый для всех направлений, который будет применяться непосредственно к создаваемым далее туннельным интерфейсам:
!* VTI IPSec general peers profile
crypto ipsec profile VTIIPSecProfile
set transform-set CryptoPeersProfile
exit
crypto ipsec profile VTIIPSecProfile
set transform-set CryptoPeersProfile
exit
Создаём "pre-shared" ключи для аутентификации подключений по направлениям ("пиров"), по одному уникальному ключу на туннель:
!* Peers pre-shared keys
crypto isakmp key 0 "strong pre-shared key" address 10.168.{10,20}.2
crypto isakmp key 0 "strong pre-shared key" address 10.168.{10,20}.2
Создаём туннель как таковой, определяем его параметры и привязываем к нему профиль шифрования проходящего через него трафика:
!* Configuration tunnel interfaces
interface Tunnel0
description VTI-IPSec from 10.168.{10,20}.2 to 10.168.{20,10}.2 via provider network
ip address 10.172.5.{1,2} 255.255.255.252
tunnel source "interface|address"
tunnel mode ipsec ipv4
tunnel destination 10.168.{20,10}.2
tunnel protection ipsec profile VTIIPSecProfile
exit
interface Tunnel0
description VTI-IPSec from 10.168.{10,20}.2 to 10.168.{20,10}.2 via provider network
ip address 10.172.5.{1,2} 255.255.255.252
tunnel source "interface|address"
tunnel mode ipsec ipv4
tunnel destination 10.168.{20,10}.2
tunnel protection ipsec profile VTIIPSecProfile
exit
Направляем в туннель интересующий нас трафик, в примере - весь:
!* Networks
ip route 0.0.0.0 0.0.0.0 10.172.5.{2,1}
ip route 0.0.0.0 0.0.0.0 10.172.5.{2,1}
Важно следить за тем, чтобы маршрутизация туннелируемой сети не смешивалась с маршрутизацией транспортной сети. В противном случае могут образовываться зацикленные маршруты, что не "есть гуд".
Отслеживать состояние подсистемы шифрования можно с помощью следующих запросов с "говорящим" выводом:
show crypto isakmp sa
show crypto map
sh crypto session
show crypto map
sh crypto session
18 сентября 2012 в 15:42
18 сентября 2012 в 21:18
2 октября 2012 в 16:47
2 октября 2012 в 20:04
14 января 2015 в 13:41
14 января 2015 в 17:08
1 февраля 2017 в 17:44
1 февраля 2017 в 18:51