СДСМ АДСМ Книги
return

Сети для самых маленьких. Часть седьмая. VPN

27 февраля 2013, 17:25
like 54 views 493103 message 125
Все выпуски СДСМ…

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

Итак, под крыло ЛинкМиАп планируется взять заводы в Новосибирске, Томске и Брно. Самое время подумать о том, как это хозяйство подключить к имеющейся сети.

Содержание выпуска

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

Указываем 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).
Подробности задачи тут

Полная конфигурация маршрутизаторов для GRE over 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 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 экономится 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. Нам бы действительно хотелось уделить внимание и этим и тем и вот ещё тем темам, но всё уложить в рамки одной статьи невозможно.

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

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

Благодарности

  • За мозгодробительные задачки спасибо Наташе
  • За комментарии и помощь спасибо Дмитрию
  • Статью для вас подготовили eucariot и gluck

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

Автор
eucariot — Марат Сибгатулин (inst, tg, in)

Оставайтесь на связи

Пишите нам: info@linkmeup.ru
Канал в телеграме: t.me/linkmeup_podcast
Канал на youtube: youtube.com/c/linkmeup-podcast
Подкаст доступен в iTunes, Google Подкастах, Яндекс Музыке, Castbox
Сообщество в вк: vk.com/linkmeup
Группа в фб: www.facebook.com/linkmeup.sdsm
Добавить RSS в подкаст-плеер.
Пообщаться в общем чате в тг: https://t.me/linkmeup_chat

Поддержите проект:

#dmvpn #ipsec #nhrp #remote access #sdsm #virtual private network #vpn #сети для самых маленьких
like 54 views 493103 message 125

125 коментариев

  • Олег

    Что такое IPSec over GRE?

    IPsec over GRE — tunnel mode GREoverIPsec — шифрованный пакет за IPsecHeader
    GRE over IPsec — transport mode GREoverIPsec — всё шифрованное добро за GREHeader
    crypto map — выбор шифруемых пакетов привязкой к ACL и физическому интерфейсу с source ip
    crypto profile — выбор шифруемых пакетов по туннельному интерфейсу(тут круто, что всё это хозяйство не привязано к внешнему интерфейсу, ECMP, маршрутизация, резервы..)
    VTI over IPsec — crypto profile cо строчкой под туннельным интерфейсом tunnel mode ipsec {ipv4|ipv6} — GRE заголовок отсутствует О_О
    Так что ли?
    Поправьте меня пожалуйста.

    11 февраля 2021, 10:10
  • Алексей

    Доброго времени суток! У самой cisco написано, что при конфиге IPSec VTY, нужно сам IPSec переводить в туннельный режим:
    Do not forget to make the following configuration on both routers in the topology.
    Rx(config)# crypto ipsec transform-set TSET esp-des esp-md5-hmac
    Rx(cfg-crypto-trans)# mode tunnel
    Это из книги «CCIE Routing and Switching v5.1 Foundations: Bridging the Gap Between CCNP and CCIE»

    1 августа 2020, 23:34
  • Петр Федоров

    Скиньте файл PT с лабораторной, пожалуйста. (можно на почту pvfedorov91@mail.ru)

    25 апреля 2017, 11:31
  • Сергей Шпилевой

    Добрый день.
    Вопрос не совсем по теме, но все же.
    Есть несколько офисов, объединенных каналом передачи данных от провайдеров. По технологии пока ничего не скажу, надо узнавать.
    Для нас это совершенно прозрачно выглядит — воткнули кабель с одной стороны в коммутатор, с другой — линк появился.
    Модернизируем сеть.
    В частности, деление на vlan и прочие радости жизни.
    Проще всего было бы разделить по географическому признаку, как рассматривается у вас.
    Но помимо всего прочего происходит постепенная установка ip-телефонов, подключенных к одной АТС в центральном офисе.
    Изначально я предполагал выделить телефонию по всем офисам в один отдельный vlan. Но тогда надо в канале между офисами передавать соответствующие метки.
    Представители провайдеров говорят, что необходимо использовать QinQ канал, и это дороже. По стоимости посчитают.
    Вопрос — прав ли я, предлагая выделить телефоны в отдельный vlan (предполагается использование порядка 300 телефонов, максимальная емкость АТС — 600 абонентов)?
    Или все же как то по другому надо?

    20 сентября 2016, 17:46
  • Bear Vorkuta

    Здравствуйте.
    Такой вопрос.
    Пользуюсь PacketTracer 6.2. Так вот crypro ipsec выдает только:
    Router(config)#crypto ipsec?
    security-association Security association parameters
    transform-set Define transform and settings

    profile отсутствует. Соответственно не могу настроить DMVPN. На всех типах роутеров проверил.
    Также mode transporte не могу выставить.
    Это ограничения PT?
    Спасибо.

    25 августа 2016, 15:06
  • Александр Вокуев

    Здравствуйте, у меня как раз конфуз ipsec over GRE или наоборот… если я правильно понял, то в статье представлена структура пакета для туннельного режима ipsec? в транспортном же режиме структура пакета будет выглядеть иначе и соответственно этой «пахабщины» о которой вы пишите не будет. Или я не прав?

    9 июля 2016, 22:24
  • Георгий Владимиров

    Видимо, в тексте статьи ошибка (там где речь идёт об OSPF на DMVPN). Раз на туннельном интерфейсе прописана /24, то и шальная карта должна быть 0.0.0.255. Нет ошибки?

    router ospf 1
    network 172.16.0.0 0.0.255.255 area 0

    8 марта 2016, 20:01
  • Sergey Pilipenko

    Коллеги, а пробовали запускать базовую конфигурацию IPSEC в UNetlab?

    Пользую образы L3 IOL, туннель поднимается — трафик не бегает

    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 0 percent (0/3)
    R1#sh cry
    R1#sh crypto se
    R1#sh crypto session
    Crypto session current status

    Interface: Ethernet0/0
    Session status: UP-ACTIVE
    Peer: 200.0.0.1 port 500
    Session ID: 0
    IKEv1 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

    В GNS3 всё в порядке, но хотелось бы разобраться с UNL

    16 февраля 2016, 11:44
  • YuriyMyagkov

    Доброго времени суток, спасибо огромное за материал =)
    У меня такая проблема после того как построил IPSEC Tunnel запускаю пинг R1#ping 10.1.1.0 source 10.0.0.0 пинг проходит, а sh crypto session в down, после того как убрал маршрут на R1 ip route 10.1.1.0 255.255.255.255 10.2.2.2, crypto session в up’e, кто нибудь может мне объяснить в чём проблема, или я делаю что то не так, заранее благодарен.)

    27 января 2016, 18:50
  • sergey symanovich

    Приветствую.
    Вопрос по исходным данным в таблице для dmvpn.
    img-fotki.yandex.ru/get/5633/83739833.23/0_abbe8_ae57f462_XL.jpg
    здесь же указаны адреса сетей для хостов. Разве так можно?
    У меня на gsn3 выдает ошибку «bad mask …»

    3 ноября 2015, 19:34
  • aleksei

    По поводу аналогов технологии DMVPN у других вендоров. Вот что есть у Juniper http://www.juniper.net/techpubs/en_US/junos12.3×48/topics/concept/security-auto-discovery-vpn-understanding.html

    24 августа 2015, 17:59
  • DenisZhuravlev

    Прочитал все Ваши статьи «Сети для самых маленьких». В CPT решил все задачи до 5 темы (дальше не решился). Сам — новичок, но долго искал, с чего начать, и впервые вижу такой материал. Сравнимо с учебниками 60-х по физике, где не профессор профессору, а для людей. Должен сказать Вам огромнейшее спасибо!!! Для Вас ничего не жалко. Ваш труд +++++++++

    20 апреля 2015, 13:03
  • DmitriyGangan

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

    1) Отправляем с 172.16.245.2 пинг на адрес Loopback-интерфейса в Томске
    2) Согласно таблице маршрутизации, следующий хоп сеть 172.16.254.3
    3) Это адрес из сети, непосредственно подключенной к интерфейсу Tunnel 0
    4) Согласно настройкам интерфейса здесь используется NHRP. Смотрим таблицу соответствия, полученную от хаба
    5) Как видите, адрес 172.16.254.3 nhrp неизвестен. Пакет ICMP отправляется на статически настроенный хаб – 198.51.100.2
    6) А хаб сразу же перенаправляет запрос на нужный адрес
    7) Томск тоже пока не знает ничего об адресе 172.16.254.2, пославшем ICMP-запрос. Поэтому отправляет ICMP ответ на хаб.
    8) Следом за ним он интересуется о публичном адресе отправителя. Хаб ему отвечает.
    У всех актуальная NHRP информация.

    Собственно вопрос, мы это 172.16.254.2, хотим пропинговать 172.16.255.132 (который находится в сети 172.16.254.3)

    Хотя зачем нам слать ICMP на хаб,если логичнее было бы отослать NHRN Resolution Request и получить NHRP Resolution Reply.
    
После чего спокойно слать ICMP на уже известный "внешний" адрес 172.16.254.3

    Ну ладно, отослали мы ICMP echo request на хаб, хаб послал этот же request в известную ему сеть 172.16.254.3, сеть не имея NHRP записи он нас, отослала
    ICMP replay обратно на хаб.
    Хаб шлет этот echo replay нам(172.16.254.2)
    Пакет будет типа:

    На этом процесс заканчивается, у всех актуальная информация NHRP.

    Не посылает ли наш хост сразу же после ping-a, NHRP запрос, и получает NHRP ответ от хаба…
    Ну или в конце, после того как хаб передал нам пинг, он не отсылает NHRP ответ нам?
    Просто здесь не понятно откуда у нас информация NHRP о пропингованной сети?
    Спасибо заранее за ответ)

    9 февраля 2015, 21:48
  • ytyqcwweere19

    If the required dose is less than 1 ml, use a 1 ml syringe graduated 0. For administration by IM injection: May be used undiluted, Bactrim ds used for bv. If the required dose is less than 1 ml, use a 1 ml syringe graduated 0. Contra-indications, adverse effects, precautions – Do not administer in patients with severe respiratory depression. Ensure that respiratory support (Ambu bag via face mask or intubation) and IV solutions for fluid replacement are ready at hand. Remarks – Do not mix with other drugs in the same syringe or infusion bag. The aim is to derive more precise and clear information from a large data pool. It is generally more reliably likely to confirm or refute a hypothesis than the individual trials. Mini-Mental State Examination (MMSE) A commonly used instrument for screening cognitive function. It is not suitable for making a diagnosis but can be used to indicate the presence of cognitive impairment, Antrima 800mg + 160mg capsule generic low cost fast Delivery Michigan with Mastercard. Phoenix Bail Bonds call 800-556-4373 Bail Bonds Phoenix Arizona. Arizona Phoenix Bail Bonds. 800-556-4373. Fast bail bonds agents for Phoenix Arizona. Arrested? Get out now get out fast! Free bail Information., Antrima 800mg capsule without prescription cheapest Arizona with Mastercard

    16 января 2015, 15:28
  • Psycho

    Очень Вам признателен за Ваш труд. Отлично объясняете. А не подскажете возможна ли реализация ВПН на Packet Tracer?
    п.с. Диплом нужно по ВПН написать, рекомендовали делать в РТ (преподаватель)
    Заранее спасибо за ответ

    9 января 2015, 00:45
  • MaksVdovkin

    Добрый день! пытаюсь в PT поднять эталонный IPSec в вакууме, но проблема на обмене айдишниками сторон в isakmp тунеле, после первого qick mode сообщения инициатор ругается что ID отправителя и получателя не совпадают, в чем может быть проблема?

    25 декабря 2014, 16:34
  • TyomaDolobanko


    На ротуре R4: Fastethenet0/0 — 198.51.102.2
    В тоже время на роутере R2 у нас единственный физический интерфейс в сторону R3, R4, R5 (fa0/1) будет иметь 198.51.101.1 для связи с R3. Как я понимаю нужно создавать на R2 3 сабинтерфейса и по сабинтерфейсу на каждом из роутеров (R3,R4,R5) с соответсвующений инкапсуляцией вланов. У вас же на этих ротуреах нет инкапсуляции. Как настроенна маршрутизация?

    19 августа 2014, 18:02
  • TyomaDolobanko

    Подскажите пожалуйста, как настроены Point-to-Point интерфейсы на роутере R2, R4,R5. Не могу понять как без сабинтерфейсов и тегированого трафика они у Вас настроенны.

    19 августа 2014, 13:00
  • ping

    Во-первых, поскольку туннель уже существует (GRE), нет нужды делать его ещё и средствами IPSec – можно перевести его в транспортный режим

    А вот в официальном Design guide для DMVPN пишут, что для устройств за NAT нужен tunnel mode. У вас в статье transport mode везде? И работает?

    If the crypto tunnel transits either a Network Address Translation (NAT) or Port Address Translation (PAT) device, tunnel mode is required.

    12 июня 2014, 10:34
  • singitforthewourld

    С предыдущими двумя вопросами разобрался. Спустя 2 дня курения cisco.com )) Возник только другой вопрос

    «Команда tunnel mode ipsec ipv4 указывает на использование VTI.
    Отличие от обычного GRE в методах инкапсуляции – в VTI экономится 4 байта путём исключения GRE-заголовка.» При этом мы можем использовать только tunnel mode:
    «Restrictions for IPsec Virtual Tunnel Interface
    IPsec Transform Set
    The IPsec transform set must be configured in tunnel mode only.» ( http://www.cisco.com/en/US/docs/ios/12_3t/12_3t14/feature/guide/gtIPSctm.html)

    Версия ios старая, но не думаю что концепция поменялась.

    Так вот — в чем выгода? В отличае от транспортного режима gre over ipsec мы добавляем ip от ipsec ( в туннельном режиме ) + 20 Bt и за счет vti убираем 4 Br. В итоге использование ipsec voer gre экономичнее на 16 Bt. С точки зрения размера пакета vti не выгоден. (Поправьте если не так). И к «плюсу» его отнесне в таком случае нельзя.

    11 июня 2014, 12:45
  • singitforthewourld

    1 А может лм IPSec VTI работать в тунельном режиме? Или только в транспортном?
    2 Tunnel protection ( где мапы генеряться сами ) возможно только в технологии gre + ipsec или на чистом ip sec тоже можно его применть, чтобы мапы с acl не прописывать?

    Заранее спасибо.

    6 июня 2014, 18:51
  • KonstantinDubrovskiy

    Такой интересный для меня вопрос. Построил тунель IPIP, пускаю пинг в удаленную приватную сеть. Смотрю снифером пакет такой как и должен быть. Эзернет кадр — IP заголовок с внешним IP — IP заголовок с частный IP — данные. Включаю шифрование посредством IPsec режим транспортный. Пускаю пинг, смотрю снифером. По моей логике пакет должен быть такой «Эзернет кадр — IP заголовок с внешним IP — IP заголовок с частный IP — Зашифрованные данные». Но он не вмещает в себя IP заголовков частной сети: «Эзернет кадр — IP заголовок с внешним IP — Зашифрованные данные». Что меня более чем устраивает) Но вопрос стоит куда пропал IP заголовок частной сети? Похоже на тунельный IPsec, но стоит точно транспорт) Дайте объяснение моей логике плиз. Благодарю

    26 апреля 2014, 20:59
  • MrScientiam

    Скиньте все настройки в начале раздела «DMVPN».
    А то в видео сказано, настроена мин связанность, и уже есть куча sub-интерфейсов на роутерах, хотя в таблицах ничего не написано
    Также не ясно как роутеры с разными подсетями висят на одном коммутаторе.

    23 апреля 2014, 21:51
  • AndreyTruschelev

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

    Ну не совсем. В arp таблице я не буду видеть мак «соседа» которому пошлю данные через GRE, и при инкапсуляции в Ethernet-frame будет подставлен соответственно мак шлюза.

    По поводу IPSec. Попробовал настроить ту же схему с IPSec в транспортном режиме без GRE — тоже заработало. Оно и логично — добавляются заголовки с новыми IP (белыми) (я поставил ещё ISP роутер по середине, фильтрующий серые IP — типо провайдер). Тогда вопрос возникает: если необходимо построить шифрованный канал м.у узлами в Интернете (и при этом можно обойтись IPsec в тунельном режиме) — есть ли смысл поднимать сначала GRE а потом его шифровать? Подсети за натом и так будут работать то.

    14 февраля 2014, 14:38
  • harabara

    Какая у вас версия прошивка маршрутизаторов? У меня нет команды crypto :(. Как я понял нужна 12.4 а у меня 12.1. Можете подсказать где скачать посвежее, можно на почту sashka_yo@mail.ru

    21 декабря 2013, 20:51
  • GlebTatur

    По первому если я уберу track 1 то собственно не будет у меня резервирования канала на случай не работоспособности интернета у провайдера(то есть тока если линк упадет), а результат исчезания маршрута из таблицы будет тот-же потому как линк в дауне и маршрут исчезнет, и не будет задержки его появления в таблице маршрутизации(а вся эта фигня возникает из-за задержки между поднятием тунельного интерфейса и появлением дефолтного маршрута). Меня все таки интересует почему при временном уходе трафика через другого прова теряется работоспособность.
    По NAT-T это все таки фича NAT в VoceIP ей тоже весьма успешно пользуются. У вас же писалось про режим работы IPsec over Gre как бы он тогда работал если NAT-T фишка IPsec. mGRE поддерживает споки за натом и без IPsec тут я уверен)

    11 декабря 2013, 21:25
  • gluck

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

    11 декабря 2013, 21:17
  • eucariot

    Для преодоления NAT и использования серых адресов нужен NAT-Traversal — это фича IPSec.

    «Spoke-маршрутизаторы могут иметь динамические IP адреса из private диапазона, и находиться за NAT. В этом случае маршрутизатор автоматически определяет наличие NAT на пути, и включает функционал NAT-T, который инкапсулирует IPsec пакеты в udp 4500». link.

    11 декабря 2013, 20:42
  • eucariot

    Здравствуйте.

    Если я правильно понял, то у вас не используется IPSec? И при этом спок находится за NAT?

    Насколько я знаю, только у IPSec есть возможность пробивать NAT. Может, попробовать его настроить?

    11 декабря 2013, 20:11
  • gluck

    вдогонку еще:
    1) вместо ip route 0.0.0.0 0.0.0.0 GigabitEthernet0/2 1.1.1.1 track 1 просто ip route 0.0.0.0 0.0.0.0 GigabitEthernet0/2 1.1.1.1
    2) crypto isakmp invalid-spi-recovery попробуйте

    11 декабря 2013, 18:58
  • gluck

    sh ip route в смысле. пишите лучше на helpme@linkmeup.ru

    11 декабря 2013, 18:34
  • gluck

    покажите sh route в момент отвала спока

    11 декабря 2013, 18:32
  • GlebTatur

    Опытным методом удалось установить что эта фигня происходит если пингануть другую сторону тунеля после того как поднялся тунельный интерфейс, но до того как переключился дефолтный маршрут, потому в этот промежуток времени и тунель погонит трафик через другого провайдера, потом идет переключение на нужного провайдера спок присылает регистрейшр реквест, спок появляется у нас в nhrp таблице. но к нему реплай уже не доходит. и все после этого отключай не отключай больше спок недоступен через это облако. ребут и все опять ок.
    Я извиняюсь что развел тут у вас флуд, но очень надеюсь на помощь человека автобуса)

    11 декабря 2013, 17:52
  • GlebTatur

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

    11 декабря 2013, 17:08
  • gluck

    а с какой целью tunnel route-via mandatory сделаны на туннелях?

    11 декабря 2013, 15:47
  • GlebTatur

    Добрый день, хотелось бы попросить совета уже не знаю к кому обратится.
    Singl HUB, два облака одно по локалке провайдера второе через другого прова. Споки во втором облаке за натом отправляют регистрейшн ревест, хаб его получает и шлет реплай но до спрока этот реплай не доходит. Подскажите куда копать пож) Причем при первой загрузке все нормально регистрируется, эта фигня начинается когда я выдергиваю линк имитируя падение провайдера через которого строится это облако.(переключается по SLA на другой маршрут по умолчанию и потом обратно, после этого не поднимается) Кофниг если что есть в этой теме http://www.certification.ru/cgi-bin/forum.cgi?action=thread&id=42637 да бы не растягивать коммент на пол страницы.

    11 декабря 2013, 10:57
  • SergeyKuzmitsky

    С другой моделью роутера всё заработало.

    6 декабря 2013, 10:27
  • SergeyKuzmitsky


    Может какие-то дополнительные настройки роутера нужны?

    6 декабря 2013, 09:59
  • admin

    Покажите листинг с ошибкой.

    4 декабря 2013, 17:45
  • SergeyKuzmitsky

    Хорошо, здесь я лох.
    но я пишу
    interface FastEthernet0/1.6
    description Internet
    encapsulation dot1Q 6
    ip address 198.51.100.2 255.255.255.240

    На моменте инкапсуляции опять появляется «Invalid input detected at ‘^’ marker.
    »

    4 декабря 2013, 17:44
  • admin

    Вы пытаетесь настроить тип порта Access на L3-интерфейсе маршрутизатора.

    4 декабря 2013, 17:28
  • SergeyKuzmitsky

    При начальной настройке VLANа в GNS появляется ошибка:
    В чём может быть проблема?

    4 декабря 2013, 17:22
  • mokinvs

    Грамотно и доступно, спасибо за труды.
    (практикующий ccnp/ccip 😉 )

    7 ноября 2013, 22:58
  • RusLukmanov

    жаль что в статье не затронули ip-ip тунели 🙁

    27 октября 2013, 23:39
  • DanilaElezov

    Скажите пожалуйста, в результате реализации DMVPN, как производить мониторинг загрузки туннеля. Правильно понимаю — будет один здоровенный «туннелище» на центральном узле?

    26 августа 2013, 11:26
  • SergeyYuzkov

    Помогите, пожалуйста, разобраться. Вроде все сделал, как написано, сравнил… сходится, но почему-то не поднимается IPSec, когда делаю пинг:
    R1:
    crypto isakmp policy 1
    encr aes
    authentication pre-share

    crypto isakmp key CISCO address 201.0.0.1

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

    crypto map MAP1 10 ipsec-isakmp
    set peer 201.0.0.1
    set transform-set AES128-SHA
    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 101.0.0.1
    tunnel destination 201.0.0.1

    interface FastEthernet0/0
    description R2
    ip address 101.0.0.1 255.255.255.252
    duplex auto
    speed auto
    crypto map MAP1

    ip route 0.0.0.0 0.0.0.0 101.0.0.2
    ip route 10.1.1.0 255.255.255.255 10.2.2.2

    access-list 101 permit ip host 10.0.0.0 host 10.1.1.0

    — R2:
    crypto isakmp policy 1
    encr aes
    authentication pre-share

    crypto isakmp key CISCO address 101.0.0.1

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

    crypto map MAP1 10 ipsec-isakmp
    set peer 101.0.0.1
    set transform-set AES128-SHA
    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 201.0.0.1
    tunnel destination 101.0.0.1

    interface FastEthernet0/1
    description R2
    ip address 201.0.0.1 255.255.255.252
    duplex auto
    speed auto
    crypto map MAP1

    ip route 0.0.0.0 0.0.0.0 201.0.0.2
    ip route 10.0.0.0 255.255.255.255 10.2.2.1

    access-list 101 permit ip host 10.1.1.0 host 10.0.0.0

    27 июля 2013, 21:27
  • AzizKayumov

    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
    crypto ipsec transform-set AES128-SHA esp-aes esp-sha-hmac
    mode transport
    access-list 101 permit gre host 100.0.0.1 host 200.0.0.1
    GRE over IPSec это и есть его код? больше нечего прописывать не надо? акцесс лист на интерфейс применять не надо? чет я запутался с GRE over IPSec.

    24 июля 2013, 00:12
  • Александр

    Уважаемые Знатоки, внимание вопрос) Раздел GRE other IPsec. Никак не могу сообразить каким образом через GRE-туннель будет передаваться OSPF. Покопавшись в интернте, наткнулся на PIM. Оно или не оно? Подскажите пожалуйста, запутался)

    18 июля 2013, 23:16
  • ping

    Подскажите, пожалуйста, по IPSec в туннельном режиме.
    Как пакет будет выглядеть, если, например, пинговать с одного маршрутизатора, другой?
    | новый IP | IPSec | старый IP | данные |
    Тогда старый IP и новый IP будут одинаковыми?

    10 июля 2013, 07:22
  • zhuchock

    Огромное СПАСИБО!

    6 апреля 2013, 19:50
  • AlekseyEfanov

    Здравствуйте.

    Со стороны провайдера настроены сабинтерфейсы

    В конфигах nsk-obsea-gw1, tmsk-lenina-gw1, ну и БРНО аналогично:
    interface FastEthernet0/0
    description Internet
    ip address 198.51.101.2 255.255.255.252 (198.51.102.2, 198.51.103.2)
    duplex auto
    speed auto
    — в этом случае пинг на 198.51.101.1 (198.51.102.1, 198.51.103.1) не проходит.

    А так ходит:
    interface FastEthernet0/0.101 (102, 103)
    description Internet
    encapsulation dot1Q 101 (102, 103)
    ip address 198.51.101.2 255.255.255.252 (198.51.102.2, 198.51.103.2)
    duplex auto
    speed auto

    Это ошибка, или я чего-то недопонял?

    С уважением

    20 марта 2013, 11:55
  • dzemchenkov

    Огромное, мега-спасибище!
    Может быть. Вы поможете, дадите верное направление рещения такой мелкой задачки.
    ROUTER1
    | |
    ISP1 ISP2
    \ /
    INTERNET
    |
    ROUTER1

    на router1 настроена балансировка по статьям с Anticisco
    VPN реализован по схеме GRE over IPSEC
    IPSEC на R2 настроен так
    crypto map MAP1 1 ipsec-isakmp
    set peer ISP1_IP default
    set peer ISP2_IP

    Есть желание реалиховать через IPSec VTI
    Каким обрахом лучше настроить GRE? пока что вижу 1 вариант: 2 GRE через 2 ISP и разный вес маршрутов d cnfnbxtcrjq таблице (взлетит, нет ?)
    Вариант с динамической маршрутизацией не рассматриваю ( а может стОит? ) пока необходимости не возникало

    При возможности поддержу проект, обещаю!

    11 марта 2013, 20:49
  • AlekseyKorolev

    Большое спасибо за статью, очень много полезного, есть несколько вопросов:
    1) Какой лучше всего использовать holdtime для NHRP на SPOKE’ах? Дело в том, что при стандратном holdtime есть такая проблема: падает (перегружается) по какой-либо причине туннель или сам роутер (который HUB), при возвращении туннеля — связь не восстановится сразу, а придется ждать пока на SPOKE’ах оттикает holdtime таймер.
    2) В чем разница между tranform-сетами ah-sha-hmac esp-aes и esp-aes esp-sha-hmac?

    28 февраля 2013, 15:07
  • Arhangel

    Снимаю перед вами шляпу! Занятие достойное уважения. Не малых, наверное, усилий стоит написание столь увесистого материала. Да и стиль подачи материала просто великолепный. Хоть в основном материал для меня не новый — прочитал все части с удовольствием. Приятно читать столь «сбитый» материал.
    Мне самому не хватает терпения и усидчивости даже инструкцию для пользователей написать. А иногда посещает желание что-нибудь подобное сделать, но все начинания разбиваются о нехватку времени (ну и конечно лень).

    P.S. Следил за «зарождением» вашего подкаста (правда, каюсь, пока не послушал).

    28 февраля 2013, 14:56
  • JuriDmitrijev

    в IPSec VTI профиль назваете VTI-P, a к туннелю прикручиваете DMVPN-P

    27 февраля 2013, 19:15
  • Олег

    VTY?
    В каких случаях нужен transport?

    11 февраля 2021, 09:18
  • Олег

    Интересно, что и в этой статье, и в других источниках crypto map привязывается только к физическому интерфейсу.

    11 февраля 2021, 09:00
  • admin

    Этот урок был уже на GNS3, поэтому файла с лабой в РТ нет.
    Можете в конце статьи скачать конфигурацию и делать по ней. Как использовать GNS3 у нас было в отдельной статье: linkmeup.ru/blog/36.html. Правда он старовата.

    28 апреля 2017, 09:20
  • Александр Вокуев

    Если хочешь сделать хорошо, сделай сам… вопрос снимается

    9 июля 2016, 23:44
  • Александр Вокуев

    Прошу прощения за опечатку, естественно пишЕте, ну да не об этом… уточню свою вопрос, если представлена структура пакета транспортного режима ipsec с инкапсулированным в него GRE, то самый первый заголовок, обозначенный в статье как «новый ip» присваивается GRE?

    9 июля 2016, 22:37
  • YuriyMyagkov

    Извините всё работает, это я невнимательный)))

    29 января 2016, 18:48
  • sergey symanovich

    лень писать письмо, поэтому напишу вопрос здесь же.
    у вас в облаке тегов есть «задачи», а есть «задачки»
    может стоит их как-то иначе разделить или вообще объединить?

    6 ноября 2015, 01:04
  • eucariot

    Верно. Ошибка в скриншоте.
    Спасибо.

    4 ноября 2015, 15:57
  • admin

    Спасибо, Денис. Какое интеллигентное и лестное сравнение)
    Надеюсь, на 7-й части не остановитесь. Через пару месяцев выйдет 11-ая. 🙂

    20 апреля 2015, 19:04
  • eucariot

    Не пробовал настраивать в РТ.
    Полагаю, что даже если есть, то самый базовый функционал. Тем более, если речь о чём-то, вроде, L2TP или MPLS VPN.
    В любом случае я бы рекомендовал GNS. Важно ведь, какая конфигурация узлов, а не в чём вы её писали. Тем более, что в GNS у вас настоящий IOS.

    10 января 2015, 15:08
  • eucariot

    Рад, что всё разрешилось. Приятного дальнейшего чтения!

    26 декабря 2014, 20:18
  • MaksVdovkin

    Был косячок с ACL, все работает
    Спасибо за интресный и полезный материал!

    26 декабря 2014, 12:11
  • eucariot

    Здравствуйте. Это темы предыдущих выпусков. В этот раз я уже не стал останавливаться на этом вопросе, чтобы не перегружать статью. Я думаю, вы в силах разобраться с этим)

    21 августа 2014, 06:55
  • eucariot

    Обратите внимание на секцию «Транспортный режим работы IPSec». В обоих режимах только один заголовок IP. Разница лишь в том, что в туннельном шифруется полностью IP-пакет, а в транспортном только данные транспортного уровня (IP-заголовок не трогается).

    5 мая 2014, 19:46
  • eucariot

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

    24 апреля 2014, 07:01
  • eucariot

    Что значит общий случай? GRE — это такой же интерфейс, как VLAN, например, или сабинтерфейс, и позволяет соответствующее с собой обращение — гибкие ACL, сбор статистики, ограничение скорости, применение политик, использование протоколов маршрутизации, настройку MTU.
    IPSec — это вообще не интерфейс со всеми вытекающими. Поэтому IPSec-туннель в чистом виде — не очень часто применяющаяся вещь. Элементарно, попробуйте привязать в MRTG статистку по IPSec-туннелю.

    Спасибо за добрые слова)

    17 февраля 2014, 20:39
  • AndreyTruschelev

    Ну не совсем. В arp таблице я не буду видеть мак «соседа» которому пошлю данные через GRE, и при инкапсуляции в Ethernet-frame будет подставлен соответственно мак шлюза.
    Возможно, вас смущает термин Локальная сеть, но подразумевается не широковещательный сегмент, а именно локальная сеть предприятия. И в этом случае всё верно — Интернет для них, как маршрутизатор.

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

    есть ли смысл поднимать сначала GRE а потом его шифровать?
    В статье об этом говорилось. При чистом IPSec не будут работать протоколы маршрутизации, фактически вообще маршрутизация вообще тут не при чём, что не гибко.

    Возможно. Если речь идет об обмене по мультикасту для OSPF — то да — это я видел. Если общий случай — то не нашел до сих пор. Т.е. если у меня только статическая маршрутизация, то смысла в GRE нет? Статья столь объемная, что не сразу всё проясняется, но за статью конечно — отдельное спасибо.

    17 февраля 2014, 10:29
  • eucariot

    Ну не совсем. В arp таблице я не буду видеть мак «соседа» которому пошлю данные через GRE, и при инкапсуляции в Ethernet-frame будет подставлен соответственно мак шлюза.

    Возможно, вас смущает термин Локальная сеть, но подразумевается не широковещательный сегмент, а именно локальная сеть предприятия. И в этом случае всё верно — Интернет для них, как маршрутизатор.

    есть ли смысл поднимать сначала GRE а потом его шифровать?

    В статье об этом говорилось. При чистом IPSec не будут работать протоколы маршрутизации, фактически вообще маршрутизация вообще тут не при чём, что не гибко.

    14 февраля 2014, 15:39
  • GlebTatur

    10.0.0.0 это старая адресация с нее переезжаем, на время переезда поддерживаем обе и 192.168.х.х и 10.х.х.х

    12 декабря 2013, 13:59
  • GlebTatur

    Да 1.1.1.1 это чисто на автомате заменил реальный IP не посмотрел. Да у меня есть готовая схема я упрощенную накидаю вечером скину. В пятницу мне уже это в продакшен выкатывать уже обговорены отключение 13 филиалов( так что я пока 1 облако просто отключу потом уже походу буду докручивать.

    12 декабря 2013, 13:58
  • gluck

    поддерживаю. и еще непонятно, откуда 10.0.0.0 берется, и вообще над eigrp надо подумать.

    12 декабря 2013, 07:08
  • eucariot

    Можете нарисовать подробную схему с указанием интерфейсов и IP-адресов? Попробую повторить на выходных.

    И ещё вопрос — адрес 1.1.1.1 — он ожидается провайдером от вас? Почему трансляции на него выполняются? Или вы так скрыли настоящий IP интерфейса Gig0/0/2?..

    Плюс:

    route-map 2-ISP-Local permit 10 
    
match ip address 140 
    
set ip next-hop 1.1.1.1

    1.1.1.1 — это адрес провайдера или ваш? Если провайдера, то почему на споке он прописан в качестве map на 192.168.23.13?

    Я бы предложил выслать на helpme@linkmeup.ru схему сети и конфигурации, как они есть.

    12 декабря 2013, 06:55
  • GlebTatur

    Конфиг спока скинул в туже тему http://www.certification.ru/cgi-bin/forum.cgi?action=thread&id=42637

    11 декабря 2013, 21:47
  • GlebTatur

    вот вывод IProute

    Gateway of last resort is 172.29.66.65 to network 0.0.0.0

    S* 0.0.0.0/0 [4/0] via 172.29.66.65, GigabitEthernet0/1
    S 172.0.0.0/8 [1/0] via 172.29.66.65, GigabitEthernet0/1
    172.29.0.0/16 is variably subnetted, 2 subnets, 2 masks
    C 172.29.66.64/26 is directly connected, GigabitEthernet0/1
    L 172.29.66.66/32 is directly connected, GigabitEthernet0/1
    192.168.13.0/24 is variably subnetted, 2 subnets, 2 masks
    C 192.168.13.0/28 is directly connected, Tunnel1
    L 192.168.13.13/32 is directly connected, Tunnel1
    192.168.100.0/32 is subnetted, 1 subnets
    C 192.168.100.1 is directly connected, Loopback1

    11 декабря 2013, 21:32
  • gluck

    точно, ipsec- то нету… по привычке сказал)) тогда про spi-recovery отбой. но включение ipsec точно ни к чему.

    11 декабря 2013, 20:20
  • GlebTatur

    это осталось с того момента когда было два равноправных дефолтных маршрута

    11 декабря 2013, 16:19
  • eucariot

    Спасибо, лестно)

    8 ноября 2013, 19:51
  • eucariot

    Цитата из статьи:

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

    tunnel mode ipip

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

    Больше трогать IP-IP не за что.

    28 октября 2013, 11:41
  • eucariot

    🙂 Только сначала с воробьями договоритесь.

    26 августа 2013, 16:02
  • DanilaElezov

    Стрелять из пушки по воробьям не будем 🙂

    26 августа 2013, 13:59
  • DanilaElezov

    Спасибо!

    26 августа 2013, 13:51
  • eucariot

    Ну вот представьте себе, что вся ваша сеть — это два маршрутизатора Cisco 1700. И она даже в перспективе не имеет тенденции к росту. Но вы поднимаете на нём OSPF и i-BGP. На всякий случай.

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

    Обслуживать туннель. А чем проще? Попрактикуйтесь с настройкой QoS и вы поймёте, что туннели не обязательны.

    2) Ну как же. Они у вас будут в таблицах, как directly connected в любом случае. Просто имейте ввиду, что вся сеть провайдера для вас — один большой маршрутизатор с двумя (или более по числу филиалов) интерфейсами.

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

    26 августа 2013, 13:29
  • DanilaElezov

    То есть ну его нафиг мою идею? :))
    1) Кажется что GRE туннели гибче и информативнее одного интерфейса (CPU не жалко не Gbit передаем) И для отладки — туннели кажутся более удобными (imho)
    2) Да про эти линковые адреса я и говорю (никакого присутствия в таблицах машрутизации)

    То есть не стоит так делать? 🙂

    26 августа 2013, 13:07
  • eucariot

    1) Не потеряете. При грамотной настройке политик — не тупо на интерфейс, а выщепление нужного трафика и применение qos на него, всё будет работать
    2) Сети провайдера вы не увидите. Если он вам даёт L3VPN, то вы изолированы ото всех, повторяюсь. То есть вы увидите только линковые адреса, которые провайдер вам выделил.

    Статистику по линку при этом вы можете снимать с филиалов, чтобы видеть объёмы трафика.

    26 августа 2013, 12:56
  • DanilaElezov

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

    26 августа 2013, 12:45
  • eucariot

    Работать это, конечно, будет.
    Смущает цель. Для чего вы это делаете? Если они уже выделяют вам L3VPN, значит ваши сети изолированы от сетей провайдера и других пользователей. Вы можете спокойно использовать самую прямую IP-маршрутизацию (правда встаёт вопрос маршрутизации у провайдера, но он решаемый).

    И при этом вы лишаете себя удовольствия поддерживать огромную махину DMVPN и снижаете нагрузку на процессоры.

    Если только дополнительное шифрование.

    26 августа 2013, 12:33
  • DanilaElezov

    А что Вас смущает?
    У нас используется одна адресация, у провайдера для организации соединений с нами используется другая(у них для нас отдельные VRF куда они «погружают» каналы со всей области, ранее был L2).
    Поверх всего этого дела — строятся туннели.

    26 августа 2013, 12:20
  • eucariot

    Если управлять QoS с помощью политик, то не имеет значения на одном туннеле вы это делаете или на разных.
    То есть с помощью ACL вы можете выбрать именно интересующий вас трафик.

    Провайдер дает MPLS L3 в филиалах.

    Вот тут не понял. Если вам првоайдер уже даёт L3VPN, зачем вам ещё DMVPN поверх него?

    26 августа 2013, 12:08
  • DanilaElezov

    Мониторинг и управление туннелями. Когда есть отдельно выделенный туннель — мы можем на нем менять Qos, бороться с отдельным видом трафика. Если будет один туннель — мы потеряем в гибкости.

    Для сведения:
    Провайдер дает MPLS L3 в филиалах.
    Конечные устройства 18хх\19хх\28хх\29хх — честно пока не знаю.

    Поправьте меня, если я ошибаюсь

    26 августа 2013, 12:05
  • eucariot

    Использовать одновременно можно вполне.

    Но почему бы вам и их в одну сеть не объединить? Филиальные железки не поддерживают DMVPN?

    26 августа 2013, 11:49
  • eucariot

    Мониторить системами мониторинга, конечно. Будет один здоровенный туннелище на стороне хаба.

    26 августа 2013, 11:48
  • DanilaElezov

    И сразу же возник второй вопрос — можно ли одновременно использовать «обычные» GRE для связи центрального узла и филиалов, и DMVPN для организации туннелей для связи между филиалами.

    Получается нагромаждено, согласен. Скажете — почему не строить обычные туннели между филиалами — их больше сотни (200 адресов на только на адресацию туннелей), различные политики качества сервиса на туннели до центра, мониторинг каналов до центра.

    26 августа 2013, 11:34
  • eucariot

    Я знал, что вы справитесь. Нужно было всего лишь время 🙂

    28 июля 2013, 15:57
  • SergeyYuzkov

    я нашел в чем ошибка! в интерфейс тунеля 0 также необходимо прописать «КАРТУ»:

    interface Tunnel0
    ip address 10.2.2.2 255.255.255.252
    tunnel source 201.0.0.1
    tunnel destination 101.0.0.1
    crypto map MAP1

    и тогда смог увидеть процесс протоколы шифрования!

    28 июля 2013, 15:12
  • SergeyYuzkov

    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 = 52/91/180 ms

    R1#sh crypto isakmp sa
    IPv4 Crypto ISAKMP SA
    dst src state conn-id slot status

    IPv6 Crypto ISAKMP SA

    27 июля 2013, 23:09
  • eucariot

    Покажите, как вы запускаете пинг и с каким результатом.

    27 июля 2013, 22:27
  • eucariot

    Если возникает общее непонимание, нужно сделать небольшую паузу, а потом взять и методично самому разобрать в симуляторе задачу от и до.
    В целом вы правы — GRE-туннель с применённым на нём шифрованием — это и есть GRE over IPSEC, только у вас на туннельном интерфейсе не хватает команды для применения шифрования.

    24 июля 2013, 05:23
  • Александр

    Спасибо, теперь всё понятно.

    19 июля 2013, 10:18
  • eucariot

    А тут как раз проблемы нет. В случае GRE over IPSec у нас есть конкретный туннельный интерфейс, на котором поднят OSPF. С этого интерфейса спокойно отсылаются мультикастовые сообщения OSPF, которые затем инкапсулируются в GRE и IPSec и достигают получателя на другом конце.
    Трудности начинаются в DMVPN, но они описаны в статье.

    19 июля 2013, 07:12
  • eucariot

    Да, примерно, так он и будет выглядеть. Внутренний и внешний IP будут одинаковыми.

    17 июля 2013, 16:47
  • eucariot

    Всегда, пожалуйста.

    6 апреля 2013, 19:53
  • AlekseyEfanov

    Это которые типа NM-16ESW? Спасибо, попробую

    20 марта 2013, 13:23
  • eucariot

    Вы можете использовать маршрутизатор со свитчовыми платами вместо коммутатора)

    20 марта 2013, 13:18
  • AlekseyEfanov

    В общем правильно, «лампочка, это лампочка, а конфиг — факт». Жаль что в GNS только GUI на свичах… Ну его, этот GUI…

    20 марта 2013, 13:16
  • AlekseyEfanov

    Я тормоз… не не так — ТОРРРМОЗЗЗ. пишу enc dot1q 101, а на свиче 1 указываю… Ура, ПОБЕДА… Спс.

    20 марта 2013, 13:10
  • eucariot

    Если не заработает, присылайте схему и конфигурацию всех устройств. (можно на почту).

    20 марта 2013, 12:56
  • AlekseyEfanov

    Вернулся на несколько дней назад, вспомнил чего делал со свичем (не работало) — поставил сейчас access (убрал fa 0/0.101, ip назначил на fa0/0) — все равно не работает, сейчас набросаю схемку с нуля — отпишу результат

    20 марта 2013, 12:54
  • eucariot

    Вы же понимаете, что когда вы настраиваете сабинтерфейс — у вас получается транковый порт и кадры идут тегированными, то есть с заголовком 802.1q.
    Если вы настраиваете обычный физический интерфейс, то кадры будут нетегированными.
    И если у вас конфигурация обоих концов будет неконсистентна, то ничего не заработает.
    Порты коммутатора, который стоит между Москвой и филиалами в каком режиме? У меня филиальные были аксессом. Но это как бы базовые вещи для траблшутинга.

    20 марта 2013, 12:43
  • AlekseyEfanov

    Да вот я и думаю — это я где-то накосячил или ошибка в статье? Чего-то я не улавливаю, а может такая же невезуха как у AlekseyTurkin из микровыпуска. При dot1q на коммутаторе 0 не ставится (Win7 x64, GNS3 0.8.3.1).
    Вообще у меня все заработало только через interface FastEthernet0/0.101 (102, 103).

    20 марта 2013, 12:37
  • eucariot

    Не совсем понял — это вы делаете тесты или у меня ошибка в статье?
    Возможно, у вас транк настроен, в сторону этих маршрутизаторов?

    20 марта 2013, 12:05
  • eucariot

    Вообще, статей и на эту тему не мало.
    Так или иначе будет два туннеля через разных провайдеров. И либо балансировка нагрузки между ними, либо активный/резервный.
    По идее и то и другое может быть реализовано, как статической маршрутизацией, так и IGP, но, разумеется, IGP предпочтительней.

    20 марта 2013, 09:04
  • Arhangel

    Я так в свое время разбирался и погружался в IP-телефонию, конкретно в Avaya. Учился сам, писал документацию для коллег, но выкристаллизовать это в подобный материал так и не собрался.
    Кстати абсолютно согласен, что при написании описаний или подобных материалов, особенно по горячим следам после того, как сам разобрался, структурирует дополнительно еще разрозненные знания и способствует лучшему пониманию. Особенно радует то, что в ваших материалах описаны не методики, а концепции. Т.е. не по принципу «Хочешь раздать интернет — nat inside source route-map MTS interface GigabitEthernet0/2 overload», а что такое NAT, и почему именно overload.

    1 марта 2013, 11:23
  • AlekseyKorolev

    По обоим вопросам все понятно) Еще раз спасибо большое за статью и ответы.

    28 февраля 2013, 17:54
  • eucariot

    1) Тут надо бы вспомнить BFD, который отсылает раз в несколько миллисекунд свои кипалайвы или настройку OSPF с таймерами hello, настроенными на обновление чаще раза в секунду.
    2) AH вообще на некоторых устройствах уже не используется, например, на ASA. Так что вполне можно обойтись ESP.

    28 февраля 2013, 17:48
  • AlekseyKorolev

    1) Задачку видел, я у себя использую holdtime 30, сомневаюсь нормально ли отправлять каждые 10 секунд reg. request’ы, или это слишком часто, поэтому и вопрос такой возник.
    2) А какой вариант лучше использовать? Использовать ESP и для шифрования пейлоада и для аутнетификации, или комбинировать с AH? Какой вариант, в данном случае, более «секьюрный»? И есть ли смысл сейчас использовать DH группы выше 2ой? Например 5ую или 14ую?
    Спасибо за ответы. 🙂

    28 февраля 2013, 17:43
  • eucariot

    1) У нас как раз об этом есть задачка. Время ставится на ваше усмотрение.
    2) D обоих случаях используется шифрование пейлоада ESP-AES, но в первом случае — аутнетификация с использованием AH, а во втором- аутнетификация силами ESP. В этом и есть основное отличие ESP от AH — он может и шифовать и аутнетифицировать.

    28 февраля 2013, 17:13
  • eucariot

    Да, вы правы — немалых. Если на первые статьи уходило месяц-два, то сейчас это занимает по четыре.
    Но вы же понимаете, что в первую очередь я учусь сам. Прежде я боялся фраз IPSec, DMVPN, как огня.

    Вы знаете, первые пару выпусков ни к чему меня не обязывали — это было просто интересно. Но теперь я уже чувствую некую ответственность, будто я должен разбираться и писать. В целом чувство очень приятно. Тем более, что это вырастает в нечто большее 🙂

    28 февраля 2013, 16:37
  • eucariot

    Вам спасибо)

    27 февраля 2013, 19:34
  • JuriDmitrijev

    оперативно у вас тут, а вообще, забыл сказать, спасибо за статью, очень познавательно!

    27 февраля 2013, 19:27
  • eucariot

    Починено.

    27 февраля 2013, 19:20

Ещё статьи

Новости linkmeup
Первая и вторая партия отошли нашим читателям и слушателям.И уже подошли новые наклейки.Пишите на info@linkmeup.ru. В заголовке письма: «Наклейки linkmeup».Укажите ФИО, адрес, индекс.Но теперь мы не раздаём их за так. ...
like 0 4814 5
4 октября 2013
Сети для самых маленьких. Микровыпуск №1. Переход на GNS3
Мы немножко нарушим хронологию цикла Сети для самых маленьких”.Следующая наша статья будет посвящена технологиям VPN и подключению удалённых офисов к центральному. Будут обсуждаться такие темы, как GRE, IPSec и DMVN. ...
like 38 81813 109
24 декабря 2012
Ответ к задаче №6.6
Задача 6.6На klgr-balt-gw1:klgr-balt-gw1(config)# router ospf 1klgr-balt-gw1(config-router)# redistribute eigrp 1 metric-type 1 subnets
like 0 9905 2
29 октября 2012