Покупка заводов в Сибири была стратегически правильным решением для компании “Лифт ми Ам”. После того, как лифты стали ездить не только вверх, но и вниз, дела компании пошли… нет полетели, вверх. Лифты начали разбирать, как горячие пирожки со стола. Название уже не соответствовало действительности и было принято решение о ребрендинге. (На самом деле их замучила судебная тяжба с Моби).
Итак, под крыло ЛинкМиАп планируется взять заводы в Новосибирске, Томске и Брно. Самое время подумать о том, как это хозяйство подключить к имеющейся сети.

Итак, сегодня рассматриваем
1) Возможные варианты подключения, их плюсы и минусы
2) Site-to-Site VPN на основе GRE и IPSec
3) Большая тема: динамическая многоточечная виртуальная сеть (DMVPN) в теории и на практике.

В традиционном видео лишь ёмкая выжимка из статьи, посвящённая работе и настройке DMVPN.



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

Давайте по порядку.

А) Собственноручно строить физический канал. Тогда это может быть:

1. Ethernet – витая пара. До 100 метров. Максимум по зданию или между соседними строениями. Скорость до 1 Гбит/c (Строго говоря, есть стандарт 10GBASE-T, позволяющий на том же расстоянии передавать данные на скорости 10Гбит/с).
2. WiFi. Расстояние зависит от реализации: можно добиться работоспособности на 40 км при использовании мощных направленных антенн. В среднем до 5 км при прямой видимости. Скорость зависит от используемого стандарта и от расстояния. Необходимо регистрировать в “Роскомнадзоре”, а при больших мощностях излучения и получать разрешение на включение.
3. xDSL – два-четыре провода. Скорость зависит от расстояния (теоретический максимум 250 Мбит/с, расстояние до 6 км). Хотя ходят слухи о разработке стандарта 1Гб/c по двум проводам.
   Или решения вроде E1.
   

   Имеется ввиду не подключение к интернету через xDSL, а именно линк: модеммодем. Да, и такие решения существуют. Можно назвать это мостом.
   

   
   
4. Радио-Релейные Линии. Расстояние до нескольких десятков километров. Скорость до 600 Мб/с. Но это решение уже операторского уровня, поскольку требует массу согласований и мероприятий по планированию, строительству, вводу в эксплуатацию.
5. Оптоволокно. 1Гб/с (решения на 10 и 100 Гб/с могут стоить неоправданно дорого). Расстояние зависит от многих факторов: от нескольких километров до сотен. Необходимы согласования по прокладке кабеля, квалифицированный персонал для строительства и обслуживания. Для небольших компаний есть смысл только для подключения здания не очень далеко от центрального узла. Вообще, конечно, каждый случай индивидуален и требует расчёта.

В этом случае для вас всё прозрачно – вы используете свою собственную физическую линию, поэтому пропускать через неё можете что угодно без ограничений.

Б) Второй вариант – арендовать канал у провайдера. В случае необходимости стабильного канала до другого города – это самый распространённый и надёжный вариант. Провайдер может вам предоставить следующие услуги:

1. Самый настоящий прямой кабель. Например, он может дать вам взаймы одно-два тёмных волокна из своего оптического пучка. Вы вольны отправлять в него всё, что вашей душе угодно. Со стороны провайдера это никак не контролируется, не ограничивается, он осуществляет только поддержку. Например, в случае аварии не вам придётся искать подрядчика и сварочный аппарат, а провайдеру. И за простой несёт ответственность он же. Если у вас это не по обоюдному согласию (читай, взаимозачёт), то, пожалуй, самый дорогой способ.
2. L2VPN. Вы так же можете пускать в канал всё, что угодно, но в данном случае, ваш трафик пойдёт через активное оборудование провайдера, поэтому может ограничиваться, например, по скорости.
   Под этим термином понимается сразу несколько услуг второго уровня:
   VLAN – в том или ином виде между филиалами вам предоставлен VLAN.
   Псевдокабель (PWE3) – это услуга Точка-Точка, когда у вас как будто бы кабель между двумя узлами. Все переданные вами фреймы без изменений доставляются до удалённой точки. Аналогично обратным образом. Это возможно благодаря тому, что ваш фрейм, приходящий на маршрутизатор провайдера инкапсулируется в PDU вышестоящего уровня, как правило, это пакет MPLS.
   VPLS (Виртуальная частная сеть) – это симуляция локальной сети. В этом случае вся сеть провайдера для вас будет как некий абстрактный гигантский коммутатор. Как и настоящий он будет хранить таблицу MAC-адресов и принимать решение о том, куда отправить пришедший кадр. Реализуется это также инкапсуляцией кадра в MPLS пакет.
3. L3VPN. В данном случае сеть провайдера – это как большой маршрутизатор с несколькими интерфейсами. То есть стык у вас будет происходить на сетевом уровне. Вы настраиваете IP-адреса на своих маршрутизаторах с обеих сторон, а вот маршрутизация в сети провайдера – это уже головная боль провайдера. IP-адреса для точек стыка можете либо определять вы, либо выдать провайдер – зависит от реализации и от вашей договорённости. Функционировать это может на основе GRE, IPSec или того же MPLS.

Эта услуга выглядит очень простой с точки зрения клиента – как в плане настройки, так и в плане реализации – но сложной – с точки зрения оператора.
С реализацией L2/L3 VPN на основе MPLS мы будем разбираться, но гораздо позже.

В) Ну и последний вариант: туннель через публичную сеть. Предположим, у вас есть выход в Интернет на обеих ваших точках. Зачастую самым дешёвым способом оказывается построить туннель между этими двумя точками. Для этого вам достаточно всего лишь иметь белые (публичные) статические адреса на всех точках (а иногда достаточно и на одной) и оборудование, на котором это реализовать. У этого решения есть ряд недостатков, которые мы рассмотрим ниже, но тем не менее именно на нём мы сегодня и остановимся.

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

Схема подключения узлов hub and spoke – по-русски говоря, звезда:



Напоминаю, что общая схема сети ЛинкМиАп выглядит сейчас уже так:



Но от неё мы абстрагируемся, напирая только на существенные вещи.

Раз уж мы взялись реализовывать вариант В, то придётся разобраться детально в вариантах.
На сегодняшний день существует неисчислимое множество всевозможных приложений и протоколов для организации VPN, но большая их часть является способами подключения хостов, а не сетей. Мы подразумеваем удалённую работу. Например так:



То есть это схема работы, когда один сотрудник подключается к корпоративной сети удалённо (teleworker в терминологии Cisco).

Откровенно говоря, нам это мало интересно, гораздо занимательнее вопрос, как подключать целые сети.



Сегодня рассмотрим такие самые распространённые варианты:

• GRE
• IPSec (туннельный и транспортный режимы)
• GRE over IPSec
• VTI
• DMVN

GRE

Generic Routing Encapsulation – очень простой протокол туннелирования.
Такс, туннелирование. Это что ещё за зверь? Грубо говоря, это означает, что берутся ваши изначальные данные вместе со служебными заголовками (как правило, это IP, но может быть и Ethernet и ATM), упаковываются в пакет и передаются по публичной сети, словно машина едет в туннеле через горы. На конечном узле заголовки нового пакета снимаются, а ваши данные в исходном виде продолжают своё путешествие.
Не очень понятно, да? Разберём на примере с GRE.

Пока возьмём абстрактную топологию:



Два маршрутизатора подключены к интернету через статические белые адреса. На каждом из них заведены приватные сети из диапазона 10.0.0.0/8.
Разумеется, эти сети не маршрутизируются в Интернете. (На картинке нарисованы компьютер и ноутбук, но на практике мы будем настраивать виртуальный интерфейс Loopback0)
Наша задача прокинуть туннель:



Таким образом для ПК1 при общении с ПК2 не существует никакого Интернета – они оба будут думать, что находятся в одной локальной сети.

Настраивается GRE-туннель следующим образом:

interface Tunnel0
ip address 10.2.2.1 255.255.255.252

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

В качестве адреса источника можно выбрать как IP-адрес выходного интерфейса
(белый адрес, предоставленный провайдером), так и его имя (FE0/0 в нашем случае):

tunnel source 100.0.0.1

Адрес destination – публичный адрес удалённой стороны:

tunnel destination 200.0.0.1

Законченный вид:

interface Tunnel0
ip address 10.2.2.1 255.255.255.252
tunnel source 100.0.0.1
tunnel destination 200.0.0.1

Сразу после этого туннель должен подняться:

R1#sh int tun 0
Tunnel0 is up, line protocol is up
Hardware is Tunnel
Internet address is 10.2.2.1/30
MTU 1514 bytes, BW 9 Kbit, DLY 500000 usec,
reliability 255/255, txload 1/255, rxload 1/255
Encapsulation TUNNEL, loopback not set
Keepalive not set
Tunnel source 100.0.0.1, destination 200.0.0.1
Tunnel protocol/transport GRE/IP

Вся основная информация здесь отражена. Обратите внимание на размер MTU – он не 1500, как ставится для обычных физических интерфейсов. О параметре MTU мы поговорим в конце статьи

По умолчанию GRE не проверяет доступность адреса назначения и сразу отправляет туннель в Up. Но стоит только добавить в туннельный интерфейс команду keepalive X, как маршрутизатор начинает отсылать кипалайвы и не поднимется, пока не будет ответа.

В нашей тестовой схеме в качестве локальной сети мы просто настроили Loopback-интерфейсы – они всегда в Up'е. Дали им адреса с маской /32. На самом же деле под ними подразумеваются реальные подсети вашего предприятия (ну, как на картинке).

interface Loopback0
ip address 10.0.0.0 255.255.255.255

На маршрутизаторе у вас должно быть два статических маршрута:

ip route 0.0.0.0 0.0.0.0 100.0.0.2
ip route 10.1.1.0 255.255.255.255 10.2.2.2

Первый говорит о том, что шлюзом по умолчанию является адрес провайдера 100.0.0.2:

R1#traceroute 200.0.0.1
Type escape sequence to abort.
Tracing the route to 200.0.0.1
1 100.0.0.2 56 msec 48 msec 36 msec
2 200.0.0.1 64 msec * 60 msec

Второй перенаправляет пакеты, адресованные хосту с адресом 10.1.1.0, на next-hop 10.2.2.2 – это адрес туннеля с обратной стороны.

GRE-туннели являются однонаправленными, и обычно подразумевается наличие обратного туннеля на другой стороне, хотя вообще говоря, это необязательно. Но в нашем случае, когда посередине Интернет, и задача – организовать приватную сеть, с обратной стороны должна быть симметричная настройка:

nsk-obsea-gw1:

interface Tunnel0
ip address 10.2.2.2 255.255.255.252
tunnel source 200.0.0.1
tunnel destination 100.0.0.1

ip route 0.0.0.0 0.0.0.0 200.0.0.2
ip route 10.0.0.0 255.255.255.255 10.2.2.1

Пробуем запустить пинг:

R1#ping 10.1.1.0 source 10.0.0.0
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.1.1.0, timeout is 2 seconds:
!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 44/71/136 ms

R1#tracer 10.1.1.0
Type escape sequence to abort.
Tracing the route to 10.1.1.0
1 10.2.2.2 68 msec * 80 msec

Великолепно! Но что происходит за кулисами?
А там, ребята, удивительные вещи:

Когда вы запускаете ping 10.1.1.0, что делает маршрутизатор?
1) Формирует IP-пакет::



2) Смотрит таблицу маршрутизации

R1#sh ip route 10.1.1.0
Routing entry for 10.1.1.0/32
Known via «static», distance 1, metric 0
Routing Descriptor Blocks:
* 10.2.2.2
Route metric is 0, traffic share count is 1

Далее рекурсивно смотрит, где адрес 10.2.2.2:

R1#sh ip rou 10.2.2.2
Routing entry for 10.2.2.0/30
Known via «connected», distance 0, metric 0 (connected, via interface)
Routing Descriptor Blocks:
* directly connected, via Tunnel0
Route metric is 0, traffic share count is 1

Такссс, Tunnel 0:

R1#sh int tun 0
Tunnel0 is up, line protocol is up
Hardware is Tunnel
Internet address is 10.2.2.1/30
MTU 1514 bytes, BW 9 Kbit, DLY 500000 usec,
reliability 255/255, txload 1/255, rxload 1/255
Encapsulation TUNNEL, loopback not set
Keepalive not set
Tunnel source 100.0.0.1, destination 200.0.0.1

3) Понимая, что это GRE-туннель, добавляет к пакету заголове GRE:



А сверху новый заголовок IР. В качестве отправителя будет значиться адрес tunnel source, а в качестве получателя – tunnel destination.



4) Новоиспечённый пакет отправляется в дивный мир по дефолтному маршруту:

R1#sh ip route
Gateway of last resort is 100.0.0.2 to network 0.0.0.0

5) Не забываем про заголовок Ethernet, при отправке провайдеру он также должен быть сформирован.

Поскольку GRE-туннель – виртуальный интерфейс 3-го уровня, он не обладает собственным MAC-адресом (как и Loopback, например). В конечном итоге кадр уйдёт с физического интерфейса FastEthernet0/0:

R1#sh ip route 100.0.0.2
Routing entry for 100.0.0.0/30
Known via «connected», distance 0, metric 0 (connected, via interface)
Routing Descriptor Blocks:
* directly connected, via FastEthernet0/0
Route metric is 0, traffic share count is 1

Соответственно его адрес он и укажет в качестве Source MAC

R1#sh int
FastEthernet0/0 is up, line protocol is up
Hardware is Gt96k FE, address is c000.25a0.0000 (bia c000.25a0.0000)
Internet address is 100.0.0.1/30

Destination по традиции берётся из ARP-кэша или получается с помощью ARP-запроса от адреса 100.0.0.2:

R1#show arp
Protocol Address Age (min) Hardware Addr Type Interface
Internet 100.0.0.1 – c000.25a0.0000 ARPA FastEthernet0/0
Internet 100.0.0.2 71 c001.25a0.0000 ARPA FastEthernet0/0

6) И в таком виде новый IP-пакет передаётся в интернет. А поскольку каждый маршрутизатор не раздербанивает пакет, а принимает решение на основе первого же заголовка IP, то никто в Интернете не будет знать о том, что где-то там внутри кроются ваши приватные адреса 10.1.1.0 и 10.0.0.0.



7) И наконец пребывает в точку назначения.
R3 обнаруживает, что адрес назначения принадлежит ему самому, снимает заголовок IP и что он под ним находит? GRE-заголовок.

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

В данном случае передать на обработку интерфейсу Loopback 0

R3#sh ip route 10.1.1.0
Routing entry for 10.1.1.0/32
Known via «connected», distance 0, metric 0 (connected, via interface)
Routing Descriptor Blocks:
* directly connected, via Loopback0
Route metric is 0, traffic share count is 1

Вот такие нехитрые манипуляции.
Пока пакет в локальной сети он выглядит так:

и обрабатывается на основе приватных адресов.
Как только попадает в публичную сеть, GRE вешает на него дополнительный IP-заголовок:

и пакет обрабатывается на основе публичных адресов.

Вот как выглядит пакет в Интернете:

1 – изначальные данные
2 – первый IP-заголовок (внутренний)
3 – заголовок GRE (с указанием, что внутри лежат данные протокола IP)
4 – новый заголовок IP (внешний, с туннельными адресами)

Рядовой обмен ICMP-сообщениями может при детальном рассмотрении выглядеть и так.

Полная конфигурация маршрутизаторов для GRE.

Если попытаться провести аналогии с осязаемым миром, то представим ситуацию, когда вы едете из деревни, инкапсулированные в автомобиль. Доезжаете до реки, и вам надо перебраться на другой берег и там продолжить своё путешествие в город.
На речном порту ваш автомобиль инкапсулируют в паром и переправляют через бушующие волны на другую сторону, где ваш автомобиль извлекают, и вы продолжаете движение. Так вот этот паром и был GRE-паромом.

Сделаем три ремарки:
Во-первых, интерфейсы Loopback и адреса с маской /32 мы выбрали просто для теста, фактически это вполне бы могли быть интерфейсы fa1/0.15 и fa0/1.16 с подсетями 172.16.15.0/24 и 172.16.16.0/24, например, или любые другие.
Во-вторых, мы тут всё ведём речи о публичных сетях и адресах, но на самом деле, конечно, это не имеет значения и туннели вполне можно поднимать даже внутри своей корпоративной сети, когда конечные сети и так имеют IP-связность без туннеля.
В-третьих, несмотря на то, что теоретически обратно трафик может возвращаться и не по туннелю, создать его необходимо, чтобы конечный узел могу успешно декапсулировать GRE-пакеты

Обычный GRE – яркий пример туннелирования, который очень просто настраивается и сравнительно легко траблшутится.
Очевидно, вы уже догадываетесь, какие три большие проблемы подстерегают нас на этом поле?

• Безопасность. Данные, инкапсулированные в GRE, передаются тем не менее в открытом виде.
• Сложность масштабирования. Если у вас 5-7 филиалов, обслуживание такого количества туннелей ещё кажется возможным, а если их 50? Причём туннелирование трафика зачастую производится на CPU, особенно на младшей и средней линейках, поэтому это лишняя нагрузка на процессор.
• Все филиалы будут взаимодействовать друг с другом через центральный узел, хотя могли бы напрямую.

IPSec

Первую озвученную выше проблему призвано решить шифрование.

Сейчас для организации шифрованного VPN-канала используются преимущественно следующие технологии: IPSec (IP Security), OpenVPN и PPTP (Point-to-Point Tunneling Protocol).

Бессменным лидером, конечно, является IPSec, о нём и поговорим.

Для начала нужно уяснить себе, что IPSec – это не протокол, это стандарт, включающий в себя целых три протокола, каждый со своими функциями:

1. ESP (Encapsulating Security Payload – безопасная инкапсуляция полезной нагрузки) занимается непосредственно шифрованием данных, а также может обеспечивать аутентификацию источника и проверку целостности данных
2. AH (Authentication Header – заголовок аутентификации) отвечает за аутентификацию источника и проверку целостности данных
3. IKE (Internet Key Exchange protocol – протокол обмена ключами) используется для формирования IPSec SA (Security Association, об этом чуть ниже), проще говоря, согласования работы участников защищенного соединения. Используя этот протокол, участники договариваются, какой алгоритм шифрования будет использоваться, по какому алгоритму будет производиться (и будет ли вообще) проверка целостности, как аутентифицировать друг друга

Прежде чем переходить дальше, разберемся с термином SA – Security Association. SA в общем смысле представляет собой набор параметров защищенного соединения (например, алгоритм шифрования, ключ шифрования), который может использоваться обеими сторонами соединения. У каждого соединения есть ассоциированный с ним SA.
Теперь по порядку, как создается защищенное соединение в IPSec:

• Для начала, участникам надо договориться, какие алгоритмы/механизмы защиты они будут использовать для своего защищенного соединения, поэтому в дело вступает IKE. Процесс состоит из двух фаз:
  
  • Фаза первая: участники аутентифицируют друг друга и договариваются о параметрах установки специального соединения (тоже защищенного), предназначенного только для обмена информацией о желаемых/поддерживаемых алгоритмах шифрования и прочих деталях будущего IPSec-туннеля. Параметры этого мини-туннеля (правильно он называется ISAKMP Tunnel) определяются политикой ISAKMP, в режим редактирования которой мы можем попасть из конфигурационного режима командой crypto isakmp policy номер_политики. Если стороны пришли к соглашению, устанавливается ISAKMP туннель (его наличие можно посмотреть командой show crypto isakmp sa), по которому уже проходит вторая фаза IKE.
  • Фаза вторая: уже доверяющие друг другу участники договариваются о том, как строить основной туннель для данных. Они по очереди предлагают друг другу варианты, указанные в команде crypto ipsec transform-set, и, если приходят к согласию, поднимают основной туннель. Нужно сказать, что, после его установления, вспомогательный ISAKMP туннель никуда не пропадает – он используется для обновления SA основного. Дело в том, что ключи, выбираемые для шифрования информации в IPSec-туннеле, имеют некоторое “время жизни” (может выражаться как в количестве байт, так и в секундах – что первое достигнет порогового значения), по истечение которого должны быть заменены. Это как пароль, который вы меняете раз в час (по умолчанию lifetime IPSec SA составляет 4608000 килобайт/3600 секунд).
  
  
• Участники получили шифрованный туннель с параметрами, которые их всех устраивают, и направляют туда потоки данных, подлежащие шифрованию, т.е., подпадающие под указанный в crypto map аксесс-лист.
• Периодически, в соответствии с настроенным lifetime, обновляются ключи шифрования для основного туннеля: участники вновь связываются по ISAKMP-туннелю, проходят вторую фазу и устанавливают новые SA.

Строго говоря, в этом процессе есть нулевой шаг: некий трафик должен попасть в соответствие аксесс-листу в крипто мапе. Только после этого будет происходить все остальное.

Теперь немного о трансформ-сете и чем отличается ESP от AH. Как будут шифроваться наши данные, идущие через туннель, определяет команда crypto ipsec transform-set имя_сета, после которой идет название протокола, который будет использован (ESP или AH) + алгоритм, по которому будет работать протокол. Например, команда crypto ipsec transform-set SET1 esp-aes даст понять роутеру, что трансформ-сет с именем “SET1”, если он будет применен, будет работать только по протоколу ESP c шифрованием алгоритмом AES. Ну если с ESP все более-менее понятно, его дело-шифровать (обеспечивать конфиденциальность), то что такое AH и зачем он вообще нужен? AH обеспечивает аутентификацию данных, то есть дает уверенность, что эти данные пришли именно от того, с кем мы установили связь, и не были изменены по дороге. Если не углубляться в подробности, работает это так: в каждый пакет между заголовком IP и заголовком транспортного уровня вставляется заголовок AH, в котором присутствует:

• информация, по которой получатель может понять, к какой SA относится данный пакет (т.е., в том числе, по какому алгоритму ему считать хеш для сравнения – MD5 или SHA)
• так называемый ICV (Integrity Check Value), представляющий собой хеш от пакета (на самом деле, не всего пакета, а неизменяемых в процессе путешествия полей), который позволяет однозначно убедиться получателю, что этот пакет не изменялся по дороге, путем вычисления хеша от той же информации и сравнения результата со значением этого поля.

IPSec может работать в двух режимах: туннельном и транспортном.

Туннельный режим работы IPSec

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

*рисунок не точен и показывает лишь суть, на самом деле заголовков там больше, а так же есть трейлеры в конце.

Это режим по умолчанию.

Давайте опять разберёмся по ходу настройки.

На локальной стороне:

Сначала общую политику для фазы 1 – установление первого, вспомогательного туннеля: тип шифрования (по умолчанию DES) и аутентификации. Аутентификацию можно делать на основе сертификатов, но мы рассмотрим простой пример с предварительным ключом:

crypto isakmp policy 1
encr aes
authentication pre-share

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

Указываем pre-shared key для проверки подлинности соседа 200.0.0.1

crypto isakmp key CISCO address 200.0.0.1

Далее мы указываем параметры для обработки трафика. Алгоритм шифрования AES с использованием ESP-заголовка и алгоритм аутентификации.

crypto ipsec transform-set AES128-SHA esp-aes esp-sha-hmac

На самом деле мы указываем сразу набор протоколов, как вы видите, он и называется transform-set. При установке IPSec-сессии маршрутизаторы обмениваются этими наборами. Они должны совпадать.

Для упрощения траблшутинга имена для transform-set обычно даются по применённым протоколам.

Теперь создаём карту шифрования:

crypto map MAP1 10 ipsec-isakmp
set peer 200.0.0.1
set transform-set AES128-SHA
match address 101

Вот именно тут и определяется адрес соседа IPSec, с которым потом будет устанавливаться туннель – 200.0.0.1. Тут же привязывается набор протоколов и ACL, определяющий, какой трафик будет шифроваться и передаваться через туннель.

В нашем случае он выглядит так:

access-list 101 permit ip host 10.0.0.0 host 10.1.1.0

Будьте внимательны при задании ACL. Он определяет параметры не только исходящего трафика, но и входящего (в отличие от ACL для NAT, например).
То есть если придут пакеты не от 10.1.1.0, а от 10.2.2.2, он не будет обработан и дешифрован.

То бишь, если мы генерируем трафик с хоста с адресом 10.0.0.0 на 10.1.1.0, то он и только он будет шифроваться и отправляться именно в IPSec-туннель. Любой другой пойдёт простым путём.

Заметим, что шифрование, происходит практически в самую последнюю очередь, после маршрутизации.
И это, кстати, очень важный момент. Вам недостаточно маршрута до публичного адреса пира (200.0.0.1). Нужен маршрут до 10.1.1.0 пусть даже он дефолтный. Иначе пакет будет отброшен в соответствии с обычными правилами маршрутизации.
Как бы странно это ни казалось, но трафик в локальную сеть у вас должен быть “зарулен”, например, в Интернет. При этом приватные пакет, которые уже вот-вот должны быть отправлены к провайдеру и там отброшены, в последний момент шифруется, получая публичные адреса.
Кстати, тут есть таблица с порядком следования операций, производимых над трафиком.

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

interface FastEthernet0/0
crypto map MAP1

С обратной стороны нужно произвести симметричную настройку.
Поэтому просто применяем следующую конфигурацию на R3:

crypto isakmp policy 1
encr aes
authentication pre-share
crypto isakmp key CISCO address 100.0.0.1
!
!
crypto ipsec transform-set AES128-SHA esp-aes esp-sha-hmac
!
crypto map MAP1 10 ipsec-isakmp
set peer 100.0.0.1
set transform-set AES128-SHA
match address 101

interface FastEthernet0/1
crypto map MAP1

access-list 101 permit ip host 10.1.1.0 host 10.0.0.0

Вот и всё.

Но сколько бы вы после ни смотрели show crypto session или show crypto isakmp sa, вы увидите только Down. Туннель никак не поднимается.
Счётчики show crypto ipsec sa. Так же по нулям.

R1#sh crypto session
Crypto session current status

Interface: FastEthernet0/0
Session status: DOWN
Peer: 200.0.0.1 port 500
IPSEC FLOW: permit ip host 10.0.0.0 host 10.1.1.0
Active SAs: 0, origin: crypto map

R1#sh crypto isakmp sa
dst src state conn-id slot status

Дело в том, что вам необходимо пустить в него трафик. В прямом смысле, например так:

R1#ping 10.1.1.0 source 10.0.0.0
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.1.1.0, timeout is 2 seconds:
Packet sent with a source address of 10.0.0.0
.!!!
Success rate is 80 percent (4/5), round-trip min/avg/max = 60/94/160 ms

И как только вы это сделали, вас ждёт успех:

R1#sh crypto session
Crypto session current status

Interface: FastEthernet0/0
Session status: UP-ACTIVE
Peer: 200.0.0.1 port 500
IKE SA: local 100.0.0.1/500 remote 200.0.0.1/500 Active
IPSEC FLOW: permit ip host 10.0.0.0 host 10.1.1.0
Active SAs: 2, origin: crypto map

R1#sh crypto isakmp sa
dst src state conn-id slot status
200.0.0.1 100.0.0.1 QM_IDLE 1 0 ACTIVE

Полная конфигурация маршрутизаторов.

=====================
Задача №1

Начальная конфигурация: «IPsec»
Маршрутизатор R1 стоит в центральном офисе.
Маршрутизатор R3 — это маршрутизатор в одном из филиалов.
К схеме добавляется маршрутизатор R4 — второй филиал.

Задание:
1. Настроить туннель IPsec с использованием crypto-map между R4 и R1:
— Политики защиты данных такие же, как и для туннеля между R3 и R1.
2. Добавить соответствующие настройки для того чтобы R3 и R4 также могли обмениваться данными:
— Данные между филиалами за R3 и R4 должны передаваться через центральный маршрутизатор R1

Подробности задачи на сайте
=====================

Что произошло?

1) Мы запустили пинг на адрес 10.1.1.0 с адреса 10.0.0.0.

2) Согласно таблице маршрутизации пакет должен быть передан в публичную сеть в том виде, в каком он есть.

3) Но маршрутизатор видит, что это подпадает по его ACL 101 и передаёт пакет в работу IPSec'у.

4) IPSec, работая в туннельном режиме (режим по умолчанию), упаковывает исходный пакет сначала в IPSec PDU, попутно шифруя всё и вся, а потом укомплектовывает его новым IP-заголовком. В качестве адреса назначения маршрутизатор прописывает адрес своего IPSec-соседа – 200.0.0.1.

На скриншоте ниже вы можете видеть инкапсуляцию:



Это был обмен ICMP-сообщениям. Все исходные данные зашифрованы, включая старый IP, новый IP-заголовок опирается на настройку IPSec.

5) На конечном узле маршрутизатор видит, что адрес назначения принадлежит ему, снимает заголовок IP и видит заголовок IPSec, этому протоколу он и передаёт пакет на обработку. Последний дешифруется, удаляется вся служебная информация, и исходный пакет путешествует дальше.

Почему мы запускали такой странный Ping? В нём мы указали адрес отправителя явно.

Если же мы попытаемся запустить Ping 10.1.1.0, то он не пройдёт, потому что маршрутизатор автоматически подставляет в качестве отправителя адрес физического интерфейса: 100.0.0.1, который не попадает в наш ACL, и поэтому пакет пытается уйти на шлюз последней надежды.

Какую самую главную проблему мы имеем тут? Бинго! Динамическая маршрутизация. Внедрить её в таких условиях невозможно – все IGP требуют прямого L2-линка между соседями, чего не обеспечивает IPSec. Поэтому в такой реализации трафик отправляется в туннель на основе ACL и карты шифрования, а не таблицы маршрутизации.
Плюс мы имеем проблему с мультикастом, потому что задаём конкретные подсети в ACL.

Полная конфигурация маршрутизаторов.

=====================
Задача №2

Конфигурация: «IPsec»

Примечание:
Задача может быть решена, как теоретически, так и практически.
Если Вы будете пробовать задачу на практике, то внимательно соблюдайте условия задачи.

Условия задачи:
Маршрутизатор R1 стоит в центральном офисе и к нему будут подключены 3 филиала (для данной задачи достаточно маршрутизаторов R1, R2, R3. R3 — в роли одного из филиалов). В филиалах используются маршрутизаторы с разными возможностями, и необходимо использовать разные политики IPsec. Всего есть 3 различные политики.
На маршрутизаторе R3, кроме туннеля в центральный офис также есть несколько туннелей с партнерами. Поэтому тут тоже созданы различные политики.
Трафик передается только из филиалов в центральный офис, между филиалами коммуникаций нет.

Со стороны филиала R3 в центральный офис R1 генерируются данные, которые инициируют туннель VPN.
Вопрос: Какую политику защиты данных будут использовать маршрутизаторы для построения туннеля между собой?

Подробности задачи на сайте
=====================

Это был туннельный режим, коллеги. Переходим к следующему экспонату.

Транспортный режим работы IPSec

Он много чем отличается от туннельного, но самое важное – это метод инкапсуляции.

Вот пакет IPSec в туннельном режиме


А это пакет IPSec в транспортном:



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

Грубо говоря, туннельный режим вы используете для того, чтобы связать две приватные сети через публичную, обеспечив при этом шифрование (Что-то вроде безопасного GRE). Транспортный же актуален тогда, когда IP-связность уже достигнута, но трафик между узлами нужно шифровать.
Удачным примером применения транспортного режима может быть схема сервер-клиент. Например, работа клиент-банка. Сервер и так уже доступен, но трафик нужно зашифровать.

Но мы не об этом. Нам всё-таки, надо объединять сети.

=====================
Задача №3

Схема: «итоговая схема задачи 7.1»
Конфигурации устройств: на сайте проекта

Описание проблемы:
Не передаются данные между R1 и R4.

Задание:
Найти ошибку и исправить конфигурацию так, чтобы туннель между R1 и R4 установился и передавался трафик между R1 и R4.

Подробности задачи на сайте
=====================

GRE over IPSec

У начинающих тут часто случается конфуз (он и у автора случился): GRE over IPSec или IPSec over GRE. В чём разница, где применяются. Нельзя на этом не остановиться.
Обычный режим, который мы рассматриваем тут и который применяется в подавляющем большинстве случаев, – это GRE over IPSec, то есть данные GRE инкапсулируются заголовками ESP или AH



А IPSec over GRE означает, наоборот, что внутри будут зашифрованные данные IPSec, а сверху заголовки GRE/IP. Они будут не зашифрованы:



Такой вариант возможен, например, если шифрование у вас происходит на отдельном устройстве перед туннелированием



Зачем такая похабщина нужна, не очень понятно, поэтому обычно используется именно GRE over IPSec.

Вернёмся к нашей старой схеме и реализуем на ней именно этот вариант.



Разумеется, при этом у нас снова появляется туннельный интерфейс (настраивается, как обычный GRE):

interface Tunnel0
ip address 10.2.2.1 255.255.255.252
tunnel source 100.0.0.1
tunnel destination 200.0.0.1

И далее вы направляете в него нужный вам трафик статическим маршрутом.

ip route 10.1.1.0 255.255.255.255 10.2.2.2

Что при этом меняется в настройке IPSec?
В принципе, даже если вы ничего не поменяете, всё уже будет работать, но это не наш путь.
Во-первых, поскольку туннель уже существует (GRE), нет нужды делать его ещё и средствами IPSec – можно перевести его в транспортный режим, тем самым, сэкономив 20 байтов на лишнем IP-заголовке:

crypto ipsec transform-set AES128-SHA esp-aes esp-sha-hmac
mode transport

*Заметьте, менять, это надо на обеих сторонах, иначе соседство IPSec не установится.

Во-вторых, шифроваться должен весь трафик между филиалами, то есть тот, который идёт через туннель, соответственно, нет необходимости прописывать все сети в ACL, поступим хитрее:

access-list 101 permit gre host 100.0.0.1 host 200.0.0.1

Условие выполняется, если на порт пришёл трафик с заголовком GRE и соответствующими адресами.

Что будет происходить при таком раскладе?
1) Пакет с адресом назначения 10.1.1.0 приходит на маршрутизатор, тот определяет по своей таблице, что пакет нужно передать на next-hop 10.2.2.2

R1#sh ip route 10.1.1.0
Routing entry for 10.1.1.0/32
Known via «static», distance 1, metric 0
Routing Descriptor Blocks:
* 10.2.2.2
Route metric is 0, traffic share count is 1

2) Это туннельный интерфейс, с адресом назначения 200.0.0.1. Пакет упаковывается заголовком GRE и новым IP заголовком.

R1#sh int tun 0
Tunnel0 is up, line protocol is up
Hardware is Tunnel
Internet address is 10.2.2.1/30
MTU 1514 bytes, BW 9 Kbit, DLY 500000 usec,
reliability 255/255, txload 1/255, rxload 1/255
Encapsulation TUNNEL, loopback not set
Keepalive not set
Tunnel source 100.0.0.1, destination 200.0.0.1
Tunnel protocol/transport GRE/IP

3) Сеть 200.0.0.1 известна через адрес 100.0.0.2

R1#sh ip route
Gateway of last resort is 100.0.0.2 to network 0.0.0.0

А подсеть 100.0.0.0/30 подключена к интерфейсу FE0/0

R1#sh ip route 100.0.0.0
Routing entry for 100.0.0.0/30, 1 known subnets
Attached (1 connections)

C 100.0.0.0 is directly connected, FastEthernet0/0

А на него применена карта шифрования с ACL.
Трафик, естественно, подпадает под него (имеет заголовок GRE и нужные IP-адреса), поэтому всё, что находится внутри внешнего IP-заголовка будет зашифровано.

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

=====================
Задача №5

Схема: «GRE_over_IPSec»

Конфигурация: на сайте проекта

Описание проблемы:
После настройки GRE over IPSec между R1 и R3, всё прекрасно работает, трафик между R1 и R3 (c 10.0.0.0 на 10.1.1.0) передается.
Однако, через несколько дней, когда администратор хотел посмотреть состояние VPN, обнаружилось, что на маршрутизаторах вообще нет установленных SA.
Соответственно, трафик между R1 и R3 не шифруется.

Задание:
Необходимо проверить настройки, исправить конфигурацию и сделать так, чтобы трафик шифровался (трафик между loopback-интерфейсами 10.0.0.0 и 10.1.1.0).

Подробности задачи на сайте
=====================

Полная конфигурация маршрутизаторов для IPSec.

Можно сделать тут ещё одно дополнение: технически, можно исключить четырёхбайтовый заголовок GRE из пакета, указав с обеих сторон, что режим работы туннеля IPIP:

interface Tunnel0
tunnel mode ipip

Нужно правда помнить, что в этом случае инкапсулировать можно только данные IP, а не любые, как в случае GRE.

=====================
Задача №4

Схема: «GRE_over_IPSec»

Конфигурация: «GRE_over_IPSec»

Задание:
Изменить исходную конфигурацию GRE over IPSec и настроить GRE over IPsec без использования crypto-map.

Подробности задачи на сайте
=====================

IPSec VTI

Последний пример Site-to-Site VPN с использованием IPSec, который, собственно, и рекомендован циской – VTI (Virtual Tunnel Interface)

Настройка IPSec отличается тем, что нам уже не нужно создавать вручную crypto-map (а соответственно и ACL), вместо него мы создаём IPSec-профиль

crypto isakmp policy 1
authentication pre-share

crypto isakmp key DMVPNpass address 0.0.0.0 0.0.0.0

crypto ipsec transform-setVTI-TS esp-aes
mode transport

crypto ipsec profile VTI-P
set transform-set VTI-TS

А его в свою очередь обязательно нужно привязать к туннельному интерфейсу.

interface Tunnel0
tunnel protection ipsec profile DMVPN-P

Отличие от использованных ранее Crypto map в том, что сейчас нет нужды создавать ACL – весь трафик, попадающий в туннель, шифруется (карты шифрования тем не менее по-прежнему создаются, но уже автоматически).

Это получился обычный Tunnel Protection без VTI. Так же широко используется.
Команда tunnel mode ipsec ipv4 указывает на использование VTI.
Отличие от обычного GRE в методах инкапсуляции – в VTI экономится 4 байта путём исключения GRE-заголовка.

Небольшое описание
Полная конфигурация маршрутизаторов для IPSec VTI.

DMVPN

Апофеоз сегодняшнего выпуска – DMVPN (Dymamic Multipoint VPN). До сих пор речь была об универсальных вендоронезависымых вещах. К сожалению, DMVPN – вещь сугубо цисковская и открытых адекватных аналогов пока не имеет (поправьте, если ошибаюсь).

В предыдущих частях мы решили проблему с безопасностью передаваемых данных – теперь мы их шифруем – и с IGP – посредством GRE over IPSec мы используем протоколы динамической маршрутизации.
Осталась последняя проблема – масштабируемость.
Хорошо, когда у вас вот такая сеточка:



По два туннеля на каждом узле и всё.
Добавляем ещё один узел:



И ещё один:



Нужно уже гораздо больше туннелей для получения полносвязной топологии. Типичная проблема со сложностью m*(m-1)/2.
Если не использовать Full-Mesh, а обратиться к топологии Hub-and-Spoke с одной центральной точкой, то появляется другая проблема – трафик между любыми филиалами будет проходить через центральный узел.

DMVPN позволяет решить обе проблемы.
Суть такая: выбирается центральная точка Hub (или несколько). Она будет сервером, к которому будут подключаться клиенты (Spoke) и получать всю необходимую информацию. При этом:

1) Данные будут зашифрованы IPSec
2) Клиенты могут передавать трафик непосредственно друг другу в обход центрального узла
3) Только на центральном узле необходим статический публичный IP-адрес. Удалённые узлы могут иметь динамический адрес и находиться даже за NATом, используя адреса из частных диапазонов (Технология NAT Traversal ). Но при этом возникают ограничения по части динамических туннелей.

Это всё средоточие мощи GRE и IPSec, сдобренное NHRP и IGP.

Теория и практика DMVPN

Абстрагируясь от нашей старой сети, возьмём в рассмотрение только Москву, сеть Интернет, которую будет эмулировать маршрутизатор Балаган-Телеком, и собственно филиалы в Новосибирске, Томске и Брно:



Новый IP-план:
Подсети, выделенные для подключения к интернету филиалов:



LAN:



Для туннельных интерфейсов возьмём внутреннюю сеть:



И назначим также адреса Loopback для них:



Идея заключается в том, что на центральном узле будет один единственный динамический туннель, который мы настроим в самом начале, а при добавлении новых удалённых точек, здесь не нужны изменения – ни добавлять новые туннельные интерфейсы, ни перенастраивать уже существующий.
Фактически при добавлении новых узлов настраивать нужно только их.
Везде запускается протокол NHRP – NBMA Next Hop resolution Protocol.
Он позволяет динамически изучать адреса удалённых точек, который желают подключиться к основной.
На нём и основана возможность реализации multipoint VPN. Хаб (центральный узел) здесь выступает как сервер (NHS – Next-Hop Server), а все удалённые узлы будут клиентами (NHC – Next-Hop Client).
Звучит это сложно. На пальцах объяснить тоже не получится. Надо лишь один раз настроить и посмотреть, как бегают пакеты.

Конфигурация хаба:

interface Tunnel0
ip address 172.16.254.1 255.255.255.0
ip nhrp map multicast dynamic
ip nhrp network-id 1
tunnel source FastEthernet0/1.6
tunnel mode gre multipoint

По порядку:
ip address 172.16.254.1 255.255.255.0 – IP-адрес из нужного диапазона.
ip nhrp map multicast dynamic – Динамическое изучение данных NHRP от клиентов. Поскольку клиентов у нас множество и они могут быть с динамическими адресами, на хабе нельзя задать явное соответствие внутренних и внешних адресов.
ip nhrp network-id 1 – Определяем Network ID – просто идентификатор, который необязательно должен быть одинаковым на всех узлах DMVPN (похож на OSPF Router-ID).
tunnel source FastEthernet0/1.6 – наследие GRE – привязка к физическому интерфейсу.
tunnel mode gre multipoint – Туннель на центральном узле будет терминировать все туннели от удалённых точек. То есть он будет точка-многоточка (Point-to-MultiPoint).

Конфигурация филиала:

interface Tunnel0
ip address 172.16.254.2 255.255.255.0
ip nhrp map 172.16.254.1 198.51.100.2
ip nhrp map multicast 198.51.100.2
ip nhrp network-id 1
ip nhrp nhs 172.16.254.1
ip nhrp registration no-unique
tunnel source FastEthernet0/0
tunnel mode gre multipoint

По порядку:
ip address 172.16.254.2 255.255.255.0 – IP-адрес из нужного диапазона.
ip nhrp map 172.16.254.1 198.51.100.2 – Статическое соотношение внутреннего и внешнего адресов хаба.
ip nhrp map multicast 198.51.100.2 мультикастовый трафик должен получать хаб.

Без этой команды у вас будут довольно интересные симптомы проблемы.
Вот вы запустили OSPF, пиринг поднимается, хаб и филиалы переходят в состояние Full, обменялись маршрутами, и вы уже радуетесь, что всё отлично, и тут бац – пинг пропадает, пиринг падает, но только с одной стороны, мол истёк dead-timer.

*Mar 1 01:51:20.331: %OSPF-5-ADJCHG: Process 1, Nbr 172.16.255.2 on Tunnel0 from FULL to DOWN, Neighbor Down: Dead timer expired
msk-arbat-gw1#
*Mar 1 01:51:25.435: %OSPF-5-ADJCHG: Process 1, Nbr 172.16.255.2 on Tunnel0 from LOADING to FULL, Loading Done

Что за фигня?
Смотрим дебаг, смотрим дампы

*Mar 1 01:53:44.915: OSPF: Send hello to 224.0.0.5 area 0 on FastEthernet0/1.4 from 172.16.2.1
*Mar 1 01:53:44.919: OSPF: Send hello to 224.0.0.5 area 0 on FastEthernet0/1.7 from 172.16.2.33
*Mar 1 01:53:44.923: OSPF: Send hello to 224.0.0.5 area 0 on FastEthernet0/1.5 from 172.16.2.17
*Mar 1 01:53:44.923: OSPF: Send hello to 224.0.0.5 area 0 on FastEthernet0/1.8 from 172.16.2.129
*Mar 1 01:53:44.963: OSPF: Send hello to 224.0.0.5 area 0 on Tunnel0 from 172.16.254.1
msk-arbat-gw1#
*Mar 1 01:53:54.919: OSPF: Send hello to 224.0.0.5 area 0 on FastEthernet0/1.4 from 172.16.2.1
*Mar 1 01:53:54.923: OSPF: Send hello to 224.0.0.5 area 0 on FastEthernet0/1.7 from 172.16.2.33
*Mar 1 01:53:54.927: OSPF: Send hello to 224.0.0.5 area 0 on FastEthernet0/1.5 from 172.16.2.17
*Mar 1 01:53:54.931: OSPF: Send hello to 224.0.0.5 area 0 on FastEthernet0/1.8 from 172.16.2.129
*Mar 1 01:53:54.963: OSPF: Send hello to 224.0.0.5 area 0 on Tunnel0 from 172.16.254.1
msk-arbat-gw1#
*Mar 1 01:54:04.919: OSPF: Send hello to 224.0.0.5 area 0 on FastEthernet0/1.4 from 172.16.2.1
*Mar 1 01:54:04.927: OSPF: Send hello to 224.0.0.5 area 0 on FastEthernet0/1.7 from 172.16.2.33
*Mar 1 01:54:04.931: OSPF: Send hello to 224.0.0.5 area 0 on FastEthernet0/1.5 from 172.16.2.17
*Mar 1 01:54:04.935: OSPF: Send hello to 224.0.0.5 area 0 on FastEthernet0/1.8 from 172.16.2.129
*Mar 1 01:54:04.963: OSPF: Send hello to 224.0.0.5 area 0 on Tunnel0 from 172.16.254.1


На 5 OSPF Hello от хаба только один Hello от филиала.
Как вы уже поняли, маршрутизатор просто не может сообразить куда посылать мультикастовые сообщения на адрес 224.0.0.5, хаб их не получает и дёргает OSPF-сессию.

ip nhrp network-id 1 – Network ID. Не обязательно должен совпадать с таким же на хабе.
ip nhrp nhs 172.16.254.1 – Статически настроенный адрес NHRP сервера – хаба. Именно поэтому в центре нам нужен статический публичный адрес. Клиенты отправляют запрос на регистрацию на хаб 172.16.254.1. Этот запрос содержит настроенный локальный адрес туннельного интерфейса, а также свой публичный адрес (случай, когда клиент находится за NAT пока не рассматриваем).
Полученную информацию хаб заносит в свою NHRP-таблицу соответствия адресов. Эту же таблицу он распространяет по запросу любому Spoke-маршрутизатору.

ip nhrp registration no-unique – если адрес в филиалах выдаётся динамически, эта команда обязательна.
tunnel source FastEthernet0/0 – привязка к физическому интерфейсу.
tunnel mode gre multipoint – указываем, что тип туннеля mGRE – это позволит создавать динамически туннели не только до хаба, но и до других филиалов.

У нас ситуация простая – без NAT – и мы можем уже сейчас проверить состояние туннелей.

msk-arbat-gw1#sh int tun 0
Tunnel0 is up, line protocol is up
Hardware is Tunnel
Internet address is 172.16.254.1/24
MTU 1514 bytes, BW 9 Kbit, DLY 500000 usec,
reliability 255/255, txload 1/255, rxload 1/255
Encapsulation TUNNEL, loopback not set
Keepalive not set
Tunnel source 198.51.100.2 (FastEthernet0/1.6), destination UNKNOWN
Tunnel protocol/transport multi-GRE/IP
Key disabled, sequencing disabled
Checksumming of packets disabled

msk-arbat-gw1#ping 172.16.254.2

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.16.254.2, timeout is 2 seconds:
!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 176/213/284 ms

msk-arbat-gw1#sh ip nhrp brief
Target Via NBMA Mode Intfc Claimed
172.16.254.2/32 172.16.254.2 198.51.101.2 dynamic Tu0
msk-arbat-gw1#sh ip nhrp
172.16.254.2/32 via 172.16.254.2, Tunnel0 created 00:09:48, expire 01:50:11
Type: dynamic, Flags: authoritative unique registered
NBMA address: 198.51.101.2

nsk-obsea-gw1#sh ip nhrp brief
Target Via NBMA Mode Intfc Claimed
172.16.254.1/32 172.16.254.1 198.51.100.2 static Tu0

OSPF

То есть связность уже обеспечена, но работать филиалы пока не могут – не настроена маршрутизация.

Тут для каждого протокола свои всплывают тонкости.
Давайте рассмотрим процесс настройки OSPF, для примера.

Поскольку мы имеем широковещательную L2 сеть на туннельных интерфейсах, указываем явно тип сети Broadcast на туннельных интерфейсах на всех узлах:

ip ospf network broadcast

Кроме того в такой сети должен выбираться DR. Логично, чтобы им стал хаб. Всем Spoke-маршрутизаторам запрещаем участие в выборах DR:

ip ospf priority 0

Ну и, естественно, определяем анонсируемые сети.

router ospf 1
network 172.16.0.0 0.0.255.255 area 0

Сети анонсируются:

msk-arbat-gw1#sh ip route

Gateway of last resort is 198.51.100.1 to network 0.0.0.0

172.16.0.0/16 is variably subnetted, 7 subnets, 3 masks
C 172.16.2.128/30 is directly connected, FastEthernet0/1.8
C 172.16.255.1/32 is directly connected, Loopback0
C 172.16.254.0/24 is directly connected, Tunnel0
C 172.16.2.32/30 is directly connected, FastEthernet0/1.7
C 172.16.2.16/30 is directly connected, FastEthernet0/1.5
C 172.16.2.0/30 is directly connected, FastEthernet0/1.4
O 172.16.255.128/32 [110/11112] via 172.16.254.2, 00:05:14, Tunnel0
198.51.100.0/28 is subnetted, 1 subnets
C 198.51.100.0 is directly connected, FastEthernet0/1.6
S* 0.0.0.0/0 [1/0] via 198.51.100.1

Пинг проходит

msk-arbat-gw1#ping 172.16.255.128

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.16.255.128, timeout is 2 seconds:
!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 60/70/80 ms

Вот так выглядят пакеты, передающиеся через сеть Интернет:

* Дамп с nsk-obsea-gw1 fa0/0

Проверяем, как у нас проходит пинг от одного филиала до другого:

nsk-obsea-gw1#ping 172.16.255.132

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.16.255.132, timeout is 2 seconds:
!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 132/231/492 ms

nsk-obsea-gw1#traceroute 172.16.255.132

Type escape sequence to abort.
Tracing the route to 172.16.255.132

1 172.16.254.3 240 msec * 172 msec

nsk-obsea-gw1#sh ip nhrp br
Target Via NBMA Mode Intfc Claimed
172.16.254.1/32 172.16.254.1 198.51.100.2 static Tu0
172.16.254.3/32 172.16.254.3 198.51.102.2 dynamic Tu0

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

Что происходит в этот момент?
1) Отправляем пинг на адрес Loopback-интерфейса в Томске
2) Согласно таблице маршрутизации, следующий хоп

nsk-obsea-gw1#sh ip route 172.16.255.132
Routing entry for 172.16.255.132/32
Known via «ospf 1», distance 110, metric 11112, type intra area
Last update from 172.16.254.3 on Tunnel0, 00:18:47 ago
Routing Descriptor Blocks:
* 172.16.254.3, from 172.16.255.132, 00:18:47 ago, via Tunnel0
Route metric is 11112, traffic share count is 1

Это адрес из сети, непосредственно подключенной к интерфейсу Tunnel 0

nsk-obsea-gw1#sh ip route 172.16.254.3
Routing entry for 172.16.254.0/24
Known via «connected», distance 0, metric 0 (connected, via interface)
Routing Descriptor Blocks:
* directly connected, via Tunnel0
Route metric is 0, traffic share count is 1

3) Согласно настройкам интерфейса здесь используется NHRP. Смотрим таблицу соответствия, полученную от хаба

nsk-obsea-gw1#sh ip nhrp brief
Target Via NBMA Mode Intfc Claimed
172.16.254.1/32 172.16.254.1 198.51.100.2 static Tu0

Как видите, адрес 172.16.254.3 nhrp неизвестен.
Поэтому пакет ICMP отправляется на статически настроенный хаб – 198.51.100.2:

msk-arbat-gw1, fa0/1:


А хаб сразу же перенаправляет запрос на нужный адрес:

msk-arbat-gw1, fa0/1:


4) Одновременно с этим маршрутизатор-клиент в Новосибирске отправляет NHRP-запрос, мол кто укрывает адрес 172.16.254.3:

msk-arbat-gw1, fa0/1:


5) Хаб обладает этим знанием:

msk-arbat-gw1#sh ip nhr br
Target Via NBMA Mode Intfc Claimed
172.16.254.2/32 172.16.254.2 198.51.101.2 dynamic Tu0
172.16.254.3/32 172.16.254.3 198.51.102.2 dynamic Tu0

И отправляет эту информацию в NHRP-ответе:

msk-arbat-gw1, fa0/1:


Больше Хаб не встревает в разговор двух споков.

6) ICMP запрос пришёл в Томск:

tmsk-lenina-gw1, fa0/0:


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

7)Томск тоже пока не знает ничего об адресе 172.16.254.2, пославшем ICMP-запрос.

tmsk-lenina-gw1(config-if)#do sh ip nh br
Target Via NBMA Mode Intfc Claimed
172.16.254.1/32 172.16.254.1 198.51.100.2 static Tu0

Поэтому ICMP-ответ он отправляет тоже на хаб:
tmsk-lenina-gw1, fa0/0:


8) Следом за ним он интересуется о публичном адресе отправителя:

tmsk-lenina-gw1, fa0/0:


9)Ну и хаб, естественно, отвечает:

tmsk-lenina-gw1, fa0/0:


10) Сейчас на всех узлах актуальная информация NHRP:

msk-arbat-gw1(config-if)#do sh ip nhr br
Target Via NBMA Mode Intfc Claimed
172.16.254.2/32 172.16.254.2 198.51.101.2 dynamic Tu0
172.16.254.3/32 172.16.254.3 198.51.102.2 dynamic Tu0

nsk-obsea-gw1(config-if)#do sh ip nhr br
Target Via NBMA Mode Intfc Claimed
172.16.254.1/32 172.16.254.1 198.51.100.2 static Tu0
172.16.254.3/32 172.16.254.3 198.51.102.2 dynamic Tu0

tmsk-lenina-gw1(config-if)#do sh ip nh br
Target Via NBMA Mode Intfc Claimed
172.16.254.1/32 172.16.254.1 198.51.100.2 static Tu0
172.16.254.2/32 172.16.254.2 198.51.101.2 dynamic Tu0

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

11) Следующий ICMP-запрос он уже отправит по-новому:

nsk-obsea-gw1#sh ip route 172.16.255.132
Routing entry for 172.16.255.132/32
Known via «ospf 1», distance 110, metric 11112, type intra area
Last update from 172.16.254.3 on Tunnel0, 00:20:24 ago
Routing Descriptor Blocks:
* 172.16.254.3, from 172.16.255.132, 00:20:24 ago, via Tunnel0
Route metric is 11112, traffic share count is 1

Подсеть 172.16.254.0 подключена к интерфейсу Tunnel 0

nsk-obsea-gw1#sh ip route 172.16.254.3
Routing entry for 172.16.254.0/24
Known via «connected», distance 0, metric 0 (connected, via interface)
Routing Descriptor Blocks:
* directly connected, via Tunnel0
Route metric is 0, traffic share count is 1

12) Мы немного повторяемся, но… Интерфейс Tunnel 0 является mGRE и согласно таблицы NHRP весь трафик, для которого следующим хопом является 172.16.254.3 должен быть инкапсулирован в GRE и внешний IP-заголовок с адресом назначения 198.51.102.2 (В качестве адреса источника будет выбран адрес физического интерфейса – 198.51.101.2):

nsk-obsea-gw1(config-if)#do sh ip nhr br
Target Via NBMA Mode Intfc Claimed
172.16.254.1/32 172.16.254.1 198.51.100.2 static Tu0
172.16.254.3/32 172.16.254.3 198.51.102.2 dynamic Tu0

tmsk-lenina-gw1, fa0/0:


13) Ну и дальше пакет с адресом получателя 198.51.102.2 отправляется согласно таблице маршрутизации:

Gateway of last resort is 198.51.101.1 to network 0.0.0.0

Тут важно понимать, что несмотря на то, что общение между филиалами осуществляется в обход центрального узла, хаб однако несёт тут жизненно важную вспомогательную функцию и без него ничего работать не будет: он предоставляет клиентам таблицу NHRP, а также анонсирует все маршруты – филиалы распространяют маршрутную информацию не непосредственно друг другу, а через хаб.

Актуальная на данный момент конфигурация узлов:

msk-arbat-gw1
interface Tunnel0
ip address 172.16.254.1 255.255.255.0
no ip redirects
ip nhrp map multicast dynamic
ip nhrp network-id 1
ip ospf network broadcast
ip ospf priority 10
tunnel source FastEthernet0/1.6
tunnel mode gre multipoint

nsk-obsea-gw1
interface Tunnel0
ip address 172.16.254.2 255.255.255.0
no ip redirects
ip nhrp map 172.16.254.1 198.51.100.2
ip nhrp map multicast 198.51.100.2
ip nhrp network-id 1
ip nhrp nhs 172.16.254.1
ip ospf network broadcast
ip ospf priority 0
tunnel source FastEthernet0/0
tunnel mode gre multipoint

tmsk-leneina-gw1
interface Tunnel0
ip address 172.16.254.3 255.255.255.0
no ip redirects
ip nhrp map 172.16.254.1 198.51.100.2
ip nhrp map multicast 198.51.100.2
ip nhrp network-id 1
ip nhrp nhs 172.16.254.1
ip ospf network broadcast
ip ospf priority 0
tunnel source FastEthernet0/0
tunnel mode gre multipoint
end

На данный момент решены следующие проблемы:
1) Связность. Филиалы подключены и доступны.
2) Маршрутизация. Через mGRE туннели успешно запущены IGP.
3) Масштабируемость. При добавлении нового spoke-маршрутизатора настраивается только он сам и нет необходимости лезть в конфигурацию уже существующих узлов.
4) Разгрузили хаб – через него передаётся только служебный трафик.

Осталось уладить вопрос с безопасностью.

IPSec

Решается это как и прежде – шифрованием.
Если для Site-to-Site VPN мы ещё могли использовать pre-shared key, потому что мы жёстко задавали адрес IPSec-пира, то в случае DMVPN нам нужна гибкость, а заранее мы не знаем адреса соседей.
В связи с этим рекомендуется использование сертификатов. На xgu есть хорошая статья по центру сертификатов на cisco.

Но мы для упрощения возьмём всё же настройку с pre-shared ключом.

crypto isakmp policy 1
authentication pre-share

От рассмотренных выше Tunnel Protection и VTI она будет отличаться использованием шаблонного адреса:

crypto isakmp key DMVPNpass address 0.0.0.0 0.0.0.0

Опасность здесь в том, что установить IPSec-сессию с хабом, зная ключ, может любое устройство

Тут можно спокойно использовать транспортный режим:

crypto ipsec transform-set AES128-SHA esp-aes esp-sha-hmac
mode transport

crypto ipsec profile DMVPN-P
set transform-set AES128-SHA

Далее созданный профиль применяется на туннельный интерфейс. Настройка на всех узлах одинаковая.

interface Tunnel0
tunnel protection ipsec profile DMVPN-P

Теперь пакеты, передающиеся через Интернет будут зашифрованы:
msk-arbat-gw1, fa0/1:


Только не вздумайте поставить tunnel mode ipsec ipv4 :)

IPSec-туннели и карты шифрования будут создаваться динамически для сеансов передачи данных между филиалами и будут перманентными для каналов Hub-Spoke.

NAT-Traversal

Тут мы не будем вдаваться в принципы работы NAT-T Передам только суть: за счёт дополнительного UDP-заголовка IPSec может строить туннель сквозь NAT. Это позволяет строить VPN даже на тех узлах, где у вас нет публичного адреса.
Нет необходимости этот функционал каким-то особым образом активировать и настраивать – он работает по умолчанию.
Усложним схему добавлением ещё одного маршрутизатора в Брно.



Допустим, это провайдерская железка, осуществляющая натирование. То есть фактически на роутере в филиале у нас будет динамический адрес из приватного диапазона на физическом интерфейсе. GRE в чистом виде не может построить VPN при таких условиях, IPSec может, но сложно настраивать. mGRE в связке с IPSec может легко!

Давайте посмотрим как выглядит таблица NHRP в этом случае:

msk-arbat-gw1#show ip nhrp brief
Target Via NBMA Mode Intfc Claimed
172.16.254.4/32 172.16.254.4 10.0.0.2 dynamic Tu0

То есть изучил он всё-таки приватный адрес, выделенный провайдером.
Надо заметить, что в таблице маршрутизации должен быть маршрут до этого приватного адреса, выданного провайдером в филиале, пусть даже дефолтный.

На туннельном интерфейсе у нас активирован IPSec, следовательно должны быть карты шифрования:

msk-arbat-gw1#show crypto map
Crypto Map «Tunnel0-head-0» 65537 ipsec-isakmp
Map is a PROFILE INSTANCE.
Peer = 198.51.103.2
Extended IP access list
access-list permit gre host 198.51.100.2 host 10.0.0.2
Current peer: 198.51.103.2
Security association lifetime: 4608000 kilobytes/3600 seconds
PFS (Y/N): N
Transform sets={
AES128-SHA,
}
Interfaces using crypto map Tunnel0-head-0:
Tunnel0

Таким образом шифрованный туннель строится между 198.51.100.2 и 198.51.103.2, дальше, данные по-прежнему шифрованные за счёт NAT-T в туннеле идут до 10.0.0.2. А дальше вы уже знаете.

Толковая подробная статья по NHRP.

=====================
Задача №6

Начальная конфигурация: «DMVPN»

Сценарий:
Сеть DMVPN была полностью работоспособной, всё работало корректно.
Но после перезагрузки хаба msk-arbat-gw1 началось странное поведение.

Задание:
1. Проверить работоспособность сети.
2. Перезагрузить хаб
3. После перезагрузки проверить работоспособность сети ещё раз
4. Устранить проблему:
4.1. (минимум) Сделать сеть снова работоспособной
4.2. Сделать так, чтобы сеть восстанавливалась автоматически, после того как хаб снова появится.

Подробности задачи на сайте
=====================

TShoot IPSec

На последок хочется сказать пару слов о том, как решать проблемы с IPSec. Процедура-то далеко не тривиальная.
При траблшутинге VPN огромную роль играют дебаги. Метод пристального взгляда на конфиг менее надежен – легко пропустить небольшую ошибку.
Исключительно ценным инструментом в траблшутинге IPSec является sh crypto ipsec sa. Нет, дело даже не в бинарном «поднялось — не поднялось», а в счетчиках, в первую очередь encaps-decaps. Можно пустить непрерывный пинг и наблюдать, какой из счетчиков растет. Большинство проблем удается локализовать именно таким образом.
Счетчики вообще не растут? См. куда применен крипто мап и все ли в порядке с ACL.
Растут error? Что-то не так с согласованием, см. дебаг.
Растут encaps, но нет decaps? Вперед изучать противоположную сторону туннеля, тут все хорошо.

MTU

Напоследок обсудим один коварный момент – размер MTU. В жизни каждого системного/сетевого администратора наступает момент, когда симптомы проблемы таковы: открывается яндекс, работает пинг, но ни один другой сайт не доступен и Outlook не коннектится.

Дьявол кроется в размере MTU и наличии дополнительных заголовков.

MTU – Maximum Transmission Unit. Это максимальный размер блока данных, который может быть передан через интерфейс. Это понятие находится на пересечении L2 и L3 и его интерпретация может различаться для разных вендоров.

Например, типичный размер MTU для физического L3-интерфейса 1500. То есть, грубо говоря, IP-пакет размером 1500 байт будет обработан, а 1501 – отброшен или фрагментирован. Зачастую фрагментация пакетов запрещена, и потому большие пакеты отбрасываются.

Если вы используете туннелирование, размер пакета увеличивается засчёт дополнительных заголовков (GRE, IPSec и т.д.)
Например, для GRE: 24 байта (GRE, Новый IP).
Для GRE over IPSec: 56 и более байтов (зависит от режима работы и типа шифрования)
Для PPPoE: 36 (PPP, PPPoE, Ethernet)

Сам туннельный интерфейс имеет стандартный MTU 1514 и пропускает такие пакеты, но у провайдера на физическом интерфейсе стоит MTU=1500, и на нём пакет будет отброшен:

R1#sh int tun 0
Tunnel0 is up, line protocol is up
Hardware is Tunnel
Internet address is 10.2.2.1/30
MTU 1514 bytes, BW 9 Kbit, DLY 500000 usec,

R1#sh int fa0/1
FastEthernet0/1 is administratively down, line protocol is down
Hardware is Gt96k FE, address is c000.19ac.0001 (bia c000.19ac.0001)
MTU 1500 bytes, BW 10000 Kbit, DLY 1000 usec,

То есть вы должны учитывать не только свои настройки, но и настройки всех промежуточных узлов.
Зачастую у вас нет возможности влиять на MTU по пути.
Поэтому вы можете уменьшить MTU, на локальной стороне, использовать механизм Path MTU Discovery или даже настраивать MSS – Maximum Segment Size (относится уже к TCP).
Подробнее о проблемах с MTU читайте тут и тут

Для всевозможных туннелей это совершенно типичная проблема.

Почему же работают пинг и яндекс?
Пакеты ICMP Request и Relpy имеют размер от 32 до 64 байтов, ya.ru возвращает очень мало информации, которая вполне укладывается в допустимый размер 1500 вместе со всеми заголовками.

P.S.К сожалению, незатронутыми остались следующие небезынтересные темы:

Полностью пролетели мимо темы удалённого доступа для сотрудников.
Кроме того очень актуальна сейчас тема FlexVPN. Это новый виток развития VPN-технологий. Но использует IKE версии 2 и поддерживается в данный момент, как обычно только оборудованием cisco.
Нам бы действительно хотелось уделить внимание и этим и тем и вот ещё тем темам, но всё уложить в рамки одной статьи невозможно.

Материалы выпуска

IP план
Конфигурация устройств GRE, IPSec, GRE over IPSec, VTI, DMVPN)

Полезные ссылки

IPSec
www.firewall.cx/networking-topics/protocols/870-ipsec-modes.html
www.tcpipguide.com/free/t_IPSecModesTransportandTunnel.htm

DMVPN
www.anticisco.ru/blogs/?tag=dmvpn
xgu.ru/wiki/%D0%9D%D0%B0%D1%81%D1%82%D1%80%D0%BE%D0%B9%D0%BA%D0%B0_DMVPN_%D0%BD%D0%B0_%D0%BC%D0%B0%D1%80%D1%88%D1%80%D1%83%D1%82%D0%B8%D0%B7%D0%B0%D1%82%D0%BE%D1%80%D0%B0%D1%85_Cisco

NHRP.
habrahabr.ru/post/84738
blog.ine.com/tag/nhrp
FlexVPN.
www.cisco.com/en/US/docs/ios-xml/ios/sec_conn_ike2vpn/configuration/15-2mt/sec-intro-ikev2-flex.html
habrahabr.ru/post/160555
alexandremspmoraes.wordpress.com/2012/06/28/hello-world-simple-lan-to-lan-flex-vpn-configuration
alexandremspmoraes.wordpress.com/2012/07/02/flex-vpn-sample-lan-to-lan-configuration-with-dynamic-routing

Статью для вас подготовили eucariot и thegluck

За мозгодробительные задачки спасибо Наташе.

За комментарии и помощь спасибо JDima.

У цикла “Сети для самых маленьких” есть свой сайт: linkmeup.ru, где вы сможете найти все выпуски аккуратно сложенными и готовыми к вдумчивому чтению.

И в качестве минутки саморекламы: на прошлой неделе вышел нулевой выпуск подкаста для связистов.