Left, Right, Center Left, Center, Right Center, Left, Right

Академия

Мы -- официальная сетевая академия Cisco (ID: 20027250)

Хочешь сказать спасибо?

Нравится наш проект?

Хотите нас поддержать (сказать "спасибо")?

Можете воспользоваться для этого следующими кошельками webmoney

R432847347204

Z150172555537

Подписка на новости

Вопрос недели

В какое время Вам будет удобно заниматься?



 

Вход в систему







Забыли пароль?
Регистрация

Про виртуальные сети (часть 9). Рассматриваем настройку VPN (GRE + IPSec) между виртуальными маршрутизаторами.

Статьи

Продолжим цикл статей про виртуальные сети, который по некоторым причинам затих. Напомним, в крайней написанной статье рассматривался вопрос настройки статического NAT, динамического NAT (Dynamic NAT Overload – PAT) и некоторые нюансы, которые могут возникать при данной настройки. В будущем мы еще вернемся к вопросу настройки NAT, так как есть еще интересные моменты, которые могут понадобиться для решения определенного круга задач (к примеру, объединение виртуальных сетей). Речи идет в частности про inter-VRF NAT. В данной же статье мы рассмотрим вопросы настройки виртуальных частных сетей (Virtual Private Network – VPN), используя довольно распространенные технологии, такие как GRE (Generic Routing Encapsulation) и IPSec (IP Security). GRE хорош тем, что пропускает мультикаст трафик, позволяет устанавливать соседство для протокола маршрутизации через данный тоннель, что упрощает построение сети и много чего другого вкусного и полезного. Но по-умолчанию весь трафик идет через GRE-тоннель в незашифрованном виде, что является огромной уязвимостью. IPSec не обладает такими функциями в плане построения сети, однако он может осуществлять шифрование трафика, в том числе алгоритмом AES, который на сегодняшний день является одним из самых надежных симметричных алгоритмов шифрования. Поэтому совместное использование данных технологий (GRE + IPSec) вполне обоснованно и позволяет получить VPN с хорошими показателями, как функционала, так и безопасности.

 

После такого небольшого ликбеза, перейдем к самой настройке.

Физическая топология у нас будет такая же, как и всегда для данного цикла статей, она приведена в третьей статье. Логическая топология приведена в той же статье за подписью «Виртуальная сеть №3», но мы ее здесь продублируем. Итак, наша схема для данной статьи выглядит следующим образом:

VPN мы будем строить между виртуальными маршрутизаторами V4R2 и V4R3. Собственно, IP адресацию мы специально подбирали таким образом, чтобы имитировать публичную и приватную адресацию. Маршрутизация, как таковая, нас в данной статье интересовать не будет. Мы можем использовать как статическую, что в купе с логикой разделения сети на приватный и публичный сегмент и маршрутами по умолчанию будет очень простым и лаконичным решением, так и несколько протоколов динамической маршрутизации. Фактически маршрутных домена тут будет два: публичный и приватный домены. Мы будем использовать статическую адресацию в публичном домене и OSPF в приватном, чтобы показать работу этого протокола динамической маршрутизации через GRE тоннель.

Сначала настроим саму маршрутизацию (Приведем пример конфига для R4 (V4R1, V4R5) – остальные по аналогии):


R4#show run ! ip cef ip vrf V4R1 rd 65001:1 ! ip vrf V4R5 rd 65001:5 ! interface Loopback41 ip vrf forwarding V4R1 ip address 10.0.0.1 255.255.255.0 ! interface Loopback45 ip vrf forwarding V4R5 ip address 172.16.0.1 255.255.255.0 ! interface FastEthernet0/0 no ip address duplex auto speed auto ! interface FastEthernet0/0.40 encapsulation dot1Q 40 ip vrf forwarding V4R1 ip address 10.0.10.1 255.255.255.0 ! interface FastEthernet0/0.43 encapsulation dot1Q 43 ip vrf forwarding V4R5 ip address 172.16.10.1 255.255.255.0 ! router ospf 1 vrf V4R1 router-id 10.0.0.1 capability vrf-lite network 10.0.0.0 0.0.255.255 area 0 ! router ospf 2 vrf V4R5 router-id 172.16.0.1 capability vrf-lite network 172.16.0.0 0.0.255.255 area 0 !

Не забываем указать в настройках OSFP «capability vrf-lite»! Понятное дело, что внутри каждого домена маршрутизации трафик ходит, но между двумя приватными нет: на V4R3 нет маршрутов о 10.0.0.0/8 и 172.16.0.0/16. И так как мы строим VPN поверх публичной сети, их там быть не должно. Кроме того, надо не забыть указать на V4R2 и V4R4 статический маршрут по умолчанию в сторону V4R3.

Дальше построим GRE туннель между виртуальными маршрутизаторами V4R2 и V4R4 (конфиг показан для V4R2, с другой стороны будет аналогичный):


R2# ! interface Tunnel0 ip vrf forwarding V4R2 ip address 10.0.100.1 255.255.255.252 tunnel source 1.1.1.1 tunnel destination 2.2.2.2 tunnel vrf V4R2 !

Опять же фокус, не забываем указать vrf, из которого строиться туннель, командой «tunnel vrf …». Если его не указать – туннель не поднимется и счастья не будет.

Теперь добавим OSPF в туннель, в ту же area 0, где у нас находятся остальные подсети в пределах частной адресации:


R2# router ospf 1 vrf V4R2 network 10.0.100.1 0.0.0.0 area 0

Как только туннели будут настроены с обоих сторон, мы увидим, что соседство установлено через туннель. Вывод команды «show ip route vrf V4Rx» покажет все маршруты, объявленные в OSPF (в том числе статические, если Вы, к примеру, объявляли маршруты по умолчанию на виртуальных маршрутизаторах V4R2 и/или V4R4), хотя для целей данной статьи это может и не имеет большого значения, так как NAT на V4R2 и V4R4 мы не настраиваем.

А дальше начинаются фокусы. Основной фокус заключается в том, что профиль ISAKMP необходимо привязать к VRF, иначе ничего работать не будет. Приводить неправильный конфиг и описывать долгий и тернистый путь к успеху мы не будем, поэтому сразу перейдем к делу. Итак, настройка ISAKMP для виртуального маршрутизатора V4R2 выглядит следующим образом:


R2#show run ! crypto keyring VRF vrf V4R2 pre-shared-key address 2.2.2.2 key 123 ! crypto isakmp policy 10 encr aes 256 authentication pre-share group 5 crypto isakmp profile VRF vrf V4R2 keyring VRF match identity address 2.2.2.2 255.255.255.255 V4R2 !

Как видно из приведенного конфига, разницы в настройки части политики нет. Но разница есть во всем остальном. Для аутентификации необходимо создать ключ, который будет привязан к VRF. Затем мы создаем ISAKMP профиль, в котором опять же указываем принадлежность его определенному VRF, а также указываем используемый ключ (сконфигурированный чуть раньше) и адрес узла, с которым будем устанавливать туннель.

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


R2#show run ! crypto ipsec transform-set V4R2 esp-aes 256 esp-sha-hmac ! crypto ipsec profile tun set transform-set V4R2 !

В настройке IPSec уже нет необходимости указывать vrf, к которому принадлежит transform-set или профиль, - здесь все так же, как и в настройке IPSec без виртуализации.

Финальной стадией является привязка профиля к интерфейсу туннеля:


R2#show run ! interface Tunnel0 tunnel protection ipsec profile tun shared !

Вот мы и получили работающую виртуальную сеть с защищенным GRE туннелем, в котором эта самая защищенность реализуется средствами IPSec. Чтобы убедиться, что все хорошо, можно снять трафик каким-либо снифером на участке V4R2-V4R3 или V4R3-V4R4 и посмотреть, что трафик между сетями 10.0.0.0/16 и 172.16.0.0/16 бежит в зашифрованном виде.

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

Удачи, друзья!

Пожалуйста, зарегистрируйтесь или войдите в систему для добавления комментариев к этой статье.
Share to Facebook Share to Twitter Share to Linkedin Share to Myspace Share to Google 
.