Знакомство с VPN. Три веселых буквы.

Рассмотрим мы следующие основные моменты.
> Реализации VPN, нюансы применения;
> Т.н. Site-to-Site VPN, и в контексте этого протоколы GRE и IPSec;
> DMVPN совсем уж дикая вещь, расшифровывающаяся как динамическая многоточечная VPN.
Прежде чем бросаться сразу на амбразуры давайте вообще рассмотрим варианты реализации соединения удаленных точек. Конечно, всё зависит от размеров удаленных сетей и собственно расстояния.
Физический канал связи.
1) Ethernet - самая стандартная витая пара. Тут мы ограничены дальностью ~100 метров, т.е. с её помощью можно организовать связь в пределах здания, ну или максимум между двумя близко расположенными строениями. Скорость ограничена 1ГБит/сек (GigabitEthernet) или, учитывая стандарт 10GBASE-T - 10ГБитами/сек.
2) WiFi - здесь уже дальность зависит от используемого стандарта. Теоретически с качественными и дорогими направленными антеннами можно получить устойчивую связь на дистанции ~40 км. Но лучше рассчитывайте на куда более скромные цифры - 5 км в условиях прямой видимости точек. Опять таки скорость зависит от используемого стандарта, расстояния и атмосферных условий (например, от осадков). Если делать всё официально, то вдобавок этот способ требует регистрации у "Роскомнадзора", и это как минимум.
3) xDSL - здесь используется медянка из двух-четырех проводов. Расстояние теоретически будет до 6 км, а скорость в идеальных (читай - никогда) условиях до 250МБит/сек. Можно почитать о разработках, позволяющих получить на двух проводах скорость до 1ГБита, но не очень рассчитывайте на это. Еще существуют специфические решения типа кабельных связок модем-модем, а-ля мост.
4) Радиорелейная связь - несколько десятков километров дистанции и скорости до 600МБит, но это решение уровня оператора или крупного провайдера, т.к. потребуется немало мер по согласованию и планированию, а также подготовке к эксплуатации.
5) Оптоволокно - честная скорость до 1ГБита (да-да, есть решения 10Гбит и даже 100Гбит, но пока это решения операторского уровня и стоят зачастую слишком дорого). В зависимости от кабеля, количества стыков на нем (сварок, кроссов) и конечных приемо-передатчиков (медиаконвертеров или SFP-модулей). Но это опять таки требует согласований, планирования и квалификации от работников (можно взять и рукожопых подрядчиков, но результат будет соответствующим). Расстояния от нескольких километров до многих десятков.
Плюс для любого из этих вариантов в том, что это именно ваша физическая линия. Вы вольны нагружать её, использовать как вам это необходимо и только на вас (и форсмажорах) лежит ответственность за её работоспособность.

Аренда канала.
Для организации стабильного канала, например, между городами это самый правильный вариант. Простой и надежный. Аренда в 99.9% случаев подразумевает входящий в её стоимость ремонт и модернизацию линии в случае... В любом случае. Тем самым вы снимаете с себя одну головную боль, ответственность за работу линии лежит не на вас. Но это не отменяет факта, что вас вы*издят при падении основного канала, если вами не было настроено резервирование.

sad but true
Какие бывают в данном случае варианты?
1) Кабель. Натурально вот прямой кабель. К примеру, пров может выделить вам одно-два волокна в модуле или даже целый модуль в магистральном кабеле. Всё, что хотите, только платите деньги. Это по сути равносильно нашему первому варианту. Это именно Ваш кабель и вы вольны им распоряжаться, гонять трафик хоть до посинения. Провайдер это никак не контролирует, а только осуществляет техническую поддержку линии в рамках вашего с ним договора аренды. Короче говоря, вам не придется судорожно искать подрядчика со сварочником в случае обрыва оптики. Опять таки, за время простоя ответственность несет провайдер. На самом деле такой вариант не из дешевых, имеет смысл искать такой вариант на основе бартера, т.е. некого взаимовыгодного сотрудничества.
2) L2VPN. Фактически это аналогичное решение. Канал также исключительно ваш, но теперь трафик льётся через активное коммуникационное оборудование провайдера, поэтому вполне возможен вариант ограничения ширины канала, например. Это термин собирательный, в него входит несколько вариантов L2-уровня.
• Вам могут предоставить отдельный VLAN, прокинутый между конечными точками.
• Это может быть PWE3, технология использования псевдокабеля, вариант предоставления услуги связи точка-точка, словно у вас действительно проложен цельный кабель. Фреймы информации будут передаваться без изменений. Происходит это потому что на маршрутизаторе провайдера ваш фрейм инкапсулируется PDU вышестоящего уровня (обычно в MPLS.
• Ах да, есть еще вариант - VPLS или виртуальная частная сеть, являющаяся по сути своей симуляцией локальной сети (чтобы было понятнее - возможно сталкивались с сервисом Hamachi? Принцип похож.). В этом варианте существования сеть провайдера является по сути одним большим коммутатором. У него будет своя таблица MAC-адресов и он также будет принимать решения об отправке фреймов исходя из неё. Реализуется также посредством их инкапсуляции в MPLS-пакеты.
2) L3VPN. Это несколько иной случай. Здесь сеть провайдера представляет из себя один большой маршрутизатор с множеством интерфейсов. В данном случае стык у нас происходит уже на сетевом уровне. С клиентской стороны настраиваются IP-адреса на конечных маршрутизаторах с обеих сторон, а настройка маршрутизации внутри сети провайдера уже не ваша головная боль. Назначение IP на точках стыка зависит от реализации проекта, они могут назначаться вами или же провайдером. Работоспособность может быть организована протоколами GRE (вот конкретика на вики), IPSec или уже известного нам MPLS.
С клиентской точки зрения услуга крайне проста, но вот настройка и реализация на стороне провайдера может оказаться весьма нетривиальной задачей. Не волнуйтесь, мы поднимем вопрос подъёма L2/L3VPN по протоколу MPLS, но несколько позже.

Туннель через публичную сеть.
Расклад такой: на обоих наших точках есть выход в интернет, а средств на развертывание чего-то крутого у нас нет. В итоге самым оптимальным вариантом становится поднять туннель между этими самыми точками. Что для этого нужно? Белые (т.е. публичные) статические IP-адреса с обоих сторон (хотя можно и на одной) и соответствующее сетевое оборудование. Да, решение не оптимальное и имеет свои недостатки. О них мы тоже поговорим. Но сейчас рассмотрим именно этот вариант.
В нашем практикуме мы будем соединять по схеме hub and spoke (звезда) три офиса - в Новосибирске, Томске и Брно (пойдем по загранице):

А схема в целом у нас на данный момент выглядит вот так:

Но всю целиком мы не будем её рассматривать, нам нужно сосредоточиться на конкретике. Мы решили строить туннель, тогда давайте разбираться, что нам предлагают современные решения. Приложений и протоколов для организации VPN туннелей точка-точка существует воз и маленькая тележка, но по большей части они служат для подключения хостов, а не целых сетей. То есть, чтобы сотрудники могли без труда подключаться к корпоративной сети удаленно (у Cisco это зовется teleworker). Мы же подразумеваем полноценную удаленную работу, поэтому нас и занимает вопрос подключения сетей.
Что мы рассмотрим? Конечно, очередной ворох протоколов.
-> GRE
-> IPSec (туннельный и транспортный режимы)
-> GRE over IPSec
-> VTI
-> DMVN

GRE

Или же для лучшего понимания, Generic Routing Encapsulation, довольно таки просто протокол тунеллирования... Про... стой?.. А что это вообще такое? Ту-нел-ли-ро... ва-ни-е? Давайте разбираться. Итак наши данные с заголовками (уровня IP, реже Ethernet или ATM) в неизменном виде инкапсулируются в пакет и передаются в публичные интернеты. По месту назначения скидываются лишние заголовки этого пакета скидываются и ваши данные предстают в изначальном виде. В принципе несложно. Но вот давайте подробнее разбираться на примере протокола GRE.
Представим в нашей голове вот такую упрощенную сеточку:

У нас имеются два маршрутизатора, которые смотрят во всемирную паутины белыми публичными айпишниками, а за ними развернуты приватные сетки из диапазона 10.0.0.0/8, о маршрутизации которых в публичной сети речи, конечно, нет. Да, на рисунке у нас два компьютера, но по факту будет происходить настройка виртуального Loopback-интерфейса.
Нам с вами нужно поднять вот такой туннель:

При такой реализации для указанных компьютеров они будут находится в единой локальной сети.
Туннельчик GRE ты будем настраивать так:

interface Tunnel0
ip address 10.2.2.1 255.255.255.252

Он является виртуальным интерфейсом L3, и через него у нас будет происходить вся маршрутизация, поэтому IP-адрес ему будет задаваться исходя из составленного плана (из приватной сети). Здесь в качестве source address может быть IP-адрес выходного интерфейса (белый, который нам выдал провайдер) так и его имя - Fe0/0, если брать наш пример.

tunnel source 100.0.0.1

А destination address - публичный адрес удаленной точки:

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, почему - об этом здесь, но чуть позднее.
Примечание. Наш протокол GRE не проверяет, доступен ли вообще destination address, а радостно рапортует, что Tunnel0 is up. Но всё меняется, если добавить в конфиг тоннеля параметр keepalive X, где нужно задать периодичность отсылки проверочных пакетов. Без полученного положительного ответа он не поднимется.
Схема у нас тестовая, поэтому вместо целой локалки у нас просто Loopback-интерфейсы, которые всегда активны, и выдали им адреса из /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

С первым понятно, он означает, что шлюзом по-умолчанию (Default Gateway) у нас будет 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

Второй маршрут рулит пакетами с destination address 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
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

Заработало. Но давайте разберемся с деталями процесса.
1) Итак, вот мы запускаем пинг до 10.1.1.0, тогда маршрутизатор формирует пакет следующего вида:

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

Отлично, он понял, что адрес за туннелем - directly connected, via Tunnel0.

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 source 100.0.0.1, destination 200.0.0.1
3) Маршрутизатор определяет его как GRE-туннель и добавляет пакету соответствующий заголовок:

А поверх всего этого безобразия новый заголовок с IP. Отправителем будет 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-туннель является виртуальным интерфейсом L3-уровня, поэтому у него имеется свой 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

О чем свидетельствует directly connected, via FastEthernet0/0. Его то он и укажет в качестве 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

Этот самый c000.25a0.0000. А destination address мы возьмем у 100.0.0.2 путем ARP-запроса или поковырявшись в ARP-кэше (вдруг он там уже есть):

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

Замечательно - c001.25a0.0000. Так будет выглядеть итоговый фрейм:

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

7) В конце концов пакет доберется до другой стороны туннеля. Маршрутизатор R3 обнаруживает в заголовке, что destination address является его собственным, снимает этот заголовок и обнаруживает уже 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

Т.к. directly connected, via Loopback0
Пребывая в локальной сети пакет будет представлять из себя это:

Обработка будет происходить исходя из приватных IP. При попадании в публичную сетку GRE накинет ему заголовок:

И обработка уже произойдет основываясь на публичных IP.
В интернете пакет выглядит так:

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

Детализация ICMP

Полный конфиг маршрутизаторов с GRE

hostname R1
!
interface Loopback0
 ip address 10.0.0.0 255.255.255.255
!
interface Tunnel0
 ip address 10.2.2.1 255.255.255.252
 tunnel source 100.0.0.1
 tunnel destination 200.0.0.1
!
interface FastEthernet0/0
 ip address 100.0.0.1 255.255.255.252
 duplex auto
 speed auto
!
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
!

hostname R2
!
interface FastEthernet0/0
 ip address 100.0.0.2 255.255.255.252
 duplex auto
 speed auto
!
interface FastEthernet0/1
 ip address 200.0.0.2 255.255.255.252
 duplex auto
 speed auto

hostname R3
!
interface Loopback0
 ip address 10.1.1.0 255.255.255.255
!
interface Tunnel0
 ip address 10.2.2.2 255.255.255.252
 tunnel source 200.0.0.1
 tunnel destination 100.0.0.1
!
interface FastEthernet0/1
 ip address 200.0.0.1 255.255.255.0
 duplex auto
 speed auto
!
!
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

Не уверен, что требуется разжевывать концепт работы протокола, но всё же. Вот вы едете из одного города инкапсулированные в автомобиль, но чтобы попасть в другой город вам нужно преодолеть реку. Делается это с помощью парома, в который инкапсулируется ваш автомобиль. Вот GRE-это паром, а мы с вами быдло-сетевеки.
Несколько важных замечаний!
1. Взятые в нашем примере интерфейсы Loopback и /32 сетки взяты нами исключительно ради теста. Абсолютно с тем же успехом ими могли быть интерфейсы типа Fa1/0.15 и Fa0/1.16 с подсетями за ними 172.16.15.0/24 и 172.16.16.0/24. Или же любые другие интерфейсы и сети.
2. Мы рассуждали о поднятии туннеля сквозь публичную сеть, но организация подобных туннелей возможна и в какой-нибудь корпоративной сетки даже при условии наличия IP-связности между конечными сетями и без туннеля.
3. Да, в теории обратный трафик может вернуться и не по прокинутому туннелю, но поднять симметричный конфиг нужно для возможности декапсуляции GRE-пакетов конечным маршрутизатором.
GRE - пример легко настраиваемого туннеля без особых заморочек в плане эксплуатации и поиска косяков в перспективе. Но давайте сразу о возможных проблемах при его использовании:
1. Передаваемые данные находятся в незашифрованном виде. Отсутствие безопасности по определению.
2. Большие проблемы при масштабировании. Да, связать пять-шесть узлов туннелями и проводить их обслуживание/мониторинг вполне посильная задача. А если таких узлов больше полусотни? Опять же тунеллируемый трафик гоняется через CPU, а это лишняя нагрузка на процы маршрутизаторов.
3. Взаимодействие между конечными точками будет происходить через центральный узел, а не напрямую.
Едем дальше.

IPSec

Это решение проблемы безопасности. Шифрование.
Для организации шифрованного VPN-туннеля используются следующие протоколы и их наборы: IPsec (IP Security), OpenVPN и PPTP (Point-to-Point Tunneling Protocol).
В большинстве случаев выбор падает на IPSec, поэтому будем обсуждать именно его.
В чистом виде IPSec - это просто стандарт, объединяющий несколько протоколов. Перечислим их.
ESP (Encapsulating Security Payload) - безопасная инкапсуляция полезной нагрузки. На нем лежит ответственность за шифрование данных и проверка их целостности, а также аутентификация источника.
AH (Authentication Header) - заголовок аутентификации. Работает над аутентификацией источника и целостностью данных.
IKE (Internet Key Exchange protocol) - протокол обмена ключами. Он используется для образования IPSec SA (Security Association), которую мы обсудим ниже. Его задача - организация согласованной работы участников шифрованного соединения. Благодаря этому протоколу участники узнают об используемом алгоритме шифрования, проверки целостности и взаимной аутентификации.
Но разберемся с тем, что же такое Security Association. Это набор параметров защищенного соединения (самый минимум - алгоритма шифрования и ключа шифрования), которые будут участниками этого самого соединения эксплуатироваться. Таким образом каждое соединение имеет свою ассоциированную конкретно с ним SA.
Теперь разберемся с алгоритмом создания IPSec-соединения.
-> Можно сказать нулевой шаг. Катализатором всего процесса служит попадание некого трафика в соответствие access list'а в crypto map'е. А уже после этого начинается волшебство.
-> Сначала запускается протокол 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 обновляются ключи шифрования основного туннеля. Партнеры по IPSec связываются посредством ISAKMP-туннеля и ставят новые SA.
Теперь давайте обсудим следующий момент. Трансформ-сет и отличия между ESP/AH. Шифрование данных при прохождении через туннель определяет команда crypto ipsec transform-set имя_сета, за которой следует название использующегося протокола и алгоритм его работы.
Вот пример:

crypto ipsec transform-set SET1 esp-aes

Следуя данной команде маршрутизатор поймет, что трансформ-сет с именем SET1 при использовании будет работать по протоколу ESP с алгоритмом шифрования AES. Ладно, с ESP ничего особенно сложного, он обеспечивает конфиденциальность информации путем её шифрования, а что же такое AH? А вот AH обеспечивает аутентификацию, чтобы на другом конце туннеля всегда были уверены в достоверности данных и правильности отправителя (может быть по пути данные были перехвачены и изменены). Мы сейчас не будем залезать в самую глубь процесса, а коснемся принципа только в двух словах.
В каждый пакет между заголовками транспортного и сетевого уровня вставляется AH-заголовок, в него при этом входит:
• Информация, благодаря которой получатель (читай, адресат) может определить к какой SA пакет относится конкретный пакет. Например, в этих директивах определяется алгоритм чтения хеша, тот же MD5 или SHA.
• Сюда же отнесем ICV (Integrity Check Value), хеш-сумма пакета. Конечно, не всего пакета, а выбранных неизменяемых в процессе транспортировки полей. Сравнение вычисленной хеш-суммы с хранящейся в соответствующем поле позволяет точно быть уверенными, что пакет не подвергался изменениям на пути между отправителем и получателем.
Существует два режима работы набора протоколов IPSec - туннельный и транспортный.

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

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

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

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

crypto isakmp policy 1
encr aes
authentication pre-share

Вообще говоря, политик может быть далеко не одна. Можно создать целый их ворох, при этом номер политики будет отражать и порядок её рассмотрения (всё зависит от инициатора соединения). Начинается проверка с первого номера, и в случае несовпадения на обеих сторонах идем проверять дальше. Самой безопасной следует сделать первую.
Тут мы укажем 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):

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

Здесь и устанавливается IP-адрес соседа по туннелю, в нашем случае это 200.0.0.1. Сюда же накидываем набор протоколов и access list'ы, которые будут определять, какой трафик станет шифроваться и отправляться по туннелю. У нас это будет так:

access-list 101 permit ip host 10.0.0.0 host 10.1.1.0

К созданию ACL для туннеля следует отнестись очень внимательно, т.к. они определяют правила не только для исходящего, но и для входящего трафика. Со списком доступа для NAT, допустим, всё иначе. Что это означает для нас? Всё очень просто, придут пакеты не с IP 10.1.1.0, а с 10.2.2.2, а их никто не станет дешифровывать и просто завернут на входе в туннель.
Еще раз, вот мы гоняем трафик с хоста из сети 10.0.0.0 на 10.1.1.0, то ходить через туннель туда-сюда будет только он, остальной трафик уйдет на другие маршруты.
Примечание. Шифрование происходит уже после маршрутизации, перед самой отправкой пакета. Почему это так важно? Дело в том, что маршрута до указанного публичного пира 200.0.0.1 нам будет мало, нужен маршрут именно до приватного 10.1.1.0 (любой, хоть дефолтный), в противном случае пакет будет дропнут, следуя стандартным правилам маршрутизации. Да, кажется слегка бредовым, но трафик в локальную сеть должен рутиться в глобальные интернеты. Пакеты с приватными IP-заголовками перед самой отправкой к провайдеру (и закономерным дропом там) шифруются и получают уже публичные IP-заголовки. Можно здесь почитать, как при этом производится обработка трафика.

Осталось привязать карту шифрования к конкретному интерфейсу. Ничего не взлетит, пока мы этого не сделаем:

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

Отчего так грустно? Просто по туннелю для его активизации нужно запулить какой-то трафик, хотя бы ICMP-пакетики:

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

Итоговый конфиг маршрутизаторов

hostname R1
!
crypto isakmp policy 1
 authentication pre-share
crypto isakmp key cisco address 200.0.0.1
!        
!
crypto ipsec transform-set AES128-SHA esp-aes esp-sha-hmac
!
crypto map MAP1 10 ipsec-isakmp
 set peer 200.0.0.1
 set transform-set AES128-SHA
 match address 101
!
!
!
!
interface Loopback0
 ip address 10.0.0.0 255.255.255.255
!         

interface FastEthernet0/0
 ip address 100.0.0.1 255.255.255.252
 duplex auto
 speed auto
 crypto map MAP1

ip route 0.0.0.0 0.0.0.0 100.0.0.2
!
access-list 101 permit ip host 10.0.0.0 host 10.1.1.0
!

hostname R2
!
interface FastEthernet0/0
ip address 100.0.0.2 255.255.255.252
duplex auto
speed auto
!
interface FastEthernet0/1
ip address 200.0.0.2 255.255.255.252
duplex auto
speed auto

hostname R3
!
crypto isakmp policy 1
 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 Loopback0
 ip address 10.1.1.0 255.255.255.255
!
interface FastEthernet0/1
 ip address 200.0.0.1 255.255.255.0
 duplex auto
 speed auto
 crypto map MAP1
!
!
ip route 0.0.0.0 0.0.0.0 200.0.0.2
!
!access-list 101 permit ip host 10.1.1.0 host 10.0.0.0

Задача №7.1

Взято с блога LinkMeUp

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

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

Стартовый конфиг R4:

hostname R4!
interface Loopback0
ip address 10.2.2.0 255.255.255.255
!
interface FastEthernet0/1
ip address 202.0.0.1 255.255.255.252
duplex auto
speed auto
!
ip route 0.0.0.0 0.0.0.0 202.0.0.2

Конфиг R2:

hostname R2
!
interface FastEthernet0/0
ip address 100.0.0.2 255.255.255.252
duplex auto
speed auto
!
interface FastEthernet0/1
ip address 200.0.0.2 255.255.255.252
duplex auto
speed auto
!
interface FastEthernet1/0
ip address 202.0.0.2 255.255.255.252
duplex auto
speed auto

Ответ

Настраиваем R4 таким образом:

crypto isakmp policy 1
authentication pre-share
crypto isakmp key cisconew 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.2.2.0 host 10.0.0.0
access-list 101 permit ip host 10.2.2.0 host 10.1.1.0

На R3 достаточно добавить ACL:

access-list 101 permit ip host 10.1.1.0 host 10.0.0.0
access-list 101 permit ip host 10.1.1.0 host 10.2.2.0

Теперь переходим к R1:

crypto isakmp policy 1
authentication pre-share
crypto isakmp key cisco address 200.0.0.1
crypto isakmp key cisconew address 202.0.0.1
!
crypto map MAP1 10 ipsec-isakmp
set peer 200.0.0.1
set transform-set AES128-SHA
match address 101
crypto map MAP1 20 ipsec-isakmp
set peer 202.0.0.1
set transform-set AES128-SHA
match address 102
!
!
interface FastEthernet0/0
crypto map MAP1
!
access-list 101 permit ip host 10.0.0.0 host 10.1.1.0
access-list 101 permit ip host 10.2.2.0 host 10.1.1.0
!
access-list 102 permit ip host 10.0.0.0 host 10.2.2.0
access-list 102 permit ip host 10.1.1.0 host 10.2.2.0

Поясним в двух словам по конфигу R1. К интерфейсу у нас может быть применена только одна crypto-map, поэтому вполне логично, что настройки туннеля до R4 добавлены в уже существующую crypto-map MAP1. Правила в crypto-map отсортированы по порядку, поэтому прогоняемый через интерфейс трафик проверяется на все ACL по порядку в искомой crypto-map.

Но давайте вернемся к нашим баранам. (1) Мы запустили пинги по туннелю с хоста 10.0.0.0 на адрес 10.1.1.0, (2) маршрутизатор исходя из таблицы маршрутизации должен передать пакет в публичную сеть в исходном виде без каких-либо изменений. (3) Но тут он замечает, что пакет попадает под его собственное правило ACL 101, после чего пакет передается уже протоколу IPSec для дальнейшей работы. (4) Работая по-умолчанию в туннельном режиме IPSec сначала инкапсулирует наш исходны пакет в IPSec PDU, шифрую в соответствии с описанным выше конфигом, а после накидывает поверх новый заголовок IP. При этом его destination address будет IP-адресом соседа по туннелю - 200.0.0.1.
Обратимся к Wireshark, чтобы посмотреть на процесс инкапсуляции:

Здесь представлен обмен ICMP-пакетами. Исходные данные зашифрованы вместе со старым IP-заголовком, новый же присвоен исходя из настроек IPSec. (5) Маршрутизатор на конечном узле видит в качестве destination address свой собственный IP, радостно разворачивает его и видит заголовок IPSec, после чего передает его соответствующему протоколу для дальнейшей обработки. IPSec дешифрует его, откидывает ненужную служебную информацию и отправляет полученный пакет в чистом виде дальше.
Наверное, нужно небольшое пояснение. Зачем запускать тот странный пинг с явным указанием адреса отправителя? Всё очень просто, если запустить ping 10.1.1.0, он банально не пройдет, т.к. маршрутизатор услужливо подставит в качестве source address IP физического интерфейса - 100.0.0.1 в нашем случае. Вот только в наших ACL его нет и пакет отправится на шлюз последней надежды.
Вроде все понятно, но... Чувствуются какие-то подводные камни... Точно! Динамическая маршрутизация испортит нам всю малину! Её попросту не получится использовать, ведь всем этим вашим IGP нужен прямой L2-линк между соседями, а наш новый знакомый IPSec по понятным причинам обеспечить это не может. Поэтому в описанной нами конфигурации трафик будет рутиться не таблицей маршрутизации, а на основе ACL и crypto map.
М-м, точно, еще и мультикаст не сможет нормально ходить, ведь в ACL мы задаем только конкретные подсети.

Текущий конфиг маршрутизаторов

hostname R1
!
crypto isakmp policy 1
 authentication pre-share
crypto isakmp key cisco address 200.0.0.1
!        
!
crypto ipsec transform-set AES128-SHA esp-aes esp-sha-hmac
!
crypto map MAP1 10 ipsec-isakmp
 set peer 200.0.0.1
 set transform-set AES128-SHA
 match address 101
!
!
!
!
interface Loopback0
 ip address 10.0.0.0 255.255.255.255
!         

interface FastEthernet0/0
 ip address 100.0.0.1 255.255.255.252
 duplex auto
 speed auto
 crypto map MAP1

ip route 0.0.0.0 0.0.0.0 100.0.0.2
!
access-list 101 permit ip host 10.0.0.0 host 10.1.1.0
!

hostname R2
!
interface FastEthernet0/0
ip address 100.0.0.2 255.255.255.252
duplex auto
speed auto
!
interface FastEthernet0/1
ip address 200.0.0.2 255.255.255.252
duplex auto
speed auto

hostname R3
!
crypto isakmp policy 1
 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 Loopback0
 ip address 10.1.1.0 255.255.255.255
!
interface FastEthernet0/1
 ip address 200.0.0.1 255.255.255.0
 duplex auto
 speed auto
 crypto map MAP1
!
!
ip route 0.0.0.0 0.0.0.0 200.0.0.2
!
!
access-list 101 permit ip host 10.1.1.0 host 10.0.0.0

Задача №7.2

Взято с блога LinkMeUp

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

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

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

crypto isakmp policy 1
encr des
authentication pre-share
group 1
hash md5
!
crypto isakmp policy 2
encr 3des
authentication pre-share
group 2
hash sha
!
crypto isakmp policy 3
encr aes
authentication pre-share
group 5
hash sha
!
crypto isakmp key cisco address 200.0.0.1
crypto isakmp key cisco123 address 202.0.0.1
crypto isakmp key cisco456 address 203.0.0.1
!
!
crypto ipsec transform-set AES128-SHA esp-aes esp-sha-hmac
crypto ipsec transform-set DES-MD5 esp-des esp-md5-hmac
crypto ipsec transform-set 3DES-SHA esp-3des esp-sha-hmac
!
crypto map MAP1 10 ipsec-isakmp
set peer 200.0.0.1
set transform-set AES128-SHA
match address 101
crypto map MAP1 20 ipsec-isakmp
set peer 202.0.0.1
set transform-set 3DES-SHA
match address 102
crypto map MAP1 30 ipsec-isakmp
set peer 203.0.0.1
set transform-set DES-MD5
match address 103
!
!
interface FastEthernet0/0
crypto map MAP1
!
!
access-list 101 permit ip host 10.0.0.0 host 10.1.1.0
access-list 102 permit ip host 10.0.0.0 host 10.2.2.0
access-list 103 permit ip host 10.0.0.0 host 10.3.3.0

Конфигурация R3 (только IPsec):

hostname R3
!
crypto isakmp policy 40
encr aes
authentication pre-share
group 5
hash sha
!
crypto isakmp policy 50
encr 3des
authentication pre-share
group 2
hash sha
!
crypto isakmp policy 100
encr des
authentication pre-share
group 1
hash md5
!
crypto isakmp key cisco address 100.0.0.1
crypto isakmp key partner1 address 22.0.0.1
crypto isakmp key partner2 address 23.0.0.1
!
!
crypto ipsec transform-set AES128-SHA esp-aes esp-sha-hmac
crypto ipsec transform-set DES-MD5 esp-des esp-md5-hmac
crypto ipsec transform-set 3DES-SHA esp-3des esp-sha-hmac
!
crypto map MAP1 10 ipsec-isakmp
set peer 100.0.0.1
set transform-set AES128-SHA
match address 101
crypto map MAP1 20 ipsec-isakmp
set peer 22.0.0.1
set transform-set 3DES-SHA
match address 102
crypto map MAP1 30 ipsec-isakmp
set peer 23.0.0.1
set transform-set DES-MD5
match address 103
!
!
interface FastEthernet0/1
crypto map MAP1
!
!
access-list 101 permit ip host 10.0.0.0 host 10.1.1.0
access-list 102 permit ip host 10.0.0.0 host 10.20.20.0
access-list 103 permit ip host 10.0.0.0 host 10.30.30.0

Ответ

R3 —> R1

crypto isakmp policy:encr desauthentication pre-sharegroup 1hash md5

Генерируем трафик с R3 на R1:

R3#ping 10.0.0.0 source 10.1.1.0

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.0.0.0, timeout is 2 seconds:
Packet sent with a source address of 10.1.1.0
!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 552/589/600 ms

Проверяем какая политика отработала:

R3#sh cry isa sa detail

C-id Local Remote I-VRF Status Encr Hash Auth DH Lifetime Cap.
1003 200.0.0.1 100.0.0.1 ACTIVE des md5 psk 1 23:59:18
Engine-id:Conn-id = SW:3

При желании, можно проверить какая политика будет, если туннель будет инициирован со стороны R1.
Прежде чем это делать, необходимо удалить предыдущие туннели IPsec:

clear crypto isakmpclear crypto ipsec sa

R1 —> R3:

crypto isakmp policy:encr aesauthentication pre-sharegroup 5hash sha

Генерируем трафик с R1 на R3:

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 100 percent (5/5), round-trip min/avg/max = 16/277/480 ms

R1#sh crypto isakmp sa detail

C-id Local Remote I-VRF Status Encr Hash Auth DH Lifetime Cap.
1003 100.0.0.1 200.0.0.1 ACTIVE aes sha psk 5 23:59:11
Engine-id:Conn-id = SW:3

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

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

Отличий от туннельного тут целый вагон, но самое важное для нас - метод инкапсуляции.
Пакет в туннельном режиме IPSec выглядит так:

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

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

Задача №7.3

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

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

hostname R1
!
crypto isakmp policy 1
authentication pre-share
crypto isakmp key cisco address 200.0.0.1
crypto isakmp key cisconew address 202.0.0.1
!
!
crypto ipsec transform-set AES128-SHA esp-aes esp-sha-hmac
!
crypto map MAP1 10 ipsec-isakmp
set peer 200.0.0.1
set transform-set AES128-SHA
match address 101
crypto map MAP1 20 ipsec-isakmp
set peer 202.0.0.1
set transform-set AES128-SHA
match address 102
!
!
interface Loopback0
ip address 10.0.0.0 255.255.255.255
!
interface FastEthernet0/0
ip address 100.0.0.1 255.255.255.252
duplex auto
speed auto
crypto map MAP1
!
ip route 0.0.0.0 0.0.0.0 100.0.0.2
!
access-list 101 permit ip 10.0.0.0 0.0.0.255 10.1.1.0 0.255.255.255
access-list 102 permit ip 10.0.0.0 0.0.0.255 10.2.2.0 0.0.0.255

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

hostname R2
!
interface FastEthernet0/0
ip address 100.0.0.2 255.255.255.252
duplex auto
speed auto
!
interface FastEthernet0/1
ip address 200.0.0.2 255.255.255.252
duplex auto
speed auto
!
interface FastEthernet1/0
ip address 202.0.0.2 255.255.255.252
duplex auto
speed auto

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

hostname R3
!
crypto isakmp policy 1
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 Loopback0
ip address 10.1.1.0 255.255.255.255
!
interface FastEthernet0/1
ip address 200.0.0.1 255.255.255.0
duplex auto
speed auto
crypto map MAP1
!
!
ip route 0.0.0.0 0.0.0.0 200.0.0.2
!
access-list 101 permit ip 10.1.1.0 0.255.255.255 10.0.0.0 0.0.0.255

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

hostname R4
!
crypto isakmp policy 1
authentication pre-share
crypto isakmp key cisconew 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 Loopback0
ip address 10.2.2.0 255.255.255.255
!
interface FastEthernet0/1
ip address 202.0.0.1 255.255.255.0
duplex auto
speed auto
crypto map MAP1
!
ip route 0.0.0.0 0.0.0.0 202.0.0.2
!
access-list 101 permit ip host 10.2.2.0 host 10.0.0.0

Ответ

Пример процесса поиска неисправностей. Проверяем работу VPN.
Со стороны R1 данные не передаются:

R1#ping 10.2.2.0 source 10.0.0.0

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.2.2.0, timeout is 2 seconds:
Packet sent with a source address of 10.0.0.0
…
Success rate is 0 percent (0/5)

На R1 isakmp sa с R4 не устанавливается (установлено только sa с R3):

R1#sh crypto isakmp sa
IPv4 Crypto ISAKMP SA
dst src state conn-id status
200.0.0.1 100.0.0.1 QM_IDLE 1007 ACTIVE

Со стороны R4 данные не передаются:

R4#ping 10.0.0.0 source 10.2.2.0

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.0.0.0, timeout is 2 seconds:
Packet sent with a source address of 10.2.2.0
…
Success rate is 0 percent (0/5)

Однако установилось ISAKMP SA с R1:

R4#sh crypto isakmp sa
IPv4 Crypto ISAKMP SA
dst src state conn-id status
100.0.0.1 202.0.0.1 QM_IDLE 1002 ACTIVE

Перепроверяем его на R1:

R1#sh crypto isakmp sa
IPv4 Crypto ISAKMP SA
dst src state conn-id status
100.0.0.1 202.0.0.1 QM_IDLE 1008 ACTIVE
200.0.0.1 100.0.0.1 QM_IDLE 1007 ACTIVE

IPsec sa не устанавливаются:

R4#sh crypto ipsec sa

interface: FastEthernet2/0
Crypto map tag: MAP1, local addr 202.0.0.1

protected vrf: (none)
local ident (addr/mask/prot/port): (10.2.2.0/255.255.255.0/0/0)
remote ident (addr/mask/prot/port): (10.0.0.0/255.255.255.0/0/0)
current_peer 100.0.0.1 port 500
PERMIT, flags={origin_is_acl,ipsec_sa_request_sent}
#pkts encaps: 5, #pkts encrypt: 5, #pkts digest: 5
#pkts decaps: 5, #pkts decrypt: 5, #pkts verify: 5
#pkts compressed: 0, #pkts decompressed: 0
#pkts not compressed: 0, #pkts compr. failed: 0
#pkts not decompressed: 0, #pkts decompress failed: 0
#send errors 20, #recv errors 0

local crypto endpt.: 202.0.0.1, remote crypto endpt.: 100.0.0.1
path mtu 1500, ip mtu 1500, ip mtu idb FastEthernet2/0
current outbound spi: 0x0(0)
PFS (Y/N): N, DH group: none

inbound esp sas:

inbound ah sas:

inbound pcp sas:

outbound esp sas:

outbound ah sas:

outbound pcp sas:

Остается проверить настройки, которые относятся ко второй фазе IPsec (все параметры crypto-map и правильность их указания).

R1#sh run | s access-list
R1#sh crypto map

Решение:
Crypto-map состоит из наборов правил, которые отсортированы по порядку. Когда трафик проходит через интерфейс, на котором применена crypto-map, он проверяется на совпадение с ACL, по порядку, по всем наборам правил crypto-map.
Если найдено совпадение, то просмотр останавливается, инициируется туннель с параметрами этого набора правил crypto-map.

На R1 в crypto-map MAP1 ACL 101 используется в первом наборе правил:

crypto map MAP1 10 ipsec-isakmp

set peer 200.0.0.1

set transform-set AES128-SHA

match address 101

crypto map MAP1 20 ipsec-isakmp

set peer 202.0.0.1

set transform-set AES128-SHA

match address 102

Но он создан таким образом, что в ACL 101 попадает и трафик с R1 на R4:

access-list 101 permit ip 10.0.0.0 0.0.0.255 10.0.0.0 0.255.255.255

Поэтому и не создается туннель между R1 и R4, если пинговать с R1 loopback-интерфейс R4. Когда пинг запускается в обратном направлении, отрабатывает первая фаза, устанавливается isakmp sa, так как настройки со стороны R4 правильные и он может инициировать создание туннеля.
Но sa второй фазы (ipsec sa) не устанавливаются, так как не совпадают ACL между R1 и R4.
Исправляем ACL 101:

R1(config)#no access-list 101 permit ip 10.0.0.0 0.0.0.255 10.0.0.0 0.255.255.255
R1(config)#access-list 101 permit ip 10.0.0.0 0.0.0.255 10.1.1.0 0.0.0.255
R1#sh run | s access
access-list 101 permit ip 10.0.0.0 0.0.0.255 10.1.1.0 0.0.0.255
access-list 102 permit ip 10.0.0.0 0.0.0.255 10.2.2.0 0.0.0.255

Всё работает:

R4#ping 10.0.0.0 source 10.2.2.0

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.0.0.0, timeout is 2 seconds:
Packet sent with a source address of 10.2.2.0
!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 508/575/628 ms

Задачка взята с блога LinkMeUp

GRE over IPSec

Давайте сразу разберемся в понятиях, не будем путать теплое с мягким - GRE over IPSec и совсем другое IPSec over GRE. Самый распространенный режим работы первый, указанный также в подзаголовке этой статьи. Принцип тут такой, что данные протокола 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 байт с каждого пакета за счет отпиливания ненужного заголовка.

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

Важно! Таким образом нужно сконфигурировать обе стороны, иначе никакой дружбы собратья по IPSec водить не будут.
Что дальше? Шифроваться должен весь трафик, который ходит между филиалами, т.е. идущий через туннель. Это значит, что в access list нет нужды прописывать все сети, можно поступить так:

access-list 101 permit gre host 100.0.0.1 host 200.0.0.1

Данное условие сработает при прохождении трафика с GRE-заголовком и указанными адресами. Как это выглядит на практике? Давайте разбираться.
1. Пакет с destination address 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. А что там у нас? Туннельный интерфейс с destination address 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

На него в свою очередь применена crupto map с ACL. Трафик подпадает под данные правила (имеется GRE-заголовок и требуемые IP), и всё кроме внешнего заголовка IP шифруется.
Эта схема работы позволяет нормально существовать протоколам динамической маршрутизации и ходить мультикаст-трафику, оставляя при этом возможность шифрования. Враг не пройдет.

Задача №7.5

Описание проблемы: После настройки 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).

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

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

hostname R1
!
crypto isakmp policy 1
authentication pre-share
crypto isakmp key cisco address 200.0.0.1
!
!
crypto ipsec transform-set AES128-SHA esp-aes esp-sha-hmac
mode transport
!
crypto map CRMAP1 10 ipsec-isakmp
set peer 200.0.0.1
set transform-set AES128-SHA
match address 120
!
interface Loopback0
ip address 10.0.0.0 255.255.255.255
!
interface Tunnel0
ip address 10.20.2.1 255.255.255.252
tunnel source 100.0.0.1
tunnel destination 200.0.0.1
!
interface FastEthernet0/0
ip address 100.0.0.1 255.255.255.252
duplex auto
speed auto
crypto map CRMAP1
!
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.20.2.2
!
access-list 120 permit gre host 10.0.0.0 host 10.1.1.0

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

hostname R2
!
interface FastEthernet0/0
ip address 100.0.0.2 255.255.255.252
duplex auto
speed auto
!
interface FastEthernet0/1
ip address 200.0.0.2 255.255.255.252
duplex auto
speed auto

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


hostname R3
!
crypto isakmp policy 1
authentication pre-share
crypto isakmp key cisco address 100.0.0.1
!
!
crypto ipsec transform-set AES128-SHA esp-aes esp-sha-hmac
mode transport
!
crypto map CRMAP1 10 ipsec-isakmp
set peer 100.0.0.1
set transform-set AES128-SHA
match address 120
!
!
interface Loopback0
ip address 10.1.1.0 255.255.255.255
!
interface Tunnel0
ip address 10.20.2.2 255.255.255.252
tunnel source 200.0.0.1
tunnel destination 100.0.0.1
!
interface FastEthernet0/1
ip address 200.0.0.1 255.255.255.0
duplex auto
speed auto
crypto map CRMAP1
!
!
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.20.2.1
!
access-list 120 permit gre host 10.1.1.0 host 10.0.0.0

Пример процесса поиска неисправностей:
Проверяем доступность loopback'а R3 с R1:

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 100 percent (5/5), round-trip min/avg/max = 200/215/220 ms

Проверяем isakmp sa (их нет):

R1#sh cry isa sa
IPv4 Crypto ISAKMP SA
dst src state conn-id status

Самые простые причины могут быть такими:
— не применена cryto-map
— не правильно настроена crypto-map
— трафик не попадает под описание того трафика, который надо шифровать

Проверяем настройки crypto-map:

R1#sh crypto map
Crypto Map «CRMAP1» 10 ipsec-isakmp
Peer = 200.0.0.1
Extended IP access list 120
access-list 120 permit gre host 10.0.0.0 host 10.1.1.0
Current peer: 200.0.0.1
Security association lifetime: 4608000 kilobytes/3600 seconds
Responder-Only (Y/N): N
PFS (Y/N): N
Transform sets={
AES128-SHA: { esp-aes esp-sha-hmac },
}
Interfaces using crypto map CRMAP1:
FastEthernet0/0

В конце видим, что crypto-map применена на правильный интерфейс, peer указан правильно.
Но если внимательно присмотреться к ACL, то видно, что он неправильно настроен.
Хотя, первичный трафик идет с 10.0.0.0 на 10.1.1.0, затем он инкапсулируется в GRE, и до физического интерфейса уже доходит с адресами в заголовках, не 10.0.0.0 и 10.1.1.0, а 100.0.0.1 и 200.0.0.1.
Надо исправить ACL на R1:

R1#sh run | s accessaccess-list 120 permit gre host 10.0.0.0 host 10.1.1.0
R1(config)# no access-list 120 permit gre host 10.0.0.0 host 10.1.1.0
R1(config)# access-list 120 permit gre host 100.0.0.1 host 200.0.0.1

Аналогично проверяем на R3:

R3#sh crypto map
Crypto Map «CRMAP1» 10 ipsec-isakmp
Peer = 100.0.0.1
Extended IP access list 120
access-list 120 permit gre host 10.1.1.0 host 10.0.0.0
Current peer: 100.0.0.1
Security association lifetime: 4608000 kilobytes/3600 seconds
Responder-Only (Y/N): N
PFS (Y/N): N
Transform sets={
AES128-SHA: { esp-aes esp-sha-hmac },
}
Interfaces using crypto map CRMAP1:
FastEthernet0/1

Исправляем ACL и на R3:

R3#sh run | s accessaccess-list 120 permit gre host 10.1.1.0 host 10.0.0.0
R3(config)#no access-list 120 permit gre host 10.1.1.0 host 10.0.0.0
R3(config)#access-list 120 permit gre host 200.0.0.1 host 100.0.0.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:
Packet sent with a source address of 10.0.0.0
!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 548/588/600 ms

R1#sh crypto isa sa
IPv4 Crypto ISAKMP SA
dst src state conn-id status
200.0.0.1 100.0.0.1 QM_IDLE 1011 ACTIVE

R1#sh crypto session detail
Crypto session current status

Code: C — IKE Configuration mode, D — Dead Peer Detection
K — Keepalives, N — NAT-traversal, T — cTCP encapsulation
X — IKE Extended Authentication, F — IKE Fragmentation

Interface: FastEthernet0/0
Uptime: 00:01:46
Session status: UP-ACTIVE
Peer: 200.0.0.1 port 500 fvrf: (none) ivrf: (none)
Phase1_id: 200.0.0.1
Desc: (none)
IKE SA: local 100.0.0.1/500 remote 200.0.0.1/500 Active
Capabilities:(none) connid:1011 lifetime:23:58:03
IPSEC FLOW: permit 47 host 100.0.0.1 host 200.0.0.1
Active SAs: 2, origin: crypto map
Inbound: #pkts dec'ed 8 drop 0 life (KB/Sec) 4467199/3493
Outbound: #pkts enc'ed 8 drop 2 life (KB/Sec) 4467199/3493

Решение:
Надо исправить ACL на R1 и R3:

R1#sh run | s accessaccess-list 120 permit gre host 10.0.0.0 host 10.1.1.0
R1(config)# no access-list 120 permit gre host 10.0.0.0 host 10.1.1.0
R1(config)# access-list 120 permit gre host 100.0.0.1 host 200.0.0.1
R3#sh run | s accessaccess-list 120 permit gre host 10.1.1.0 host 10.0.0.0
R3(config)#no access-list 120 permit gre host 10.1.1.0 host 10.0.0.0
R3(config)#access-list 120 permit gre host 200.0.0.1 host 100.0.0.1

Задача с блога LinkMeUp

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

hostname R1
!
crypto isakmp policy 1
authentication pre-share
crypto isakmp key cisco address 200.0.0.1
!        
!
crypto ipsec transform-set T1 esp-aes esp-sha-hmac
mode transport
!
crypto map MAP1 10 ipsec-isakmp
set peer 200.0.0.1
set transform-set T1
match address 101
!
!
!
!
interface Loopback0
ip address 10.0.0.0 255.255.255.255
!
interface Tunnel0
ip address 10.2.2.1 255.255.255.252
tunnel source 100.0.0.1
tunnel destination 200.0.0.1
!      
interface FastEthernet0/0
ip address 100.0.0.1 255.255.255.252
crypto map MAP1
duplex auto
speed auto
!
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
!
access-list 101 permit gre host 100.0.0.1 host 200.0.0.1
!

hostname R2
!
interface FastEthernet0/0
ip address 100.0.0.2 255.255.255.252
duplex auto
speed auto
!
interface FastEthernet0/1
ip address 200.0.0.2 255.255.255.252
duplex auto
speed auto

hostname R3
!
crypto isakmp policy 1
authentication pre-share
crypto isakmp key cisco address 100.0.0.1
!        
!
crypto ipsec transform-set T1 esp-aes esp-sha-hmac
mode transport
!
crypto map MAP1 10 ipsec-isakmp
set peer 100.0.0.1
set transform-set T1
match address 101
!
!
!
!
interface Loopback0
ip address 10.1.1.0 255.255.255.255
!
interface Tunnel0
ip address 10.2.2.2 255.255.255.252
tunnel source 200.0.0.1
tunnel destination 100.0.0.1
!
interface FastEthernet0/1
ip address 200.0.0.1 255.255.255.0
crypto map MAP1
duplex auto
speed auto
!
!
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
!
access-list 101 permit gre host 200.0.0.1 host 100.0.0.1

Замечание. Вообще-то можно выкинуть заголовок GRE из пакетов, указав на обоих концах туннеля режим работы IPIP:

interface Tunnel0
tunnel mode ipip

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

Задача №7.4

IPSec VTI

Ну, а это уже рекомендованный самой циской тип Site-to-Site VPN с использованием IPSec - Virtual Tunnel Interface или просто VTI. Давайте попробуем разобраться в разнице настройки. Нам уже не нужно создавать crypto-map, а вместе с ней ACL, требуется только запилить IPSec-профиль:

crypto isakmp policy 1
authentication pre-share
crypto isakmp key CISCO address 100.0.0.1
!
!
crypto ipsec transform-set AES128-SHA esp-aes esp-sha-hmac 
mode transport

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

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

interface Tunnel0
tunnel protection ipsec profile VTI-P

Почему такое отличие по сравнению с создававшимися ранее crypto-map? Нам уже не нужны ACL, т.к. весь трафик идущий в туннель шифруется. При этом указанные карты шифрования таки создаются, но не пользователем, а в автоматическом режиме.
Мы получили самый обычный Tunnel Protection, но без VTI. Распространен он очень сильно. А уже добавив команду tunnel mode ipsec ipv4 мы получим этот самый VTI. В чем отличие от обычного GRE? По сути только в процессе инкапсуляции, т.к. в VTI просто нет четырехбайтового GRE-заголовка.
Подробнее на английском.

Полный конфиг IPSec VTI ver.7


hostname R1
!
crypto isakmp policy 1
 authentication pre-share
crypto isakmp key cisco address 200.0.0.1
!        
!
crypto ipsec transform-set AES128-SHA esp-aes esp-sha-hmac
mode transport
!
crypto ipsec profile P1
set transform-set AES128-SHA
!
!
!
!
!
!
interface Loopback0
 ip address 10.0.0.0 255.255.255.255
!
!
interface Tunnel0
 ip address 10.2.2.1 255.255.255.252
 tunnel source 100.0.0.1
 tunnel destination 200.0.0.1
 tunnel mode ipsec ipv4
 tunnel protection ipsec profile P1
!
interface FastEthernet0/0
 ip address 100.0.0.1 255.255.255.252
 duplex auto
 speed auto
!
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

hostname R2
!
interface FastEthernet0/0
ip address 100.0.0.2 255.255.255.252
duplex auto
speed auto
!
interface FastEthernet0/1
ip address 200.0.0.2 255.255.255.252
duplex auto
speed auto

hostname R3
!
crypto isakmp policy 1
 authentication pre-share
crypto isakmp key cisco address 100.0.0.1
!        
!
crypto ipsec transform-set AES128-SHA esp-aes esp-sha-hmac
mode transport
!
crypto ipsec profile P1
 set transform-set AES128-SHA
!
!
!
!
!
!
interface Loopback0
 ip address 10.1.1.0 255.255.255.255
!
interface Tunnel0
 ip address 10.2.2.2 255.255.255.252
 tunnel source 200.0.0.1
 tunnel destination 100.0.0.1
 tunnel mode ipsec ipv4
 tunnel protection ipsec profile P1
!
interface FastEthernet0/1
 ip address 200.0.0.1 255.255.255.0
 duplex auto
 speed auto
!
!
ip route 0.0.0.0 0.0.0.0 200.0.0.2
ip route 10.0.0.0 255.255.255.255 Tunnel0
!

DMVPN

Настройка DMVPN на маршрутизаторах Cisco. XGU.RU
dmvpn/config XGU.RU
В качестве изюминки на кексе рассмотрим Dymamic Multipoint VPN или же просто DMVPN. До этого мы говорили об универсальных механизмах создания туннелей, а вот этот зверь уже проприетарная разработка Cisco со всеми вытекающими.
Проблемы с безопасностью мы порешали путем шифрования данных, и с IGP тоже, ведь с GRE over IPSec мы можем юзать протоколы динамической маршрутизации. Теперь разберемся с масштабируемостью нашей сети.
Ладно, если у нас такая маленькая сетка:

Всего по два туннеля на каждом из узлов. Попробуем добавить еще один узел:

А потом еще один...

Туннелей нужно всё больше и больше, чтобы топология была адекватно связана. Проблемка со сложностью вида m*(m-1)/2.
Окей, давайте не будем использовать Full-Mesh, а организуем топологию Hub-and-Spoke только с одной центральной точкой. Но тогда весь трафик со всех филиалов будет проходить через центральный узел.
В нашем случае DMVPN станет панацеей от всех этих проблем. Как это работает? Выбирается одна или несколько точек, которые назначаются центральными (Hub). Хаб является сервером, к которому будут подключаться клиенты (Spoke) и получать всю необходимую им информацию. При этом имеются все возможные удобства:
> Шифрование данных посредством IPSec.
> Возможность передачи данных клиент-клиент минуя центральный узел.
> Только на центральном Hub-узле требуется публичный IP-адрес. Клиенты при этом могут иметь динамические IP или вообще сидеть за NAT'ом с приватными адресами (курим технологию NAT traversal). Правда есть косяк с созданием динамических туннелей, но это уже другая история.

Теория и практика 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 nhrp map multicast dynamic - то самое динамическое изучение NHRP-данных от клиентов. Понятное дело, если клиентов у нас валом и они вдобавок имеют динамические IP-адреса, то явного соответствия внешних айпишников внутренним задать не получится.
ip nhrp network-id 1 - назначаем Network ID, некий идентификатор, который в принципе не обязательно должен быть одинаковым у всех узлов сети. Тут он напоминает Router-ID у протокола OSPF.
tunnel source FastEthernet0/1.6 - скажем так, рудимент протокола GRE, привязка к физическому интерфейсу (или сабинтерфейсу, если брать наш случай).
tunnel mode gre multipoint - включаем терминирование всех туннелей от Spoke-точек. Будет он, следуя оригинальному термину, 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

А видим, что хаб послал аж пять Hello-пакетов и всего лишь один получил от филиала. В чем дело? Просто-напросто маршрутизатор не понимает, куда запуливать мультикастовые сообщения с destination address 224.0.0.5. В итоге хаб эти сообщения не получает и обрывает OSPF-сессию.

Продолжим разбираться с настройкой клиента.
ip nhrp network-id 1 - все тот же Network ID, да-да, и он может не совпадать с этим значением на хабе.
ip nhrp nhs 172.16.254.1 - адрес NHRP-сервера, т.е. статически прописанный адрес хаба. Вот почему для центрального узла нам нужен неизменный публичный IP. Именно на 172.16.254.1 клиенты будут отправлять запросы на регистрацию. В запросе содержится настроенный локальный адрес туннельного интерфейса и публичный адрес клиента (да-да, про нахождение клиента за NAT'ом пока не будем говорить). Всю полученную информацию хаб любовно записывает в свою NHRP-таблицу, в которой отражено соответствие IP-адресов. Да, эту самую таблицу он раздает по запросу клиентских 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 < >

Видим, что Tunnel0 is up, line protocol is up, и он имеет следующие параметры: Tunnel source 198.51.100.2 (FastEthernet0/1.6), destination UNKNOWN
Tunnel protocol/transport multi-GRE/IP
Отлично!

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 < >

Отлично, пакеты не проходят через хаб, а прямиком через глобальную сеть идут к целевому Spoke-узлу. Но это на вид всё так просто.
Как выглядит механика этого процесса?
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

* 172.16.254.3, from 172.16.255.132, 00:18:47 ago, via Tunnel0 - адрес сети directly connected к нашему 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

* directly connected, via Tunnel0 - и верно.
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 неизвестен и потому пакет уходит на хаб с публичным IP 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:

На этом роль хаба в общении двух Spoke-маршрутизаторов завершена.
6. Вот ICMP-запрос пришел на маршрутизатор в Томске.
tmsk-lenina-gw1, fa0/0:

Да, видно, что внешний заголовок гласит, что source address - это адрес хаба, но внутри присутствует заголовок с изначальным IP Новосибирского маршрутизатора.
7. Томск тоже пока не в курсе, кто там за IP 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 весь трафик с next hop 172.16.254.3 инкапсулируется в GRE с внешним IP-заголовком destination address 198.51.102.2 (при этом в роли source address выступит адрес физического интерфейса 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. Теперь пакет с destiantion address 198.51.102.2 уходит следуя таблице маршрутизации:

Gateway of last resort is 198.51.101.1 to network 0.0.0.0

В этом месте требуется небольшое уточнение. Да, филиалы общаются друг с другом не гоняя трафик через центральный узел, но без хаба ничего функционировать не будет, ведь именно он анонсирует клиентам NHRP-таблицу и все требующиеся маршруты. Филиалы по факту распространяют информацию о маршрутах не напрямую друг другу, а через хаб.
Сейчас конфиг узлов такой:

msk-arbat-gw1

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

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

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

Резюмируя. С чем мы уже разобрались:
- Филиалы подключены друг к другу, связность настроена.
- Поднята маршрутизация. Через mGRE без проблем гуляют IGP.
- Легкость масштабирования сети. При появлении нового Spoke-узла настроить нужно только его, остальных узлов сети и хаба это не касается.
- Сняли нагрузку с хаба. Он теперь гоняет только служебный трафик.
Что теперь? Б - безопасность.

IPSec

Эту нашу проблему решит шифрование. Да, при Site-to-Site VPN еще можно юзать pre-shared key, ведь IP-адрес у IPSec-пира задавался жестко, но с DMVPN такой фокус не пройдет - здесь нам нужна адаптивность конфигурации, мы ведь даже адресов нейборов не знаем наперед. Поэтому мы будем использовать сертификаты, в контексте цисок статью об этом можно покурить на xgu.
Это для следующих частей, а пока попользуем самый обыкновенный pre-shared key:

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 и crypto-map будут динамически подниматься при каждом сеансе между филиалами, но вот для каналов Hub-Spoke они всегда будут неизменны.

NAT-Traversal

Не пугайтесь, под занавес статьи не будет обсуждения принципов работы NAT traversal (aka NAT-T), всё будет коротко и по делу. Что это и с чем едят. Благодаря наличию дополнительного заголовка UDP протокол IPSec способен поднимать туннели сквозь NAT. Таким образом даже лишенный публичного адреса узел способен запустить VPN-сессию. Вся прелесть в том, что данный функционал уже не нужно включать/настраивать, он уже работает по дефолту.
Тем временем подкинем самим себе проблем и добавим в Брно еще один маршрутизатор.

Пусть это будет маршрутизатор местного прова, вся задача которого натить нашу сетку. Т.е. на физическом интерфейсе роутера в филиале будет динамический IP из приватного пула. Сам по себе протокол GRE тут будет сосать лапу, VPN при таком раскладе не поднять. Опять таки IPSec это может, но мы замучаемся ставить костыли. А вот если добавить к нему на помощь mGRE!..
Взглянем на 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 < >

10.0.0.2 - как видим, перед нами именно приватный IP от прова.
При этом в route table обязан иметься маршрут до этого выданного провайдером адреса. Так или иначе, пусть даже это маршрут по-умолчанию.
На туннельном интерфейса мы развернули IPSec, а значит там должны иметься crypto-map:

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

Peer = 198.51.103.2
Current peer: 198.51.103.2
Получается, что туннель у нас поднимается между 198.51.100.2 и 198.51.103.2, а уже потом шифрованный посредством NAT-T данные в туннеле идут на приватный 10.0.0.2
Остальное вам уже известно.
На хабре имеется крутой ликбез по NHRP.

Сеть и интернет / Статьи и теория

Жалоба
3 706
0

Jack Frost от 6-02-2018, 02:06

Знакомство с VPN. Три веселых буквы.

Похожее

Теги