что такое тоннель в сети
Как работает VPN-туннель? Типы VPN-туннелей. Что такое раздельное туннелирование?
Хакеры, снуперы, интернет-провайдеры и правительства могут превратить цифровую жизнь пользователя в ад. Не так уж много требуется, чтобы быть взломанным в интернете, подвергнуться цензуре или постоянно сталкиваться с различными препятствиями, пытаясь получить доступ к определенным услугам. VPN-туннель поможет защититься от всех этих неприятностей.
Как работает VPN-туннель?
У хакеров свои мотивы. Они используют вредоносные программы, фишинг, программы-вымогатели, DDoS-атаки и другие методы для перехвата данных и взлома ваших банковских счетов.
Когда вы подключаетесь к интернету через VPN, ваш трафик проходит через зашифрованный туннель, обеспечивая защиту данных и перенаправляя их на один из серверов поставщика VPN. Вы можете сидеть перед своим компьютером в России и притворяться, что вы из Канады. Ни интернет-провайдеры, ни хакеры, не смогут вас идентифицировать, а также получить ваши данные или отследить настоящее местоположение.
Типы VPN-туннелей
Существует множество различных протоколов VPN-туннелирования, различающихся по скорости, уровню безопасности и другим характеристикам. Стоит рассмотреть наиболее распространенные из них.
OpenVPN
OpenVPN — это популярный протокол с открытым кодом, который работает со всеми основными операционными системами. Вы можете загрузить исходный код, просмотреть его и изменить, как вам угодно. OpenVPN может работать через интернет-протоколы TCP или UDP. Он также считается самым безопасным протоколом VPN.
IPSec/IKEv2
Протокол IKEv2/IPSec может похвастаться преимуществами безопасности IPSec и высокой скоростью IKEv2, что делает его серьезным конкурентом в индустрии VPN-туннелирования. Когда ваше VPN-соединение прерывается или вы переключаетесь между сетями, функция автоподключения IKEv2/IPSec восстанавливает все до нормального состояния.
WireGuard
WireGuard — самый новый и быстрый из всех протоколов. Пока он все еще находится на ранней стадии разработки и поэтому имеет некоторые недостатки в безопасности.
SSTP — это VPN-протокол, который был создан компанией Microsoft, но он также доступен и на многих других системах. Многие провайдеры VPN скептически относятся к SSTP, поскольку, как известно, компания Microsoft сотрудничает с Агентством национальной безопасности. Тем не менее, нет никаких доказательств того, что протокол использовался не по назначению.
Что такое раздельное туннелирование?
VPN-туннель шифрует весь ваш трафик, но иногда возникают определенные ситуации, когда вам это не нужно. Именно в этом и заключается принцип раздельного туннелирования — вы можете создавать исключения для определенных приложений или сайтов и получать к ним доступ без использования VPN.
Таким образом, вы можете смотреть потоковое видео Netflix из Канады, сохраняя при этом доступ к локальным ресурсам из вашего родного города в России.
Какой VPN-протокол лучше всего использовать?
Все зависит от личных потребностей, но OpenVPN считается лучшим выбором среди большинства провайдеров VPN. У каждого из них есть свои как слабые, так и сильные стороны, которые предпочтут разные пользователи.
Технология VPN — определение, принципы использования и способы организации
Содержание:
По мере развития информационных технологий, тема безопасности и анонимности в Интернете становится всё более актуальной. Киберпреступники постоянно совершенствуют способы похищения личных данных, а интернет-провайдеры следят за своими клиентами и ограничивают их возможности различными способами.
VPN (Virtual Private Network, англ. «виртуальная частная сеть») позволяет защититься от вмешательства третьих лиц в процесс обмена информацией по сети. Изначально технология разрабатывалась для решения задач в корпоративной среде, но позже её преимущества оценили и обычные пользователи.
В этом материале мы подробно расскажем о том, что же такое VPN и как работает эта технология. А также приведём полезные советы по реализации VPN-соединения с построением архитектуры как на личном сервере, так и с использованием VPN-провайдеров.
Что такое VPN
VPN – это виртуальная частная сеть, которая объединяет несколько устройств, туннелируя их трафик поверх другого сетевого соединения. Если говорить простыми словами, то VPN – технология, позволяющая анонимизировать и обезопасить свою деятельность в Интернете или какой-либо другой сети.
Для более глубокого понимания принципа использования технологии, стоит подробнее разобрать составляющие термина виртуальная частная сеть.
Архитектура VPN
VPN-подключение создаётся за счёт использования как минимум двух устройств.
Между сервером и клиентом постоянно перемещается зашифрованная информация через VPN-туннель, а все процессы криптографической обработки данных (шифрование/дешифрование) выполняются на самих устройствах. Поэтому в условиях туннелирования, никто не сможет перехватить данные пользователя.
Варианты использования VPN
Частная сфера
Технология VPN популярна среди пользователей, поскольку защищает проходящий через сеть трафик от злоумышленников и скрывает действия в Интернете от сетевых-провайдеров, которые зачастую передают данные посторонним лицам. Всё, что видит провайдер при использовании VPN — факт подключения к VPN-серверу, объем передаваемых данных и длительность подключения.
Иногда VPN используется для обхода сетевых запретов, наложенных администратором или интернет-провайдером. Например, ограничение доступа к заблокированным ресурсам или урезание скорости для файлообменников, таких как BitTorrent.
Подобные возможности доступны благодаря маршрутизации трафика через VPN-сервер. Это значит, что отправленные пользователем запросы сначала передаются через туннель от клиента к серверу, а только потом отправляются в Интернет к необходимому веб-ресурсу. Это делает сёрфинг в Интернете анонимным, а также позволяет получить доступ к ресурсам, которые заблокировали IP-адрес клиента.
Маршрутизация потока через VPN-сервис
Корпоративная сфера.
В корпоративной сфере VPN используется для объединения или, наоборот, обособления сетей различных отделов. Эта технология позволяет обойти локальные ограничения между подключёнными устройствами.
Кроме того, VPN нужен для объединения корпоративных сетей через Интернет между отдалёнными объектами компании: офисами, региональными филиалами, зарубежными представительствами. Это гораздо выгоднее, чем использование физического локального подключения — кабельной или беспроводной связи.
Соединение двух сетей через VPN-туннель. Тип подключения «точка-точка».
VPN также даёт сотрудникам возможность подключаться к рабочей сети, находясь вне офиса. Например, дома или в общественном месте. После установки соединения пользователь получает доступ к корпоративным ресурсам и оборудованию.
Получение удалённого доступа к корпоративной сети (Intranet) с помощью VPN.
Подробно о практических способах применения технологии VPN можно почитать в этой статье.
Преимущества и недостатки использования VPN
Преимущества использования VPN напрямую вытекают из его богатых возможностей.
Использование VPN для выхода в интернет предполагает наличие недостатков, которые могут стать существенной проблемой для некоторых пользователей.
Протоколы VPN
Архитектура VPN-сетей строится на базе VPN-протоколов, которые применяются для реализации туннелирования между устройствами. Все они различаются между собой характеристиками, принципом работы и доступностью на разных операционных системах.
Способы организации VPN
Собственный сервер
Понадобится арендовать VPS/VDS сервер и самостоятельно развернуть необходимое ПО, предварительно выбрав подходящий VPN-протокол. Реализация подобного способа требует наличия знаний в администрировании. Но именно он является наиболее надёжным, безопасным и гибким в настройке, поскольку пользователь сам выстраивает архитектуру и уверен в том, что его данные не попадут в чужие руки.
Подробнее о том, как настроить и пользоваться VPN (OpenVPN) на собственном сервере, рассказано в этой статье.
VPN-провайдер
При использовании VPN-сервисов пользователям предоставляется на выбор сразу несколько серверов из разных стран. Для установки соединения используются расширения для туннелирования трафика только в браузере или отдельные программные клиенты, обеспечивающие перенаправление всех системных данных.
Подобный вариант создания VPN-подключения не всегда безопасен. Многие провайдеры обещают анонимность в сети, но при этом зачастую собирают данные пользователей. А в худшем случае продают информацию третьим лицам.
Показатели стабильности и скорости у VPN-сервисов тоже не из лучших. Ведь на каждый сервер приходится несколько клиентов, активность которых может негативно повлиять на «соседей».
На рынке присутствуют платные и бесплатные сервисы. Вторые живут преимущественно за счёт показа рекламы или предлагают услуги в рамках пробного периода. Средняя цена за VPN составляет 10-13 долларов в месяц.
Выбор VPN-сервиса
В первую очередь нужно изучить отзывы пользователей и ознакомиться с документацией. Важно, чтобы сервис не собирал статистику использования VPN — некоторые провайдеры заранее предупреждают об отсутствии логирования на серверах.
Важно! Рекомендуется сразу отсеять бесплатные варианты, поскольку у таких VPN—сервисов наблюдаются наихудшие показатели стабильности, скорости и безопасности.
Стоит обратить внимание на то, какая информация требуется для совершения регистрации. Хороший провайдер не будет запрашивать личные данные.
Нужно выбирать такого провайдера, серверы которого достаточно стабильны и быстры для комфортного использования сети. Подключение должно совершаться через надёжный VPN-протокол.
Популярные VPN-сервисы
Заключение
Технология VPN продолжает стремительно набирать популярность, ведь её можно использовать для реализации совершенно разных целей — от обеспечения собственной безопасности в Интернете до гибкого управления сетевой инфраструктурой в организациях.
При наличии даже минимальных технических знаний можно самостоятельно развернуть VPN-сеть с использованием собственного оборудования. Тем, кто хочет получить сразу готовый вариант сервиса можно воспользоваться платными услугами VPN-провайдеров.
Виртуальные сервера Eternalhost — проверенное решение для создания собственной сети VPN! Оперативная техподдержка 24/7 и бесплатная защита от DDoS.
Туннелирование (компьютерные сети)
Суть туннелирования состоит в том, чтобы «упаковать» передаваемую порцию данных, вместе со служебными полями, в новый «конверт» для обеспечения конфиденциальности и целостности всей передаваемой порции, включая служебные поля. Туннелирование может применяться на сетевом и на прикладном уровнях. Комбинация туннелирования и шифрования позволяет реализовать закрытые виртуальные частные сети. Туннелирование обычно применяется для согласования транспортных протоколов либо для создания защищённого соединения между узлами сети.
Содержание
Типы протоколов
В процессе инкапсуляции (туннелирования) принимают участие следующие типы протоколов:
Протокол транзитной сети является несущим, а протокол объединяемых сетей — транспортируемым. Пакеты транспортируемого протокола помещаются в поле данных пакетов несущего протокола с помощью протокола инкапсуляции. Пакеты-«пассажиры» не обрабатываются при транспортировке их по транзитной сети никаким образом. Инкапсуляцию выполняет пограничное устройство (маршрутизатор или шлюз), которое находится на границе между исходной и транзитной сетями. Извлечение пакетов транспортируемого протокола из несущих пакетов выполняет второе пограничное устройство, расположенное на границе между транзитной сетью и сетью назначения. Пограничные устройства указывают в несущих пакетах свои адреса, а не адреса узлов в сети назначения.
Согласование транспортных протоколов
Туннель может быть использован, когда две сети с одной транспортной технологией необходимо соединить через сеть, использующую другую транспортную технологию. При этом пограничные маршрутизаторы, которые подключают объединяемые сети к транзитной, упаковывают пакеты транспортного протокола объединяемых сетей в пакеты транспортного протокола транзитной сети. Второй пограничный маршрутизатор выполняет обратную операцию.
Обычно туннелирование приводит к более простым и быстрым решениям по сравнению с трансляцией, так как решает более частную задачу, не обеспечивая взаимодействия с узлами транзитной сети.
Основные компоненты туннеля
Основными компонентами туннеля являются:
Инициатор туннеля встраивает (инкапсулирует) пакеты в новый пакет, содержащий наряду с исходными данными новый заголовок с информацией об отправителе и получателе. Несмотря на то, что все передаваемые по туннелю пакеты являются пакетами IP, инкапсулируемые пакеты могут принадлежать к протоколу любого типа, включая пакеты немаршрутизируемых протоколов. Маршрут между инициатором и терминатором туннеля определяет обычная маршрутизируемая сеть IP, которая может быть и сетью, отличной от Internet. Терминатор туннеля выполняет процесс, который является обратным инкапсуляции — он удаляет новые заголовки и направляет каждый исходный пакет в локальный стек протоколов или адресату в локальной сети. Инкапсуляция сама по себе никак не влияет на защищенность пакетов сообщений, передаваемых по туннелю VPN. Но инкапсуляция даёт возможность полной криптографической защиты инкапсулируемых пакетов. Конфиденциальность инкапсулируемых пакетов обеспечивается путем их криптографического закрытия, т. е. зашифровывания, а целостность и подлинность — путем формирования цифровой подписи. Так как существует множество методов криптозащиты данных, необходимо чтобы инициатор и терминатор туннеля использовали одни и те же методы и могли согласовывать друг с другом эту информацию. Более того, для возможности расшифровывания данных и проверки цифровой подписи при приеме инициатор и терминатор туннеля должны поддерживать функции безопасного обмена ключами. Чтобы туннели VPN создавались только между уполномоченными пользователями, конечные стороны взаимодействия требуется аутентифицировать.
Тоннелирование
Cодержание
Функциональность
В процессе туннелирования данные будут разбиваться на более мелкие фрагменты, известные как пакеты, которые будут перемещаться по «туннелю» для транспортировки к конечному пункту назначения. Когда эти пакеты проходят через туннель, они шифруются и инкапсулируются. Частные сетевые данные и сопутствующий им информационный протокол также инкапсулируются в передающие устройства сети общего пользования для отправки. В принимающей стороне будет происходить процесс декапсуляции и дешифровки. Кроме того, туннель рассматривается в качестве логического пути или соединения, которое будет инкапсулировать пакеты, проходящие через транзитную внутреннюю сеть. Этот протокол туннелирования будет шифровать исходный кадр, чтобы содержимое не было интерпретировано за пределами маршрута. Для того чтобы процесс действительно работал, данные будут отправляться, как только туннель будет уже установлен, и клиенты или сервер будут использовать один и тот же туннель для передачи и получения данных через внутреннюю сеть. Передача данных будет зависеть от протоколов туннелирования, которые используются для передачи.
Тоннелеукладчики
VPN туннели могут быть созданы на следующих уровнях открытого системного взаимодействия или эталонной модели OSI:
VPN протоколы, которые работают на этом уровне, являются точкой, указывающей на протокол туннелирования и протокол туннелирования второго уровня.
IPSec может работать как VPN протокол на сетевом уровне эталонной модели OSI. [3]
Протоколы
Протоколы проходки тоннелей
Ниже приведены различные протоколы, разрешающие прокладку тоннелей:
Протокол туннелирования точка-точка (PPTP)
Это обеспечивает безопасность данных, даже если они передаются по сетям общего пользования. Авторизованные пользователи могут получить доступ к частной сети, которая называется виртуальной частной сетью или VPN, предоставляемой провайдером интернет-услуг или провайдером интернет-услуг. Это частная сеть в виртуальном смысле, потому что она создана в туннельной среде. Данный протокол позволяет корпорациям расширять собственную корпоративную сеть по частному каналу через общедоступный интернет.
Протокол проходки тоннелей второго уровня (L2TP)
Этот протокол включает в себя комбинацию использования PPTP и переадресации второго уровня. Это используется для поддержки виртуальных частных сетей (VPN) в рамках предоставления услуг по протоколам Интернет-услуг или провайдерам интернет-услуг. Оно не обеспечивает шифрование и конфиденциальность только само по себе. Но для обеспечения конфиденциальности он использует протокол шифрования, проходящий в туннеле. Он использует сетевые соединения с пакетной коммутацией, что позволяет размещать конечные точки на разных машинах. Это означает, что соединение может быть прервано на концентраторе локальной цепи и исключает, помимо прочих преимуществ, возможные расходы на междугороднее соединение. Таким образом, с другой точки зрения, с точки зрения проведения операции никакой разницы нет. [4]
Таким образом, туннелирование действительно полезно и полезно в корпоративной среде, а также предоставляет функции безопасности, такие как опции шифрования. [2:1] В двух словах, туннели рассматриваются как механизм, используемый для отправки неподдерживаемых протоколов по различным и разнообразным сетям. Туннелирование данных, VPN или других, увеличит размер пакета, что приведет к меньшему количеству передаваемых данных на пакет. Эти данные туннелирования через SSH обычно представляют собой VPN для каждого приложения, но в последней версии открытой SSH будет реализована полномасштабная бесперебойная VPN.
Ниже перечислены два типа проходки тоннелей:
Добровольное туннелирование
В этом типе туннелирования клиент начнет процесс инициализации соединения с VPN сервером. Существует требование для того, чтобы процесс работал, и это требование представляет собой существующее соединение между сервером и клиентом. Это соединение, которое VPN клиент будет использовать для создания туннельного соединения с VPN сервером. Для добровольного туннелирования компьютер пользователя будет рассматриваться в качестве конечной точки туннеля и будет выступать в качестве клиента туннеля. Клиент здесь или пользователь выдаст запрос конфигурации и создаст добровольный туннель. Им потребуется коммутируемое соединение или подключение к локальной сети (LAN). В этом типе туннелирования требуется, чтобы компьютер клиента имел соответствующее программное обеспечение и чтобы протоколы были предварительно установлены, чтобы соединение стало возможным.
Обязательное прокладка тоннелей
В этом типе туннелирования будет создано соединение между двумя VPN серверами и двумя устройствами VPN доступа или VPN маршрутизаторами. При этом сервер удаленного доступа будет настраивать и настраивать VPN с помощью устройства, которое называется сервером коммутируемого доступа. Это будет действовать как клиент туннеля. При использовании принудительного туннеля компьютер пользователя не считается конечной точкой туннеля.
Сети для самых маленьких. Часть седьмая. VPN
Покупка заводов в Сибири была стратегически правильным решением для компании “Лифт ми Ам”. После того, как лифты стали ездить не только вверх, но и вниз, дела компании пошли… нет полетели, вверх. Лифты начали разбирать, как горячие пирожки со стола. Название уже не соответствовало действительности и было принято решение о ребрендинге. (На самом деле их замучила судебная тяжба с Моби).
Итак, под крыло ЛинкМиАп планируется взять заводы в Новосибирске, Томске и Брно. Самое время подумать о том, как это хозяйство подключить к имеющейся сети.
Итак, сегодня рассматриваем
1) Возможные варианты подключения, их плюсы и минусы
2) Site-to-Site VPN на основе GRE и IPSec
3) Большая тема: динамическая многоточечная виртуальная сеть (DMVPN) в теории и на практике.
В традиционном видео лишь ёмкая выжимка из статьи, посвящённая работе и настройке DMVPN.
Когда вы хотите связать несколько офисов, у вас огромнейший выбор способов и средств. Всё зависит только от ваших возможностей, способностей, желаний и наличия оборудования.
Давайте по порядку.
Имеется ввиду не подключение к интернету через xDSL, а именно линк: модеммодем. Да, и такие решения существуют. Можно назвать это мостом.
В этом случае для вас всё прозрачно – вы используете свою собственную физическую линию, поэтому пропускать через неё можете что угодно без ограничений.
Б) Второй вариант – арендовать канал у провайдера. В случае необходимости стабильного канала до другого города – это самый распространённый и надёжный вариант. Провайдер может вам предоставить следующие услуги:
Эта услуга выглядит очень простой с точки зрения клиента – как в плане настройки, так и в плане реализации – но сложной – с точки зрения оператора.
С реализацией L2/L3 VPN на основе MPLS мы будем разбираться, но гораздо позже.
В) Ну и последний вариант: туннель через публичную сеть. Предположим, у вас есть выход в Интернет на обеих ваших точках. Зачастую самым дешёвым способом оказывается построить туннель между этими двумя точками. Для этого вам достаточно всего лишь иметь белые (публичные) статические адреса на всех точках (а иногда достаточно и на одной) и оборудование, на котором это реализовать. У этого решения есть ряд недостатков, которые мы рассмотрим ниже, но тем не менее именно на нём мы сегодня и остановимся.
Итак, ваша воля выбирать, какой вариант использовать, исходя из бюджета, целесообразности и ваших способностей к убеждению руководства.
В рамках данного выпуска нам нужно подключить 3 офиса: в Новосибирске, Томске и Брно. Условимся, что везде мы будем использовать только подключение к сети Интернет.
Схема подключения узлов hub and spoke – по-русски говоря, звезда:
Напоминаю, что общая схема сети ЛинкМиАп выглядит сейчас уже так:
Но от неё мы абстрагируемся, напирая только на существенные вещи.
Раз уж мы взялись реализовывать вариант В, то придётся разобраться детально в вариантах.
На сегодняшний день существует неисчислимое множество всевозможных приложений и протоколов для организации VPN, но большая их часть является способами подключения хостов, а не сетей. Мы подразумеваем удалённую работу. Например так:
То есть это схема работы, когда один сотрудник подключается к корпоративной сети удалённо (teleworker в терминологии Cisco).
Откровенно говоря, нам это мало интересно, гораздо занимательнее вопрос, как подключать целые сети.
Generic Routing Encapsulation – очень простой протокол туннелирования.
Такс, туннелирование. Это что ещё за зверь? Грубо говоря, это означает, что берутся ваши изначальные данные вместе со служебными заголовками (как правило, это IP, но может быть и Ethernet и ATM), упаковываются в пакет и передаются по публичной сети, словно машина едет в туннеле через горы. На конечном узле заголовки нового пакета снимаются, а ваши данные в исходном виде продолжают своё путешествие.
Не очень понятно, да? Разберём на примере с GRE.
Пока возьмём абстрактную топологию:
Два маршрутизатора подключены к интернету через статические белые адреса. На каждом из них заведены приватные сети из диапазона 10.0.0.0/8.
Разумеется, эти сети не маршрутизируются в Интернете. (На картинке нарисованы компьютер и ноутбук, но на практике мы будем настраивать виртуальный интерфейс Loopback0)
Наша задача прокинуть туннель:
Таким образом для ПК1 при общении с ПК2 не существует никакого Интернета – они оба будут думать, что находятся в одной локальной сети.
Настраивается GRE-туннель следующим образом:
interface Tunnel0
ip address 10.2.2.1 255.255.255.252
Поскольку туннель является виртуальным L3 интерфейсом, через который у нас будет происходить маршрутизация, ему должен быть назначен IP-адрес, который выбирается согласно вашему IP-плану, вероятно, из приватной сети.
В качестве адреса источника можно выбрать как IP-адрес выходного интерфейса
(белый адрес, предоставленный провайдером), так и его имя (FE0/0 в нашем случае):
interface Tunnel0
ip address 10.2.2.1 255.255.255.252
tunnel source 100.0.0.1
tunnel destination 200.0.0.1
Сразу после этого туннель должен подняться:
R1#sh int tun 0
Tunnel0 is up, line protocol is up
Hardware is Tunnel
Internet address is 10.2.2.1/30
MTU 1514 bytes, BW 9 Kbit, DLY 500000 usec,
reliability 255/255, txload 1/255, rxload 1/255
Encapsulation TUNNEL, loopback not set
Keepalive not set
Tunnel source 100.0.0.1, destination 200.0.0.1
Tunnel protocol/transport GRE/IP
Вся основная информация здесь отражена. Обратите внимание на размер MTU – он не 1500, как ставится для обычных физических интерфейсов. О параметре MTU мы поговорим в конце статьи
По умолчанию GRE не проверяет доступность адреса назначения и сразу отправляет туннель в Up. Но стоит только добавить в туннельный интерфейс команду keepalive X, как маршрутизатор начинает отсылать кипалайвы и не поднимется, пока не будет ответа.
В нашей тестовой схеме в качестве локальной сети мы просто настроили Loopback-интерфейсы – они всегда в Up’е. Дали им адреса с маской /32. На самом же деле под ними подразумеваются реальные подсети вашего предприятия (ну, как на картинке).
interface Loopback0
ip address 10.0.0.0 255.255.255.255
ip route 0.0.0.0 0.0.0.0 100.0.0.2
ip route 10.1.1.0 255.255.255.255 10.2.2.2
Первый говорит о том, что шлюзом по умолчанию является адрес провайдера 100.0.0.2:
R1#traceroute 200.0.0.1
Type escape sequence to abort.
Tracing the route to 200.0.0.1
1 100.0.0.2 56 msec 48 msec 36 msec
2 200.0.0.1 64 msec * 60 msec
Второй перенаправляет пакеты, адресованные хосту с адресом 10.1.1.0, на next-hop 10.2.2.2 – это адрес туннеля с обратной стороны.
GRE-туннели являются однонаправленными, и обычно подразумевается наличие обратного туннеля на другой стороне, хотя вообще говоря, это необязательно. Но в нашем случае, когда посередине Интернет, и задача – организовать приватную сеть, с обратной стороны должна быть симметричная настройка:
interface Tunnel0
ip address 10.2.2.2 255.255.255.252
tunnel source 200.0.0.1
tunnel destination 100.0.0.1
ip route 0.0.0.0 0.0.0.0 200.0.0.2
ip route 10.0.0.0 255.255.255.255 10.2.2.1
Пробуем запустить пинг:
R1#ping 10.1.1.0 source 10.0.0.0
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.1.1.0, timeout is 2 seconds:
.
Success rate is 100 percent (5/5), round-trip min/avg/max = 44/71/136 ms
R1#tracer 10.1.1.0
Type escape sequence to abort.
Tracing the route to 10.1.1.0
1 10.2.2.2 68 msec * 80 msec
Великолепно! Но что происходит за кулисами?
А там, ребята, удивительные вещи:
Когда вы запускаете ping 10.1.1.0, что делает маршрутизатор?
1) Формирует IP-пакет::
2) Смотрит таблицу маршрутизации
R1#sh ip route 10.1.1.0
Routing entry for 10.1.1.0/32
Known via «static», distance 1, metric 0
Routing Descriptor Blocks:
* 10.2.2.2
Route metric is 0, traffic share count is 1
Далее рекурсивно смотрит, где адрес 10.2.2.2:
R1#sh ip rou 10.2.2.2
Routing entry for 10.2.2.0/30
Known via «connected», distance 0, metric 0 (connected, via interface)
Routing Descriptor Blocks:
* directly connected, via Tunnel0
Route metric is 0, traffic share count is 1
R1#sh int tun 0
Tunnel0 is up, line protocol is up
Hardware is Tunnel
Internet address is 10.2.2.1/30
MTU 1514 bytes, BW 9 Kbit, DLY 500000 usec,
reliability 255/255, txload 1/255, rxload 1/255
Encapsulation TUNNEL, loopback not set
Keepalive not set
Tunnel source 100.0.0.1, destination 200.0.0.1
3) Понимая, что это GRE-туннель, добавляет к пакету заголове GRE:
А сверху новый заголовок IР. В качестве отправителя будет значиться адрес tunnel source, а в качестве получателя – tunnel destination.
4) Новоиспечённый пакет отправляется в дивный мир по дефолтному маршруту:
R1#sh ip route
Gateway of last resort is 100.0.0.2 to network 0.0.0.0
5) Не забываем про заголовок Ethernet, при отправке провайдеру он также должен быть сформирован.
Поскольку GRE-туннель – виртуальный интерфейс 3-го уровня, он не обладает собственным MAC-адресом (как и Loopback, например). В конечном итоге кадр уйдёт с физического интерфейса FastEthernet0/0:
R1#sh ip route 100.0.0.2
Routing entry for 100.0.0.0/30
Known via «connected», distance 0, metric 0 (connected, via interface)
Routing Descriptor Blocks:
* directly connected, via FastEthernet0/0
Route metric is 0, traffic share count is 1
Соответственно его адрес он и укажет в качестве Source MAC
R1#sh int
FastEthernet0/0 is up, line protocol is up
Hardware is Gt96k FE, address is c000.25a0.0000 (bia c000.25a0.0000)
Internet address is 100.0.0.1/30
Destination по традиции берётся из ARP-кэша или получается с помощью ARP-запроса от адреса 100.0.0.2:
R1#show arp
Protocol Address Age (min) Hardware Addr Type Interface
Internet 100.0.0.1 – c000.25a0.0000 ARPA FastEthernet0/0
Internet 100.0.0.2 71 c001.25a0.0000 ARPA FastEthernet0/0
6) И в таком виде новый IP-пакет передаётся в интернет. А поскольку каждый маршрутизатор не раздербанивает пакет, а принимает решение на основе первого же заголовка IP, то никто в Интернете не будет знать о том, что где-то там внутри кроются ваши приватные адреса 10.1.1.0 и 10.0.0.0.
7) И наконец пребывает в точку назначения.
R3 обнаруживает, что адрес назначения принадлежит ему самому, снимает заголовок IP и что он под ним находит? GRE-заголовок.
Он проверяет, что у него действительно есть такой GRE-туннель, снимает заголовок GRE, и дальше это уже самый обычный IP-пакет, с которым нужно распорядиться согласно записям в таблице маршрутизации.
В данном случае передать на обработку интерфейсу Loopback 0
R3#sh ip route 10.1.1.0
Routing entry for 10.1.1.0/32
Known via «connected», distance 0, metric 0 (connected, via interface)
Routing Descriptor Blocks:
* directly connected, via Loopback0
Route metric is 0, traffic share count is 1
Вот такие нехитрые манипуляции.
Пока пакет в локальной сети он выглядит так:
и обрабатывается на основе приватных адресов.
Как только попадает в публичную сеть, GRE вешает на него дополнительный IP-заголовок:
и пакет обрабатывается на основе публичных адресов.
Вот как выглядит пакет в Интернете:
1 – изначальные данные
2 – первый IP-заголовок (внутренний)
3 – заголовок GRE (с указанием, что внутри лежат данные протокола IP)
4 – новый заголовок IP (внешний, с туннельными адресами)
Рядовой обмен ICMP-сообщениями может при детальном рассмотрении выглядеть и так.
Если попытаться провести аналогии с осязаемым миром, то представим ситуацию, когда вы едете из деревни, инкапсулированные в автомобиль. Доезжаете до реки, и вам надо перебраться на другой берег и там продолжить своё путешествие в город.
На речном порту ваш автомобиль инкапсулируют в паром и переправляют через бушующие волны на другую сторону, где ваш автомобиль извлекают, и вы продолжаете движение. Так вот этот паром и был GRE-паромом.
Сделаем три ремарки:
Во-первых, интерфейсы Loopback и адреса с маской /32 мы выбрали просто для теста, фактически это вполне бы могли быть интерфейсы fa1/0.15 и fa0/1.16 с подсетями 172.16.15.0/24 и 172.16.16.0/24, например, или любые другие.
Во-вторых, мы тут всё ведём речи о публичных сетях и адресах, но на самом деле, конечно, это не имеет значения и туннели вполне можно поднимать даже внутри своей корпоративной сети, когда конечные сети и так имеют IP-связность без туннеля.
В-третьих, несмотря на то, что теоретически обратно трафик может возвращаться и не по туннелю, создать его необходимо, чтобы конечный узел могу успешно декапсулировать GRE-пакеты
IPSec
Первую озвученную выше проблему призвано решить шифрование.
Сейчас для организации шифрованного VPN-канала используются преимущественно следующие технологии: IPSec (IP Security), OpenVPN и PPTP (Point-to-Point Tunneling Protocol).
Бессменным лидером, конечно, является IPSec, о нём и поговорим.
Строго говоря, в этом процессе есть нулевой шаг: некий трафик должен попасть в соответствие аксесс-листу в крипто мапе. Только после этого будет происходить все остальное.
IPSec может работать в двух режимах: туннельном и транспортном.
Туннельный режим работы IPSec
В этом режиме берётся ваш изначальный IP-пакет, шифруется полностью, вместе с заголовком IP, добавляется служебная информация IPSec и новый заголовок IP:
*рисунок не точен и показывает лишь суть, на самом деле заголовков там больше, а так же есть трейлеры в конце.
Это режим по умолчанию.
Давайте опять разберёмся по ходу настройки.
На локальной стороне:
Сначала общую политику для фазы 1 – установление первого, вспомогательного туннеля: тип шифрования (по умолчанию DES) и аутентификации. Аутентификацию можно делать на основе сертификатов, но мы рассмотрим простой пример с предварительным ключом:
crypto isakmp policy 1
encr aes
authentication pre-share
Часто задаются несколько таких политик с различными комбинациями шифрования, хеша и группы DH.
При создании isakmp sa, та сторона, которая инициирует соединение, отправляет все локально настроенные политики isakmp.
Принимающая сторона просматривает по очереди, в порядке приоритетности свои локально настроенные политики. Первая же политика, для которой найдено совпадение, будет использоваться.
Указываем pre-shared key для проверки подлинности соседа 200.0.0.1
crypto isakmp key CISCO address 200.0.0.1
crypto ipsec transform-set AES128-SHA esp-aes esp-sha-hmac
На самом деле мы указываем сразу набор протоколов, как вы видите, он и называется transform-set. При установке IPSec-сессии маршрутизаторы обмениваются этими наборами. Они должны совпадать.
Для упрощения траблшутинга имена для transform-set обычно даются по применённым протоколам.
Теперь создаём карту шифрования:
crypto map MAP1 10 ipsec-isakmp
set peer 200.0.0.1
set transform-set AES128-SHA
match address 101
Вот именно тут и определяется адрес соседа IPSec, с которым потом будет устанавливаться туннель – 200.0.0.1. Тут же привязывается набор протоколов и ACL, определяющий, какой трафик будет шифроваться и передаваться через туннель.
В нашем случае он выглядит так:
access-list 101 permit ip host 10.0.0.0 host 10.1.1.0
Будьте внимательны при задании ACL. Он определяет параметры не только исходящего трафика, но и входящего (в отличие от ACL для NAT, например).
То есть если придут пакеты не от 10.1.1.0, а от 10.2.2.2, он не будет обработан и дешифрован.
Заметим, что шифрование, происходит практически в самую последнюю очередь, после маршрутизации.
И это, кстати, очень важный момент. Вам недостаточно маршрута до публичного адреса пира (200.0.0.1). Нужен маршрут до 10.1.1.0 пусть даже он дефолтный. Иначе пакет будет отброшен в соответствии с обычными правилами маршрутизации.
Как бы странно это ни казалось, но трафик в локальную сеть у вас должен быть “зарулен”, например, в Интернет. При этом приватные пакет, которые уже вот-вот должны быть отправлены к провайдеру и там отброшены, в последний момент шифруется, получая публичные адреса.
Кстати, тут есть таблица с порядком следования операций, производимых над трафиком.
interface FastEthernet0/0
crypto map MAP1
crypto isakmp policy 1
encr aes
authentication pre-share
crypto isakmp key CISCO address 100.0.0.1
!
!
crypto ipsec transform-set AES128-SHA esp-aes esp-sha-hmac
!
crypto map MAP1 10 ipsec-isakmp
set peer 100.0.0.1
set transform-set AES128-SHA
match address 101
interface FastEthernet0/1
crypto map MAP1
access-list 101 permit ip host 10.1.1.0 host 10.0.0.0
Но сколько бы вы после ни смотрели show crypto session или show crypto isakmp sa, вы увидите только Down. Туннель никак не поднимается.
Счётчики show crypto ipsec sa. Так же по нулям.
R1#sh crypto session
Crypto session current status
Interface: FastEthernet0/0
Session status: DOWN
Peer: 200.0.0.1 port 500
IPSEC FLOW: permit ip host 10.0.0.0 host 10.1.1.0
Active SAs: 0, origin: crypto map
R1#sh crypto isakmp sa
dst src state conn-id slot status
Дело в том, что вам необходимо пустить в него трафик. В прямом смысле, например так:
R1#ping 10.1.1.0 source 10.0.0.0
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.1.1.0, timeout is 2 seconds:
Packet sent with a source address of 10.0.0.0
.
Success rate is 80 percent (4/5), round-trip min/avg/max = 60/94/160 ms
R1#sh crypto session
Crypto session current status
Interface: FastEthernet0/0
Session status: UP-ACTIVE
Peer: 200.0.0.1 port 500
IKE SA: local 100.0.0.1/500 remote 200.0.0.1/500 Active
IPSEC FLOW: permit ip host 10.0.0.0 host 10.1.1.0
Active SAs: 2, origin: crypto map
R1#sh crypto isakmp sa
dst src state conn-id slot status
200.0.0.1 100.0.0.1 QM_IDLE 1 0 ACTIVE
Начальная конфигурация: «IPsec»
Маршрутизатор R1 стоит в центральном офисе.
Маршрутизатор R3 — это маршрутизатор в одном из филиалов.
К схеме добавляется маршрутизатор R4 — второй филиал.
Задание:
1. Настроить туннель IPsec с использованием crypto-map между R4 и R1:
— Политики защиты данных такие же, как и для туннеля между R3 и R1.
2. Добавить соответствующие настройки для того чтобы R3 и R4 также могли обмениваться данными:
— Данные между филиалами за R3 и R4 должны передаваться через центральный маршрутизатор R1
1) Мы запустили пинг на адрес 10.1.1.0 с адреса 10.0.0.0.
2) Согласно таблице маршрутизации пакет должен быть передан в публичную сеть в том виде, в каком он есть.
3) Но маршрутизатор видит, что это подпадает по его ACL 101 и передаёт пакет в работу IPSec’у.
4) IPSec, работая в туннельном режиме (режим по умолчанию), упаковывает исходный пакет сначала в IPSec PDU, попутно шифруя всё и вся, а потом укомплектовывает его новым IP-заголовком. В качестве адреса назначения маршрутизатор прописывает адрес своего IPSec-соседа – 200.0.0.1.
На скриншоте ниже вы можете видеть инкапсуляцию:
Это был обмен ICMP-сообщениям. Все исходные данные зашифрованы, включая старый IP, новый IP-заголовок опирается на настройку IPSec.
5) На конечном узле маршрутизатор видит, что адрес назначения принадлежит ему, снимает заголовок IP и видит заголовок IPSec, этому протоколу он и передаёт пакет на обработку. Последний дешифруется, удаляется вся служебная информация, и исходный пакет путешествует дальше.
Почему мы запускали такой странный Ping? В нём мы указали адрес отправителя явно.
Если же мы попытаемся запустить Ping 10.1.1.0, то он не пройдёт, потому что маршрутизатор автоматически подставляет в качестве отправителя адрес физического интерфейса: 100.0.0.1, который не попадает в наш ACL, и поэтому пакет пытается уйти на шлюз последней надежды.
Какую самую главную проблему мы имеем тут? Бинго! Динамическая маршрутизация. Внедрить её в таких условиях невозможно – все IGP требуют прямого L2-линка между соседями, чего не обеспечивает IPSec. Поэтому в такой реализации трафик отправляется в туннель на основе ACL и карты шифрования, а не таблицы маршрутизации.
Плюс мы имеем проблему с мультикастом, потому что задаём конкретные подсети в ACL.
Примечание:
Задача может быть решена, как теоретически, так и практически.
Если Вы будете пробовать задачу на практике, то внимательно соблюдайте условия задачи.
Условия задачи:
Маршрутизатор R1 стоит в центральном офисе и к нему будут подключены 3 филиала (для данной задачи достаточно маршрутизаторов R1, R2, R3. R3 — в роли одного из филиалов). В филиалах используются маршрутизаторы с разными возможностями, и необходимо использовать разные политики IPsec. Всего есть 3 различные политики.
На маршрутизаторе R3, кроме туннеля в центральный офис также есть несколько туннелей с партнерами. Поэтому тут тоже созданы различные политики.
Трафик передается только из филиалов в центральный офис, между филиалами коммуникаций нет.
Со стороны филиала R3 в центральный офис R1 генерируются данные, которые инициируют туннель VPN.
Вопрос: Какую политику защиты данных будут использовать маршрутизаторы для построения туннеля между собой?
Это был туннельный режим, коллеги. Переходим к следующему экспонату.
Транспортный режим работы IPSec
Он много чем отличается от туннельного, но самое важное – это метод инкапсуляции.
Вот пакет IPSec в туннельном режиме
А это пакет IPSec в транспортном:
То есть туннельный шифрует изначальный пакет полностью и добавляет новый заголовок IP. Транспортный же шифрует всё, что выше уровня IP, а заголовок IP оставляет без изменений.
Грубо говоря, туннельный режим вы используете для того, чтобы связать две приватные сети через публичную, обеспечив при этом шифрование (Что-то вроде безопасного GRE). Транспортный же актуален тогда, когда IP-связность уже достигнута, но трафик между узлами нужно шифровать.
Удачным примером применения транспортного режима может быть схема сервер-клиент. Например, работа клиент-банка. Сервер и так уже доступен, но трафик нужно зашифровать.
Но мы не об этом. Нам всё-таки, надо объединять сети.
Схема: «итоговая схема задачи 7.1»
Конфигурации устройств: на сайте проекта
Описание проблемы:
Не передаются данные между R1 и R4.
Задание:
Найти ошибку и исправить конфигурацию так, чтобы туннель между R1 и R4 установился и передавался трафик между R1 и R4.
GRE over IPSec
У начинающих тут часто случается конфуз (он и у автора случился): GRE over IPSec или IPSec over GRE. В чём разница, где применяются. Нельзя на этом не остановиться.
Обычный режим, который мы рассматриваем тут и который применяется в подавляющем большинстве случаев, – это GRE over IPSec, то есть данные GRE инкапсулируются заголовками ESP или AH
А IPSec over GRE означает, наоборот, что внутри будут зашифрованные данные IPSec, а сверху заголовки GRE/IP. Они будут не зашифрованы:
Такой вариант возможен, например, если шифрование у вас происходит на отдельном устройстве перед туннелированием
Зачем такая похабщина нужна, не очень понятно, поэтому обычно используется именно GRE over IPSec.
Вернёмся к нашей старой схеме и реализуем на ней именно этот вариант.
Разумеется, при этом у нас снова появляется туннельный интерфейс (настраивается, как обычный GRE):
interface Tunnel0
ip address 10.2.2.1 255.255.255.252
tunnel source 100.0.0.1
tunnel destination 200.0.0.1
crypto ipsec transform-set AES128-SHA esp-aes esp-sha-hmac
mode transport
*Заметьте, менять, это надо на обеих сторонах, иначе соседство IPSec не установится.
Во-вторых, шифроваться должен весь трафик между филиалами, то есть тот, который идёт через туннель, соответственно, нет необходимости прописывать все сети в ACL, поступим хитрее:
access-list 101 permit gre host 100.0.0.1 host 200.0.0.1
Условие выполняется, если на порт пришёл трафик с заголовком GRE и соответствующими адресами.
Что будет происходить при таком раскладе?
1) Пакет с адресом назначения 10.1.1.0 приходит на маршрутизатор, тот определяет по своей таблице, что пакет нужно передать на next-hop 10.2.2.2
R1#sh ip route 10.1.1.0
Routing entry for 10.1.1.0/32
Known via «static», distance 1, metric 0
Routing Descriptor Blocks:
* 10.2.2.2
Route metric is 0, traffic share count is 1
2) Это туннельный интерфейс, с адресом назначения 200.0.0.1. Пакет упаковывается заголовком GRE и новым IP заголовком.
R1#sh int tun 0
Tunnel0 is up, line protocol is up
Hardware is Tunnel
Internet address is 10.2.2.1/30
MTU 1514 bytes, BW 9 Kbit, DLY 500000 usec,
reliability 255/255, txload 1/255, rxload 1/255
Encapsulation TUNNEL, loopback not set
Keepalive not set
Tunnel source 100.0.0.1, destination 200.0.0.1
Tunnel protocol/transport GRE/IP
3) Сеть 200.0.0.1 известна через адрес 100.0.0.2
R1#sh ip route
Gateway of last resort is 100.0.0.2 to network 0.0.0.0
А подсеть 100.0.0.0/30 подключена к интерфейсу FE0/0
R1#sh ip route 100.0.0.0
Routing entry for 100.0.0.0/30, 1 known subnets
Attached (1 connections)
C 100.0.0.0 is directly connected, FastEthernet0/0
А на него применена карта шифрования с ACL.
Трафик, естественно, подпадает под него (имеет заголовок GRE и нужные IP-адреса), поэтому всё, что находится внутри внешнего IP-заголовка будет зашифровано.
Такая схема работы позволяет нормально внедрять протоколы динамической маршрутизации, а также передавать мультикастовый трафик, оставляя возможность шифрования. Хулиганы уже не смогут выкрасть секретные рецепты приготовления лифтов.
Конфигурация: на сайте проекта
Описание проблемы:
После настройки GRE over IPSec между R1 и R3, всё прекрасно работает, трафик между R1 и R3 (c 10.0.0.0 на 10.1.1.0) передается.
Однако, через несколько дней, когда администратор хотел посмотреть состояние VPN, обнаружилось, что на маршрутизаторах вообще нет установленных SA.
Соответственно, трафик между R1 и R3 не шифруется.
Задание:
Необходимо проверить настройки, исправить конфигурацию и сделать так, чтобы трафик шифровался (трафик между loopback-интерфейсами 10.0.0.0 и 10.1.1.0).
Можно сделать тут ещё одно дополнение: технически, можно исключить четырёхбайтовый заголовок GRE из пакета, указав с обеих сторон, что режим работы туннеля IPIP:
Нужно правда помнить, что в этом случае инкапсулировать можно только данные IP, а не любые, как в случае GRE.
Задание:
Изменить исходную конфигурацию GRE over IPSec и настроить GRE over IPsec без использования crypto-map.
IPSec VTI
Последний пример Site-to-Site VPN с использованием IPSec, который, собственно, и рекомендован циской – VTI (Virtual Tunnel Interface)
Настройка IPSec отличается тем, что нам уже не нужно создавать вручную crypto-map (а соответственно и ACL), вместо него мы создаём IPSec-профиль
crypto isakmp policy 1
authentication pre-share
crypto isakmp key DMVPNpass address 0.0.0.0 0.0.0.0
crypto ipsec transform-setVTI-TS esp-aes
mode transport
crypto ipsec profile VTI-P
set transform-set VTI-TS
interface Tunnel0
tunnel protection ipsec profile DMVPN-P
Отличие от использованных ранее Crypto map в том, что сейчас нет нужды создавать ACL – весь трафик, попадающий в туннель, шифруется (карты шифрования тем не менее по-прежнему создаются, но уже автоматически).
Это получился обычный Tunnel Protection без VTI. Так же широко используется.
Команда tunnel mode ipsec ipv4 указывает на использование VTI.
Отличие от обычного GRE в методах инкапсуляции – в VTI экономится 4 байта путём исключения GRE-заголовка.
DMVPN
Апофеоз сегодняшнего выпуска – DMVPN (Dymamic Multipoint VPN). До сих пор речь была об универсальных вендоронезависымых вещах. К сожалению, DMVPN – вещь сугубо цисковская и открытых адекватных аналогов пока не имеет (поправьте, если ошибаюсь).
В предыдущих частях мы решили проблему с безопасностью передаваемых данных – теперь мы их шифруем – и с IGP – посредством GRE over IPSec мы используем протоколы динамической маршрутизации.
Осталась последняя проблема – масштабируемость.
Хорошо, когда у вас вот такая сеточка:
По два туннеля на каждом узле и всё.
Добавляем ещё один узел:
Нужно уже гораздо больше туннелей для получения полносвязной топологии. Типичная проблема со сложностью m*(m-1)/2.
Если не использовать Full-Mesh, а обратиться к топологии Hub-and-Spoke с одной центральной точкой, то появляется другая проблема – трафик между любыми филиалами будет проходить через центральный узел.
DMVPN позволяет решить обе проблемы.
Суть такая: выбирается центральная точка Hub (или несколько). Она будет сервером, к которому будут подключаться клиенты (Spoke) и получать всю необходимую информацию. При этом:
1) Данные будут зашифрованы IPSec
2) Клиенты могут передавать трафик непосредственно друг другу в обход центрального узла
3) Только на центральном узле необходим статический публичный IP-адрес. Удалённые узлы могут иметь динамический адрес и находиться даже за NATом, используя адреса из частных диапазонов (Технология NAT Traversal ). Но при этом возникают ограничения по части динамических туннелей.
Это всё средоточие мощи GRE и IPSec, сдобренное NHRP и IGP.
Теория и практика DMVPN
Абстрагируясь от нашей старой сети, возьмём в рассмотрение только Москву, сеть Интернет, которую будет эмулировать маршрутизатор Балаган-Телеком, и собственно филиалы в Новосибирске, Томске и Брно:
Новый IP-план:
Подсети, выделенные для подключения к интернету филиалов:
Для туннельных интерфейсов возьмём внутреннюю сеть:
И назначим также адреса Loopback для них:
Идея заключается в том, что на центральном узле будет один единственный динамический туннель, который мы настроим в самом начале, а при добавлении новых удалённых точек, здесь не нужны изменения – ни добавлять новые туннельные интерфейсы, ни перенастраивать уже существующий.
Фактически при добавлении новых узлов настраивать нужно только их.
Везде запускается протокол NHRP – NBMA Next Hop resolution Protocol.
Он позволяет динамически изучать адреса удалённых точек, который желают подключиться к основной.
На нём и основана возможность реализации multipoint VPN. Хаб (центральный узел) здесь выступает как сервер (NHS – Next-Hop Server), а все удалённые узлы будут клиентами (NHC – Next-Hop Client).
Звучит это сложно. На пальцах объяснить тоже не получится. Надо лишь один раз настроить и посмотреть, как бегают пакеты.
interface Tunnel0
ip address 172.16.254.1 255.255.255.0
ip nhrp map multicast dynamic
ip nhrp network-id 1
tunnel source FastEthernet0/1.6
tunnel mode gre multipoint
По порядку:
ip address 172.16.254.1 255.255.255.0 – IP-адрес из нужного диапазона.
ip nhrp map multicast dynamic – Динамическое изучение данных NHRP от клиентов. Поскольку клиентов у нас множество и они могут быть с динамическими адресами, на хабе нельзя задать явное соответствие внутренних и внешних адресов.
ip nhrp network-id 1 – Определяем Network ID – просто идентификатор, который необязательно должен быть одинаковым на всех узлах DMVPN (похож на OSPF Router-ID).
tunnel source FastEthernet0/1.6 – наследие GRE – привязка к физическому интерфейсу.
tunnel mode gre multipoint – Туннель на центральном узле будет терминировать все туннели от удалённых точек. То есть он будет точка-многоточка (Point-to-MultiPoint).
interface Tunnel0
ip address 172.16.254.2 255.255.255.0
ip nhrp map 172.16.254.1 198.51.100.2
ip nhrp map multicast 198.51.100.2
ip nhrp network-id 1
ip nhrp nhs 172.16.254.1
ip nhrp registration no-unique
tunnel source FastEthernet0/0
tunnel mode gre multipoint
По порядку:
ip address 172.16.254.2 255.255.255.0 – IP-адрес из нужного диапазона.
ip nhrp map 172.16.254.1 198.51.100.2 – Статическое соотношение внутреннего и внешнего адресов хаба.
ip nhrp map multicast 198.51.100.2 мультикастовый трафик должен получать хаб.
Без этой команды у вас будут довольно интересные симптомы проблемы.
Вот вы запустили OSPF, пиринг поднимается, хаб и филиалы переходят в состояние Full, обменялись маршрутами, и вы уже радуетесь, что всё отлично, и тут бац – пинг пропадает, пиринг падает, но только с одной стороны, мол истёк dead-timer.
*Mar 1 01:51:20.331: %OSPF-5-ADJCHG: Process 1, Nbr 172.16.255.2 on Tunnel0 from FULL to DOWN, Neighbor Down: Dead timer expired
msk-arbat-gw1#
*Mar 1 01:51:25.435: %OSPF-5-ADJCHG: Process 1, Nbr 172.16.255.2 on Tunnel0 from LOADING to FULL, Loading Done
Что за фигня?
Смотрим дебаг, смотрим дампы
*Mar 1 01:53:44.915: OSPF: Send hello to 224.0.0.5 area 0 on FastEthernet0/1.4 from 172.16.2.1
*Mar 1 01:53:44.919: OSPF: Send hello to 224.0.0.5 area 0 on FastEthernet0/1.7 from 172.16.2.33
*Mar 1 01:53:44.923: OSPF: Send hello to 224.0.0.5 area 0 on FastEthernet0/1.5 from 172.16.2.17
*Mar 1 01:53:44.923: OSPF: Send hello to 224.0.0.5 area 0 on FastEthernet0/1.8 from 172.16.2.129
*Mar 1 01:53:44.963: OSPF: Send hello to 224.0.0.5 area 0 on Tunnel0 from 172.16.254.1
msk-arbat-gw1#
*Mar 1 01:53:54.919: OSPF: Send hello to 224.0.0.5 area 0 on FastEthernet0/1.4 from 172.16.2.1
*Mar 1 01:53:54.923: OSPF: Send hello to 224.0.0.5 area 0 on FastEthernet0/1.7 from 172.16.2.33
*Mar 1 01:53:54.927: OSPF: Send hello to 224.0.0.5 area 0 on FastEthernet0/1.5 from 172.16.2.17
*Mar 1 01:53:54.931: OSPF: Send hello to 224.0.0.5 area 0 on FastEthernet0/1.8 from 172.16.2.129
*Mar 1 01:53:54.963: OSPF: Send hello to 224.0.0.5 area 0 on Tunnel0 from 172.16.254.1
msk-arbat-gw1#
*Mar 1 01:54:04.919: OSPF: Send hello to 224.0.0.5 area 0 on FastEthernet0/1.4 from 172.16.2.1
*Mar 1 01:54:04.927: OSPF: Send hello to 224.0.0.5 area 0 on FastEthernet0/1.7 from 172.16.2.33
*Mar 1 01:54:04.931: OSPF: Send hello to 224.0.0.5 area 0 on FastEthernet0/1.5 from 172.16.2.17
*Mar 1 01:54:04.935: OSPF: Send hello to 224.0.0.5 area 0 on FastEthernet0/1.8 from 172.16.2.129
*Mar 1 01:54:04.963: OSPF: Send hello to 224.0.0.5 area 0 on Tunnel0 from 172.16.254.1
На 5 OSPF Hello от хаба только один Hello от филиала.
Как вы уже поняли, маршрутизатор просто не может сообразить куда посылать мультикастовые сообщения на адрес 224.0.0.5, хаб их не получает и дёргает OSPF-сессию.
ip nhrp network-id 1 – Network ID. Не обязательно должен совпадать с таким же на хабе.
ip nhrp nhs 172.16.254.1 – Статически настроенный адрес NHRP сервера – хаба. Именно поэтому в центре нам нужен статический публичный адрес. Клиенты отправляют запрос на регистрацию на хаб 172.16.254.1. Этот запрос содержит настроенный локальный адрес туннельного интерфейса, а также свой публичный адрес (случай, когда клиент находится за NAT пока не рассматриваем).
Полученную информацию хаб заносит в свою NHRP-таблицу соответствия адресов. Эту же таблицу он распространяет по запросу любому Spoke-маршрутизатору.
ip nhrp registration no-unique – если адрес в филиалах выдаётся динамически, эта команда обязательна.
tunnel source FastEthernet0/0 – привязка к физическому интерфейсу.
tunnel mode gre multipoint – указываем, что тип туннеля mGRE – это позволит создавать динамически туннели не только до хаба, но и до других филиалов.
У нас ситуация простая – без NAT – и мы можем уже сейчас проверить состояние туннелей.
msk-arbat-gw1#sh int tun 0
Tunnel0 is up, line protocol is up
Hardware is Tunnel
Internet address is 172.16.254.1/24
MTU 1514 bytes, BW 9 Kbit, DLY 500000 usec,
reliability 255/255, txload 1/255, rxload 1/255
Encapsulation TUNNEL, loopback not set
Keepalive not set
Tunnel source 198.51.100.2 (FastEthernet0/1.6), destination UNKNOWN
Tunnel protocol/transport multi-GRE/IP
Key disabled, sequencing disabled
Checksumming of packets disabled
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.16.254.2, timeout is 2 seconds:
.
Success rate is 100 percent (5/5), round-trip min/avg/max = 176/213/284 ms
msk-arbat-gw1#sh ip nhrp brief
Target Via NBMA Mode Intfc Claimed
172.16.254.2/32 172.16.254.2 198.51.101.2 dynamic Tu0
msk-arbat-gw1#sh ip nhrp
172.16.254.2/32 via 172.16.254.2, Tunnel0 created 00:09:48, expire 01:50:11
Type: dynamic, Flags: authoritative unique registered
NBMA address: 198.51.101.2
nsk-obsea-gw1#sh ip nhrp brief
Target Via NBMA Mode Intfc Claimed
172.16.254.1/32 172.16.254.1 198.51.100.2 static Tu0
То есть связность уже обеспечена, но работать филиалы пока не могут – не настроена маршрутизация.
Тут для каждого протокола свои всплывают тонкости.
Давайте рассмотрим процесс настройки OSPF, для примера.
Поскольку мы имеем широковещательную L2 сеть на туннельных интерфейсах, указываем явно тип сети Broadcast на туннельных интерфейсах на всех узлах:
router ospf 1
network 172.16.0.0 0.0.255.255 area 0
Gateway of last resort is 198.51.100.1 to network 0.0.0.0
172.16.0.0/16 is variably subnetted, 7 subnets, 3 masks
C 172.16.2.128/30 is directly connected, FastEthernet0/1.8
C 172.16.255.1/32 is directly connected, Loopback0
C 172.16.254.0/24 is directly connected, Tunnel0
C 172.16.2.32/30 is directly connected, FastEthernet0/1.7
C 172.16.2.16/30 is directly connected, FastEthernet0/1.5
C 172.16.2.0/30 is directly connected, FastEthernet0/1.4
O 172.16.255.128/32 [110/11112] via 172.16.254.2, 00:05:14, Tunnel0
198.51.100.0/28 is subnetted, 1 subnets
C 198.51.100.0 is directly connected, FastEthernet0/1.6
S* 0.0.0.0/0 [1/0] via 198.51.100.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.16.255.128, timeout is 2 seconds:
.
Success rate is 100 percent (5/5), round-trip min/avg/max = 60/70/80 ms
Вот так выглядят пакеты, передающиеся через сеть Интернет:
* Дамп с nsk-obsea-gw1 fa0/0
Проверяем, как у нас проходит пинг от одного филиала до другого:
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.16.255.132, timeout is 2 seconds:
.
Success rate is 100 percent (5/5), round-trip min/avg/max = 132/231/492 ms
Type escape sequence to abort.
Tracing the route to 172.16.255.132
1 172.16.254.3 240 msec * 172 msec
nsk-obsea-gw1#sh ip nhrp br
Target Via NBMA Mode Intfc Claimed
172.16.254.1/32 172.16.254.1 198.51.100.2 static Tu0
172.16.254.3/32 172.16.254.3 198.51.102.2 dynamic Tu0
Как видите пакеты не заходят на хаб, а идут напрямую сразу на маршрутизатор другого филиала через Интернет. Но действительность несколько сложнее.
Что происходит в этот момент?
1) Отправляем пинг на адрес Loopback-интерфейса в Томске
2) Согласно таблице маршрутизации, следующий хоп
nsk-obsea-gw1#sh ip route 172.16.255.132
Routing entry for 172.16.255.132/32
Known via «ospf 1», distance 110, metric 11112, type intra area
Last update from 172.16.254.3 on Tunnel0, 00:18:47 ago
Routing Descriptor Blocks:
* 172.16.254.3, from 172.16.255.132, 00:18:47 ago, via Tunnel0
Route metric is 11112, traffic share count is 1
Это адрес из сети, непосредственно подключенной к интерфейсу Tunnel 0
nsk-obsea-gw1#sh ip route 172.16.254.3
Routing entry for 172.16.254.0/24
Known via «connected», distance 0, metric 0 (connected, via interface)
Routing Descriptor Blocks:
* directly connected, via Tunnel0
Route metric is 0, traffic share count is 1
3) Согласно настройкам интерфейса здесь используется NHRP. Смотрим таблицу соответствия, полученную от хаба
nsk-obsea-gw1#sh ip nhrp brief
Target Via NBMA Mode Intfc Claimed
172.16.254.1/32 172.16.254.1 198.51.100.2 static Tu0
Как видите, адрес 172.16.254.3 nhrp неизвестен.
Поэтому пакет ICMP отправляется на статически настроенный хаб – 198.51.100.2:
msk-arbat-gw1, fa0/1:
А хаб сразу же перенаправляет запрос на нужный адрес:
msk-arbat-gw1, fa0/1:
4) Одновременно с этим маршрутизатор-клиент в Новосибирске отправляет NHRP-запрос, мол кто укрывает адрес 172.16.254.3:
msk-arbat-gw1, fa0/1:
5) Хаб обладает этим знанием:
msk-arbat-gw1#sh ip nhr br
Target Via NBMA Mode Intfc Claimed
172.16.254.2/32 172.16.254.2 198.51.101.2 dynamic Tu0
172.16.254.3/32 172.16.254.3 198.51.102.2 dynamic Tu0
И отправляет эту информацию в NHRP-ответе:
msk-arbat-gw1, fa0/1:
Больше Хаб не встревает в разговор двух споков.
6) ICMP запрос пришёл в Томск:
tmsk-lenina-gw1, fa0/0:
Несмотря на то, что во внешнем заголовке IP адрес источника – это адрес хаба, внутри фигурирует изначальный адрес Новосибирского маршрутизатора:
7)Томск тоже пока не знает ничего об адресе 172.16.254.2, пославшем ICMP-запрос.
tmsk-lenina-gw1(config-if)#do sh ip nh br
Target Via NBMA Mode Intfc Claimed
172.16.254.1/32 172.16.254.1 198.51.100.2 static Tu0
Поэтому ICMP-ответ он отправляет тоже на хаб:
tmsk-lenina-gw1, fa0/0:
8) Следом за ним он интересуется о публичном адресе отправителя:
tmsk-lenina-gw1, fa0/0:
9)Ну и хаб, естественно, отвечает:
tmsk-lenina-gw1, fa0/0:
10) Сейчас на всех узлах актуальная информация NHRP:
msk-arbat-gw1(config-if)#do sh ip nhr br
Target Via NBMA Mode Intfc Claimed
172.16.254.2/32 172.16.254.2 198.51.101.2 dynamic Tu0
172.16.254.3/32 172.16.254.3 198.51.102.2 dynamic Tu0
nsk-obsea-gw1(config-if)#do sh ip nhr br
Target Via NBMA Mode Intfc Claimed
172.16.254.1/32 172.16.254.1 198.51.100.2 static Tu0
172.16.254.3/32 172.16.254.3 198.51.102.2 dynamic Tu0
tmsk-lenina-gw1(config-if)#do sh ip nh br
Target Via NBMA Mode Intfc Claimed
172.16.254.1/32 172.16.254.1 198.51.100.2 static Tu0
172.16.254.2/32 172.16.254.2 198.51.101.2 dynamic Tu0
Как видите, распространение происходит не автоматически, а по запросу, причём инициаторами являются только клиенты, потому что фактически, только они знают, куда обращаться (хаб изначально не знает о клиентах ничего)
11) Следующий ICMP-запрос он уже отправит по-новому:
nsk-obsea-gw1#sh ip route 172.16.255.132
Routing entry for 172.16.255.132/32
Known via «ospf 1», distance 110, metric 11112, type intra area
Last update from 172.16.254.3 on Tunnel0, 00:20:24 ago
Routing Descriptor Blocks:
* 172.16.254.3, from 172.16.255.132, 00:20:24 ago, via Tunnel0
Route metric is 11112, traffic share count is 1
Подсеть 172.16.254.0 подключена к интерфейсу Tunnel 0
nsk-obsea-gw1#sh ip route 172.16.254.3
Routing entry for 172.16.254.0/24
Known via «connected», distance 0, metric 0 (connected, via interface)
Routing Descriptor Blocks:
* directly connected, via Tunnel0
Route metric is 0, traffic share count is 1
12) Мы немного повторяемся, но… Интерфейс Tunnel 0 является mGRE и согласно таблицы NHRP весь трафик, для которого следующим хопом является 172.16.254.3 должен быть инкапсулирован в GRE и внешний IP-заголовок с адресом назначения 198.51.102.2 (В качестве адреса источника будет выбран адрес физического интерфейса – 198.51.101.2):
nsk-obsea-gw1(config-if)#do sh ip nhr br
Target Via NBMA Mode Intfc Claimed
172.16.254.1/32 172.16.254.1 198.51.100.2 static Tu0
172.16.254.3/32 172.16.254.3 198.51.102.2 dynamic Tu0
tmsk-lenina-gw1, fa0/0:
13) Ну и дальше пакет с адресом получателя 198.51.102.2 отправляется согласно таблице маршрутизации:
Gateway of last resort is 198.51.101.1 to network 0.0.0.0
Тут важно понимать, что несмотря на то, что общение между филиалами осуществляется в обход центрального узла, хаб однако несёт тут жизненно важную вспомогательную функцию и без него ничего работать не будет: он предоставляет клиентам таблицу NHRP, а также анонсирует все маршруты – филиалы распространяют маршрутную информацию не непосредственно друг другу, а через хаб.
Актуальная на данный момент конфигурация узлов:
msk-arbat-gw1
interface Tunnel0
ip address 172.16.254.1 255.255.255.0
no ip redirects
ip nhrp map multicast dynamic
ip nhrp network-id 1
ip ospf network broadcast
ip ospf priority 10
tunnel source FastEthernet0/1.6
tunnel mode gre multipoint
nsk-obsea-gw1
interface Tunnel0
ip address 172.16.254.2 255.255.255.0
no ip redirects
ip nhrp map 172.16.254.1 198.51.100.2
ip nhrp map multicast 198.51.100.2
ip nhrp network-id 1
ip nhrp nhs 172.16.254.1
ip ospf network broadcast
ip ospf priority 0
tunnel source FastEthernet0/0
tunnel mode gre multipoint
tmsk-leneina-gw1
interface Tunnel0
ip address 172.16.254.3 255.255.255.0
no ip redirects
ip nhrp map 172.16.254.1 198.51.100.2
ip nhrp map multicast 198.51.100.2
ip nhrp network-id 1
ip nhrp nhs 172.16.254.1
ip ospf network broadcast
ip ospf priority 0
tunnel source FastEthernet0/0
tunnel mode gre multipoint
end
На данный момент решены следующие проблемы:
1) Связность. Филиалы подключены и доступны.
2) Маршрутизация. Через mGRE туннели успешно запущены IGP.
3) Масштабируемость. При добавлении нового spoke-маршрутизатора настраивается только он сам и нет необходимости лезть в конфигурацию уже существующих узлов.
4) Разгрузили хаб – через него передаётся только служебный трафик.
Осталось уладить вопрос с безопасностью.
IPSec
Решается это как и прежде – шифрованием.
Если для Site-to-Site VPN мы ещё могли использовать pre-shared key, потому что мы жёстко задавали адрес IPSec-пира, то в случае DMVPN нам нужна гибкость, а заранее мы не знаем адреса соседей.
В связи с этим рекомендуется использование сертификатов. На xgu есть хорошая статья по центру сертификатов на cisco.
Но мы для упрощения возьмём всё же настройку с pre-shared ключом.
crypto isakmp policy 1
authentication pre-share
crypto isakmp key DMVPNpass address 0.0.0.0 0.0.0.0
Опасность здесь в том, что установить IPSec-сессию с хабом, зная ключ, может любое устройство
Тут можно спокойно использовать транспортный режим:
crypto ipsec transform-set AES128-SHA esp-aes esp-sha-hmac
mode transport
crypto ipsec profile DMVPN-P
set transform-set AES128-SHA
interface Tunnel0
tunnel protection ipsec profile DMVPN-P
Теперь пакеты, передающиеся через Интернет будут зашифрованы:
msk-arbat-gw1, fa0/1:
Только не вздумайте поставить tunnel mode ipsec ipv4 🙂
IPSec-туннели и карты шифрования будут создаваться динамически для сеансов передачи данных между филиалами и будут перманентными для каналов Hub-Spoke.
NAT-Traversal
Тут мы не будем вдаваться в принципы работы NAT-T Передам только суть: за счёт дополнительного UDP-заголовка IPSec может строить туннель сквозь NAT. Это позволяет строить VPN даже на тех узлах, где у вас нет публичного адреса.
Нет необходимости этот функционал каким-то особым образом активировать и настраивать – он работает по умолчанию.
Усложним схему добавлением ещё одного маршрутизатора в Брно.
Допустим, это провайдерская железка, осуществляющая натирование. То есть фактически на роутере в филиале у нас будет динамический адрес из приватного диапазона на физическом интерфейсе. GRE в чистом виде не может построить VPN при таких условиях, IPSec может, но сложно настраивать. mGRE в связке с IPSec может легко!
Давайте посмотрим как выглядит таблица NHRP в этом случае:
msk-arbat-gw1#show ip nhrp brief
Target Via NBMA Mode Intfc Claimed
172.16.254.4/32 172.16.254.4 10.0.0.2 dynamic Tu0
То есть изучил он всё-таки приватный адрес, выделенный провайдером.
Надо заметить, что в таблице маршрутизации должен быть маршрут до этого приватного адреса, выданного провайдером в филиале, пусть даже дефолтный.
На туннельном интерфейсе у нас активирован IPSec, следовательно должны быть карты шифрования:
msk-arbat-gw1#show crypto map
Crypto Map «Tunnel0-head-0» 65537 ipsec-isakmp
Map is a PROFILE INSTANCE.
Peer = 198.51.103.2
Extended IP access list
access-list permit gre host 198.51.100.2 host 10.0.0.2
Current peer: 198.51.103.2
Security association lifetime: 4608000 kilobytes/3600 seconds
PFS (Y/N): N
Transform sets= <
AES128-SHA,
>
Interfaces using crypto map Tunnel0-head-0:
Tunnel0
Таким образом шифрованный туннель строится между 198.51.100.2 и 198.51.103.2, дальше, данные по-прежнему шифрованные за счёт NAT-T в туннеле идут до 10.0.0.2. А дальше вы уже знаете.
Толковая подробная статья по NHRP.
Сценарий:
Сеть DMVPN была полностью работоспособной, всё работало корректно.
Но после перезагрузки хаба msk-arbat-gw1 началось странное поведение.
Задание:
1. Проверить работоспособность сети.
2. Перезагрузить хаб
3. После перезагрузки проверить работоспособность сети ещё раз
4. Устранить проблему:
4.1. (минимум) Сделать сеть снова работоспособной
4.2. Сделать так, чтобы сеть восстанавливалась автоматически, после того как хаб снова появится.
TShoot IPSec
На последок хочется сказать пару слов о том, как решать проблемы с IPSec. Процедура-то далеко не тривиальная.
При траблшутинге VPN огромную роль играют дебаги. Метод пристального взгляда на конфиг менее надежен – легко пропустить небольшую ошибку.
Исключительно ценным инструментом в траблшутинге IPSec является sh crypto ipsec sa. Нет, дело даже не в бинарном «поднялось — не поднялось», а в счетчиках, в первую очередь encaps-decaps. Можно пустить непрерывный пинг и наблюдать, какой из счетчиков растет. Большинство проблем удается локализовать именно таким образом.
Счетчики вообще не растут? См. куда применен крипто мап и все ли в порядке с ACL.
Растут error? Что-то не так с согласованием, см. дебаг.
Растут encaps, но нет decaps? Вперед изучать противоположную сторону туннеля, тут все хорошо.
Напоследок обсудим один коварный момент – размер MTU. В жизни каждого системного/сетевого администратора наступает момент, когда симптомы проблемы таковы: открывается яндекс, работает пинг, но ни один другой сайт не доступен и Outlook не коннектится.
Дьявол кроется в размере MTU и наличии дополнительных заголовков.
MTU – Maximum Transmission Unit. Это максимальный размер блока данных, который может быть передан через интерфейс. Это понятие находится на пересечении L2 и L3 и его интерпретация может различаться для разных вендоров.
Например, типичный размер MTU для физического L3-интерфейса 1500. То есть, грубо говоря, IP-пакет размером 1500 байт будет обработан, а 1501 – отброшен или фрагментирован. Зачастую фрагментация пакетов запрещена, и потому большие пакеты отбрасываются.
Если вы используете туннелирование, размер пакета увеличивается засчёт дополнительных заголовков (GRE, IPSec и т.д.)
Например, для GRE: 24 байта (GRE, Новый IP).
Для GRE over IPSec: 56 и более байтов (зависит от режима работы и типа шифрования)
Для PPPoE: 36 (PPP, PPPoE, Ethernet)
Сам туннельный интерфейс имеет стандартный MTU 1514 и пропускает такие пакеты, но у провайдера на физическом интерфейсе стоит MTU=1500, и на нём пакет будет отброшен:
R1#sh int tun 0
Tunnel0 is up, line protocol is up
Hardware is Tunnel
Internet address is 10.2.2.1/30
MTU 1514 bytes, BW 9 Kbit, DLY 500000 usec,
R1#sh int fa0/1
FastEthernet0/1 is administratively down, line protocol is down
Hardware is Gt96k FE, address is c000.19ac.0001 (bia c000.19ac.0001)
MTU 1500 bytes, BW 10000 Kbit, DLY 1000 usec,
То есть вы должны учитывать не только свои настройки, но и настройки всех промежуточных узлов.
Зачастую у вас нет возможности влиять на MTU по пути.
Поэтому вы можете уменьшить MTU, на локальной стороне, использовать механизм Path MTU Discovery или даже настраивать MSS – Maximum Segment Size (относится уже к TCP).
Подробнее о проблемах с MTU читайте тут и тут
Для всевозможных туннелей это совершенно типичная проблема.
Почему же работают пинг и яндекс?
Пакеты ICMP Request и Relpy имеют размер от 32 до 64 байтов, ya.ru возвращает очень мало информации, которая вполне укладывается в допустимый размер 1500 вместе со всеми заголовками.
P.S.К сожалению, незатронутыми остались следующие небезынтересные темы:
Полностью пролетели мимо темы удалённого доступа для сотрудников.
Кроме того очень актуальна сейчас тема FlexVPN. Это новый виток развития VPN-технологий. Но использует IKE версии 2 и поддерживается в данный момент, как обычно только оборудованием cisco.
Нам бы действительно хотелось уделить внимание и этим и тем и вот ещё тем темам, но всё уложить в рамки одной статьи невозможно.
Материалы выпуска
Полезные ссылки
Статью для вас подготовили eucariot и thegluck
За мозгодробительные задачки спасибо Наташе.
За комментарии и помощь спасибо JDima.
У цикла “Сети для самых маленьких” есть свой сайт: linkmeup.ru, где вы сможете найти все выпуски аккуратно сложенными и готовыми к вдумчивому чтению.
И в качестве минутки саморекламы: на прошлой неделе вышел нулевой выпуск подкаста для связистов.