Безопасность IP телефонии Cisco

Здравствуйте коллеги! Представляем вниманию обзорную статью нашего инструктора, которая затрагивает основные тенденции и угрозы в IP телефонии,  и самое главное, те инструменты защиты, что на данный момент предлагает производитель в качестве защиты (если выражаться языком специалистов по безопасности, то рассмотрим какие инструменты предлагает производитель для уменьшения уязвимостей, которыми смогут воспользоваться нелегитимные лица).  Итак, меньше слов– переходим к делу.

Для многих читающих термин IP телефония Cisco (как и IP телефония другого вендора) уже давно сформировался, а также и то, что данная телефония «лучше», дешевле по сравнению с телефонией общего пользования (ТФОП), богата различными дополнительными функциями и т.д. И это действительно так, однако… отчасти. По мере перехода от аналоговой (цифровой) телефонии со своими абонентскими линиями (от абонентского телефона до станции или станционного выноса) и соединительными линиями (меж станционная линия связи) ни много ни мало были только лишь в зоне доступа и управления провайдера телефонии. Иными словами, обычным обывателям туда доступа не было (ну или практически так, если не учитывать кабельную канализацию).  Вспоминается один вопрос на старом добром форуме хакеров «Подскажите, как получить доступ к АТС? – ответ: «Ну как, берешь бульдозер – таранишь стену здания АТС и вуаля». И эта шутка имеет свою долю правды) Однако с переносом телефонии в дешевую IP среду мы получили в довесок и те угрозы, которые несет в себе открытая IP среда. Примером приобретенных угроз может служить следующее:

·         Сниффинг сигнальных портов с целью совершения платных вызовов за чужой счет

·         Подслушивание за счет перехвата голосовых IP пакетов

·         Перехват звонка, представление нелегитимным пользователем как легитимный пользователь, атака «человек по середине»

·         DDOS атаки на сигнальные сервера станции с целью вывода из строя всей телефонии

·         Спам-атаки, обрушение большого количества фантомных вызовов на станцию с целью занять все её свободные ресурсы

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

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

У многих производителей голосового оборудования (в том числе и у Cisco Systems) есть уже интегрированные инструменты  безопасности от обычного ограничения диапазона ip адресов, с которых можно совершать вызовы, до аутентификации оконечных устройств по сертификату. Например, у производителя Cisco Systems с его голосовой линейкой продуктов CUCM (Cisco Unified CallManager) с версии продукта 8.0 (дата выхода в свет май 2010г.; на данный момент доступна версия 10.5 от мая 2014г.) стала интегрироваться функция  «Безопасность по умолчанию». Что она в себя включает:

·         Аутентификация всех скачиваемых по/с TFTP файлов (конфигурационные файлы, файлы прошивки для телефонов т.д.)

·         Шифрование конфигурационных файлов

·         Проверка сертификата с инициализации телефоном HTTPS соединения

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

Рис.1 Атака «человек посередине»

 

Для защиты от этого нам понадобятся знания по несимметричному шифрованию, инфраструктуре открытых ключей и представления о составляющих «Безопасности по умолчанию», с которыми мы сейчас познакомимся: Identity Trust List (ITL) и Trust Verification Service (TVS). TVS – сервис, предназначенный для обработки запросов с IP телефонов, у которых нет ITL или CTL файла во внутренней памяти. IP телефон обращается к TVS  в случае необходимости удостовериться может ли он доверять тому или иному сервису перед тем, как начать обращаться к нему. Станция к тому же выступает в роле репозитория, хранящем сертификаты доверенных серверов. В свою очередь ITL представляет собой список из открытых ключей составляющих кластер станции элементов, но для нас важно, что там хранится открытый ключ TFTP сервера и открытый ключ TVS сервиса.  При первоначальной загрузке телефона, когда телефон получил свой IP адрес и адрес TFTP сервера, он запрашивает наличие ITL файла (рис.2). Если он есть на TFTP сервере, то, слепо доверяя, загружает его в свою внутреннюю память и хранит до следующей перезагрузки. После скачивания ITL файла телефон запрашивает подписанный конфигурационный файл.

Рис. 2 Загрузка данных IP телефоном

 

Теперь рассмотрим как мы сможем использовать инструменты криптографии – подписывание файла с помощью хеш-функций MD5 или SHA и шифрование с помощью закрытого ключа TFTP сервера (рис.3). Особенность хеш-функций заключается в том, что это однонаправленные функции. По полученному хешу с какого-либо файла, нельзя проделать обратную операцию и получить в точности оригинальный файл. При изменении файла  - изменяется и сам хеш, полученный с этого файла. Стоит отметить, что хеш не записывается в сам файл, а просто добавляется к нему и передается совместно с ним.

Рис.3 Подписывание файла конфигурации телефона

 

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

При получении данного файла с настройками, телефон первоначально проверяет его на целостность. Мы помним, что хеш - это однонаправленная функция, поэтому телефону не остается ничего делать, кроме как отделить зашифрованный TFTP сервером хеш от конфигурационного файла, расшифровать его с помощью открытого ключа TFTP (а откуда его знает IP телефон? – а как раз из ITL файла), из чистого конфигурационного файла вычислить хеш и  сравнить его  с тем, что мы получили при расшифровании.  Если хеш совпадает - значит при передаче в файл не вносились никакие изменения и его можно смело применять на телефоне (рис.4).

Рис.4 Проверка файла конфигурации IP телефоном

 

 Подписанный конфигурационный файл для телефона  представлен ниже:

Рис. 5 Подписанный файл IP телефона в Wireshark

 

Подписав конфигурационный файл, мы смогли обеспечить целостность передаваемого файла с настройками, однако мы не защитили его от просмотра. Из пойманного файла конфигурации можно получить достаточно много полезной информации, например ip адрес телефонной станции (в нашем примере это 192.168.1.66) и открытые порты на станции (2427) и т.д. Не правда ли достаточно важная информация, которую не хотелось бы  просто так «светить» в сети? Для скрытия данной информации производители предусматривают использование симметричного шифрования (для шифрования и дешифрования используется один и тот же ключ). Ключ в одном случае может быть введен на телефон вручную, в другом случае шифрование файла конфигурации телефона на станции происходит с использованием открытого ключа телефона. Перед отправлением файла телефону – tftp сервер, на котором хранится этот файл, шифрует его с помощью открытого ключа телефона и подписывает с помощью своего закрытого ключа (тем самым мы обеспечиваем не только скрытость, но и целостность передаваемых файлов). Здесь главное не запутаться, кто какой ключ использует, но давайте разберем по порядку: tftp сервер, зашифровав файл открытым ключом IP телефона, обеспечил тем самым, что этот файл сможет открыть только владелец парного открытого ключа. Подписав файл своим закрытым ключом, tftp сервер подтверждает, что именно он создал его.  Зашифрованный файл представлен на рисунке 6:

Рис.6 Зашифрованный файл конфигурации IP телефона Cisco

 

Итак, на данный момент мы рассмотрели возможность защищать наши конфигурационные файлы для телефонов от просмотра и обеспечивать их целостность. На этом функции «Безопасности по умолчанию» заканчиваются. Для обеспечения шифрования голосового трафика, скрытия сигнальной информации (о том кто звонит и куда звонит), необходимы дополнительные инструменты, основанные на списке доверенных сертификатов – CTL, который мы рассмотрим далее.

 

Аутентификация телефонной станции Cisco CME

Когда телефону необходимо взаимодействие с телефонной станцией (например, согласовать TLS соединение для обмена сигнализации), IP телефону необходимо аутентифицировать станцию. Как можно догадаться, для решения данной задачи также широко используются сертификаты. На данный момент современные IP станции состоят из большого количества элементов: несколько сигнальных серверов для обработки вызовов, выделенный сервер администрирования (через него добавляются новые телефоны, пользователи, шлюзы, правила маршрутизации и т.д.), выделенный TFTP сервер для хранения файлов конфигурации и программного обеспечения для телефонов, сервер для вещания музыки на удержании и проч, кроме этого в голосовой инфраструктуре может быть голосовая почта, сервер определения текущего состояния абонента (online, offline, «на обеде») – список набирается внушительный и, что самое главное, каждый сервер имеет свой самоподписанный сертификат и каждый работает как корневой удостоверяющий центр (рис.7). По этой причине любой сервер в голосовой инфраструктуре не будет доверять сертификату другого сервера, например голосовой сервер не доверяет TFTP серверу, голосовая почта – сигнальному серверу и к тому же телефоны должны хранить у себя сертификаты всех участвующих в обмене сигнального трафика элементов. Сертификаты телефонной станции изображены на рисунке 7.

Рис.7 Самоподписанные сертификаты Cisco IP станции

 

Для задач установления доверительных отношений между вышеописанными элементами в голосовой инфраструктур, а также шифрования голосового и сигнального трафика в игру входит так называемый список доверенных сертификатов Certificate Trust List (CTL). CTL содержит все самоподписанные сертификаты всех серверов в кластере голосовой станции, а также участвующих в обмене сигнальными сообщениями телефонии (например, файервол) и этот файл подписывается закрытым ключом доверенного центра сертификации (рис.8). CTL файл эквивалентен проинсталлированным сертификатам, которые используются в работе веб браузеров при работе с https протоколом.

Рис.8 Список доверенных сертификатов

 

Для того чтобы создать CTL файл на оборудовании Cisco, потребуется ПК с USB разъемом, установленная на нем программа CTL client и сам токен Site Administrator Security Token (SAST) (рис.9), содержащий закрытый ключ и X.509v3 сертификат, подписанный центром аутентификации производителя (Cisco).

Рис.9 eToken Cisco

 

CTL client - программа, которая устанавливается на Windows ПК и с которой можно перевести ВСЮ телефонную станцию в так называемый mixed mode ,то есть смешанный режим поддержки регистрации оконечных устройств в безопасном и небезопасном режимах. Запускаем клиент, указываем IP адрес телефонной станции, вводим логин/пароль администратора и CTL client устанавливает TCP соединение по порту 2444 со станцией (рис.10). После этого будет предложено всего лишь два действия:

Рис.10 Cisco CTL Client

 

После создания CTL файла, остается перезагрузить TFTP сервера для того, чтобы они подкачали к себе новый созданный CTL файл, и далее перезагрузить голосовые сервера, чтобы IP телефоны также перезагрузились и загрузили новый CTL файл (32 килобайта). Загруженный CTL файл можно просмотреть из настроек IP телефона (рис.11)

Рис.11 CTL файл на IP телефоне

 

Аутентификация оконечных устройств

Для обеспечения подключения и регистрации только доверенных оконечных устройств необходимо внедрение  аутентификации устройств. На этот случай многие производители используют уже проверенный способ – аутентификация устройств по сертификатам (рис.12). Например, в голосовой архитектуре Cisco это реализовано следующим образом: имеются два вида сертификатов для аутентификации с соответствующими открытыми и закрытыми ключами, которые хранятся на телефоне:

·         Manufacturer Installed Certificate - (MIC). Сертификат, установленный производителем, содержит 2048 битный ключ, который подписан центром сертификации компании производителя (Cisco). Данный сертификат установлен не на все модели телефонов, и если он установлен, то в наличии другого сертификата (LSC) нет необходимости.

·         Locally Significant Certificate (LSC) Локально значащий сертификат, содержит открытый ключ IP телефона, который подписан закрытым ключом локального центра аутентификации, который работает на самой телефонной станции Сertificate Authority Proxy Function (CAPF).

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

Рис.12 Сертификаты для аутентификации оконечных устройств

 

По умолчанию на IP телефон не установлен LSC сертификат и его установка возможна, используя MIB сертификат (при его наличии), или через TLS соединение (Transport Layer Security) по разделяемому общему ключу, сгенерированному администратором вручную на станции и введенном на телефоне.

Процесс установки на телефон локально значащего сертификата (LSC), содержащий открытый ключ телефона, подписанного локальным центром сертификации изображен на рисунке 13:

Рис.13 Процесс установки локально значащего сертификата LSC

 

1.      После загрузки IP телефон запрашивает доверенный список сертификатов (CTL-файл) и файл с конфигурацией

2.      Станция отправляет запрашиваемые файлы

3.      Из полученной конфигурации телефон определяет – нужно ли ему загружать локально значащий сертификат (LSC) со станции

4.      Если мы на станции выставили для телефона, чтобы он установил LSC сертификат (см.ниже), который станция будет использовать для аутентификации данного IP телефона, то мы должны позаботиться о том, чтобы на запрос об выдаче LSC сертификата – станция выдала его тому, кому он предназначается. Для этих целей мы можем использовать MIC-сертификат (если он есть), сгенерировать одноразовый пароль на каждый телефон и ввести его на телефоне вручную либо не использовать авторизацию вообще.

На примере продемонстрирован процесс установки LSC с использованием сгенерированного ключа.

На станции в режиме настроек IP телефона указываем, что мы хотим установить LSC сертификат на телефон и при этом установка будет произведена успешна, если на телефоне ввести аутентификационный ключ, который мы определили как 12345 (рис.14).

Рис.14 Режим настроек CAPF на телефоне

 

Заходим в режим настройки телефона и вводим наш ключ (рис.15):

Рис.15 аутентификационный ключ для установки LSC

 

После этого установка LSC сертификата на телефон прошла успешна (рис.16):

Рис.16 Настройки безопасности на IP телефоне

 

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

 

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

 

Шифрование разговоров - SRTP

Рассмотрим, что на данный момент предлагает производитель, для выполнения самой востребованной задачи – обеспечения конфиденциальности разговоров.

Стандартно все сигнальные и голосовые сообщения передаются в открытом виде, как на представленном рисунке 17:

Рис.17 Открытое сообщение SIP

 

Secure Real Time Protocol (SRTP) – это специально разработанный протокол RTP, призванный для передачи голоса и видео, однако дополненный механизмами обеспечения конфиденциальности, целостности передаваемой информации не только через RTP, но и RTCP. Голосовое приложение, поддерживающие SRTP, должно конвертировать RTP пакеты в SRTP перед отправкой их по сети. Обратная операция должна быть продела на приемной стороне. В архитектуре SRTP определены два типа ключей: мастер-ключ и сессионный ключ (для шифрования и аутентификации) (рис. 18). Однако SRTP не регламентирует порядок обмена мастер-ключами, для данных целей необходимо использовать TLS или IPSec. Для обмена ключами стандартизованным решением для SRTP является MIKEY (Multimedia Internet Keying), однако могут быть использованы и такие протоколы как SDES и ZRTP.

Рис.18 Совершение звонка с помощью SRTP

Процесс обмена сообщениями SRTP:

·         Телефон и сервер обмениваются сертификатами;

·         Телефон и сервер аутентифицируют друг друга;

·         Телефон создает TLS ключи для SHA аутентификации и для шифрования AES;

·         Телефон шифрует ключи с помощью открытого ключа станции и отправляет. Станция расшифровывает с помощью своего закрытого ключа;

·         Станция обменивается TLS ключами с каждым из телефонов и приступает к безопасному обмену телефонных сигнальных сообщений (телефон вызываемого абонента звонит);

·         Станция создает сессионные ключи для SRTP SHA аутентификации и SRTP AES шифрованию;

·         Станция распространяет сессионные ключи обоим телефонам через защищенное сигнальное соединение;

·         Телефоны приступают обмен голосового трафика через защищенное SRTP соединение (вызываемый поднял трубку).

Включением шифрования и аутентификации на оборудовании Cisco заведуют профайлы безопасности. Выглядит он следующим образом (рис.19):

Рис.19 Профайл безопасности на Cisco CallManager

 

В нем мы определяем в каком режиме будут регистрироваться и работать оконечные устройства (телефоны). При выборе опции Non Secure – не шифруются ни сигнальные данные, ни голос; Authenticated – шифруются сигнальные сообщения, но не шифруется голос; Encrypted – шифруется и сигнализация и голос. Есть возможность выбора шифрования конфигурационных данных. После создания профайла необходимо его назначить на телефон (рис.20).

Рис.20 Профайл безопасности телефона на Cisco CallManager

 

На данный момент мы рассмотрели основные моменты в безопасности IP телефонии, позволяющие бороться против основных угроз телефонии, однако это только шапка айсберга всей безопасности голосовой инфраструктуры) Отдельно необходимо рассмотрение физической безопасности инфраструктуры (например здесь: ГОСТ Р ИСО/МЭК 17799-2005 Практические правила управления информационной безопасностью), и отдельную тему можно посвятить сетевой безопасности. Надеюсь, что тот, кто дочитал статью до конца, остался ей доволен и информация была полезной.

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

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

Типы VPN соединений

Ниже систематизированы VPN-ы, которые доступны для настройки в корпоративной сети. Технологии VPN распределены по уровню предоставляемых клиенту каналов по модели OSI (рис 1):

 

 

Схема VPN-ов относительно возможности пропуска мультикаста и работы протоколов маршрутизации (рис. 2):

 

Дополнительно приводится структурированная схема VPN-ов (рис.3), которые могут предоставляться провайдером, но в данной статье подробно они не рассматриваются:

 

 

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

В таблице представлены результаты настроек, исследование полученного формата пакета, настройка протокола маршрутизации (OSPF) через VPN-ы, а также рассмотрены вопросы масштабируемости протокола.

Таблица VPN

Тип VPN

Настройка HUB

Настройка Spoke

Настройка HUB при добавлении нового Spoke

Настройка Spoke при добавлении другого нового Spoke

Использование протоколов динамической маршрутизации OSPF, EIGRP

Особенности

Regular IPSec (crypto map)

isakmp

Crypto-map

isakmp

Crypto-map

Да:

isakmp,

crypto-map:

set peer,

transform-set,

crypto ACL

Да:

Для обеспечения связности между Spoke-ми необходимо добавить маршруты нового Spoke-a в crypto ACL всех существующих Spoke-ах

Нет

Удобен в случае кол-ва Spoke <5-10. Для обеспечения связности между Spokе-ми через HUB требуется добавление в crypto ACL N сетей на N spoke-ах

Крайне немасштабируемый.

Regular IPSec (Profile)

isakmp profile,

IPSec Profile,

сrypto-map

isakmp profile,

IPSec Profile,

сrypto-map

Да:

crypto-map:

set peer,

crypto ACL

Да:

Добавление новых маршрутов в crypto ACL

Нет

Крайне не  масштабируемый.

Меньше конфигурации засчет объединения типовых настроек в profile.

Regular IPSec (Profile, Static VTI)

isakmp profile,

IPSec Profile,

VTI (Virtual Tunnel Interface)

isakmp,

IPSec Profile,

VTI (Virtual Tunnel Interface)

Да:

isakmp,

новый VTI (Virtual Tunnel Interface)

Да

static route до сетей уд. офиса

Да

В конфигурации SVTI без IGP – крайне не масштабируемый.

На каждый Spoke по SVTI.

N spokeN VTI и своя подсеть.

На Spoke требуется добавление маршрутов до удаленных Spoke-в. Пропускает multicast!

По умолчанию на каждый SVTI только одна SA IPSec c traffic selector “IP any any.” Нет команды crypto ACL. В туннель заворачиваются те сети, которые определены через static route на SVTI.

Regular IPSec (Profile, Static VTI and IGP)

isakmp,

IPSec Profile,

VTI (Virtual Tunnel Interface)

isakmp,

IPSec Profile,

VTI (Virtual Tunnel Interface)

Да:

isakmp,

новый VTI (Virtual Tunnel Interface)

Нет

Да

Не масштабируемый.

На каждый Spoke по SVTI.

N spoke – N VTI и своя подсеть. Маршруты от IGP попадают в туннель.

IPSec with dynamic IP (Dynamic VTI and Static VTI and IGP)

keyring,

isakmp policy,

isakmp profile,

ipsec profile,

loopback for unnumbered interface (обязательно),

Virtual-Template type tunnel

keyring,

isakmp policy,

isakmp profile,

ipsec profile,

loopback for unnumbered interface,

Static VTI

Нет

Нет

Да

Очень масштабируемый. Все spoke и hub находятся в одной сети! Dynamic VTI (DVTIs) также point-to-point интерфейс. В режиме point-to-multipoint соседство OSPF не устанавливается.

Использование Unnumbered IP в качестве адреса DVTI обязательно

Easy VPN

ААА – для авторизации клиентов

Isakmp,

isakmp policy,

isakmp profile,

ipsec profile,

interface,

Virtual-Template type tunnel

DHCP для клиентов

Minimum

IPsec client конфигурация, с указанием VPN-сервера, VPN группы, пользователя для ааа,

Указание внутренних и внешний интерфейсов.

Нет

Нет

Да

Масштабируемый.

Если ранее был настроен NAT/PAT, то перед внедрением EASY VPN должна быть эта конфигурация удалена. Есть особенности в настройке transform-set.

 

GRE

Interface Tunnel,

Static route

Interface Tunnel,

Static route

Да

Int tunnel,

Static route

Да

Static route

Да

Не масштабируемый. Образует P2P линк, на каждый туннель – своя подсеть. Прекрасно подходит для туннелирования IGP протоколов.

IGP over GRE

Interface Tunnel,

Static route

Interface Tunnel,

Static route

Да

Int tunnel

Нет

Да

Не масштабируемый.

На каждый туннель – своя подсеть. IGP протоколы работают через туннель при настройках по умолчанию.

DMVPN (проприетарный)

DMVPN phase 1 – кон-ция только mGRE

DMVPN phase 2 – настройка ipsec profile для защиты трафика

Minimum:

DMVPN phase 1 – кон-ция только mGRE

DMVPN phase 2 – настройка ipsec profile для защиты трафика

Нет

Нет:

при добавлении нового spoke – туннель до него строится автоматически

Да:

EIGRP на HUB выключаем расщепление горизонта  и сохранения себя в качестве next-hop в анонсах маршрута

Наиболее масштабируемый протокол. GRE multipoint. Туннели между удаленными офисами создаются динамически.

PPTP

Vpdn-group,

interface Virtual-Template,

IP local pool,

username/password для авториз-и, static route до сетей уд.офиса

service internal (для включения настроек pptp клиента),

vpdn-group, interface Dialer, dialer-list,

static route до сетей центр.,удал. офиса

Да

Static route для внутренних сетей за PPTP клиентом

Да

Static route для новых внутренних сетей за новым PPTP клиентом

Да

Масштабируемый с ограничениями.

Морально устаревший протокол, уязвимости в криптографии в протоколе авторизации MSCHAPv2. Чаще всего используется для создания удаленного доступа. Поддерживается множеством популярных версий ОС Windows. Исп только один протокол для шифрования -MPPE (RC4 со 128-битным ключом). Поддерживает мультикаст, т.к. PPP инкапсулируются в GRE.

IGP over PPTP

Vpdn-group,

interface Virtual-Template,

IP local pool,

username/password для авториз-и, IGP protocol (router ospf process)

service internal (для включения настроек pptp клиента),

vpdn-group, interface Dialer, dialer-list,

IGP protocol (router ospf process)

Нет

Нет

Да

Масштабируемый с ограничениями.

Поддерживает мультикаст, т.к. PPP инкапсулируются в GRE.

Морально устаревший протокол  -> альтернатива L2TP over IPSec

L2TPv3 xconnect

pseudowire-class

xconnect

pseudowire-class

xconnect

Да

xconnect

Нет

Да

Не масштабируемый.

Отлично подходит для разнесения «native» L2 vlan-а через IP сеть. Но, необходимо наличие резервного шлюза по умолчанию. Создавая xconnect на интерфейсе маршрутизатора мы должны удалить IP адрес с его интерфейса, тем самым удалив маршрут по умолчанию для всех устройств внутри этой сети.

L2TPv2/v3

aaa new-model,

username для авторизации L2TP пира,

VPDN-group,

interface Virtual-Template,

static route до сетей уд. офиса

username для авторизации L2TP HUBa,

interface virtual-ppp,

pseudowire class,

static route до сетей центр.,удал. офиса

Да:

static route до внутренних сетей удаленного офиса

Да:

static route до внутренних сетей удаленного офиса

Да

Масштабируемый.

L2TPv3 дает большие преимущества, позволяя инкапсулировать не только PPP трафик, как L2TPv2, но и передавать метку VLANа и, а также инкапсулировать HDLC, Frame Relay.

IGP over L2TPv2/v3

aaa new-model,

username для авторизации L2TP пира,

VPDN-group,

interface Virtual-Template,

IGP (router ospf process)

username для авторизации L2TP HUBa,

interface virtual-ppp,

pseudowire class,

IGP (router ospf process)

Нет

Нет

Да

Очень масштабируемый. Позволяет настраивать протоколы маршрутизации «по умолчанию», связь удаленных офисов осуществляется через L2TPv2/v3 HUB (в центральном офисе).

Установление IPSec, сообщения, режимы работы.

В процессе установления соединения через IPSec двум участникам защищенного канала необходимо согласовать значительный ряд параметров: по необходимости они должны аутентифицировать друг друга, сгенерировать и обменяться общими ключами (причем через недоверенную среду), установить какой трафик шифровать (от какого отправителя и к какому получателю), а также договориться с помощью каких протоколов шифровать, а с помощью каких - аутентифицировать. Служебной информации предполагается обменяться много, не правда ли? По этой причине IPSec и состоит из стека протоколов, обязанность которых обеспечить установление, работу и управление защищенным соединением. Процесс установления соединения состоит из 2 фаз: первая фаза устанавливается для того, чтобы обеспечить безопасный обмен ISAKMP сообщений во второй фазе. А ISAKMP (Internet Security Association and Key Management Protocol) служит для согласования политик безопасности (SA) между участниками VPN соединения, в который как раз и определяются с помощью какого протокола шифровать (AES, 3DES, DES), и с помощью чего аутентифицировать (HMAC SHA, MD5).

Режим работы IKE (Internet Key Exchange):

IKE Фаза 1
  • (опционально) аутентификация пиров

  • Согласование IKE SA между пирами

    • Работают в 2 режимах Main Mode (6 сообщений), Aggressive Mode (3 сообщения)

Main Mode (6 сообщений)

  • [First exchange] Начало согласований начинаются с отправки пиром друг другу предложений о поддерживаемом шифровании, протоколов аутентификации самих сообщений IKE, времени жизни ассоциаций безопасности. Пир выбирает предложенный SA и отправляет их предложившему пиру. Эти настройки определяются в ISAKMP Policy

  • [Second exchange] Генерация общих разделяемых ключей через обмен открытыми ключами по Diffie-Hellman. Дальнейший обмен сообщениями происходит уже зашифрованными сообщениями.

  • [Third exchange] Обмен сообщениями для аутентификации ISAKMP сессии (IKE_I_MM4)

После установки IKE SA (то есть установления 1-ой фазы), происходит согласование IPSEC в quick mode (QM). Сообщения режима Main Mode (MM):

-        IKE_READY New State = IKE_I_MM1

-        IKE_I_MM1 New State = IKE_I_MM2

-        IKE_I_MM2 New State = IKE_I_MM3

-        IKE_I_MM3 New State = IKE_I_MM4

-        IKE_I_MM4 New State = IKE_I_MM5

-        IKE_I_MM5 New State = IKE_I_MM6

Aggressive Mode (3 сообщения)

Инициатором в первое сообщение помещается предложение о шифровании, протоколе аутентификации самих сообщений IKE, времени жизни ключей, сообщения об обмене ключами Диффи-Хеллмана (DH), идентификатор сессии, её аутентификация.

Команда для диагностики данной фазы на оборудовании Cisco **show crypto isakmp sa

IKE Фаза 1.5

Не используется в стандартном peer-to-peer VPN соединении, применяется при организации удаленных подключений.

Имеет два режима:

Xauth (User Authentication)

  • Дополнительная аутентификация пользователей в пределах IKE протокола. Для этого используется протокол Extended Authentication.

Mode config (Push Config)

  • Передается дополнительная информация клиенту о IP адресе, маске, DNS-серверах и т.д.

IKE Фаза 2

IPsec SAs/SPIs

На этом этапе ISAKMP ответственен за обмен сессионными ключами и согласование политик безопасности (SA) для обеспечения конфиденциальности и целостности пользовательского трафика. В настройке (в Cisco IOS) за это отвечает transform-set.

Quick mode

QM делает все то, что и IPSec SAs/SPIs за меньшее количество служебных сообщений. По аналогии с Aggressive Mode.

Рассмотрим пример обмена служебными сообщениями во время установления IPSec туннеля. Работающий вариант.

ISAKMP:(1007):Old State = IKE_I_MM6  New State = IKE_I_MM6

*Sep  3 08:59:27.539: ISAKMP:(1007):Input = IKE_MESG_INTERNAL, IKE_PROCESS_COMPLETE

*Sep  3 08:59:27.543: ISAKMP:(1007):Old State = IKE_I_MM6  New State = IKE_P1_COMPLETE

ФАЗА 2

*Sep  3 08:59:27.559: ISAKMP:(1007):beginning Quick Mode exchange, M-ID of 2551719066

*Sep  3 08:59:27.563: ISAKMP:(1007):QM Initiator gets spi

*Sep  3 08:59:27.575: ISAKMP:(1007): sending packet to 192.168.0.2 my_port 500 peer_port 500 (I) QM_IDLE

*Sep  3 08:59:27.575: ISAKMP:(1007):Sending an IKE IPv4 Packet.

*Sep  3 08:59:27.583: ISAKMP:(1007):Node 2551719066, Input = IKE_MESG_INTERNAL, IKE_INIT_QM

*Sep  3 08:59:27.587: ISAKMP:(1007):Old State = IKE_QM_READY  New State = IKE_QM_I_QM1

 

*Sep  3 08:59:27.803: ISAKMP:(1007):Checking IPSec proposal 1

*Sep  3 08:59:27.803: ISAKMP: transform 1, ESP_AES

*Sep  3 08:59:27.807: ISAKMP:   attributes in transform:

*Sep  3 08:59:27.807: ISAKMP:      encaps is 1 (Tunnel)

*Sep  3 08:59:27.811: ISAKMP:      SA life type in seconds

*Sep  3 08:59:27.815: ISAKMP:      SA life duration (basic) of 3600

*Sep  3 08:59:27.815: ISAKMP:      SA life type in kilobytes

*Sep  3 08:59:27.819: ISAKMP:      SA life duration (VPI) of  0x0 0x46 0x50 0x0

*Sep  3 08:59:27.827: ISAKMP:      authenticator is HMAC-SHA

*Sep  3 08:59:27.827: ISAKMP:      key length is 128

*Sep  3 08:59:27.831: ISAKMP:(1007):atts are acceptable.

*Sep  3 08:59:27.855: ISAKMP:(1007):Old State = IKE_QM_I_QM1  New State = IKE_QM_IPSEC_INSTALL_AWAIT

ISAKMP:(1007):Old State = IKE_QM_IPSEC_INSTALL_AWAIT  New State = IKE_QM_PHASE2_COMPLETE

 

А теперь я предлагаю рассмотреть пару примеров неработоспособности IPSec.

Case1

“Old State = IKE_I_MM1  New State = IKE_I_MM1”

Причина №1

Не договорились по IKE proposal (предложенным IKE) в Фазе 1. На одной стороне указан 3des, на другом aes.

Error while processing SA request: Failed to initialize SA

*Sep  3 08:36:38.239: ISAKMP: Error while processing KMI message 0, error 2.

*Sep  3 08:36:38.287: ISAKMP:(0): retransmitting phase 1 MM_NO_STATE...

*Sep  3 08:40:38.307: ISAKMP (0): incrementing error counter on sa, attempt 3 of 5: retransmit phase 1

*Sep  3 08:40:38.307: ISAKMP:(0): retransmitting phase 1 MM_NO_STATE

*Sep  3 08:37:08.339: ISAKMP:(0):deleting SA reason "Death by retransmission P1" state (I) MM_NO_STATE (peer 192.168.0.2)

*Sep  3 08:41:08.359: ISAKMP:(0):Input = IKE_MESG_INTERNAL, IKE_PHASE1_DEL

*Sep  3 08:41:08.359: ISAKMP:(0):Old State = IKE_I_MM1  New State = IKE_DEST_SA

На маршрутизаторе отображается следующее состояние:

R7#sh crypto isakmp sa

IPv4 Crypto ISAKMP SA

       dst                     src                       state             conn-id status

192.168.0.2     192.168.0.1     MM_NO_STATE          0    ACTIVE

Причина №2

ACL на физическом интерфейсе блокируется трафик ISAKMP.

Case2

Если transform set на одном роутере один

R7#sh run | i transform

crypto ipsec transform-set TRANSFORM esp-aes esp-md5-hmac

…а на другом роутере другой

R10#sh run | i transform

crypto ipsec transform-set TRANSFORM esp-aes esp-sha-hmac

,то не сойдется SA IPSEC (не будет увеличиваться количество зашифрованных и расшифрованных пакетов

*Sep  3 08:56:08.551: ISAKMP:(1006): IPSec policy invalidated proposal with error 256

*Sep  3 08:56:08.559: ISAKMP:(1006): phase 2 SA policy not acceptable! (local 192.168.0.1 remote 192.168.0.2)

*Sep  3 08:56:08.563: ISAKMP: set new node -1456368678 to QM_IDLE

*Sep  3 08:56:08.567: ISAKMP:(1006):Sending NOTIFY PROPOSAL_NOT_CHOSEN protocol 3

        spi 1785687224, message ID = 2838598618

*Sep  3 08:56:08.575: ISAKMP:(1006): sending packet to 192.168.0.2 my_port 500 peer_port 500 (I) QM_IDLE

*Sep  3 08:56:08.579: ISAKMP:(1006):Sending an IKE IPv4 Packet.

*Sep  3 08:56:08.583: ISAKMP:(1006):purging node -1456368678

*Sep  3 08:56:08.587: ISAKMP:(1006):deleting node 1350414148 error TRUE reason "QM rejected"

*Sep  3 08:56:08.591: ISAKMP:(1006):Node 1350414148, Input = IKE_MESG_FROM_PEER, IKE_QM_EXCH

*Sep  3 08:56:08.595: ISAKMP:(1006):Old State = IKE_QM_READY  New State = IKE_QM_READY

Case3

Если неправильно указали preshared key на IPSec пирах:

R7#sh run | i isakmp key

crypto isakmp key cisco123 address 172.16.1.2

R10#sh run | i isakmp key

crypto isakmp key cisco address 0.0.0.0 0.0.0.0

 

Тогда будет ошибка «retransmitting phase 1 MM_KEY_EXCH»

*Sep  3 09:14:30.659: ISAKMP:(1010): retransmitting phase 1 MM_KEY_EXCH...

*Sep  3 09:14:30.663: ISAKMP (1010): incrementing error counter on sa, attempt 3 of 5: retransmit phase 1

*Sep  3 09:14:30.663: ISAKMP:(1010): retransmitting phase 1 MM_KEY_EXCH

*Sep  3 09:14:30.663: ISAKMP:(1010): sending packet to 192.168.0.2 my_port 500 peer_port 500 (I) MM_KEY_EXCH

*Sep  3 09:14:30.663: ISAKMP:(1010):Sending an IKE IPv4 Packet.

*Sep  3 09:14:30.711: ISAKMP (1010): received packet from 192.168.0.2 dport 500 sport 500 Global (I) MM_KEY_EXCH

*Sep  3 09:14:30.715: ISAKMP:(1010): phase 1 packet is a duplicate of a previous packet.

*Sep  3 09:14:50.883: ISAKMP:(1011): retransmitting due to retransmit phase 1

*Sep  3 09:14:51.383: ISAKMP:(1011): retransmitting phase 1 MM_KEY_EXCH...

*Sep  3 09:14:51.387: ISAKMP:(1011):peer does not do paranoid keepalives.

*Sep  3 09:14:51.387: ISAKMP:(1011):deleting SA reason "Death by retransmission P1" state (R) MM_KEY_EXCH (peer 192.168.0.2)

*Sep  3 09:14:51.395: ISAKMP:(1011):Input = IKE_MESG_INTERNAL, IKE_PHASE1_DEL

 

Regular IPSec

 

 

Настройка через Crypto map

Конфигурация устройств:

HUB

Spoke1

Настройка первой фазы IPSec для обмена сессионного ключа:

 

crypto isakmp policy 1

 hash md5

 authentication pre-share

 group 5

crypto isakmp key cisco123 address 172.16.1.2

!

Настройка второй фазы IPSec c заданием алгоритма шифрования и аутентификации

 

crypto ipsec transform-set Trans_HUB1_SP1 esp-aes 256 esp-md5-hmac

!

crypto map HUB_SPOKEs 1 ipsec-isakmp

 set peer 172.16.1.2

 set transform-set Trans_HUB1_SP1

 match address TO_Spoke1

 reverse-route static

!

crypto isakmp policy 1

 hash md5

 authentication pre-share

 group 5

crypto isakmp key cisco123 address 192.168.1.1   

!

crypto ipsec transform-set Trans_SP1_HUB1 esp-aes 256 esp-md5-hmac

!

crypto map SP1_HUB 1 ipsec-isakmp

 set peer 192.168.1.1

 set transform-set Trans_SP1_HUB1

 match address TO_HUB

 reverse-route static

!

Настройка заворачивания маршрутов в туннель

ip access-list extended TO_Spoke1

 permit ip 10.0.0.0 0.0.0.255 1.1.1.0 0.0.0.255

!

Interface Ethernet0/0

ip address 192.168.1.1 255.255.255.0

crypto map HUB_SPOKEs

!

ip access-list extended TO_HUB

 permit ip 1.1.1.0 0.0.0.255 10.0.0.0 0.0.0.255

!

Interface Ethernet0/0

ip address 172.16.1.1 255.255.255.0

crypto map SP1_HUB

!

 

Проверка работоспособности

HUB#ping 1.1.1.1 source 10.0.0.1

.!!!!

Success rate is 80 percent (4/5), round-trip min/avg/max = 4/4/5 ms

Spoke1#ping 10.0.0.1 source 1.1.1.1

.!!!!

Success rate is 80 percent (4/5), round-trip min/avg/max = 4/4/5 ms

Проверка сходимости VPN:

Успешный обмен ключами:

Spoke1#show crypto isakmp sa

IPv4 Crypto ISAKMP SA

dst                       src                    state              conn-id status

192.168.1.1     172.16.1.2      QM_IDLE           1007 ACTIVE

 

Успешное прохождение трафика через VPN:

Spoke1#show crypto ipsec sa

 

interface: Ethernet0/0

    Crypto map tag: SP1_HUB, local addr 172.16.1.2

 

   protected vrf: (none)

   local  ident (addr/mask/prot/port): (1.1.1.0/255.255.255.0/256/0)

   remote ident (addr/mask/prot/port): (10.0.0.0/255.255.255.0/256/0)

   current_peer 192.168.1.1 port 500

     PERMIT, flags={origin_is_acl,}

    #pkts encaps: 4, #pkts encrypt: 4, #pkts digest: 4

    #pkts decaps: 4, #pkts decrypt: 4, #pkts verify: 4

    #pkts compressed: 0, #pkts decompressed: 0

    #pkts not compressed: 0, #pkts compr. failed: 0

    #pkts not decompressed: 0, #pkts decompress failed: 0

    #send errors 0, #recv errors 0

 

     local crypto endpt.: 172.16.1.2, remote crypto endpt.: 192.168.1.1

     path mtu 1500, ip mtu 1500, ip mtu idb Ethernet0/0

     current outbound spi: 0xA7424886(2806139014)

     PFS (Y/N): N, DH group: none

 

SPI передается в IPSec пакете для того, чтобы при получении его пир-ом, в данном случае HUB-ом,  HUB знал какой SA (security association) использовать, то есть какой протокол шифрования, какой протокол аутентификации и т.д. используется и как пакет расшифровывать. На HUB-е есть точно такая же SA с таким же SPI.

Успешное прохождение трафика через VPN на HUB-e

HUB#sho crypto ipsec sa

 

interface: Ethernet0/0

    Crypto map tag: HUB_SPOKEs, local addr 192.168.1.1

 

   protected vrf: (none)

   local  ident (addr/mask/prot/port): (10.0.0.0/255.255.255.0/256/0)

   remote ident (addr/mask/prot/port): (1.1.1.0/255.255.255.0/256/0)

   current_peer 172.16.1.2 port 500

     PERMIT, flags={origin_is_acl,}

    #pkts encaps: 4, #pkts encrypt: 4, #pkts digest: 4

    #pkts decaps: 4, #pkts decrypt: 4, #pkts verify: 4

    #pkts compressed: 0, #pkts decompressed: 0

    #pkts not compressed: 0, #pkts compr. failed: 0

    #pkts not decompressed: 0, #pkts decompress failed: 0

    #send errors 0, #recv errors 0

 

     local crypto endpt.: 192.168.1.1, remote crypto endpt.: 172.16.1.2

     path mtu 1500, ip mtu 1500, ip mtu idb Ethernet0/0

     current outbound spi: 0x10101858(269490264)

     PFS (Y/N): N, DH group: none

 

     inbound esp sas:

      spi: 0xA7424886(2806139014)

        transform: esp-256-aes esp-md5-hmac ,

        in use settings ={Tunnel, }

        conn id: 19, flow_id: SW:19, sibling_flags 80000040, crypto map: HUB_SPOKEs

        sa timing: remaining key lifetime (k/sec): (4360017/2846)

        IV size: 16 bytes

        replay detection support: Y

        Status: ACTIVE(ACTIVE)

 

Теперь добавим еще один Spoke, посмотрим, какие изменения нам потребуется внести

Настройка на HUB

Настройка на новом Spoke

HUB#

crypto isakmp policy 1

 hash md5

 authentication pre-share

 group 5

crypto isakmp key cisco123 address 172.16.1.2    

crypto isakmp key cisco456 address 172.16.2.3    

!

!

crypto ipsec transform-set Trans_HUB1_SP1 esp-aes 256 esp-md5-hmac

!

crypto map HUB_SPOKEs 1 ipsec-isakmp

 set peer 172.16.1.2

 set peer 172.16.2.3

 set transform-set Trans_HUB1_SP1

 match address TO_Spokes

 reverse-route static

!

ip access-list extended TO_Spokes

 permit ip 10.0.0.0 0.0.0.255 1.1.1.0 0.0.0.255

 permit ip 10.0.0.0 0.0.0.255 2.2.2.0 0.0.0.255

 

т.е. для добавления N spoke-ов, нужно 3N дополнительный строчек

Настройка такая же как и на первом Spoke1 (с учетом  поправки внутренних сетей в ACL)

Spoke2#

crypto isakmp policy 1

 hash md5

 authentication pre-share

 group 5

crypto isakmp key cisco456 address 192.168.1.1   

!

!

crypto ipsec transform-set Trans_SP2_HUB1 esp-aes 256 esp-md5-hmac

!

crypto map SP2_HUB 1 ipsec-isakmp

 set peer 192.168.1.1

 set transform-set Trans_SP2_HUB1

 match address TO_HUB

 reverse-route static

!

ip access-list extended TO_HUB

 permit ip 2.2.2.0 0.0.0.255 10.0.0.0 0.0.0.255

 

Проверка работы VPN

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

HUB#ping 2.2.2.2 source 10.0.0.1

.!!!!

Success rate is 80 percent (4/5), round-trip min/avg/max = 4/4/5 ms

 

На HUBе теперь появилась дополнительная сессия обмена ключами со вторым Spoke:

HUB#sho crypto isakmp sa

IPv4 Crypto ISAKMP SA

dst                        src                     state              conn-id status

192.168.1.1     172.16.2.3      QM_IDLE           1009 ACTIVE

192.168.1.1     172.16.1.2      QM_IDLE           1008 ACTIVE

 

Однако связи между офисами нет (даже через HUB).

Spoke1#ping 2.2.2.2 source 1.1.1.1

.....

Success rate is 0 percent (0/5)

 

Отсутствие связности до Spoke2 неудивительно - необходимо включать внутренние сети нового удаленного офиса в Crypto ACL, в итоге для обеспечения связности между Spokе-ми через HUB требуется добавление в Crypto ACL N сетей на N spoke-ах.

 

Альтернатива. Множественные Crypto map.

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

 

 

HUB#

crypto ipsec transform-set 3DES-MD5 esp-3des esp-md5-hmac

 mode tunnel

!

crypto ipsec profile Spokes_VPN_Profile

set security-association lifetime seconds 86400

set transform-set 3DES-MD5

set reverse-route distance 1

reverse-route

!

crypto dynamic-map hq-vpn 30

 set profile Spokes_VPN_Profile

 match address VPN33-32-TRAFFIC

crypto dynamic-map hq-vpn 3348

 set profile Spokes_VPN_Profile

 match address VPN3348-TRAFFIC

crypto dynamic-map hq-vpn 50

 set profile Spokes_VPN_Profile

 match address VPN33-64-TRAFFIC

!        

crypto map VPN 1 ipsec-isakmp dynamic hq-vpn

!

interface GigabitEthernet1/0

 ip address 55.1.1.5 255.255.255.0

<omitted...>

crypto map VPN

!

ip access-list extended VPN33-32-TRAFFIC

 permit ip any 192.168.33.32 0.0.0.15

ip access-list extended VPN33-48-TRAFFIC

 permit ip any 192.168.33.48 0.0.0.15

ip access-list extended VPN33-64-TRAFFIC

 permit ip any 192.168.33.64 0.0.0.15

Spoke#

crypto ipsec transform-set 3DES-MD5 esp-3des esp-md5-hmac

 mode tunnel

!

crypto map VPN 1 ipsec-isakmp

 set peer 55.1.1.5

 set transform-set 3DES-MD5

 match address TO_HUB

 reverse-route static

!

interface FastEthernet0/0

 ip address negotiated

<omitted...>

crypto map VPN

!

ip access-list extended TO_HUB

 permit ip 192.168.33.32 0.0.0.15 any

 

В данной схеме и в данной конфигурации на удаленных офисах выставлено в Crypto ACL в качестве сети назначения – ip any, т.е. трафик к любому хосту будет заворачиваться в туннель, и при подключении нового удаленного офиса нет необходимости в изменении во всех остальных Crypto ACL в N удаленных офисах.

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

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

  1. Отойти от crypto map к VTI и настроить динамическую маршрутизацию.

  2. Для настройки динамического протокола маршрутизации (OSPF) перейдем от использования метода crypto  map к такой же настройке, но только через VTI интерфейс (поддерживает unicast, multicast).

Настройка через Virtual Tunnel Interface + профайлы.

Virtual Tunnel Interface обеспечивают маршрутизирующий интерфейс для терминирования IPSec туннелей и более простой способ обеспечения безопасного соединения удаленных корпоративных сетей. VTI поддерживает передачу через туннель только юникаста и мультикаста, что позволяет обеспечить работу динамических протоколов маршрутизации без дополнительной необходимости в инкапсулировании пакета в GRE (дополнительные 4-байта). Существуют два типа виртуальных туннельных интерфейса:

Static virtual interface – представляет собой point-to-point туннель

Dуnamic virtual interface – позволяет масштабировать решение по VPN-ам путем терминирования множественных туннелей на себя с удаленных Spoke-ов, которые могут иметь динамический IP адрес. Единственный недостаток – только удаленные spoke маршрутизаторы могут инициировать установление туннеля (т.к. только у них указан tunnel destination HUB_ip).

При настройке DVTI на HUB маршрутизаторе создается шаблон настроек virtual-template, при успешном обмене ключами с удаленным spoke-м и установлении с ним туннеля - из «шаблона» на HUBе создается virtual-access интерфейс, который является как SVTI туннельный интерфейс  для данного туннеля.

Особенности VTI:

  • Traffic selector (т.е. тот трафик, который будет завернут в туннель) у Static VTI всегда ip any any;

  • Traffic selector у Dynamic VTI тоже по умолчанию ip any any и поддерживает только одну IPSec SA, но может принимать тот traffic selector, который предлагает ему инициатор;

  • Не поддерживается Stateful Failover;

  • Режим работы transform-set только в туннельном режиме.

 

 

Настройка Static VTI через профайлы

HUB#

crypto isakmp policy 1

 hash md5

 authentication pre-share

 group 5

crypto isakmp key cisco123 address 172.16.1.2    

!

crypto ipsec transform-set Trans_HUB_SP esp-aes esp-sha-hmac

!

crypto ipsec profile P1

 set transform-set Trans_HUB_SP

!

interface Tunnel0

 ip address 10.1.1.254 255.255.255.0

 ip ospf mtu-ignore*(см.ниже)

 load-interval 30

 tunnel source 192.168.1.1

 tunnel mode ipsec ipv4

 tunnel destination 172.16.1.2

 tunnel protection ipsec profile P1

!

router ospf 1

 network 10.0.0.0 0.0.0.255 area 0

 network 10.1.1.0 0.0.0.255 area 0

Spoke1#

crypto isakmp policy 1

 hash md5

 authentication pre-share

 group 5

crypto isakmp key cisco123 address 192.168.1.1   

!

crypto ipsec transform-set Trans_HUB_SP esp-aes esp-sha-hmac

!

crypto ipsec profile P1

 set transform-set Trans_HUB_SP

!

interface Tunnel0

 ip address 10.1.1.1 255.255.255.0

 ip ospf mtu-ignore

 load-interval 30

 tunnel source 172.16.1.2

 tunnel mode ipsec ipv4

 tunnel destination 192.168.1.1

 tunnel protection ipsec profile P1

!

router ospf 1

 network 1.1.1.0 0.0.0.255 area 0

 network 10.1.1.0 0.0.0.255 area 0

 

Проверка установления соседства через OSPF over Static VTI

HUB#sh ip ospf neighbor

 

Neighbor ID     Pri   State           Dead Time   Address      Interface

     1.1.1.1           0    FULL/  -        00:00:33    10.1.1.1        Tunnel0

 

Сеть на Spoke 1 теперь доступна через туннель

HUB#sh ip route

      1.0.0.0/32 is subnetted, 1 subnets

O        1.1.1.1 [110/1001] via 10.1.1.1, 00:02:56, Tunnel0

      10.0.0.0/8 is variably subnetted, 6 subnets, 2 masks

C        10.0.0.0/24 is directly connected, Loopback0

L        10.0.0.1/32 is directly connected, Loopback0

C        10.0.1.0/24 is directly connected, Loopback1

L        10.0.1.1/32 is directly connected, Loopback1

C        10.1.1.0/24 is directly connected, Tunnel0

L        10.1.1.254/32 is directly connected, Tunnel0

 

Проверка доступности сетей в Центральном офисе со Spoke 1

Spoke1#ping 10.0.0.1 source 1.1.1.1

!!!!!

Success rate is 100 percent (5/5), round-trip min/avg/max = 5/5/5 ms

 

Traffic Selector для Static VTI ip any any, т.е. все, что мы направим в туннель через статический маршрут либо через протокол маршрутизации, то и будет шифроваться/дешифроваться.

Spoke1#sho crypto ipsec sa

 

interface: Tunnel0

    Crypto map tag: Tunnel0-head-0, local addr 172.16.1.2

   protected vrf: (none)

   local  ident (addr/mask/prot/port): (0.0.0.0/0.0.0.0/256/0)

   remote ident (addr/mask/prot/port): (0.0.0.0/0.0.0.0/256/0)

   current_peer 192.168.1.1 port 500

     PERMIT, flags={origin_is_acl,}

    #pkts encaps: 76, #pkts encrypt: 76, #pkts digest: 76

    #pkts decaps: 65, #pkts decrypt: 65, #pkts verify: 65

    #pkts compressed: 0, #pkts decompressed: 0

    #pkts not compressed: 0, #pkts compr. failed: 0

    #pkts not decompressed: 0, #pkts decompress failed: 0

    #send errors 0, #recv errors 0

 

interface Tunnel0

ip address 10.1.1.254 255.255.255.0

ip ospf mtu-ignore

 

OSPF Neighbor осуществляет проверку на использование одинакового значения MTU на интерфейсе. Если neighbor получит размер MTU в DBD пакете бОльший, чем MTU своего входящего интерфейса, то соседство не установится.

При подключении второго Spoke2 настраивается второй Tunnel (HUB-Spoke2), на которого выделяется своя отдельная подсеть.

HUB#sho ip ospf neighbor

 

Neighbor ID     Pri   State       Dead Time   Address         Interface

2.2.2.2               0   FULL/  -        00:00:31    10.1.2.2        Tunnel1

1.1.1.1               0   FULL/  -        00:00:30    10.1.1.1        Tunnel0

 

Маршруты на Spoke1

Spoke1#sh ip route

Gateway of last resort is 172.16.1.5 to network 0.0.0.0

 

<...ommited...>

C        1.1.1.0/24 is directly connected, Loopback0

L        1.1.1.1/32 is directly connected, Loopback0

      2.0.0.0/32 is subnetted, 1 subnets

O        2.2.2.2 [110/2001] via 10.1.1.254, 01:53:04, Tunnel0 <-Сеть Spoke2

      10.0.0.0/8 is variably subnetted, 5 subnets, 2 masks

O        10.0.0.1/32 [110/1001] via 10.1.1.254, 02:04:11, Tunnel0  <-Сеть Головного офиса

O        10.0.1.1/32 [110/1001] via 10.1.1.254, 02:04:11, Tunnel0  <-подсеть туннеля HUB-Spoke1

C        10.1.1.0/24 is directly connected, Tunnel0

L        10.1.1.1/32 is directly connected, Tunnel0

O        10.1.2.0/24 [110/2000] via 10.1.1.254, 01:53:14, Tunnel0  <-подсеть туннеля HUB-Spoke2

      172.16.0.0/16 is variably subnetted, 2 subnets, 2 masks

 

Сообщение до второго удаленного офиса через Центральный офис:

Spoke1#traceroute 2.2.2.2

Type escape sequence to abort.

Tracing the route to 2.2.2.2

VRF info: (vrf in name/id, vrf out name/id)

  1 10.1.1.254 5 msec 4 msec 5 msec

  2 10.1.2.2 5 msec 10 msec *

 

IPSec with Dynamic IP, Dynamic VTI

 

 

Рассмотрим на нашем примере схему с использованием Dynamic VTI на HUBе, Static VTI на spoke-ах.  К Dynamic VTI могут подключаться также и с настроенными crypto map-ами.

HUB#

crypto keyring KEY_Dynamic_connection 

  pre-shared-key address 0.0.0.0 0.0.0.0 key cisco123

!

crypto isakmp policy 1

 hash md5

 authentication pre-share

 group 5

crypto isakmp profile DVTI

   keyring KEY_Dynamic_connection

   match identity address 0.0.0.0

   virtual-template 1

!

crypto ipsec transform-set Trans_HUB_SP esp-aes esp-sha-hmac

!

crypto ipsec profile P1

 set transform-set Trans_HUB_SP

 set isakmp-profile DVTI

!

interface Loopback1

 ip address 10.1.1.254 255.255.255.0

!

interface Virtual-Template1 type tunnel

 ip unnumbered Loopback1

 ip ospf mtu-ignore

 tunnel mode ipsec ipv4

 tunnel protection ipsec profile P1

!

router ospf 1

 network 10.0.0.0 0.0.0.255 area 0

 network 10.1.1.0 0.0.0.255 area 0

Spoke1#

crypto keyring KEY_Dynamic_connection 

  pre-shared-key address 0.0.0.0 0.0.0.0 key cisco123

!

crypto isakmp policy 1

 hash md5

 authentication pre-share

 group 5

crypto isakmp profile DVTI

   keyring KEY_Dynamic_connection

   match identity address 0.0.0.0

!

crypto ipsec transform-set Trans_HUB_SP esp-aes esp-sha-hmac

!

crypto ipsec profile P1

 set transform-set Trans_HUB_SP

 set isakmp-profile DVTI

!

interface Loopback1

 ip address 10.1.1.1 255.255.255.0
!

interface Tunnel0

 ip unnumbered Loopback1

 ip ospf mtu-ignore

 tunnel source Ethernet0/0

 tunnel mode ipsec ipv4

 tunnel destination 192.168.1.1

 tunnel protection ipsec profile P1

!

router ospf 1

 network 1.1.1.0 0.0.0.255 area 0

 network 10.1.1.0 0.0.0.255 area 0

 

Проверим установленные туннели при двух подключенных Spoke-ах:

HUB#sh crypto isakmp sa

IPv4 Crypto ISAKMP SA

        dst                  src                  state            conn-id status

192.168.1.1     172.16.2.3      QM_IDLE           1047 ACTIVE

192.168.1.1     172.16.1.2      QM_IDLE           1046 ACTIVE

 

HUB# sh ip int br

  Interface                    IP-Address      OK? Method   Status           Protocol

Ethernet0/0                192.168.1.1     YES NVRAM      up                    up     

Ethernet0/1                unassigned      YES  manual        up                    up     

Ethernet0/2                unassigned      YES NVRAM    down              down   

Ethernet0/3                unassigned      YES manual         up                    up     

Loopback0                   10.0.0.1        YES manual          up                    up     

Loopback1                   10.1.1.254      YES manual        up                     up     

Virtual-Access1          10.1.1.254      YES unset           up                    up     

Virtual-Access2          10.1.1.254      YES unset           up                    up     

Virtual-Template1      10.1.1.254      YES manual         up                  down

 

HUB#sho crypto ipsec sa

 

interface: Virtual-Access2

    Crypto map tag: Virtual-Access2-head-0, local addr 192.168.1.1

   protected vrf: (none)

   local  ident (addr/mask/prot/port): (0.0.0.0/0.0.0.0/256/0)

   remote ident (addr/mask/prot/port): (0.0.0.0/0.0.0.0/256/0)

   current_peer 172.16.1.2 port 500

 

interface: Virtual-Access1

    Crypto map tag: Virtual-Access1-head-0, local addr 192.168.1.1

   protected vrf: (none)

   local  ident (addr/mask/prot/port): (0.0.0.0/0.0.0.0/256/0)

   remote ident (addr/mask/prot/port): (0.0.0.0/0.0.0.0/256/0)

   current_peer 172.16.2.3 port 500

 

Работа OSPF через туннели:

HUB#sh ip ospf neighbor

 

Все spoke-и находятся в одной сети!

 

Neighbor ID     Pri   State           Dead Time   Address         Interface

    1.1.1.1           0     FULL/  -        00:00:32    10.1.1.1        Virtual-Access2

    2.2.2.2           0     FULL/  -        00:00:35    10.1.1.2        Virtual-Access1

 

Маршруты Центрального Офиса

HUB#sh ip route        

Gateway of last resort is not set

 

      1.0.0.0/32 is subnetted, 1 subnets

O        1.1.1.1 [110/2] via 10.1.1.1, 00:05:00, Virtual-Access2 <-Сеть Spoke1

      2.0.0.0/32 is subnetted, 1 subnets

O        2.2.2.2 [110/2] via 10.1.1.2, 00:44:01, Virtual-Access1 <-Сеть Spoke2

      10.0.0.0/8 is variably subnetted, 6 subnets, 2 masks

C        10.0.0.0/24 is directly connected, Loopback0

L        10.0.0.1/32 is directly connected, Loopback0

C        10.1.1.0/24 is directly connected, Loopback1

O        10.1.1.1/32 [110/2] via 10.1.1.1, 00:05:00, Virtual-Access2  <-Туннельные интерфейсы Spoke1

O        10.1.1.2/32 [110/2] via 10.1.1.2, 00:44:01, Virtual-Access1  <-Туннельные интерфейсы Spoke2

L        10.1.1.254/32 is directly connected, Loopback1

      172.16.0.0/24 is subnetted, 3 subnets

      192.168.1.0/24 is variably subnetted, 2 subnets, 2 masks

C        192.168.1.0/24 is directly connected, Ethernet0/0

L        192.168.1.1/32 is directly connected, Ethernet0/0

 

Маршруты на Spoke1:

Spoke1#sh ip route    

Gateway of last resort is 172.16.1.5 to network 0.0.0.0

 

S*    0.0.0.0/0 [1/0] via 172.16.1.5

      1.0.0.0/8 is variably subnetted, 2 subnets, 2 masks

C        1.1.1.0/24 is directly connected, Loopback0

L        1.1.1.1/32 is directly connected, Loopback0

      2.0.0.0/32 is subnetted, 1 subnets

O        2.2.2.2 [110/1002] via 10.1.1.254, 00:05:38, Tunnel0 <-Сеть Spoke2

      10.0.0.0/8 is variably subnetted, 5 subnets, 2 masks

O        10.0.0.1/32 [110/1001] via 10.1.1.254, 00:05:38, Tunnel0 <- Сети Центрального офиса

C        10.1.1.0/24 is directly connected, Loopback1

L        10.1.1.1/32 is directly connected, Loopback1

O        10.1.1.2/32 [110/1002] via 10.1.1.254, 00:05:38, Tunnel0 <-Туннельный интерфейс Spoke2

O        10.1.1.254/32 [110/1001] via 10.1.1.254, 00:02:26, Tunnel0 <-Туннельный интерфейс HUBa

      172.16.0.0/16 is variably subnetted, 2 subnets, 2 masks

C        172.16.1.0/24 is directly connected, Ethernet0/0

L        172.16.1.2/32 is directly connected, Ethernet0/0

 

Spoke1#traceroute 2.2.2.2

  1 10.1.1.254 5 msec 5 msec 5 msec

  2 10.1.1.2     9 msec 5 msec *

 

Spoke1#traceroute 10.1.1.2

  1 10.1.1.254 5 msec 5 msec 5 msec

  2 10.1.1.2     5 msec 10 msec *

 

Восстановление канала при падении линка

Выключим Tunnel интерфейс на Spoke, очистим ipsec сессии и обмененными ключами. После этого включим интерфейс обратно:

Spoke1(config-if)#no shutdown

*Aug  6 10:02:27.669: %CRYPTO-6-ISAKMP_ON_OFF: ISAKMP is ON

*Aug  6 10:02:27.702: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel0, changed state to up

*Aug  6 10:02:27.713: %OSPF-5-ADJCHG: Process 1, Nbr 10.0.0.1 on Tunnel0 from LOADING to FULL, Loading Done

Восстановление туннеля прошло автоматически.

 

EAZY VPN

Идея технологии Eazy VPN заключается в облегчении установления VPN-подключения региональным маршрутизаторам засчет того, что часть настроек касательно IPSec сообщается VPN-клиенту самим VPN HUB-ом. Для этого в протокол согласования ассоциаций безопасности (ISAKMP) была внесена дополнительная фаза 1.5. Через эту фазу vpn-клиент может запросить информацию о IP-адресе, DNS-ы, ACL для split tunnel. Чаще всего эта технология используется в организации удаленного подключения через Cisco VPN Client.

Три режима работы Easy VPN Remote[1]:

  • клиентский режим. В этом случае на VPN-клиенте(маршрутизаторе) вся локальная сеть удаленного офиса подвергается NAT/PAT-трансляции в адрес, который выдан сервером из заданного пула

  • режим сетевого расширения. В этом случае, все сетевые устройства, которые находятся за VPN-клиентом (маршрутизатором), получают IP-адреса и являются полноценными участниками IP-маршрутизации. В этом случае PAT не используется, что позволяет конечным рабочим станциям работать друг с другом напрямую.

  • режим сетевого расширения «плюс». Аналогичен режиму простого сетевого расширения, но с дополнением в виде возможности запроса IP-адреса в процессе установления защищенного канала связи и его автоматической установки на доступный Loopback-интерфейс. Ассоциации безопасности IPsec для этого IP-адреса автоматически создаются Easy VPN Remote’ом. Этот IP чаще всего используется для устранения неисправностей (ping, telnet, ssh и т.д.).

Есть и особенности в настройках:

Cisco Easy VPN Remote не поддерживает transform set с установленной безопасностью без аутентификации (ESP-DES and ESP-3DES) или transform-set, обеспечивающий аутентификацию без шифрования (ESP-NULL ESP-SHA-HMAC and ESP-NULL ESP-MD5-HMAC)

Если на VPN-клиенте (маршрутизаторе) настроен NAT/PAT до настройки Cisco Easy VPN Remote, то в первую очередь необходимо удалить NAT-правила (в последствии они создадутся автоматически)

 

Настройка Easy VPN в client mode

На VPN-клиенте (маршрутизаторе) вся локальная сеть удаленного офиса подвергается NAT/PAT-трансляции в адрес, который выдан сервером из заданного пула

VPN_HUB#

aaa new-model

!

aaa authorization network LOCAL-AUTHOR local

crypto isakmp policy 10

 authentication pre-share

 group 2

!        

crypto isakmp client configuration group VPN-CLIENT-GROUP

 key vpnclientcisco

 pool VPN-LOCAL-POOL

 acl 100

crypto isakmp profile PROFILE-ISAKMP

   match identity group VPN-CLIENT-GROUP

   isakmp authorization list LOCAL-AUTHOR

   client configuration address respond

   client configuration group VPN-CLIENT-GROUP

   virtual-template 1

!

crypto ipsec transform-set TRANSFORM-IPSEC esp-aes esp-sha-hmac

!

crypto ipsec profile PROFILE-IPSEC

 set transform-set TRANSFORM-IPSEC

 set isakmp-profile PROFILE-ISAKMP

interface Ethernet0/0

 ip address 192.168.1.2 255.255.255.0

 ip nat inside

 ip virtual-reassembly in

!

interface Ethernet0/1

 ip address 77.1.1.2 255.255.255.0

 ip nat outside

 ip virtual-reassembly in

!

interface Virtual-Template1 type tunnel

 ip unnumbered Ethernet0/1

 ip nat inside

 ip virtual-reassembly in

 tunnel mode ipsec ipv4

 tunnel protection ipsec profile PROFILE-IPSEC

!

ip local pool VPN-LOCAL-POOL 172.16.40.1 172.16.40.100

!

ip nat inside source list TONAT interface Ethernet0/1 overload

(задаем ip адрес VPN HUBа, указываем VPN-группу, режим работы VPN-клиента и аутентификационные данные)

VPN_Client#

crypto ipsec client ezvpn EZVPN-CLIENT

 connect auto

 group VPN-CLIENT-GROUP key vpnclientcisco

 mode client

 peer 77.1.1.2

 username cisco password cisco

 xauth userid mode local

!

interface Ethernet0/0

 ip address 172.16.1.7 255.255.255.0

 crypto ipsec client ezvpn EZVPN-CLIENT

!

interface Ethernet0/2

 ip address 192.168.2.7 255.255.255.0

 ip nat inside

 crypto ipsec client ezvpn EZVPN-CLIENT inside

Клиенту выдается автоматически IP

VPN_Client#sh ip int br

Interface                     IP-Address       OK? Method     Status                Protocol

Ethernet0/0                172.16.1.7       YES NVRAM        up                    up     

Ethernet0/2                192.168.2.7     YES NVRAM        up                    up     

Loopback0                   7.7.7.7           YES NVRAM       up                     up     

Loopback10000       172.16.40.49     YES TFTP             up                     up     

NVI0                            172.16.1.7     YES unset              up                    up     

 

Автоматически прописывается ip outside nat (ip nat inside мы должны прописать) и добавляются ACL!

Проверим, что NAT настроился автоматически, прописался исходящий интерфейс и добавились списки контроля доступа ACL интересующего нас трафика

VPN_Client#sh ip nat statistics

Total active translations: 0 (0 static, 0 dynamic; 0 extended)

Peak translations: 0

Outside interfaces:

  Ethernet0/0

Inside interfaces:

  Ethernet0/2

Hits: 0  Misses: 0

CEF Translated packets: 0, CEF Punted packets: 0

Expired translations: 0

Dynamic mappings:

-- Inside Source

[Id: 106] access-list EZVPN-CLIENT_internet-list interface Ethernet0/0 refcount 0

[Id: 105] access-list EZVPN-CLIENT_enterprise-list pool EZVPN-CLIENT refcount 0

 pool EZVPN-CLIENT: netmask 255.255.255.0

        start 172.16.40.49 end 172.16.40.49

        type generic, total addresses 1, allocated 0 (0%), misses 0

 

Видно, что добавились автоматически два списка доступа. Посмотрим, какой тип трафика они определяют

VPN_Client#sh access-lists EZVPN-CLIENT_internet-list (не локальные сети пускать в инет)

Extended IP access list EZVPN-CLIENT_internet-list

    10 deny ip 192.168.2.0 0.0.0.255 192.168.1.0 0.0.0.255

    20 deny ip 192.168.2.0 0.0.0.255 2.2.2.0 0.0.0.255

    30 permit ip 192.168.2.0 0.0.0.255 any

!

VPN_Client#sh access-lists EZVPN-CLIENT_enterprise-list (локальные сети натить в назначенный IP)

Extended IP access list EZVPN-CLIENT_enterprise-list

    10 permit ip 192.168.2.0 0.0.0.255 192.168.1.0 0.0.0.255

    20 permit ip 192.168.2.0 0.0.0.255 2.2.2.0 0.0.0.255

 

GRE tunnel. OSPF over GRE

Gre представляет собой транспорт для многих типов остальных протоколов, будь то сигнальные сообщения динамических протоколов маршрутизации (OSPF, EIGRP) либо IPv6 пакеты. Данные пакеты инкапсулируются в еще один IP пакет (тип 47) с GRE заголовком. GRE прост в настройке, хотя и разработан первоначально Cisco, сейчас представляет собой открытый стандарт RFC 2784.

GRE туннель создает point-to-point линк со всеми вытекающими из этого проблемами масштабирования. В реальной сети это выливается в создании каждого туннеля для каждого удаленного офиса (маршрутизатора) с выделением отдельной подсети.

 

LNS#

interface Tunnel1

 ip address 10.3.7.3 255.255.255.0

 tunnel source Ethernet0/1

 tunnel destination 77.1.1.7

LAC#

interface Tunnel1

 ip address 10.3.7.7 255.255.255.0

 tunnel source Ethernet0/0

 tunnel destination 55.1.1.3

Если мы выбрали GRE, то воспользуемся сразу его преимуществом и настроим OSFP

LNS#

router ospf 1

network 10.3.9.0 0.0.0.255 area 0

 network 10.3.7.0 0.0.0.255 area 0

 network 192.168.1.0 0.0.0.255 area 0

LAC#

router ospf 1

network 10.3.7.0 0.0.0.255 area 0

network 172.30.1.0 0.0.0.255 area 0

 

Проверка работы OSPF

LAC#sh ip ospf neighbor

 

Neighbor ID     Pri   State           Dead Time   Address         Interface

3.3.3.3               0     FULL/  -        00:00:30     10.3.7.3         Tunnel1

 

Все маршруты, полученные через OSPF, теперь доступны через туннельный интерфейс.

 

LAC#sh ip route ospf

 

      10.3.9.0/8 is variably subnetted, 3 subnets, 2 masks

O        10.3.9.0/24 [110/2000] via 10.3.7.3, 00:19:02, Tunnel1 <- подсеть туннеля R3 <-> R9

      99.0.0.0/32 is subnetted, 1 subnets

O        99.99.99.99 [110/2001] via 10.3.7.3, 00:19:02, Tunnel1 <- loopback на R9

O     192.168.1.0/24 [110/1010] via 10.3.7.3, 00:19:02, Tunnel1 <- локальная сеть HQ

 

LAC#ping 192.168.1.1 source 172.30.1.7                 

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 192.168.1.1, timeout is 2 seconds:

Packet sent with a source address of 172.30.1.7

!!!!!

Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/1 ms

 

Формат пакета:

 

GRE over IPSec

LNS#

crypto isakmp policy 10

 encr 3des

 authentication pre-share

 group 2

!

crypto isakmp key ipseckey123 address 77.1.1.7

!

crypto ipsec transform-set ESP-AES256-SHA1 esp-aes 256 esp-sha-hmac

 mode transport

!

crypto map GREoverIPSec  5 ipsec-isakmp

 set peer 77.1.1.7

 set transform-set ESP-AES256-SHA1

 match address GRE

!

! Так как GRE помечается как тип трафика 47, то достаточно определить для шифрования весь  трафик по порту 47

ip access-list extended GRE

 permit gre any any

!

interface Ethernet0/1

 ip address 55.1.1.3 255.255.255.0

 crypto map GREoverIPSec

LAC#

crypto isakmp policy 10

 encr 3des

 authentication pre-share

 group 2

!

crypto isakmp key ipseckey123 address 55.1.1.3

!

crypto ipsec transform-set ESP-AES256-SHA1 esp-aes 256 esp-sha-hmac

 mode transport

!

crypto map GREoverIPSec 5 ipsec-isakmp

 set peer 55.1.1.3

 set transform-set ESP-AES256-SHA1

 match address GRE

!

!

ip access-list extended GRE

 permit gre any any

!

interface Ethernet0/0

 ip address 77.1.1.7 255.255.255.0

 crypto map GREoverIPSec

!

!

 

Проверка работы GRE over IPSec

LAC#ping 192.168.1.1 source 172.30.1.7

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 192.168.1.1, timeout is 2 seconds:

Packet sent with a source address of 172.30.1.7

!!!!!

Success rate is 100 percent (5/5), round-trip min/avg/max = 4/5/6 ms

 

Проверка сходимости IPSec

LAC#sh crypto isakmp sa

IPv4 Crypto ISAKMP SA

    dst                src                   state          conn-id   status

55.1.1.3        77.1.1.7        QM_IDLE           1001   ACTIVE

 

Проверка установления политик безопасности (SA)

LAC#sh crypto ipsec sa

 

interface: Ethernet0/0

    Crypto map tag: GREoverIPSec, local addr 77.1.1.7

 

   protected vrf: (none)

   local  ident (addr/mask/prot/port): (0.0.0.0/0.0.0.0/47/0)

   remote ident (addr/mask/prot/port): (0.0.0.0/0.0.0.0/47/0)

   current_peer 55.1.1.3 port 500

     PERMIT, flags={origin_is_acl,}

    #pkts encaps: 109, #pkts encrypt: 28559, #pkts digest: 28559

    #pkts decaps: 184, #pkts decrypt: 28784, #pkts verify: 28784

    #pkts compressed: 0, #pkts decompressed: 0

    #pkts not compressed: 0, #pkts compr. failed: 0

    #pkts not decompressed: 0, #pkts decompress failed: 0

    #send errors 0, #recv errors 0

 

     local crypto endpt.: 77.1.1.7, remote crypto endpt.: 55.1.1.3

     path mtu 1500, ip mtu 1500, ip mtu idb Ethernet0/0

     current outbound spi: 0xBCF71DA2(3170311586)

     PFS (Y/N): N, DH group: none

 

Формат пакета:

Работа OSPF over GRE over IPSec

OSPF работает в стандартной конфигурации (как в случае network type broadcast)

LAC#sh ip ospf neighbor

 

Neighbor ID     Pri   State           Dead Time   Address         Interface

     3.3.3.3           0    FULL/  -        00:00:31    10.3.7.3          Tunnel1

 

DMVPN

DMVPN реализует multipoint GRE архитектуру, позволяя использовать, во-первых, одно адресное пространство для всех vpn удаленных офисов, во-вторых, пропускать через туннель большой список сторонних протоколов, а также мультикаст, и в-третьих, устанавливать динамически туннели между региональными удаленными площадками в случае возникновения трафика между ними. Однако есть одно но, данная технология реализуема только на моновендорной сети на Cisco.

 

 

Настройка маршрутизатора HQ как DMVPN HUB, Spoke 1 как DMVPN Client

HUB#

interface Tunnel1

 description DMVPN_HUB

/// настройка mGRE

 ip address 10.5.5.1 255.255.255.0

 tunnel source FastEthernet0/0

 tunnel mode gre multipoint

 tunnel key 111001

 no ip redirects

 ip mtu 1416

 /// настройка NHRP

 ip nhrp map multicast dynamic

 ip nhrp network-id 101

 ip nhrp server-only

 

 ip tcp adjust-mss 1376

end

Spoke#

interface Tunnel1

ip address 10.5.5.3 255.255.255.0

 no ip redirects

 ip mtu 1416

 

 ip nhrp map multicast dynamic

 ip nhrp map multicast 192.168.1.1 (физ.адрес)

 ip nhrp map 10.5.5.1 192.168.1.1

 ip nhrp network-id 101

 ip nhrp nhs 10.5.5.1 (туннельный адрес)

 

 ip tcp adjust-mss 1380

 keepalive 10 3

 tunnel source FastEthernet0/0

 tunnel mode gre multipoint

 tunnel key 111001

end

 

Проверка работы DMVPN

Проверяем установился ли туннель до DMVPN HUBa.

Обращаем внимание, что NBMA address – реальный адрес HUBa.

Spoke#sh dmvpn

Legend: Attrb --> S - Static, D - Dynamic, I - Incomplete

        N - NATed, L - Local, X - No Socket

        # Ent --> Number of NHRP entries with same NBMA peer

        NHS Status: E --> Expecting Replies, R --> Responding, W --> Waiting

        UpDn Time --> Up or Down Time for a Tunnel

==========================================================================

 

Interface: Tunnel1, IPv4 NHRP Details

Type:Spoke, NHRP Peers:1,

 

 # Ent  Peer NBMA Addr   Peer Tunnel Add  State  UpDn Tm Attrb

 ----- --------------- --------------- ----- -------- -----

     1        192.168.1.1            10.5.5.254             UP  00:02:59     S

 

На HUBe видны два подключенных удаленных офиса:

 

HUB#sh dmvpn

Legend: Attrb --> S - Static, D - Dynamic, I - Incomplete

        N - NATed, L - Local, X - No Socket

        # Ent --> Number of NHRP entries with same NBMA peer

        NHS Status: E --> Expecting Replies, R --> Responding, W --> Waiting

        UpDn Time --> Up or Down Time for a Tunnel

==========================================================================

 

Interface: Tunnel1, IPv4 NHRP Details

Type:Hub, NHRP Peers:2,

 

 # Ent  Peer NBMA Addr  Peer Tunnel Add State  UpDn Tm Attrb

 ----- --------------- --------------- ----- -------- -----

     1       172.16.1.2             10.5.5.1               UP      00:04:08     D

     1       172.16.2.3             10.5.5.2               UP      00:02:57     D

 

Связка туннельного адреса и реального (физического)

HUB#sh ip nhrp brief

   Target                    Via                NBMA             Mode   Intfc   Claimed

10.5.5.1/32          10.5.5.1        172.16.1.2      dynamic  Tu1     <   >

10.5.5.2/32          10.5.5.2        172.16.2.3      dynamic  Tu1     <   >

 

Создание динамического GRE туннеля от удаленного офиса Spoke1 к Spoke2

Вначале загрузки у  Spoke 1 был только 1 туннель до HUBа. При генерировании трафика (пинга) до Spoke2, сразу же создался туннель до Spoke2

Router#ping 10.5.5.2

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 10.5.5.2, timeout is 2 seconds:

!!!!!

Success rate is 100 percent (5/5), round-trip min/avg/max = 1/4/5 ms

 

Смотрим установленные туннели на данный момент:

Router#sh dmvpn

Legend: Attrb --> S - Static, D - Dynamic, I - Incomplete

        N - NATed, L - Local, X - No Socket

        # Ent --> Number of NHRP entries with same NBMA peer

        NHS Status: E --> Expecting Replies, R --> Responding, W --> Waiting

        UpDn Time --> Up or Down Time for a Tunnel

==========================================================================

 

Interface: Tunnel1, IPv4 NHRP Details

Type:Spoke, NHRP Peers:2,

 

 # Ent  Peer NBMA Addr   Peer Tunnel Add    State  UpDn Tm Attrb

 ----- --------------- --------------- ----- -------- -----

     1        172.16.2.3                 10.5.5.2                UP    00:04:04     D

     1       192.168.1.1              10.5.5.254             UP    00:09:31     S

 

На данный момент схема сети (рис.13) будет уже выглядеть так:

 

Динамические протоколы маршрутизации через DMVPN

Настройка OSPF

Сделав настройки по DMVPN и включив общую сеть для VPN-а 10.5.5.0 в процесс OSPF – мы будем наблюдать как OSPF на HUBе будет устанавливать смежные отношения сначала со Spoke1 до того момента, как не получит hello пакет со Spoke2, после этого отношения рушатся с ошибкой Neighbor Down: Adjacency forced to reset, так как по умолчанию interface Tunnel выставлен как point-to-point интерфейс. Для корректной работы OSPF необходимо выставить network type как broadcast. Если выставить broadcast только на HUBe, то соседства установятся, но маршрутов через OSPF на Spok-aх не будет, поэтому необходимо выставить broadcast и на HUB, и на Spoke-ах.

Ниже приведены таблицы поведения OSPF в зависимости от выбранного значения network type.

HUB

Spoke 1

Spoke 2

BROADCAST

BROADCAST

BROADCAST

HUB#sh ip ospf neighbor

 

Neighbor I Pri            State            Dead Time   Address         Interface

1.1.1.1           0   FULL/DROTHER    00:00:34    10.5.5.1        Tunnel1

2.2.2.2           0   FULL/DROTHER    00:00:31    10.5.5.2        Tunnel1

 

Spoke_1#sh ip ospf neighbor

 

Neighbor ID     Pri   State           Dead Time   Address         Interface

10.0.0.1          1   FULL/DR         00:00:36    10.5.5.254      Tunnel1

 

Spoke_1#sh ip ospf neighbor

 

Neighbor ID     Pri   State            Dead Time   Address         Interface

10.0.0.1              1   FULL/DR         00:00:36    10.5.5.254      Tunnel1

 

Известные маршруты на Spoke 1 через OSPF

Spoke_1#sh ip route

 

Gateway of last resort is 172.16.1.5 to network 0.0.0.0

 

S*    0.0.0.0/0 [1/0] via 172.16.1.5

      1.0.0.0/32 is subnetted, 1 subnets

C        1.1.1.1 is directly connected, Loopback1

      2.0.0.0/32 is subnetted, 1 subnets

O        2.2.2.2 [110/1001] via 10.5.5.3, 00:00:07, Tunnel1 <- внутренняя сеть Spoke2

      10.0.0.0/8 is variably subnetted, 3 subnets, 2 masks

O        10.0.0.0/24 [110/1001] via 10.5.5.254, 00:05:19, Tunnel1 <- внутренняя сеть Центрального офиса

C        10.5.5.0/24 is directly connected, Tunnel1

L        10.5.5.1/32 is directly connected, Tunnel1

      172.16.0.0/16 is variably subnetted, 2 subnets, 2 masks

C        172.16.1.0/24 is directly connected, GigabitEthernet0/0

L        172.16.1.2/32 is directly connected, GigabitEthernet0/0

 

Связность между Spoke 1 и Spoke 2 осуществляется напрямую:

Spoke_1#traceroute 2.2.2.2 source 1.1.1.1

Type escape sequence to abort.

Tracing the route to 2.2.2.2

VRF info: (vrf in name/id, vrf out name/id)

  1 10.5.5.3 216 msec 256 msec 216 msec

 

DMVPN c EIGRP

HUB (R1)

Spoke (R3)

Spoke (R4)

По умолчанию, маршруты на Spoke только HUB (из-за split-horizon не видны маршруты Spoke 2)

HUB#sh ip route eigrp    

     1.0.0.0/8 is variably subnetted, 2 subnets, 2 masks

D       1.0.0.0/8 is a summary, 00:04:18, Null0

D    3.0.0.0/8 [90/409600] via 10.5.5.3, 00:04:24, Tunnel1

D    4.0.0.0/8 [90/409600] via 10.5.5.4, 00:03:51, Tunnel1

     10.0.0.0/8 is variably subnetted, 3 subnets, 2 masks

D       10.0.0.0/8 is a summary, 00:04:18, Null0

 

Нет маршрута до 4.4.4.4

Spoke_1#sh ip route eigrp

D    1.0.0.0/8 [90/324096] via 10.5.5.1, 00:04:04, Tunnel4

     3.0.0.0/8 is variably subnetted, 2 subnets, 2 masks

D       3.0.0.0/8 is a summary, 00:04:11, Null0

     10.0.0.0/8 is variably subnetted, 3 subnets, 2 masks

D       10.0.0.0/8 is a summary, 00:04:11, Null0

Выключаем на HUBe split-horizon

HUB (R1)

Spoke (R3)

Spoke (R4)

HUB(conf)#

router eigrp 1

no ip split-horizon eigrp 1

Нет доп.настройки

Нет доп.настройки

HUB#sh ip route eigrp    

     1.0.0.0/8 is variably subnetted, 2 subnets, 2 masks

D       1.0.0.0/8 is a summary, 00:04:18, Null0

D    3.0.0.0/8 [90/409600] via 10.5.5.3, 00:04:24, Tunnel101

D    4.0.0.0/8 [90/409600] via 10.5.5.4, 00:03:51, Tunnel101

     10.0.0.0/8 is variably subnetted, 3 subnets, 2 masks

D       10.0.0.0/8 is a summary, 00:04:18, Null0

 

Маршрут на Spoke1 появился, но ведет через HUB

Spoke_1#sh ip route eigrp

D    1.0.0.0/8 [90/324096] via 10.5.5.1, 00:05:45, Tunnel4

     3.0.0.0/8 is variably subnetted, 2 subnets, 2 masks

D       3.0.0.0/8 is a summary, 00:00:26, Null0

D    4.0.0.0/8 [90/435200] via 10.5.5.1, 00:00:26, Tunnel4

     10.0.0.0/8 is variably subnetted, 3 subnets, 2 masks

D       10.0.0.0/8 is a summary, 00:05:51, Null0

 

R3#traceroute 4.4.4.4 source 3.3.3.3

Type escape sequence to abort.

Tracing the route to 4.4.4.4

  1 10.5.5.1 88 msec 92 msec 76 msec

  2 10.5.5.4 128 msec *  140 msec

Избавимся от HUB-а как промежуточного устройства в связности Spoke1 <-> Spoke2

HUB (R1)

Spoke (R3)

Spoke (R4)

HUB(conf)#

router eigrp 1

no ip split-horizon eigrp 1

no ip next-hop-self eigrp 1

Нет доп.настройки

Нет доп.настройки

Теперь маршрут до сети Spoke_2 ведет напрямую:

R3#sh ip route eigrp 1

D    1.0.0.0/8 [90/324096] via 10.5.5.1, 00:00:06, Tunnel4

     3.0.0.0/8 is variably subnetted, 2 subnets, 2 masks

D       3.0.0.0/8 is a summary, 00:00:06, Null0

D    4.0.0.0/8 [90/435200] via 10.5.5.4, 00:00:04, Tunnel4

     10.0.0.0/8 is variably subnetted, 3 subnets, 2 masks

D       10.0.0.0/8 is a summary, 00:19:55, Null0

 

R3#traceroute 4.4.4.4 source 3.3.3.3

Type escape sequence to abort.

Tracing the route to 4.4.4.4

  1 10.5.5.4 84 msec *  72 msec

 

PPTP

PPTP стал совместной разработкой консорциумов Microsoft, 3Com, Ascend Communication. Хорошо масштабируемый протокол. Может использоваться для соединения офисов по типу точка-точка, но, больше всего подходит для организации удаленного подключения по архитектуре клиент-сервер. Достаточно настроить центральный PPTP VPN HUB, а удаленные пользователи подключаются через PPTP клиент, который внедрен во всех OC Windows, в том числе MacOS и Linux-дистрибутивах.

Существуют криптографические проблемы в протоколе аутентификации MSCHAPv2 [https://technet.microsoft.com/ru-ru/library/security/2743314.aspx] , поэтому в большинстве случаев рекомендовано использование даже на той же самой OC Windows протокола L2TP over IPSec вместо PPTP.

В качестве средств шифрования используется только один протокол шифрования Microsoft Point-to-Point Encryption (128битный ключ), в качестве аутентификации – MSCHAPv2, PEAP (рекомендовано).

PPTP в процессе своей работы устанавливает 2 сессии: PPP сессию с использованием GRE протокола и TCP соединение по порту 1723 для обслуживания PPTP сессии.

Установление TCP сессии перед установлением PPP соединения

 

 

Формат PPP пакета (рис.15)

 

PPTP_HUB #

Username cisco2 password cisco2

!

interface Loopback1

 ip address 192.168.2.2 255.255.255.0

!

vpdn enable

!

vpdn-group 1

 ! Default PPTP VPDN group

 accept-dialin

  protocol pptp

  virtual-template 1

!

interface Virtual-Template1

 ip unnumbered Loopback1

 ip mtu 1400

 ip tcp adjust-mss 1360

 peer default ip address pool PPTP-Pool

 ppp encrypt mppe auto

 ppp authentication ms-chap-v2 chap callin

!

ip local pool PPTP-Pool 192.168.2.5 192.168.2.50

!

Проверка установленных PPTP соединений.

Пользователь cisco2 авторизован и сессия установлена.

PPTP_HUB #sho vpdn session

%No active L2TP tunnels

PPTP Session Information Total tunnels 1 sessions 1

LocID RemID TunID Intf    Username      State   Last Chg Uniq ID

55592     0     17168 Vi3        cisco2        estabd  00:04:13      6       

Пользователю выдан ip адрес из DHCP Pool-а и создан virtual-access

PPTP_HUB#sh ip int br

   Interface              IP-Address   OK? Method            Status               Protocol

 Ethernet0/0           unassigned   YES NVRAM administratively down down

GigabitEthernet0/0 192.168.1.3 YES NVRAM            up                       up

GigabitEthernet1/0  77.1.1.3      YES NVRAM            up                       up

 Loopback0              3.3.3.3       YES NVRAM             up                       up

 Loopback1           192.168.2.2  YES NVRAM             up                       up

Virtual-Access1    unassigned   YES   unset                down                 down

Virtual-Access2    unassigned   YES   unset                  up                       up

Virtual-Access3    192.168.2.5  YES   unset                  up                       up

Virtual-Template1 192.168.2.5 YES   unset               down                   down

 

В случае если возникает задача конкретному PPTP клиенту выдавать принадлежащий только ему IP адрес, то тогда можно прибегнуть к созданию TXT файла с перечислением всех PPTP клиентов.

Настройка на маршрутизаторе:

ip dhcp pool STATIC

   import all

   origin file flash:/static2.txt

   default-router 192.168.2.2

   dns-server 8.8.8.8 8.8.4.4

   domain-name lab.local

   lease 3

!

interface Virtual-Template1

 ip unnumbered Loopback1

 ip mtu 1400

 ip tcp adjust-mss 1360

 peer default ip address pool STATIC (PPTP-Pool нам уже не нужен)

 ppp encrypt mppe auto

 ppp authentication ms-chap-v2 chap callin

 

Сам TXT файлик static2.txt.

*time* Mar 01 2002 12:23 AM

*version* 2

!IP address Type Hardware address Lease expiration VRF

192.168.2.77 /25 1000c.2984.4f84Infinite

192.168.2.17 /25 1000c.2946.1575Infinite

192.168.2.18 /25 10000.0000.1111Infinite

 

L2TP

L2TP – это стандарт IETF, который вобрал в себя лучшее от протокола L2F от Cisco и PPTP от Microsoft. Не предлагает средств по защите данных, поэтому часто используется с IPSec.

L2TP – один из немногих представителей VPN протоколов (к тому же доступный для внедрения в корпоративной сети), который может предложить технологию pseudowire – проброс native vlan-а через L3 сеть. Технологию pseudowire поддерживает только L2TP version 3. Кроме этого L2TPv3 поддерживает следующие L2-протоколы, данные (payloads) которых могут прозрачно передаваться через псевдо-туннель L2TPv3:

  • Ethernet

  • Ethernet VLAN (802.1q)

  • HDLC

  • PPP

  • MPLS

Главное отличие L2TPv3 перед L2TPv2 это то, что L2TPv3 может туннелировать различный тип трафика (см. выше), в то время как v2 только PPP.

L2TPv3 использует два типа сообщений:

  • Сигнальные (Control Connection)

  • Для данных (Session data)

L2TPv3 сигнальные сообщения так и сообщения с данными могут быть перенесены через IP (protocol ID 115), т.е. L2TPv3 использует меньший overhead

IP_add_s_global        IP_add_d_global

Type 115

L2TP_header

L2_sublayer

Data

 L2TPv2 инкапсулирует данные в IP/UDP (UDP порт 1701).

IP_add_s_global          IP_add_d_global

UDP_s_port              UDP_d_port(1701)

L2TP_header

PPP_header

IP_add_s_local               IP_add_d_local

Data

 

L2TPv3 Pseudowire

В архитектуре L2TP, равно как и в архитектуре PPTP, используются следующие понятия:

LAC

L2TP access concentrator

LAC принимает на себя запросы от клиента и согласует L2TP параметры туннелей и сессий с LNS и передает запрос LNS

LNS

L2TP network server

LNS согласует L2TP параметры туннелей и сессий с LAC

LCCE

L2TP Control Connection Endpoint

Это LAC, который участвует в сигнальном соединении.

Модель работы протоколов для L2TPv3 LNS – LNS, а для L2TPv2 LAC – LNS  (подробнее см.ниже).

Создадим pseudowire между R5 в Центральном офисе и в R9 в региональном офисе, тем самым расширим сеть 192.168.1.x/24 в региональный офис.

 

 

R5#

pseudowire-class L2TP_Class

 encapsulation l2tpv3

 protocol none (то есть не используется динамическое установление сессии)

 ip pmtu

 ip local interface GigabitEthernet1/0

!

interface GigabitEthernet0/0

 no ip address

 xconnect 44.1.1.9 1 encapsulation l2tpv3 manual pw-class L2TP_Class

  l2tp id 1 2

l2tp cookie local 4 55111

l2tp cookie remote 44119

R9#

pseudowire-class L2TP_Class

 encapsulation l2tpv3

 protocol none (то есть не используется динамическое установление сессии)

 ip pmtu

 ip local interface GigabitEthernet0/0

!

interface GigabitEthernet1/0

 no ip address

 xconnect 55.1.1.1 1 encapsulation l2tpv3 manual pw-class L2TP_Class

  l2tp id 2 1

l2tp cookie local 4 44119

l2tp cookie remote 4 55111

 

Проверка установления сессии:

R5_VPN_HUB_Pr#sh l2tp session 

 

L2TP Session Information Total tunnels 0 sessions 1

 

LocID      RemID      TunID      Username, Intf/      State  Last Chg Uniq ID  

                                                       Vcid, Circuit                                 

    1               2             n/a               1, Gi0/0               est      00:00:03   1        

 

R5_VPN_HUB_Pr#sh l2tp session all

 

L2TP Session Information Total tunnels 0 sessions 1

 

Session id 1 is up, logical session id 33356, tunnel id n/a      

  Remote session id is 2, remote tunnel id n/a      

  Locally initiated session

  Unique ID is 4

Session Layer 2 circuit, type is Ethernet, name is GigabitEthernet0/0

  Session vcid is 1

  Circuit state is UP

    Local circuit state is UP

    Remote circuit state is UP

Call serial number is 0

Remote tunnel name is

  Internet address is 44.1.1.9

Local tunnel name is

  Internet address is 55.1.1.5

IP protocol 115

  Session is manually signaled

  Session state is established, time since change 02:29:58

    1130 Packets sent, 1982 received

    151213 Bytes sent, 197759 received

  Last clearing of counters never

 

R7 теперь доступен без протоколов маршрутизации:

R10#ping 192.168.1.7 repeat 10

Type escape sequence to abort.

Sending 10, 100-byte ICMP Echos to 192.168.1.7, timeout is 2 seconds:

!!!!!!!!!!

Success rate is 100 percent (10/10), round-trip min/avg/max = 128/142/180 ms

 

Работа OSPF через L2TP

Соседство установилось по умолчанию, включив сеть 192.168.1.0 на R7 и R10

R7_DATA_Center_Servers#sh ip ospf neighbor

 

Neighbor ID      Pri    State            Dead Time    Address           Interface

192.168.1.10      1   FULL/DR         00:00:37    192.168.1.10    GigabitEthernet0/0

 

R10#sh ip ospf neighbor

 

Neighbor ID     Pri   State            Dead Time     Address               Interface

    7.7.7.7           1   FULL/BDR        00:00:35    192.168.1.7     GigabitEthernet0/0

 

Недостатки:

Если L2TP создается на маршрутизаторе как в нашем примере, то через pseudowire соединения не пройдут следующие L2 PDU: CDP, STP, VTP, LLDP. Для туннелирования таких протоколов необходимо создавать L2TPv3 туннель на L3 коммутаторе.

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

L2 VPN работает в двух режимах:

  • обязательный туннельный режим

  • добровольный (опциональный) туннельный режим.

Обязательный туннельный режим относится к провайдер-определяемым (provider provisioning) и в таком режиме работают протоколы L2F, PPTP, L2TP. В обязательном туннельном режиме через L2TP удаленные пользователи подключаются к LAC по обычному PPP соединению, LAC их терминирует на себя и туннелирует PPP сессии к LNS. Причем удаленный пользователь даже не подозревает об L2TP.

 

 

В добровольном /клиентском инициированном туннеле удаленный хост действует как LAC, то есть он согласует и устанавливает L2TP сессию непосредственно с LNS.

 

 

 

В нашем примере Cisco R9 (44.1.1.9) будет действовать как LAC и устанавливать L2TP соединение с Cisco R5 в ЦОДе (55.1.1.1), которая будет выступать в роли LNS.

 

 

*Oct 20 19:52:55.861: L2X  tnl   08287:________: Create logical tunnel

*Oct 20 19:52:55.865: L2TP tnl   08287:________: Create tunnel

*Oct 20 19:52:55.869: L2TP tnl   08287:________:     version set to V2 (протокол L2TPv2)

*Oct 20 19:52:55.873: L2TP tnl   08287:________:     remote ip set to 44.1.1.9

*Oct 20 19:52:55.873: L2TP tnl   08287:________:     local ip set to 55.1.1.1

*Oct 20 19:52:55.877: L2TP tnl   08287:00003073: FSM-CC ev Rx-SCCRQ

(Start-Control-Connection-Request) LNS проверяет валидность отправителя и наличие собственных ресурсов, также на этом этапе согласуется список поддерживаемых типов pseudowire (Ethernet, Frame Relay)

*Oct 20 19:52:55.877: L2TP tnl   08287:00003073: FSM-CC    Idle->Proc-SCCRQ

*Oct 20 19:52:55.877: L2TP tnl   08287:00003073: FSM-CC do Rx-SCCRQ

*Oct 20 19:52:55.881: L2X        _____:________: Tunnel author started for LAC

*Oct 20 19:52:55.901: L2X        _____:________: Tunnel author found

*Oct 20 19:52:55.905: L2TP tnl   08287:00003073: Author reply, data source: "VPDN-L2TP"

*Oct 20 19:52:55.909: L2X        _____:________: class [AAA author, group "VPDN-L2TP"]

*Oct 20 19:52:55.913: L2X        _____:________:   created

*Oct 20 19:52:55.917: L2TP tnl   08287:00003073: FSM-CC ev SCCRQ-OK

*Oct 20 19:52:55.917: L2TP tnl   08287:00003073: FSM-CC    Proc-SCCRQ->Wt-SCCCN

Start-Control-Connection-Connected (SCCCN) ожидаем состояния Connected

*Oct 20 19:52:55.917: L2TP tnl   08287:00003073: FSM-CC do Tx-SCCRP

Start-Control-Connection-Reply (SCCRP) отправили ответное сообщение

*Oct 20 19:52:55.917: L2X        _____:________: l2x_open_socket: is called

*Oct 20 19:52:55.921: L2TP tnl   08287:00003073: Open sock 55.1.1.1:1701->44.1.1.9:1701

Используется UDP с портом 1701 для служебных сообщений

*Oct 20 19:52:55.925: L2TP tnl   08287:00003073: FSM-CC ev Sock-Ready

*Oct 20 19:52:55.929: L2TP tnl   08287:00003073: FSM-CC    in Wt-SCCCN

*Oct 20 19:52:55.929: L2TP tnl   08287:00003073: FSM-CC do Ignore-Sock-Up

*Oct 20 19:52:55.941: L2X        _____:________: Disabled security for VPDN

*Oct 20 19:52:56.053: L2TP tnl   08287:00003073: FSM-CC ev Rx-SCCCN

*Oct 20 19:52:56.053: L2TP tnl   08287:00003073: FSM-CC    Wt-SCCCN->Proc-SCCCN

*Oct 20 19:52:56.053: L2TP tnl   08287:00003073: FSM-CC do Rx-SCCCN

*Oct 20 19:52:56.053: L2TP tnl   08287:00003073: Got a response in SCCCN from LAC

*Oct 20 19:52:56.057: L2TP tnl   08287:00003073: Tunnel Authentication success

*Oct 20 19:52:56.061: L2TP tnl   08287:00003073: FSM-CC ev SCCCN-OK

*Oct 20 19:52:56.065: L2TP tnl   08287:00003073: FSM-CC    Proc-SCCCN->established

*Oct 20 19:52:56.069: L2TP tnl   08287:00003073: FSM-CC do Established

*Oct 20 19:52:56.073: L2TP tnl   08287:00003073: Control channel up

*Oct 20 19:52:56.077: L2TP tnl   08287:00003073:   55.1.1.1<->44.1.1.9

 

Служебный канал установился, теперь устанавливается канал для данных (PPP фреймов).

Стоит отметить, что по одному установившемуся туннелю может проходить множество клиентских сессий.

 

Для установки сессии для данных LAC отправляет ICRQ (Call-Request), если на LNS достаточно ресурсов, то LNS отвечает сообщением ICRP (Call-Reply). Для завершения установления сессии – LAC отправляет ICCN Incoming-Call-Connected.

*Oct 20 19:52:56.117: L2X  _____:_____:________: Create logical session

*Oct 20 19:52:56.121: L2TP _____:_____:________: Create session

*Oct 20 19:52:56.121: L2TP _____:_____:________:   Using ICRQ FSM

Incoming-Call-Request (ICRQ) Здесь передается требуемый pseudowire тип, требуемый для уровня L2

*Oct 20 19:52:56.125: L2TP _____:_____:________:     remote ip set to 44.1.1.9

*Oct 20 19:52:56.125: L2TP _____:_____:________:     local ip set to 55.1.1.1

*Oct 20 19:52:56.129: L2TP tnl   08287:00003073: FSM-CC ev Session-Conn

*Oct 20 19:52:56.129: L2TP tnl   08287:00003073: FSM-CC    in established

*Oct 20 19:52:56.129: L2TP tnl   08287:00003073: FSM-CC do Session-Conn-Est

*Oct 20 19:52:56.129: L2TP tnl   08287:00003073:   Session count now 1

*Oct 20 19:52:56.129: L2TP _____:08287:0000754C: Session attached

*Oct 20 19:52:56.129: L2TP _____:08287:0000754C: FSM-Sn ev Rx-ICRQ

*Oct 20 19:52:56.129: L2TP _____:08287:0000754C: FSM-Sn    Idle->Proc-ICRQ

*Oct 20 19:52:56.129: L2TP _____:08287:0000754C: FSM-Sn do Rx-ICRQ

*Oct 20 19:52:56.129: L2TP _____:08287:0000754C:   Chose application VPDN

*Oct 20 19:52:56.133: L2TP _____:08287:0000754C:   App type set to VPDN

*Oct 20 19:52:56.133: L2TP tnl   08287:00003073:   VPDN Session count now 1

*Oct 20 19:52:56.189: L2TP 00005:08287:0000754C: FSM-Sn ev ICRQ-OK

*Oct 20 19:52:56.193: L2TP 00005:08287:0000754C: FSM-Sn    Proc-ICRQ->Wt-Tx-ICRP

*Oct 20 19:52:56.193: L2TP 00005:08287:0000754C: FSM-Sn do Tx-ICRP-Local-Check

*Oct 20 19:52:56.193: L2TP 00005:08287:0000754C: FSM-Sn ev Local-Cont

*Oct 20 19:52:56.193: L2TP 00005:08287:0000754C: FSM-Sn    Wt-Tx-ICRP->Wt-Rx-ICCN

*Oct 20 19:52:56.193: L2TP 00005:08287:0000754C: FSM-Sn do Tx-ICRP

Incoming-Call-Reply (ICRP)

*Oct 20 19:52:56.197: L2TP 00005:08287:0000754C: Open sock 55.1.1.1:1701->44.1.1.9:1701

*Oct 20 19:52:56.197: L2TP 00005:08287:0000754C: FSM-Sn    in Wt-Rx-ICCN    (ожидаем ICCN)

*Oct 20 19:52:56.397: L2TP 00005:08287:0000754C: FSM-Sn ev Rx-ICCN             (ICCN получили)

*Oct 20 19:52:56.401: L2TP 00005:08287:0000754C: FSM-Sn    Wt-Rx-ICCN->Proc-ICCN

*Oct 20 19:52:56.405: L2TP 00005:08287:0000754C: FSM-Sn do Rx-ICCN

*Oct 20 19:52:56.437: L2TP 00005:08287:0000754C: FSM-Sn ev ICCN-OK

*Oct 20 19:52:56.441: L2TP 00005:08287:0000754C: FSM-Sn    Proc-ICCN->established

*Oct 20 19:52:56.445: L2TP 00005:08287:0000754C: FSM-Sn do Established

*Oct 20 19:52:56.449: L2TP 00005:08287:0000754C: Session up      (Ceccия для данных установилась)

*Oct 20 19:52:58.197: L2TP 00005:08287:0000754C: FSM-Sn    in established

*Oct 20 19:52:58.241: %LINEPROTO-5-UPDOWN: Line protocol on Interface Virtual-Access3, changed state to up

*Oct 20 19:52:58.273: %LINK-3-UPDOWN: Interface Virtual-Access3, changed state to up

 

В нашем примере сформировался один туннель между LAS и LNS и одна пользовательская сессия.

ISP_NAT#sh l2tun tunnel

L2TP Tunnel Information Total tunnels 1 sessions 1

LocTunID   RemTunID   Remote Name   State  Remote Address  Sessn L2TP Class/

                                                                                                         Count VPDN Group

30933              12403                  LNS            est            55.1.1.1               1     1             

 

ISP_NAT#sh l2tp session      

L2TP Session Information Total tunnels 1 sessions 1

LocID      RemID      TunID      Username, Intf/      State  Last Chg       Uniq ID  

                                                     Vcid, Circuit                                 

32700      30028      30933           LNS, Vi1                est      00:51:35       0        

Настройка L2TP в добровольном туннельном режиме очень похожа в настройке с обязательным туннельным режимом. Различие в настройке VPDN группы следующее:

  • Команда terminate-from не нужна
  • Аутентификация L2TP туннеля выключена командой no l2tp tunnel authentication
 

Настройка L2TPv2

На некоторых типах маршрутизаторов нельзя создать interface virtual-ppp, поэтому привожу в качестве альтернативны другую рабочую конфигурацию через создание interface Dialer. Конфигурация предоставляется «AS IS».

LNS#

aaa new-model

aaa authorization network default local

!

vpdn enable

vpdn-group VPDN-L2TP

 accept-dialin

  protocol l2tp

  virtual-template 2

 lcp renegotiation on-mismatch

 terminate-from hostname LAC

 l2tp tunnel password 0 cisco123

 ip pmtu

!

interface Virtual-Template2

 ip unnumbered GigabitEthernet0/0

 autodetect encapsulation ppp

 peer default ip address pool L2TP-pool

 ppp authentication ms-chap-v2

LAC#

vpdn enable

!

vpdn-group 1

 request-dialin

  protocol l2tp

  pool-member 1

 initiate-to ip 55.1.1.1

 source-ip 44.1.1.9

 local name LAC (имя должно совпадать с terminate-from на LNS)

 l2tp tunnel password 0 cisco123

!

interface Dialer1

 ip address negotiated

 encapsulation ppp

 dialer pool 1

 dialer idle-timeout 0

 dialer string 123

 dialer vpdn

 dialer-group 1

 ppp authentication chap callin

 ppp chap hostname LNC

 ppp chap password 0 cisco123

!

ip route 192.168.1.0 255.255.255.0 Dialer1

 

Конфигурация L2TPv2 через interface virtual-ppp

 

 

LNS#

aaa new-model

!

aaa authorization network default local

!

username LAC password 0 cisco123

!

vpdn enable

vpdn-group VPDN-L2TP

accept-dialin

protocol l2tp

virtual-template 2

terminate-from hostname LAC

l2tp tunnel password 0 cisco123

!

interface Loopback0

ip address 3.3.3.3 255.255.255.255

!

interface Virtual-Template2

ip unnumbered Loopback0

autodetect encapsulation ppp

no peer default ip address

ppp authentication ms-chap-v2

!

ip route 172.30.1.0 255.255.255.0 7.7.7.7

!добавляем статический маршрут до сети удаленного офиса R7

(P.S. маршрут до 7.7.7.7 добавляется автоматически при установлении сессии

LNS#show ip route

7.0.0.0/32 is subnetted, 1 subnets

C 7.7.7.7 is directly connected, Virtual-Access3 )

LAC#

username LNS password 0 cisco123

!

l2tp-class client.init.class

authentication

password cisco123

!

pseudowire-class pwclass1

encapsulation l2tpv2

protocol l2tpv2 client.init.class

ip local interface Ethernet0/0

!

interface Loopback0

ip address 7.7.7.7 255.255.255.255

!

interface Virtual-PPP1

ip unnumbered loopback0

ppp authentication ms-chap-v2

no cdp enable

pseudowire 55.1.1.3 1 pw-class pwclass1

!

ip route 192.168.1.0 255.255.255.0 Virtual-PPP1

!добавляем статический маршрут до ЦО

(P.S. маршрут до 3.3.3.3 добавляется автоматически при установлении сессии

3.0.0.0/32 is subnetted, 1 subnets

C 3.3.3.3 is directly connected, Virtual-PPP1 )

 

Проверка установления туннеля и заодно проверяем работу сессии через пинг с внутренней сети удаленного клиента (LAC) и просмотра статистики сессионных пакетов на L2TP HUBe (LNS)

 

LNS#show vpdn

L2TP Tunnel and Session Information Total tunnels 1 sessions 1

LocTunID RemTunID Remote Name State Remote Address Sessn L2TP Class/

Count VPDN Group

60224 63290 LAC est 77.1.1.7 1 VPDN-L2TP

LocID RemID TunID Username, Intf/ State Last Chg Uniq ID

Vcid, Circuit

46580 40688 60224 LAC, Vi3 est 00:14:12 102

LAC#sho vpdn

L2TP Tunnel and Session Information Total tunnels 1 sessions 1

LocTunID RemTunID Remote Name State Remote Address Sessn L2TP Class/

Count VPDN Group

63290 60224 LNS est 55.1.1.3 1 client.init.cla

LocID RemID TunID Username, Intf/ State Last Chg Uniq ID

Vcid, Circuit

40688 46580 63290 1, Vp1 est 00:20:54 8

LNS#sh caller user LAC

User: LAC, line Vi3, service PPPoVPDN

Connected for 00:03:34, Idle for 00:00:04

Timeouts: Limit Remaining Timer Type

- - -

PPP: LCP Open, MS CHAP V2 (<-->), IPCP

IP: Local 3.3.3.3, remote 7.7.7.7

Counts: 101 packets input, 2932 bytes, 0 no buffer

0 input errors, 0 CRC, 0 frame, 0 overrun

78 packets output, 3770 bytes, 0 underruns

0 output errors, 0 collisions, 0 interface resets

<после прохождения всех ping-ов проверяем вновь>

LNS#sh caller user LAC

User: LAC, line Vi3, service PPPoVPDN

Connected for 00:03:40, Idle for 00:00:02

Timeouts: Limit Remaining Timer Type

- - -

PPP: LCP Open, MS CHAP V2 (<-->), IPCP

IP: Local 3.3.3.3, remote 7.7.7.7

Counts: 201 packets input, 13332 bytes, 0 no buffer

0 input errors, 0 CRC, 0 frame, 0 overrun

179 packets output, 15650 bytes, 0 underruns

0 output errors, 0 collisions, 0 interface resets

Проверяем доступность сети Центрального офиса (LNS) с R7

LAC#ping 192.168.1.1 source 172.30.1.7 repeat 100

Type escape sequence to abort.

Sending 100, 100-byte ICMP Echos to 192.168.1.1, timeout is 2 seconds:

Packet sent with a source address of 172.30.1.7

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

Success rate is 100 percent (100/100), round-trip min/avg/max = 1/4/6 ms

 

Формат пакета L2TPv2

Overhead UDP (8байт) + L2TPv2 (8байт) + PPP (4 байта) +IPv4 (20 байт) = 40байт

 

Работа OSPF через L2TPv2

OSPF работает словно через broadcast сеть

LNS#

router ospf 1

 network 3.3.3.3 0.0.0.0 area 0

 network 192.168.1.0 0.0.0.255 area 0

 default-information originate always

Объявим сеть 3.3.3.3 в ospf area 0

LAC#

interface Loopback1

 ip address 77.77.77.77 255.255.255.255

!

router ospf 1

 network 3.3.3.3 0.0.0.0 area 0

network 77.77.77.77 0.0.0.0 area 0

 

LSA протокола OSPF через L2TPv2

Обратите, пожалуйста, внимание на получившийся overhead.

 

Overhead UDP (8байт) + L2TPv2 (8байт) + PPP (4 байта) +IPv4 (20 байт) = 40байт

Проверка установленного соседства

LNS#sh ip ospf neighbor

 

Neighbor ID     Pri   State           Dead Time   Address         Interface

    7.7.7.7            0   FULL/  -        00:00:30       7.7.7.7         Virtual-Access3

 

LAC#sh ip ospf neighbor

 

Neighbor ID     Pri   State           Dead Time   Address         Interface

   3.3.3.3            0   FULL/  -           00:00:35    3.3.3.3         Virtual-PPP1

 

Настройка для L2TPv3

 

Настройка L2TPv3 практически ничем не отличается на удаленных клиентах, в то время как настройка на VPN HUB-е отличается очень разительно.

LNS#

username LAC password 0 cisco123

!

pseudowire-class client.init.pw

 encapsulation l2tpv3

 protocol l2tpv3 client.inint.class

 ip local interface Ethernet0/1

 !

interface Virtual-PPP1

 ip unnumbered Loopback0

 ppp authentication ms-chap-v2

 pseudowire 77.1.1.7 1 pw-class client.init.pw

!

interface Loopback0

 ip address 3.3.3.3 255.255.255.255

!

interface Virtual-PPP1

 ip unnumbered Loopback0

ppp authentication ms-chap-v2

 pseudowire 77.1.1.7 1 pw-class client.init.pw

!

ip route 172.30.1.0 255.255.255.0 Virtual-PPP1

LAC#

username LNS password 0 cisco123

!

pseudowire-class pwclass2

 encapsulation l2tpv3

 protocol l2tpv3 client.init.class

 ip local interface Ethernet0/0

!

interface Virtual-PPP1

 ip address negotiated

 ppp authentication ms-chap-v2

 no cdp enable

 pseudowire 55.1.1.3 1 pw-class pwclass2

!

ip route 192.168.1.0 255.255.255.0 Virtual-PPP1

 

Проверка установленной L2TPv3 сессии на LNS

LNS#show vpdn

 

L2TP Tunnel  and Session Information Total tunnels 1 sessions 1

 

LocTunID        RemTunID   Remote Name   State  Remote Address  Sessn L2TP Class/

                                                                                                                   Count VPDN Group

4168123058 3050381103              LAC           est           77.1.1.7             1     client.inint.cl

 

     LocID             RemID         TunID        Username, Intf/      State  Last Chg Uniq ID  

                                                                     Vcid, Circuit                                 

2122433254    2810410257   4168123058           1, Vp1            est        00:16:22      53       

 

Сессия в состояние established, туннельные ID совпадают

 

Проверка установленной L2TPv3 сессии на LAC

LAC#show vpdn

L2TP Tunnel and Session Information Total tunnels 1 sessions 1

LocTunID   RemTunID   Remote Name   State  Remote Address  Sessn L2TP Class/

                                                                                                         Count VPDN Group

3050381103 4168123058          LNS           est    55.1.1.3        1     client.init.cla

 

     LocID               RemID       TunID        Username, Intf/      State  Last Chg Uniq ID  

                                                                           Vcid, Circuit                                 

 2810410257      2122433254 3050381103      1, Vp1               est        00:15:57        5        

 

Формат пакета L2TPv3

Overhead L2TPv3 (4байта) + HDLC (4байта) = 8 байт

Проверяем работу сессии через пинг с внутренней сети удаленного клиента (LAC) и просмотра статистики сессионных пакетов на L2TP HUBe (LNS)

Проверка установления L2TPv3 сессии

LNS#show caller user LAC

 

  User: LAC, line Vp1, service PPP

        Connected for 00:01:52, Idle for 00:01:52

  Timeouts:    Limit     Remaining Timer Type

               -         -         -        

  PPP: LCP Open, MS CHAP V2 (<-->), IPCP

  IP: Local 3.3.3.3, remote 7.7.7.7

  Counts: 1241 packets input, 74748 bytes, 0 no buffer

          0 input errors, 0 CRC, 0 frame, 0 overrun

          1078 packets output, 78056 bytes, 0 underruns

          0 output errors, 0 collisions, 0 interface resets

 

<после прохождения всех ping-ов проверяем вновь>

LNS#show caller user LAC

 

  User: LAC, line Vp1, service PPP

        Connected for 00:02:02, Idle for 00:02:02

  Timeouts:    Limit     Remaining Timer Type

               -         -         -        

  PPP: LCP Open, MS CHAP V2 (<-->), IPCP

  IP: Local 3.3.3.3, remote 7.7.7.7

  Counts: 1343 packets input, 84976 bytes, 0 no buffer

          0 input errors, 0 CRC, 0 frame, 0 overrun

          1180 packets output, 88552 bytes, 0 underruns

          0 output errors, 0 collisions, 0 interface resets

Пропингуем 100 пакетов удаленной сети через туннель

LAC#ping 192.168.1.1 source 172.30.1.7 repeat 100

Type escape sequence to abort.

Sending 100, 100-byte ICMP Echos to 192.168.1.1, timeout is 2 seconds:

Packet sent with a source address of 172.30.1.7

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

Success rate is 100 percent (100/100), round-trip min/avg/max = 2/4/29 ms

 

L2TPv2 over IPSec

Протокол L2TP не обеспечивает защищенность передаваемых по нему данных, поэтому для обеспечения целостности и конфиденциальности данных используем набор протоколов IPSec. Из средств безопасности L2TP может предложить аутентификацию хоста, инициализирующего туннель, а также PPP аутентификацию. Так как в нашем примере использован протокол L2TPv2, который использует IP/UDP инкапсуляцию, то достаточно в крипто ACL определить лишь UDP трафик по порту 1701. В настройке IPSec используется транспортный режим, а не туннельный, чтобы шифровать трафик от оконечного клиента оконечному (в транспортном режиме), нежели создавать дополнительные IP туннельные интерфейсы и шифровать трафик только между ними (в туннельном режиме).

 

 

Схема сети:

LNS#

crypto isakmp policy 10

 encr 3des

 authentication pre-share

 group 2

!

crypto isakmp key ipseckey123 address 77.1.1.7

!

crypto ipsec transform-set ESP-AES256-SHA1 esp-aes 256 esp-sha-hmac

 mode transport

!

crypto map L2TP_VPN 10 ipsec-isakmp

 set peer 77.1.1.7

 set transform-set ESP-AES256-SHA1

 match address L2TP_TRAFFIC

!

! Так как мы используем L2TPv2, то достаточно !определить для шифрования весь UDP трафик !по порту 1701

ip access-list extended L2TP_TRAFFIC

 permit udp host 55.1.1.3 eq 1701 host 77.1.1.7 eq 1701

!

interface Ethernet0/1

 ip address 55.1.1.3 255.255.255.0

 crypto map L2TP_VPN

LAC#

crypto isakmp policy 10

 encr 3des

 authentication pre-share

 group 2

!

crypto isakmp key ipseckey123 address 55.1.1.3

!

crypto ipsec transform-set ESP-AES256-SHA1 esp-aes 256 esp-sha-hmac

 mode transport

!

crypto map L2TP_VPN 10 ipsec-isakmp

 set peer 55.1.1.3

 set transform-set ESP-AES256-SHA1

 match address L2TP_TRAFFIC

!

!

ip access-list extended L2TP_TRAFFIC

 permit udp host 77.1.1.7 eq 1701 host 55.1.1.3 eq 1701

!

interface Ethernet0/0

 ip address 77.1.1.7 255.255.255.0

 crypto map L2TP_VPN

!

!

 

Проверяем работу сессии через пинг с внутренней сети удаленного клиента (LAC) и просмотра статистики сессионных пакетов на L2TP HUBe (LNS)

Проверяем статистики L2TPv3 сессии

LNS#sh caller user LAC

 

  User: LAC, line Vi3, service PPPoVPDN

        Connected for 00:04:10, Idle for 00:00:05

  Timeouts:    Limit     Remaining Timer Type

               -         -         -        

  PPP: LCP Open, MS CHAP V2 -->), IPCP

  IP: Local 3.3.3.3, remote 7.7.7.7

  Counts: 247 packets input, 16456 bytes, 0 no buffer

          0 input errors, 0 CRC, 0 frame, 0 overrun

          129 packets output, 3846 bytes, 0 underruns

          0 output errors, 0 collisions, 0 interface resets

 

<после прохождения всех ping-ов проверяем вновь>

LNS#sh caller user LAC

 

  User: LAC, line Vi3, service PPPoVPDN

        Connected for 00:04:45, Idle for 00:00:02

  Timeouts:    Limit     Remaining Timer Type

               -         -         -        

  PPP: LCP Open, MS CHAP V2 (ß>), IPCP

  IP: Local 3.3.3.3, remote 7.7.7.7

  Counts: 327 packets input, 23288 bytes, 0 no buffer

          0 input errors, 0 CRC, 0 frame, 0 overrun

          188 packets output, 4226 bytes, 0 underruns

          0 output errors, 0 collisions, 0 interface resets

Пропингуем 100 пакетов удаленной сети через туннель

LAC#ping 192.168.1.1 repeat 100 source 172.30.1.7

Type escape sequence to abort.

Sending 100, 100-byte ICMP Echos to 192.168.1.1, timeout is 2 seconds:

!.!!!!!!!.!!!!!.!!!!!.!!!.!!!!!..!.!!!!!!!!!!!!.!!!!!..!!!!.

 

Формат пакета L2TPv2 over IPSec

Формат пакета IP | ESP header | UDP | L2TP | PPP | ESP trailer | Auth trailer

Overhead ESP_header (8байт) + UDP (8байт) + L2TPv2 (8байт) + PPP (4 байта) + ESP_trailer (min 2байта) + SHA_auth (160бит =  20 байт) = 50 бaйт

Работа OSPF over L2TPv2 over IPSec

Соседство через OSPF не было потеряно, hello пакеты по-прежнему приходят через каждый 10 сек. Маршруты анонсируются через удаленный OSPF соседний маршрутизатор.

LNS#sh ip ospf neighbor

 

Neighbor ID     Pri   State           Dead Time   Address         Interface

7.7.7.7                0   FULL/  -        00:00:35    7.7.7.7         Virtual-Access3

192.168.1.1       1   FULL/DR      00:00:33    192.168.1.1     Ethernet0/0

 

LNS#sh ip route

C        7.7.7.7 is directly connected, Virtual-Access3

O        77.77.77.77/32 [110/2] via 7.7.7.7, 21:54:59, Virtual-Access3

      172.30.0.0/24 is subnetted, 1 subnets

S        172.30.1.0 [1/0] via 7.7.7.7

      192.168.1.0/24 is variably subnetted, 2 subnets, 2 masks

 

Масштабирование. Подключение нового удаленного офиса через L2TPv2

Настройка для LNS, т.е. для L2TPv2 HUBа минимальная – необходимо лишь добавить пользователя для PPP CHAP авторизации. Если этого не сделать, то будет следующая ошибка:

*Nov  9 10:31:35.178: VPDN uid:123 disconnect (AAA) IETF: 17/user-error Ascend: 26/PPP CHAP Fail

*Nov  9 10:31:35.178: VPDN uid:123 vpdn shutdown session, result=2, error=6, vendor_err=0, syslog_error_code=8, syslog_key_type=1

 

Добавляем второго LAC

 

 

LNS#

username LAC_9 password 0 cisco123

LAC_9#

username LNS password 0 cisco123

!

l2tp-class client.init.class

 authentication

 password cisco123

!

pseudowire-class pwclass1

 encapsulation l2tpv2

 protocol l2tpv2 client.init.class

 ip local interface Ethernet0/0

!

interface Loopback0

 ip address 9.9.9.9 255.255.255.255

!

interface Virtual-PPP1

 ip address loopback0

 ppp authentication ms-chap-v2

 no cdp enable

 pseudowire 55.1.1.3 1 pw-class pwclass1

!

ip route 192.168.1.0 255.255.255.0 Virtual-PPP1

 

После этого на LNS уже 2 туннеля

LNS#sh vpdn tunnel

 

L2TP Tunnel Information Total tunnels 2 sessions 2

 

LocTunID   RemTunID   Remote Name   State  Remote Address  Sessn L2TP Class/

                                                                                                                          Count VPDN Group

35949            21672             LAC                  est           77.1.1.7             1     VPDN-L2TP     

49973            18492             LAC_9              est           44.1.1.9            1     VPDN-L2TP     

 

Работа OSPF в L2TPv2

В случае подключение удаленных офисов через L2TPv2 – нет ограничений в использовании динамических протоколов маршрутизации. Для включения OSPF заведем на каждом удаленном маршрутизаторе по сети на loopback-е:

LNS#

interface Loopback0

 ip address 3.3.3.3 255.255.255.255

router ospf 1

 network 3.3.3.3 0.0.0.0 area 0

LAC#

interface Loopback0

 ip address 7.7.7.7 255.255.255.255

!

interface Loopback1

 ip address 77.77.77.77 255.255.255.255

!

router ospf 1

 router-id 7.7.7.7

 network 7.7.7.7 0.0.0.0 area 0

 network 77.77.77.77 0.0.0.0 area 0

LAC_9#

interface Loopback0

 ip address 9.9.9.9 255.255.255.255

!

interface Loopback1

 ip address 99.99.99.99 255.255.255.255

!

router ospf 1

router-id 9.9.9.9

 network 9.9.9.9 0.0.0.0 area 0

 network 99.99.99.99 0.0.0.0 area 0

 

Проверяем OSPF соседство и настроенные маршруты

LNS#sh ip ospf neighbor

 

Neighbor ID     Pri   State           Dead Time   Address         Interface

9.9.9.9                0   FULL/  -        00:00:39    9.9.9.9         Virtual-Access3

7.7.7.7                0   FULL/  -        00:00:39    7.7.7.7         Virtual-Access4

192.168.1.1       1   FULL/DR      00:00:39    192.168.1.1     Ethernet0/0

 

Все региональные офисы видят маршруты друг друга через R3 – L2TPv2 HUB

LAC_9#sh ip route ospf (видны маршруты маршрутизатора R7)

      7.0.0.0/32 is subnetted, 1 subnets

O        7.7.7.7 [110/3] via 3.3.3.3, 00:02:14, Virtual-PPP1

      77.0.0.0/32 is subnetted, 1 subnets

O        77.77.77.77 [110/3] via 3.3.3.3, 00:02:14, Virtual-PPP1

 

Трассировка между удаленными офисами:

LAC_9#traceroute 77.77.77.77 source 99.99.99.99

Type escape sequence to abort.

Tracing the route to 77.77.77.77

VRF info: (vrf in name/id, vrf out name/id)

  1 3.3.3.3 5 msec 2 msec 4 msec

  2 7.7.7.7 5 msec 4 msec *

 

В случае не использования OSPF, каждое добавление нового регионального офиса требует статического добавления маршрутов на каждом существующем маршрутизаторе (и региональном и L2TP HUBe) с адресом достижения – ip адрес ppp интерфейса.

В случае хорошего дизайна распределения IP адресов мы можем ограничиться тем, что на региональных маршрутизаторах 1 раз добавили суммарный маршрут до всей внутренних региональных сетей, например 192.168.25.0/24 на interface virtual-ppp VPN HUBa, тогда при подключении новой подсети а-ля 192.168.25.16/29 нам не нужно будет ничего добавлять на региональных маршрутизаторах, останется только лишь на VPN HUBе указать за каким vitual-ppp интерфейсом нового регионального маршрутизатора находится эта сеть:

HUB(conf)#ip route 192.168.25.16 255.255.255.248 16.16.16.16 (<- где 16.16.16.16 это virtual-ppp интерфейс нового регионального маршрутизатора, и который в таблице маршрутизации VPN HUBa будет выглядеть как непосредственно подключенный:

C        16.16.16.16 is directly connected, Virtual-Access4)

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

P.S.

Все дампы пакетов, собранные при обзоре указанных выше VPN-ов, доступны для скачивания здесь.

разработка сайтов