Одна из самых востребованных технологий – защита канала передачи данных. Самая распространенная и безопасная технология – IPSec. Попробуем построить самый простой туннель между маршрутизатором vyatta и маршрутизатором cisco с использованием предустановленных ключей (pre-shared key).
Забегая вперед скажу, что все настройки интуитивно понятны и туннель поднялся без проблем. Vyatta использует Openswan IPSec 2.4.
Итак, как известно, построение IPSec идет в 2 фазы: IKE Phase I и IKE Phase II
Первая фаза работает по протоколу isakmp (UDP/500). Для её настройки нам надо задать политику создания первичного (служебного) туннеля и ключ для аутентификации.
Создадим политику isakmp с именем {IKENAME}, в которой будет один шаблон (номер 1):
[edit]
edit vpn ipsec
[edit vpn ipsec]
edit ike-group {IKENAME} proposal 1
[edit vpn ipsec ike-group {IKENAME} proposal 1]
set dh-group {2|5}
[edit vpn ipsec ike-group {IKENAME} proposal 1]
set encryption {3des|aes128|aes256}
[edit vpn ipsec ike-group {IKENAME} proposal 1]
set hash {md5|sha}
[edit vpn ipsec ike-group {IKENAME} proposal 1]
commit
Как видно, надо настроить группу Диффи-Хелман для выработки общего ключа для первичной сессии (только группы 2 и 5), метод шифрования (заметьте: DES не поддерживается) и алгоритм хэширования. В-отличие от маршрутизаторов cisco, в политике не указывается способ аутентификации. Его мы выбираем отдельно для каждого конкретного соседа и для каждого соседа указываем ключ, если используется аутентификация по предустановленному ключу (pre-shared key)
[edit vpn ipsec]
edit site-to-site peer {IP}
[edit vpn ipsec site-to-site peer {IP}]
set authentication mode {pre-shared-secret|rsa}
[edit vpn ipsec site-to-site peer {IP}]
set authentication pre-shared-secret {КЛЮЧ}
[edit vpn ipsec site-to-site peer {IP}]
commit
Теперь определим политику создания вторичного туннеля (IKE Phase II) с одним запросом (proposal 1)
[edit vpn ipsec]
edit esp-group {ESPNAME}
[edit vpn ipsec edit esp-group {ESPNAME}]
set proposal 1 encryprion {3des|aes128|aes256}
[edit vpn ipsec edit esp-group {ESPNAME}]
set proposal 1 hash {sha|md5}
[edit vpn ipsec edit esp-group {ESPNAME}]
set lifetime {#seconds}
[edit vpn ipsec edit esp-group {ESPNAME}]
set mode {tunnel|transport}
[edit vpn ipsec edit esp-group {ESPNAME}]
set pfs {enable|disable}
[edit vpn ipsec edit esp-group {ESPNAME}]
commit
Задать Диффи-Хелман группу отдельно на вторичный туннель не получается: можно только включить PFS и вычислять новый ключ для IKE Phase II, но той же группы, что указана в политике isakmp.
Теперь укажем, что шифровать для каждого соседа, как строить с ним первичный вторичный туннели. А также укажем внешний адрес, с которого будем слать шифрованные пакеты.
[edit vpn ipsec]
set ipsec-interfaces interface {OUT_INTERFACE}
[edit vpn ipsec]
edit site-to-site peer {IP}
[edit vpn ipsec site-to-site peer {IP}]
set ike-group {IKENAME}
[edit vpn ipsec site-to-site peer {IP}]
set tunnel 1 esp-group {ESPNAME}
[edit vpn ipsec site-to-site peer {IP}]
set tunnel 1 local-subnet {LOCAL_NET}
[edit vpn ipsec site-to-site peer {IP}]
set tunnel 1 remote-subnet {PEER_NET}
[edit vpn ipsec site-to-site peer {IP}]
set local-ip {OUR_OUT_IP}
[edit vpn ipsec site-to-site peer {IP}]
commit
Для простейшего случая site-to-site IPSec VPN больше ничего не нужно. Однако, если необходимо, то можно включить и DPD, и NAT-T, указать несколько сетей для шифрования (то, что у cisco описывается при помощи ACL для интересного трафика) к одному соседу и другие стандартные IPSec возможности
Конфигурация будет примерно следующая:
esp-group NEW {
mode tunnel
proposal 1 {
encryption aes128
}
}
ike-group NEW {
proposal 1 {
dh-group 2
}
}
ipsec-interfaces {
interface eth0
}
site-to-site {
peer 192.168.5.1 {
authentication {
pre-shared-secret CISCO
}
ike-group NEW
local-ip 192.168.4.1
tunnel 1 {
esp-group NEW
local-subnet 10.4.4.0/24
remote-subnet 10.5.5.0/24
}
}
}
Примечание: для сравнения в конце этой статьи приводится конфиг IPSec соседского маршрутизатора cisco.
Для нашей топологии ещё важно помнить, что трансляция сетевых адресов (NAT) выполняется до шифрования (это типично для большинства сетевых устройств разных производителей). Поэтому, если мы хотим прозрачно связать две частные сети, то надо исключить трафик, идущий из нашей локальной сети (local-subnet) в чужую локальную сеть (remote-subnet) из трансляции. В простейшем случае это делается при помощи исключающего правила (надо добавить знак «!» перед указанием сети назначения в том правиле, в котором мы описываем трансляцию наружу нашей локальной сети.)
[edit service nat]
edit service nat rule 100
[edit service nat rule 100]
set source address 10.4.4.0/24
[edit service nat rule 100]
set destination address !10.5.5.0/24
[edit service nat rule 100]
commit
Посмотреть созданные первичные туннели можно командой
vyatta@vyatta:~$ show vpn ike sa
Local Peer State Encrypt Hash NAT-T A-Time L-Time
-------- ------- ----- ------- ---- ----- ------ ------
192.168.4.1 192.168.5.1 up aes128 sha1 No 13196 28800
Посмотреть созданные вторичные (для передачи данных) туннели можно командой
vyatta@vyatta:~$ show vpn ipsec sa
Peer Tunnel# Dir SPI Encrypt Hash NAT-T A-Time L-Time
------- ------- --- --- ------- ---- ----- ------ ------
192.168.5.1 1 in 93782005 aes128 sha1 No 624 3600
192.168.5.1 1 out 13c11a86 aes128 sha1 No 624 3600
Чтобы посмотреть пакеты, переданные и полученные, надо добавить ключевое слово statistics
vyatta@vyatta:~$ show vpn ipsec sa statistics
Peer Dir SRC Network DST Network Bytes
------- --- ----------- ----------- -----
192.168.5.1 in 10.4.4.0/24 10.5.5.0/24 240
192.168.5.1 out 10.5.5.0/24 10.4.4.0/24 240
Обращаю внимание, что сосед один, а туннелей – два. Это происходит потому, что номер туннеля (SPI) присваивается отдельно исходящему, а отдельно – входящему соединению.
Также хочу обратить внимание на то, что правило МСЭ отрабатывает уже после того, как мы расшифровали полученный пакет. Поэтому если мы хотим пропускать внутрь трафик из сети соседа в нашу внутреннюю сеть надо добавить
[edit firewall name FROMOUT rule 3]
set action accept
[edit firewall name FROMOUT rule 3]
set source 10.5.5.0/24
[edit firewall name FROMOUT rule 3]
set destination 10.4.4.0/24
[edit firewall name FROMOUT rule 3]
commit
______________________________________
Конфигурация маршрутизатора cisco:
Первичный туннель:
crypto isakmp policy 1
encr aes
authentication pre-share
group 2
crypto isakmp key CISCO address 192.168.4.1
Интересный трафик:
ip access-list extended TEST
permit ip 10.5.5.0 0.0.0.255 10.4.4.0 0.0.0.255
Вторичный туннель:
crypto ipsec transform-set AESSHA esp-aes esp-sha-hmac
crypto map TEST 10 ipsec-isakmp
set peer 192.168.4.1
set transform-set AESSHA
match address TEST
Применение на интерфейс:
(config-if)# crypto-map TEST
____________________________________________
интересные статьи, сейчас как раз занимаюсь подбором по, на что можно заменить циски.
интересует как сделать failover ipsec тунелей, а также балансировку трафика по ним (если например два офиса, у каждого по 2 прова) то что бы при нормальной работе всех провов — работали два туннеля, попарно, и траф между ними балансировался, а при падении одного из них — траф ходил по работающему.. это тут возможно?
Я бы настроил GRE (или IPIP) туннель поверх IPsec, а дальше как в http://www.anticisco.ru/blogs/?p=487
Затраты производительности на GRE невелики, а обращаться можно почти как с физическим интерфейсом.
я вьяту только изучаю, посему для меня — это все еще сложно 🙁 и так бы л очень рад попав на данный блог… вот и ищ готовые решения, хоть и с консоли, и с небольшими переделками под свои задачи 🙂
Вот пример из моего конфига про два GRE поверх IPsec с общей политикой.
http://pastebin.com/rsFA2qNZ
Если нужно срочно или есть существенные трудности, то мы готовы за умеренную плату настроить и проконсультировать 🙂
Просто на вопросы отвечаем за просто так, можно на форуме.
за предложение — спасибо, форум какой имеется ввиду?
а по поводу срочности — у нас эта срочность уже полгода тянется… 🙂 я просто только начал изучать, а изучать — всегда более удобно по примерам.
Форум имеется в виду местный: http://www.anticisco.ru/forum/