IPsec: IKE, Диффи-Хеллман и инкапсуляция

Так, коллеги, у нас с вами сегодня 10 октября, это уже получается 7-й день курса Cisco Industry 0, и мы вплотную подобрались к теме виртуальных частных сетей VPN. Мы с вами сейчас будем грызть теорию, теории будет много, не бойтесь, она несложная, здесь никакой супер математики не будет. Я думаю, что вы убедились, что даже самые сложные темы мы с вами превращаем в простые. И в частности будет серьезный разговор про IPsec, потому что всё кончается на нём, дальше буду про это говорить. Но для начала немножечко классификации. Мы с вами слово «классификация» уже успели подзабыть с первых дней нашего курса, но здесь тоже есть что классифицировать и есть что

разложить по полочкам. Вполне возможно, что кто-то вас спросит про это, например, на экзамене. Виртуальные частные сети — все виртуальные частные сети можно классифицировать по следующим признакам. Какие они бывают? Во-первых, по типу доступа. VPN бывают двух типов: либо это будет VPN так называемый site-to-site, когда мы будем соединять две сети, либо это будет VPN remote access, когда с одной стороны будет какая-то сеть, а с другой стороны будет единичный один абонент. Remote access — не обязательно это будет какой-то человек, человечек, вот у нас такой нарисованный в свитере с компьютером, не обязательно это будет мобильный телефон, это тоже может быть какой-то роутер, но смысл в том, что он будет единичным

абонентом, единственным, и именно с этого устройства нужно получить доступ в какую-то сеть. Это remote access VPN. Всё, что у нас будет подразумевать соединение двух сетей или больше сетей — это всё называется site-to-site VPN. На самом деле здесь нельзя говорить про соединение больше двух сетей, потому что в результате всё равно у нас всегда будет соединение point-to-point. В технологиях VPN всегда будет устанавливаться туннель от одного устройства к другому устройству. Есть технологии типа DMVPN в Cisco, когда получается практически NBMA-сеть с множественным доступом, но всё равно это всегда будут site-to-site туннели, всегда будет соединение point-to-point присутствовать, это очень важно. По типу

связываемых сетей — либо это будет intranet, два сайта, которые принадлежат одной компании, либо будет это какой-то extranet. Мы с вами говорили, что такое экстранет — это удалённые сети, не под нашим административным руководством, но те сети, которые нужно связать вместе с нами. Экстранет — такое слово немножко нам непривычное. Либо по технологии подключения. Технологий VPN придумано за всю историю сетей немало. В настоящее время многие из них умерли, многие остались, но основные — это будут либо IPsec, либо что-то на основе SSL, либо может быть L2TP, может быть GRE, обычный GRE-туннель — это тоже будет VPN, и PPTP, и другие. Сразу L2TP — живее всех живых, им часто пользуются. Более

того, я скажу, что я сам пользуюсь L2TP. Почему нет? L2TP хорош тем, что он реализован как стандартная возможность в той же Windows, в операционных системах, поэтому не требуется никаких специальных клиентов. Он удобный — взял, настроил в той же Windows, и он работает. Почему нет? Он жив, это нормальная технология, не стоит говорить, что это ерунда. Сразу может возникнуть вопрос: каким боком здесь GRE и IP-in-IP? Вроде бы шифрования-то нет. Ответ на этот вопрос будет очень простой: шифрование в VPN не является обязательным. Очень часто

ставят знак равенства между VPN и шифрованием. На самом деле шифрование в VPN не обязательно, оно факультативно. Так что простой GRE-туннель тоже можно рассматривать как VPN, если он выполняет свои функции. Хотя сейчас VPN без шифрования как-то не очень интересен. Теперь давайте поговорим уже про IPsec. IPsec — это одна из технологий, которая будет востребована для реализации VPN. Нельзя сказать, что это какой-то протокол, нет, это фреймворк, наверное, это будет самое подходящее слово. Это набор технологий, набор

протоколов, набор стандартов, который будет совершенно чётко описан, структурирован, и с помощью этого фреймворка мы можем уже устанавливать VPN-соединения. Какие функции будут у IPsec? Если вспомнить основные задачи безопасности CIA, они здесь все будут у нас присутствовать. Про доступность можно поспорить, хотя тоже. Конфиденциальность — IPsec будет исключать чтение данных третьей стороной с помощью шифрования. Будет конфиденциальность обеспечиваться шифрованием, мы с вами уже знакомы, и здесь никаких прям открытий для нас не будет. Хотя одно открытие нас ждёт в части шифрования. Целостность данных в IPsec будет обеспечиваться с помощью обычной хэш-подписи сообщений, то, о чём мы с вами уже тоже

говорили. Аутентификация источника здесь тоже будет работать — будем удостоверяться, что соединение установлено с доверенной стороной. Мы будем дальше говорить про протокол IKE, все по-разному это произносят, и именно в нём и будет реализована аутентификация, она может быть реализована по-разному. Запрет повторной передачи — это достаточно важная штука: в IPsec каждый пакет будет проверяться на его уникальность, чтобы исключить возможность повторов, то есть передать один и тот же пакет в IPsec невозможно. Управление ключами — опять же IPsec предусматривает автоматизированное управление ключами. Помните, мы с вами говорили вообще про важность криптографических ключей, про то,

что именно нужно уметь ими управлять, нужно правильно генерировать, и что самое главное — периодически обновлять. Как это сделать через интернет, тот же самый, через недоверенную среду, как обновлять эти ключи — всё это будет описано в IPsec, и мы с вами с этим познакомимся. По кусочкам, как я сказал, это фреймворк, и в него входит куча разных кирпичиков. У нас дальше будет слайд с этими кирпичиками, сейчас поговорим про каждую из функций. Во-первых, шифрование. Для шифрования данных в IPsec используется симметричный алгоритм шифрования с общим ключом, который у нас быстрый и достаточно надёжный. Здесь может использоваться куча всяких алгоритмов: и DES, и 3DES, AES, и RC4, и те же самые семейства RC4, либо даже наш ГОСТовский алгоритм. Никто не

запрещает использовать даже свой придуманный алгоритм, который вы сами придумаете, опишете и реализуете в программном коде. Почему нет? В IPsec можно использовать свои алгоритмы, но есть какие-то устоявшиеся практики. Мы с вами будем дальше говорить про криптографические стандарты, всё-таки стандартов лучше придерживаться в выборе алгоритмов. Аутентификация — Миша говорит, можно «набор протоколов» вместо «фреймворк». Здесь набор не только протоколов, Миш. Фреймворк — это можно перевести как набор компонентов. Можно говорить «набор компонентов», потому что там кроме протоколов ещё много всего будет: протоколы, алгоритмы шифрования, набор стандартов — короче, компоненты. Ладно, это терминологическая штука, которая в русском языке не очень предусмотрена для описания IPsec. По

поводу аутентификации — смотрите, аутентификация в IPsec будет реализована с помощью нескольких различных механизмов. Самый простой — это pre-shared key, общий ключ, про который мы с вами уже тоже где-то говорили, когда просто у двух сторон обмена сообщениями есть какой-то общий ключ, который мы будем использовать для подписи этих сообщений. На самом деле штука в принципе нормальная. Можно встретить очень много споров по поводу использования общего ключа, что это плохо. Я не могу сказать, что это прямо совсем плохо, если этот общий ключ с какой-то периодичностью менять. Например, как в

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

общего ключа, который в принципе проще всего использовать, мы также можем использовать те же самые RSA-подписи, когда мы будем использовать уже сертификаты, мы будем с вами просто сначала обмениваться своими цифровыми сертификатами, а потом с помощью приватных и открытых ключей, с помощью асимметричного шифрования, будем уже удостоверять, будем подписывать сообщения. Есть ещё одна техника, которая здесь называется RSA nonces, про неё нужно сказать, про неё нужно вам знать. Сейчас, одну секундочку, сейчас, Роман, я прокомментирую. Про RSA nonces немножко поговорим. Nonce — это случайное число, сгенерированное каким-либо из участников

обмена. RSA nonces — это тоже на основании асимметричной криптографии будет обмен, просто здесь будут фигурировать эти случайные числа. Мы с вами ещё где-то, по-моему, это ещё у нас всплывёт. На самом деле просто запомните: это применяется не так часто, этот метод, гораздо популярнее просто RSA-подписи. Есть ещё ECDSA — это опять же будет асимметричное шифрование использоваться, то же самое, как RSA, просто здесь будут использоваться другие алгоритмы с использованием эллиптических кривых. И Kerberos классический также можем использовать как аутентификацию в IPsec. Роман говорит, что с банком

настраивал по общему ключу, 24 символа, в двух частях. Да, это нормально, рекомендации по безопасности — это совершенно нормально работать по общему ключу. Единственное — как его передать, вот и всё. Здесь вся фишка не в том, что плохо использовать общий ключ, а вся фишка в том, как безопасно этот общий ключ передать. Вот и всё. Банк придумал такой способ, когда одна часть одним каналом передаётся, другая часть — другим каналом. Очень здорово. Здесь даже 24 символа — это не сам ключ, это исходный материал, из которого будет генерироваться потом ключ. Наверно, правильно сказать — ключевая фраза. По поводу управления ключами — смотрите, я повторяюсь, мы уже с вами говорили

про то, что в криптографии наиболее важная проблема — это то, как передать безопасно ключ. Мы смотрели, как можно передать ключ с использованием асимметричного шифрования. Помните рассказ про установку соединения SSH1? В SSH2 я тогда сказал, что такая схема уже не используется, там будет использоваться немножко другая схема. Эта другая схема — это будет алгоритм Диффи-Хеллмана. Надо запомнить, что существует такой алгоритм, мы его с вами разберём в общих чертах, чтобы вы понимали хотя бы, о чём идёт речь. Алгоритм Диффи-Хеллмана — это способ сгенерировать общий ключ так, чтобы не передавать этот ключ никаким образом между участниками. Немножечко хитрый способ, математический. Он на самом деле не очень сложный. Если у кого-то хорошо с математикой, вы сейчас

посмотрите дальше на слайды и всё сразу поймёте. Если у кого-то не очень хорошо с математикой — не обязательно запоминать этот алгоритм, главное просто понять смысл применения этого алгоритма. Есть его усиленная модификация, там уже будет с эллиптическими кривыми. Математику лучше даже не спрашивайте меня, что это такое, я вам всё равно нормально это не объясню. Проверка целостности — проверка целостности — это тот самый старый добрый HMAC и CMAC, обычная подпись, хэш с ключом. Здесь ничего такого нового мы не встретим. Вот эти самые кирпичики, из которых будет строиться фреймворк IPsec. Какие будут у нас собственно компоненты во фреймворке, которые мы не упомянули? Во-первых, это протоколы. В IPsec можно использовать два стандартизированных протокола для того, чтобы

защищать наши пакетики. Есть у нас протокол ESP — Encapsulating Security Payload, этот протокол у нас будет обеспечивать шифрование и целостность. Либо у нас есть просто протокол AH — Authentication Header, это будет протокол, с помощью которого мы будем просто подписывать сообщения. Он будет обеспечивать только целостность. При использовании Authentication Header шифрование обеспечиваться не будет. Вот эти два протокола, с помощью которых мы будем наш пакет защищать. Их можно комбинировать, кстати, что в принципе встречается не так часто, хотя нет, часто тоже встречается. Про конфиденциальность мы сказали, что будут

использоваться разные алгоритмы шифрования. Целостность данных здесь у нас будет с помощью хэшей обеспечиваться — те же самые MD5 и SHA-1, SHA-2. Про это уже говорили. Про аутентификацию мы сказали. И управление ключами — это будет либо Диффи-Хеллман, либо Диффи-Хеллман. Здесь у нас не особо получится по-другому управлять ключами, потому что Диффи-Хеллман — совершенно стандартная штука в IPsec. IKE1 и IKE2 — это служебные протоколы, которые будут внутри использовать тот же самый Диффи-Хеллман. Иннокентий показывал доступный ролик про Диффи-Хеллмана из YouTube, и я найду для вас этот ролик, брошу ссылочку, когда мы подойдём к Диффи-Хеллману, чтобы было понятно. Секундочку. Откуда такие —

RSA signatures — это просто имеется в виду аутентификация по сертификатам. А RSA encrypted — это как раз encrypted nonces, вот эти — это будет ещё с использованием случайных чисел. Не забегайте вперёд, Ром. Давайте про протокол IKE поговорим. Internet Key Exchange — этот протокол является стандартной частью IPsec. Он имеет две версии: IKE1 и IKE2. Кстати, по поводу IKE2 — столько я вижу вопросов с выпученными глазами во всяких интернет-конференциях: «Блин, ё-моё, что делать, IKE2 даёт...» Почему-то все думают, что он

сложнее. На самом деле мы разберём, Андрей, он на самом деле проще. Он вообще проще, ничего такого нет. Я не понимаю. Сейчас давайте по слайду пробегусь и обо всём обстоятельно поговорим. Что делает протокол IKE? Во-первых, согласование параметров. Здесь есть новый термин, которого мы ещё не касались. Этот термин у нас будет звучать как SA — Security Association. Security Association — это некая сущность, на самом деле это массив данных, в котором будут у нас определены все параметры для нашего соединения. SA — просто запомните, что SA — это какая-то коробочка, в которой лежат нужные параметры: что и как делать в процессе установления соединения, в процессе соединения. Об этом сейчас всё поговорим.

Протокол IKE будет согласовывать все эти параметры, потому что две стороны IPsec-соединения должны, естественно, договориться обо всех этих параметрах. Все эти кирпичики берутся по одному из каждой строчки, но они должны совпадать с двух сторон, иначе ничего не заведётся, иначе просто не договоримся. Потому что если одна сторона будет подписывать данные с помощью MD5, а вторая будет думать, что подписывается с помощью SHA-1, просто между ними дружбы не сложится. Так что согласование параметров в IPsec очень важно. Забегая вперёд, скажу, что 90 процентов всего траблшутинга IPsec —

это как пить дать, в согласовании параметров. 99 процентов... Нет, это конечно нельзя огульно говорить, но по моему опыту, по моим наблюдениям, процентов 90 всех ошибок в настройке IPsec — это согласование параметров. Особенно когда за IPsec, за настройку берутся люди, которые в принципе представляют, но что там внутри — они не особо заморачиваются. Тогда все эти параметры, когда ты не понимаешь, что вот это означает, что вот это значит — это правда очень сложно. Но мы с вами всё это разберём, и точно скажу, что IPsec будете настраивать на раз-два. Ну, как на раз-два — если реализация не кривая, то всё будете настраивать правильно. По крайней мере вы будете точно знать, что что означает. Что ещё делает IKE? Генерация ключей — управление алгоритмом Диффи-Хеллмана, это всё будет в рамках

протокола IKE. Аутентификация соседей. Перегенерация ключей по каким-то критериям: либо это временной критерий, когда мы можем ключи перегенерировать раз в сколько-то там секунд, либо перегенерация ключей у нас может ещё происходить по количеству трафика — мы отправили 100 килобайт, давайте перегенерируем. Я вам рассказывал такую историю. IKE2 — это современная версия протокола, в которой есть несколько улучшений по сравнению с IKE1. Она проще, она быстрее считается. Ну, как быстрее — здесь скорость работы протокола IKE она в принципе не особо играет роль, если вы не устанавливаете соединение каждые две секунды, не переустанавливаете соединение. В принципе не особо можно париться. IKE2, конечно, работает быстрее, потому что он просто меньше

транзакций, меньше сообщений требует. Штатная поддержка расширений. За время существования IKE первой версии был придуман ряд костылей. Например, NAT traversal, когда нужно IPsec пробросить через NAT. Эта штука, которая важна, этот костыль был придуман уже давно, но в IKE2 он уже включён по умолчанию и будет работать. Dead peer detection — это когда мы будем опрашивать нашего соседа, тыкать палочкой, как любит Иннокентий говорить, и понимать — умер он или не умер, чтобы просто освободить оперативную память. Тоже нужная вещь. Надёжность: в IKE2 есть защита от повторов, подтверждения и коррекция ошибок. Гибкость конфигурирования —

сейчас про NAT traversal поговорю. Гибкость конфигурирования — здесь можно... В IKE1 тоже есть защита от повтора, конечно. Дальше, здесь можно использовать тот же самый EAP — Extensible Authentication Protocol, если я правильно расшифровал. Мы тоже — мы с вами два слова сказали, мы его вообще на курсе не разбираем, это слишком большая тема. Это тоже своеобразный фреймворк, внутри которого можно любые протоколы аутентификации использовать. Мобильность — MOBIKE для роуминга на сетевом уровне. Вообще роуминг на сетевом уровне — это тема, которая ни в одном известном мне курсе не рассматривается. Чуть-чуть там где-то я про неё то ли в CCNP Service Provider видел упоминание, в каких-то сессиях чуть-чуть просто касаются, но вообще роуминг — это...

Примеры роуминга на сетевом уровне. Роуминг на сетевом уровне — это костыль, который был придуман ещё в эпоху IPv4, костыль, который перешёл в IPv6 на уровне спецификации изначально, но которым никто не пользуется, и не знаю, будут ли пользоваться. Смысл роуминга очень простой: когда мы можем менять наш IP-адрес, когда мы можем менять, скажем, провайдера, как вот вы путешествуете со своим телефоном, вы перепрыгиваете из одной сети Wi-Fi в другую, но вместе с тем сохраняете все свои сессии, например TCP-сессии — вот это роуминг. Он будет осуществляться с помощью различных костылей. По-другому назвать эти вещи, наверное, пока нельзя. Там много разных хитрых

реализаций. А MOBIKE — это как раз расширение протокола IKE2, чтобы роуминг работал. На самом деле не знаю, куда всё это приведёт. NAT traversal — мы с вами... Давайте сейчас в двух словах. Какая, в чём проблема передать IPsec-пакет через NAT? Проблема в том, что у нас будет роутер перебивать сетевые адреса. Давайте чуть попозже, когда начнём про туннельный режим говорить, да, вот просто — что во что запаковывается, вы там сразу увидите. Просто дело в том, что оригинальный пакет, например зашифрованный, там шифруется полностью, полностью этот пакет вместе с IP-адресами. Роутер будет

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

вся эта дополнительная конструкция пакета — сейчас перейдём к слайдам, поговорим — будет ещё дополнительно запаковываться в UDP. И вот этот UDP уже можно там перебивать как угодно. То есть просто ещё дополнительная одна инкапсуляция, чтобы пройти через NAT. Вот и всё. Ну, кровь из ушей пошла — это нормально. Мы про IPsec говорим. Давайте поговорим про обмены. Да. Давайте теперь про те самые фазы, которые тоже вы про них слышали наверняка. Кто не очень хорошо знает IPsec — сейчас во всё врубитесь. Очень часто говорят: первая фаза, вторая фаза — что за ерунда? Давайте разбираться. Ещё раз напоминаю: протокол IKE —

это тот кусочек IPsec, который будет просто устанавливать начальное соединение. Собственно, здесь будет больше всего геморроя, траблшутинга, и здесь больше всего будет ошибок. Протокол IKE будет работать — его работа будет состоять из двух фаз. Так, протокол IKE будет работать, его работа будет состоять из двух фаз. Первая фаза — это будет согласование. Он будет согласовывать на самом деле два туннеля. Если говорить, например, про туннели IPsec, на самом-то деле там целых два будет туннеля, сейчас мы поговорим. Первый туннель — это будет такой служебный туннель, который в принципе нужен для согласования параметров и для того, чтобы подготовить работу второго туннеля. Второй туннель, который будет во второй фазе строиться —

вот это уже боевой трафик. Это уже будет нормальное шифрование симметричное, там уже будут боевые данные бегать. А по первому туннельчику там будут только служебные данные бегать. Например, перегенерация ключа периодическая, либо сообщение «ты живой? — я не живой», dead peer detection — это будет работать в первом туннеле. Просто представляете, да, что есть два туннеля? И что ещё вообще в фазе 1... Первая фаза — построение первого туннеля. Там есть два режима: main mode, простой режим, и aggressive mode. Есть некоторое количество сообщений, которые должны передать участники друг другу, чтобы согласовать все параметры и установить этот туннель.

В обычном режиме этих сообщений будет 9, в агрессивном режиме их будет меньше — там просто некоторая информация будет передаваться за одно сообщение, сразу несколько параметров. Не будем разбирать сейчас очень подробно, просто запомните, что есть агрессивный режим и простой режим. Агрессивный режим считается менее безопасным, потому что там сначала пойдут нешифрованные сообщения, и в них в принципе что-то можно перехватить. Aggressive mode нужен просто для ускорения согласования. Трафик там копеечный, экономить здесь не имеет никакого смысла, просто чтобы отработало чуть-чуть побыстрее. На быстрых каналах нельзя говорить про секунды, это будут миллисекунды. Просто 9 сообщений и 6 сообщений, 9 пакетов и 6 пакетов — разница в принципе не такая уж и большая. Наверное, игра не стоит свеч на современных каналах связи.

Теперь смотрите, дальше чуть-чуть развёрнуто основной режим. Там будут три действия: сначала согласование политик IKE — мы сейчас про политики будем подробно говорить — потом будет создание ключей, и в конце будет аутентификация соседей. В агрессивном режиме первые два действия — согласование политик и создание ключа — будут объединяться в одно, и в принципе на одно сообщение меньше, но возможности согласования ограничены. Не надо так прямо бояться этого агрессивного режима, все его боятся, а там ничего супер-небезопасного нет. Ключи перегенерируются. Понимаете, все эти танцы с бубном вокруг IPsec, вокруг его безопасности — какой режим безопаснее, какой небезопаснее — это всё идёт только вокруг ключей, передачи ключей. Всё равно будет работать тот же Диффи-Хеллман классический, всё равно ключи будут перегенерироваться со временем.

Про IKE версии 1 — смотрите, почему, например, лучше использовать IKE версии 2. Кстати, мне кто-то недавно спрашивал — не помню кто — какой аргумент привести, чтобы перейти на IKE версии 2, какой есть железный аргумент. Давайте я вам расскажу про этот один аргумент. Он, наверное, самый главный, самый железный, с ним поспорить трудно. Смотрите, IKE версии 1, давайте про основной режим поговорим, имеет одну очень нехорошую особенность. Вот какую: аутентификация соседей выполняется в последнюю очередь. Сначала, когда связываются два участника IPsec — две стороны туннеля — сначала они будут согласовывать политики, потом они будут создавать ключи, а уже потом, в последнюю очередь, они будут друг друга аутентифицировать, чтобы выяснить, кто есть кто.

Так вот, создание ключей, мы с вами говорили, штука на самом деле затратная. И в этом случае для злоумышленников открывается прекрасная возможность. Какой тип атак будет здесь? Это же простой DoS. Всё правильно, Роман говорит: IKE версии 1 подвержен DoS-атакам. Злоумышленник может насогласовывать с вами, открыть очень много соединений, согласовать какие-то параметры, может быть даже очень тяжёлые параметры — например, согласовать, что мы будем использовать самое мощное шифрование, самые длинные ключи, — а потом заставить какой-то роутер начать генерировать эти ключи. И он будет устанавливать эти соединения с очень большой интенсивностью и в очень большом количестве,

и бедный несчастный роутер просто загнётся. Он будет пытаться сначала сгенерировать ключи для всех этих соединений, даже не выяснив, а кто вообще с другой стороны. Поэтому имейте в виду: в IKE версии 2 это уже поправили — сначала будет аутентификация, а потом уже генерация ключевого материала, самая тяжёлая в принципе операция при установлении соединений. Так что вот вам такой аргумент, который можно приводить, если вы хотите перейти на IKE версии 2. Сейчас давайте продолжать. Ещё раз: у нас есть три действия в нормальной работе IKE версии 1, в первой фазе. Мы сейчас эти три действия по кусочкам разберём — что там, каким образом, чего надо согласовывать, что делать.

Первое действие — это согласование политик IKE. Есть пять параметров, которые должны совпадать с двух сторон будущего туннеля. Эти параметры запомнить не так сложно. Давайте разберём каждый из них. Они будут называться IKE proposal. Смотрите, чтобы всё удачно сложилось — если вспомним слайд, который был несколько позиций до этого, с кирпичиками — нужно, чтобы все кирпичики совпали. Нам нужно выбрать следующие вещи: выбрать общий алгоритм хэширования, выбрать общий алгоритм аутентификации, определить группу Диффи-Хеллмана.

Про группу Диффи-Хеллмана чуть-чуть будет позже разговор. Просто скажу, что алгоритм Диффи-Хеллмана, который нужен для создания общего ключа, — он настраиваемый. Можно задать сложность этого алгоритма, сложность получаемого ключа. Эта сложность будет называться словом «группа». Чем выше группа Диффи-Хеллмана, тем ключ будет более качественный, пространство ключа будет лучше подобрано, и битовость тоже будет выше. Группа Диффи-Хеллмана — это просто сложность ключа, сложность алгоритма, которую мы подкручиваем. Она тоже должна совпадать с двух сторон, естественно. Дальше — lifetime. Это сколько времени будет жить весь набор security association. Мы с вами говорили, что этот массив данных для первого туннеля тоже не вечно живёт,

и его тоже иногда нужно переустанавливать, чтобы и ключики новые генерировать. Это называется lifetime. И последнее — это алгоритм шифрования, то есть чем мы будем шифровать. Запомнить их можно по такому акрониму: ХАГЛИ. Не знаю, как это у вас отложится в голове, но просто запомните: Хэш, Аутентификация, Группа, Лайфтайм, Энкрипшн. Дальше. Роман предложил, как защищаться от слабости первой фазы. Так и защищают — не позволять кому угодно устанавливать с вами IPsec-соединения. Просто дело в том, что можно в принципе access-list повесить на интерфейс. Почему это проблематично — просто будет access-list на интерфейсе, но здесь стоит оговориться: если вам заранее известны все участники обмена.

А если у вас, например, L2TP — что делать, если это предусмотрено для мобильных пользователей, которые могут подключаться откуда угодно? Так что access-list — это не панацея. Если у вас site-to-site VPN, там пять туннелей, десять туннелей — можно access-list написать и принимать сообщения IKE только от доверенных IP-адресов. А если это L2TP-сервер — там начинаются проблемы, потому что вы теоретически должны принимать соединения откуда угодно. Вы не можете access-list написать жёстко для всех возможных точек, откуда ваши сотрудники из командировки подключаются.

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

Поэтому с разными участниками можно в принципе согласовывать разные параметры. У нас есть политика IKE, она может включать в себя несколько наборов. Смотрите, как здесь нарисовано — это прямо такой схематичный кусок конфигурации. Мы можем обозначить один набор параметров, дальше в конфигурации второй набор параметров, третий, четвёртый. Этих наборов параметров можно в принципе обозначить много, потому что вариантов совпадений можно придумать множество. С другой стороны тоже можно не один придумать. В результате они рано или поздно договорятся, просто будет немножко дольше. Когда начинают договариваться стороны, они прямо политику будут перебирать: первый набор, policy 10, policy 20, второй набор, третий набор, четвёртый набор — и будет слишком много обменов.

Можно в принципе на все случаи жизни написать эти наборы, но лучше всё-таки придерживаться какого-то минимализма в конфигурации и конфигурировать однотипно. Миша говорит, что на ASA там визарды подо всё есть. Да, это всё руками. Сейчас мы с вами дальше поговорим. В принципе, здесь уже для вас в этом наборе практически неизвестных вещей нет. Вы знаете, что такое хэш, и можно просто прикинуть: если у нас слабое железо, какой хэш лучше использовать — SHA-256 или всё-таки MD5? Конечно лучше MD5 — он и пошустрее будет работать, он и проще. Конечно, он более подвержен коллизиям, но я не думаю, что это будет прямо совсем страшно — что кто-то сможет подобрать коллизии.

Но мы понимаем: всё будет зависеть от стоимости наших активов, которые мы защищаем. Про хэш вы знаете. Про метод аутентификации тоже мы поговорили — либо RSA использовать, сертификаты, либо общие ключи использовать. Про Диффи-Хеллмана сейчас будет ещё разговор. Время жизни туннеля — рекомендации, конечно: чем чаще вы всё перегенерируете, все туннели, тем будет намного лучше и безопаснее. С другой стороны, надо тоже отдавать себе отчёт: есть ли смысл часто-часто перенастраивать туннели, часто перегенерировать ключи? Не знаю, стандартное значение — стандарт везде разный на всех платформах — 86 400, это одно из стандартных значений. И выбор алгоритма шифрования — здесь мы тоже с вами уже говорили много. Просто смотрите на ваши вычислительные возможности. Конечно же лучше закрыть всё это каким-нибудь мощным алгоритмом, но если слабое железо — 3DES вполне подойдёт, почему нет.

Поэтому, Андрей, в принципе составить эти наборы не так сложно. Надо просто смотреть на ваши возможности и на возможности соседей тоже. Иногда бывает так, что когда устанавливают между двумя компаниями какой-то site-to-site IPsec — чья компания круче, где сисадмины больше нос задирают — они будут диктовать условия. Скажут: «IPsec с нами можно поставить, вот вам такие-то параметры, давайте настраивать, но мы вам ничего не поможем, потому что мы такие крутые». Такое тоже часто бывает. Роман говорит, что клепал policy для каждого туннеля. Бывает и такое — знаний не хватает, и человек увидел в конфигурации для туннеля policy и для каждого туннеля будет эти policy просто копировать в конфигурации. Есть ли смысл? Конечно, нет смысла это делать. Одна и та же policy может использоваться всеми туннелями сразу. Это просто набор параметров, которые будут согласовываться с другой стороной — и всё, ничего больше нет. Просто надо согласовать параметры. Это первое действие протокола IKE.

Давайте дальше. Второе действие — Диффи-Хеллман. Сейчас я вам постараюсь объяснить на пальцах. Я на паузу снял, потому что искал ссылку на видео. Скажу под запись, что дал ссылку на видео с Диффи-Хеллманом. Просто на пальцах — здесь вставлена замечательная картинка, где в принципе всё объясняется. У Алисы и Боба — давайте говорить профессиональным языком — у Алисы и Боба задача родить общий ключ, как-то сгенерировать общий ключ, чтобы он был одинаковый.

Как это происходит? Здесь на примере красок всё объясняется. У них есть какое-то общее число — общий какой-то цвет, например жёлтый. И Алиса его знает, и Боб его знает. Если проработать алгоритм Диффи-Хеллмана: Алиса говорит, какое у них будет общее число — вот эта жёлтая краска. Видите, g и p — две константы, которые Алиса придумывает и потом просто передаёт Бобу, они у них общие. И есть какие-то секретные числа — секретные цвета — у Алисы и у Боба. Этих секретных чисел не знает вообще никто, только они. Дальше, если Алиса и Боб смешают их со своей общей краской, они получат два каких-то производных цвета. Ими они могут спокойно обменяться через недоверенную среду.

Если вдруг кто-то перехватит эти два цвета — он никогда в жизни не поймёт, из чего они состоят. Мы понимаем, два числа можно умножить друг на друга, но здесь будут более сложные математические операции. Просто два числа можно как-то сложить, но потом разложить это общее число на множители либо на составляющие — это будет уже невероятно сложная задача. На этом всё и построено. Они будут обмениваться этими общими числами, а потом, применив к этому числу свой секрет, у них точно получится общий ключ. Это если совсем-совсем на пальцах. Ещё раз: у каждого из них есть приватное число, которое они держат в уме, и общее число. На определённом шаге и Алиса, и Боб будут делать нехитрую математическую операцию и потом обмениваться тем, что у них получилось в результате первой математической операции.

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

Это и есть второй пункт — именно создание общего ключа. Если в SSH1, помните, сессионный ключ передавали другим способом — одна сторона придумывала сессионный ключ, шифровала его с помощью открытого ключа, передавала другой стороне, и только другая сторона могла его своим приватным ключом расшифровать. Таким образом это была именно передача ключа. Здесь передачи ключа вообще никакой не будет. Очень часто, кстати, говорят, что протокол Диффи-Хеллмана — это протокол обмена ключами. Это никакой не обмен ключами, здесь обмена ключей вообще нет. Ключевой материал никаким образом не передаётся. Это не передача ключа, а именно протокол совместной генерации ключа. Это важно, иногда можно и нужно придираться к терминам.

Так что вот это протокол Диффи-Хеллмана. Группа Диффи-Хеллмана. У нас есть одно из значений — число p, которое будет использоваться в расчётах. Это число p можно варьировать, можно разный размер этого числа устанавливать, и потом у нас будут получаться разные ключи по стойкости. Смотрите, групп у нас в настоящее время больше, чем здесь написано, но основные группы — это первая, вторая и пятая. Старайтесь их избегать, они уже считаются устаревшими. В настоящее время у нас от 14-й и выше. Если железо поддерживает с двух сторон более высокую группу, можно её поставить.

Обратите внимание, что здесь должна поддерживать не обязательно прямо железные компоненты — операционная система. Это математические операции, они к железу особо не привязаны, это реализация в операционной системе. Здесь у нас 19-я группа будет лучше, чем 16-я, совершенно точно. Длина ключа меньше, но здесь будут использоваться эллиптические кривые. Криптография на эллиптических кривых предусматривает меньшую длину ключа, но ключи получаются более стойкие. Я не математик, я не смогу объяснить эллиптические кривые, честно. Диффи-Хеллман пишется в битах. Кстати, если я не ошибаюсь, в каких-то версиях ASA тоже можно было в битах писать.

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

Здесь нужно искать какой-то компромисс. Если вы не очень часто перегенерируете ключ, можно помощнее поставить, постарше группу Диффи-Хеллмана. Я проверил: в ASA в битах указать нельзя. Группа Диффи-Хеллмана — только именно номер. Но давайте дальше, Андрей, я предлагаю не углубляться в криптографию. Мне не стыдно признаться в том, что я не криптограф и плохо эту тему знаю. Давайте про третье действие поговорим — это аутентификация. У нас может быть, мы уже проговаривали, ещё раз: pre-shared key и RSA-подписи. RSA nonces — здесь не используются сертификаты, будут просто шифроваться случайные числа, но тоже с помощью приватного и публичного ключа.

Результат аутентификации у нас будет либо разрыв security association, либо, в случае удачной аутентификации, переход ко второй фазе. Третье действие — мы либо после аутентификации идём дальше, либо нет. Ещё раз: не очень удачно то, что аутентификация в самом конце происходит, после того же Диффи-Хеллмана. Но она является тем действием, которое уже будет определять: дальше пойдём или не пойдём — либо разрыв соединения, либо переход ко второй фазе. Давайте сделаем небольшой перерыв. Смотрите, по поводу ISAKMP и IKE. ISAKMP — как же он расшифровывается — сейчас одну секундочку: Internet Security Association and Key Management Protocol.

Это один из протоколов, который впоследствии был включён в спецификацию IKE. Если я всё правильно помню, IKE включает в себя там ещё OAKLEY и ещё какой-то третий протокол. Это, так скажем, современная реализация — это IKE. ISAKMP — это просто часть протокола IKE. Очень часто, в том числе и в конфигурации устройств, эти два протокола как бы равнозначно используются, то есть взаимозаменяемые понятия в современном мире. На самом деле ISAKMP — это просто часть спецификации. Про аутентификацию мы поговорили. Давайте про протоколы IPsec уже дальше двинем. Про первую фазу мы поговорили. Теперь, каким образом устанавливать соединение, нам более-менее понятно: согласовываются параметры, генерируется общий ключ, проходит аутентификация,

и дальше у нас уже будет работать вторая фаза — собственно защита наших данных, наших пакетов. Защищать пакеты можно с помощью двух протоколов, которые включены во фреймворк IPsec. Это Authentication Header и Encapsulating Security Payload. У этих протоколов есть номера: AH — это 51-й номер, и ESP — 50-й. Номера протоколов нужно знать и всегда помнить. В чём их отличие? Давайте сначала AH — он более простой. Он обеспечивает аутентификацию источника, обеспечивает целостность данных, защиту от повторов, но не обеспечивает шифрование, конфиденциальность данных. Данные передаются в открытом виде, но они подписываются. Тем самым мы в принципе можем и источник аутентифицировать, и защититься от повторов, и целостность данных обеспечить.

Иногда это оправданно — когда мы точно знаем, что по этому каналу ничего сверхсекретного не будет передаваться, но нам нужно точно аутентифицировать данные и точно убедиться в их целостности. Можно использовать Authentication Header — просто и понятно. Он полегче в плане вычислительных затрат, поэтому и побыстрее. ESP — этот протокол будет и аутентификацию обеспечивать, и целостность, и защиту от повторов, и конфиденциальность данных — здесь будет шифрование. Наиболее часто будет использоваться именно ESP. Если есть возможность шифровать — почему бы не использовать такую прекрасную возможность? Поэтому в IPsec чаще встретите ESP.

Как работает протокол AH? На самом деле всё очень просто. Мы будем брать заголовок IP, брать данные — грубо говоря, весь IP-пакет — будем брать ключ, который мы получили уже с помощью Диффи-Хеллмана, делать из этого хэш. Упрощённо: будем делать хэш и будем вставлять этот заголовок AH между IP-заголовком и данными, и дальше отправлять по интернету. С другой стороны, другой сосед будет делать в принципе все те же самые действия. Это похоже на электронную подпись, на цифровую подпись, о которой мы уже говорили. Точно так же будет брать заголовок, данные, ключ, хэшировать и сравнивать полученный AH-хэш с тем, который мы сейчас вычислили. Ничего сложного здесь не будет, всё это будет прекрасно работать и обеспечивать всё то, о чём мы говорили раньше.

Теперь про ESP. Смотрите, в ESP будет немножечко похитрее. ESP будет у нас обеспечивать и шифрование, и аутентификацию. Кто спрашивал — Роман спрашивал — по поводу алгоритма хэша: SHA или MD5? Вот для этого нужен хэш — для аутентификации и в протоколе AH, и в ESP. Мы будем сначала шифровать пакет — прямо берём заголовок, данные, будем шифровать этот пакет, — а затем прогонять всё это через алгоритм хэширования, брать хэш и тоже присоединять.

ESP out, такой trailer 2 будет, и будем добавлять свои заголовки, будем добавлять новый заголовок IP. Зачем ESP? Для шифрования, а AH не шифрует ничего. ESP out — аутентификация. ESP будет выполнять сразу два действия: он будет и шифровать, и плюс ещё делать подпись. Два дополнительных механизма. ESP out — это то, что мы сначала зашифруем, а потом сделаем хэш. Так, или что-то я не понял? Так, ещё раз сначала про transform set, и сейчас, Роман, дальше поговорим. Да, здесь уже будет вторая фаза.

Работать — сейчас мы про вторую фазу тоже поговорим. Про вторую фазу сейчас даже не забегаем вперёд. Ещё раз сначала: ESP будет выполнять две функции. Во-первых, это шифрование — когда будет браться весь пакет и зашифровываться. Затем этот зашифрованный пакет будет прогоняться ещё через алгоритм хэширования, будет получаться подпись этого пакета, которая тоже будет вместе с пакетом отправляться. Давайте про ESP чуть-чуть подробнее. Смотрите, у ESP есть два режима. Эти два режима, я думаю, тоже те, кто настраивал хоть раз IPsec, видели: туннельный режим и транспортный режим. Зачем они вообще нужны? Смотрите, мы можем использовать более облегчённый вариант — это транспортный

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

добавлять в него свой новый заголовок IP. Который тоже не очень хорошо изменять, когда будет NAT. В принципе и туннельный режим, и транспортный режим не хорошо NATить. NAT — это другое немножечко. Да, Миш, правильнее сказать так. Миш, спасибо большое за ремарку. Когда у нас есть IPsec между хостами, то лучше использовать транспортный режим. Если нет — туннельный. Обычно по умолчанию везде будет использоваться туннельный режим. Дальше про фазу вторую. Что же будет происходить в этой самой второй фазе и что там нужно, как настраивать и что понимать?

Параметры этих протоколов — какое применять шифрование в ESP, какой хэш-алгоритм применять — они будут настраиваться во второй фазе. Туннель первой фазы, который у нас будет построен, он к данным не имеет отношения. Данные будут передаваться в туннеле второй фазы. Здесь будут ещё раз согласовываться параметры уже IPsec. Опять термин — такая терминологическая засада. И в конфигурации будет терминологическая засада. Согласуются параметры IPsec. В конфигурации мы так и будем писать, что параметры IPsec. На самом деле имеется в виду вторая фаза. IPsec здесь будет рассматриваться как

IPsec-туннель — это туннель второй фазы этого шифрования уже с помощью протокола ESP и того же самого. Это не весь фреймворк, куда всё это входит. Так что запутаться есть где, это совершенно точно. Итак, во второй фазе мы устанавливаем туннель, будем делать перегенерацию ключей. Это определено в IPsec. Нет, Андрей, ещё раз: в первой фазе мы выбрали всё для туннеля первой фазы. Сейчас картинки нет подходящей. Ещё раз, с этими двумя туннелями путаница. Первый туннель — служебный, чисто служебный. Когда в первой фазе мы согласуем параметры этого первого туннеля, он нам нужен для того, чтобы потом безопасно передавать параметры для второй фазы, чтобы там ключи согласовывать.

Так что он только служебный. Там data plane нет. Роман правильно сказал — это только control plane, только управляющая информация. Там боевые данные никакие не идут, там протокол ISAKMP бегает, никакой — это уже будет в туннеле второй фазы происходить. Есть опциональная такая штука, как PFS — Perfect Forward Secrecy. Perfect Forward Secrecy. Сейчас я постараюсь объяснить очень коротко. На самом деле эта самая перегенерация ключей она нечестная. Мы, не углубляясь в криптографию, просто скажу, что по умолчанию перегенерация ключа она недостаточно честная, и там будет генерироваться просто большой ключевой материал,

из него потом нарезаться определённые куски. Когда мы будем заказывать перегенерацию ключей, будут просто новые куски вырезаться из уже готового ключевого материала. Там не будет по-честному генерироваться новый ключ, новая битовая каша. Perfect Forward Secrecy — опция PFS будет указывать на то, что каждый раз при перегенерации ключей нужно генерировать новый ключевой материал добросовестно. Так что она в принципе не будет лишней. Миша говорит: PFS для параноиков. В принципе да, это уж совсем, но я бы не сказал, что прям совсем для параноиков. Но да, она добавляет параноидальному мышлению свои нотки. Понимаете, что Perfect Forward Secrecy говорит нам о том, что

ключевой материал должен по-честному перегенерироваться. Ещё раз: это просто второй раз ещё Диффи-Хеллман провести, всё с нуля. По умолчанию перегенерация ключей здесь будет нечестной, Диффи-Хеллман не будет запускаться. Будет уже сгенерированный ключевой материал, и просто потом будут нарезаться разные куски из ключа, если упрощённо. PFS включает именно честную перегенерацию с нуля. Но, конечно, она будет жрать какие-то ресурсы. Теперь чуть-чуть про криптографический стандарт Suite B. Мы говорили с вами про то, что мы можем выбирать параметры и шифрования, и хэширования на основании наших личных предпочтений, либо на основании того, насколько мощное у нас железо. Но есть совершенно конкретный стандарт Suite B,

который говорит, какие параметры всё-таки лучше выбирать. Этот набор криптографических алгоритмов рекомендован Национальным агентством безопасности, американским, и в принципе он такой — это общая рекомендация для индустрии. Он одобрен для использования с секретными и совершенно секретными данными, но не нашим правительством. Понятно, наше правительство — я не знаю честно, что одобряет наше правительство, но то, что в ГОСТах написано, конечно, одобряет. Включает в себя: конфиденциальность — AES, шифрование здесь будет AES. Никаких DES, никаких 3DES здесь уже не будет. Suite B чётко говорит: используем только AES. Целостность — только SHA-2. Всё остальное — MD5, SHA-1 — тоже можно забывать.

Аутентификация будет с использованием эллиптических кривых. И управление ключами здесь будет тоже Диффи-Хеллман с эллиптическими кривыми. Всё, что не написано в стандарте Suite B, лучше не использовать уже в современном мире. Есть такой совершенно чёткий стандарт. Криптографические стандарты в Российской Федерации. У нас есть такой Технический комитет по стандартизации ТК-26. У них есть даже свой сайт, сейчас я ссылочку брошу. Кто интересуется — на их сайте можно много всего интересного почитать. Там на главной странице фотография с учёными и академиками. Тоже всё серьёзно. У нас криптография отечественная не такая уж плохая, потому что я думаю, что математическая школа в нашей стране она хороша и признана.

Так вот, этот Технический комитет 26 тоже определяет стандарты, которые работают в нашей стране. Я не знаю, нужно ли вам запоминать эти ГОСТы. У нас есть 34-й ГОСТ, который определяет: 34.11 — хэширование, 34.10 — цифровую подпись. И есть отдельный ГОСТ — шифрование у нас 28.147, ещё 34.12. Это стандарты на настоящий момент, которые приняты у нас в стране. Я делаю скидку на то, что большинство слушателей из Российской Федерации, хотя — подождите, кто из Казахстана, напомните мне? Роман, а у вас тоже есть какой-то мега-супер ГОСТ? Он от российского как сильно отличается, или вы не знаете, что там?

Просто интересно, я даже не представляю, что в Казахстане. «Кумыс-2017» — это такой прикол или так он официально называется? У нас «Кузнечик», у вас «Кумыс». Такое казахское название. Про казахский язык не знаю, хотя имею некоторое отношение к Казахстану тоже. Так, давайте дальше про развитие мыслей про IKE. Я сказал по поводу того, что IKE версии 1 в настоящее время уже, скажем откровенно, устарел. В настоящее время у нас есть вторая версия, она описана в одном единственном RFC 4306. IKEv1

описан в нескольких RFC, там целая пачка такая. Я не стал заморачиваться их номерами, потому что всё равно не запомним. Я думаю, что можно в Википедии посмотреть, и всё будет понятно. В нём улучшена производительность, улучшена безопасность, вообще всё на свете улучшено. Есть поддержка более понятного и простого процесса установки соединения. Там нет первой фазы и второй фазы, привычных нам в IKEv1. Там будет немножко по-другому. Так, давайте сейчас я закончу мысль. Там будет три — можно их назвать тоже, но это не фазы даже, там не называется это словом «фаза». Там будет три процесса. Сначала будет IKE_SA_INIT — это где будут устанавливаться

служебные... Даже не служебный туннель — это будет согласование параметров. Потом будет аутентификация. И там же будет генерация ключевого материала после аутентификации. И последнее — это будет CREATE_CHILD_SA, и это будет уже устанавливаться IPsec-туннель. Детального разбора IKEv2 у нас на самом деле нет в курсе, я признаюсь честно, но настраивается он будет очень похоже. Там просто будет меньше сообщений. Так, Миша поправил, что 7296. Сейчас — 7296, она... Да, это хорошее замечание. 4306 — сейчас подождите, это важно.

Он у нас сейчас — 4206... 7296. 7296 тоже не последний. Так, про RFC ещё раз — там слайды не успевают за RFC. 4306 был потом переработан в 5996, а 5996 был заменён на 7296. Да, спасибо, текущий — 7296 у нас сейчас. Эта информация на самом деле взята из руководства по подготовке к курсу, а руководство по подготовке к курсу у нас было написано немножечко

не сейчас. На самом деле бывает — в отношении RFC я, кстати, замечу: впервые в официальных руководствах, даже которые потом пишутся после уже изменения RFC, текст на самом деле не такой уж свежий в книжке. Так что да, это наш косяк. Так, и пару слов, наверное, стоит сказать про IPv6. Смотрите, поддержка IPsec в IPv6 рекомендована. Вообще поддержка IPsec рекомендована для всех устройств, которые должны поддержать IPv6. До до принятия RFC 6434 — текущего RFC по IPv6 — до принятия этого RFC говорилось, что поддержка IPsec должна быть обязательной.

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

заголовки будут другие. Мы помним же, у нас Глеб Вадимович — фанат IPv6, он подтвердит. Да, если кто-то не помнит, а Глеб Вадимович помнит, то дополнительные опциональные заголовки в IPv6 — они будут у нас выполнять работу и нести в себе заголовки ESP или AH. Не будет, как в IPv4, нового заголовка. В IPv6 будет дополнительный заголовок просто расширения вставляться. Рекомендовано к использованию Suite B и IKEv2 уже в IPv6. Если проектируется какая-то система с IPv6, то решили всё старое, что было до этого, не тащить — всякие там старые алгоритмы

шифрования, хэширования. IPsec в принципе можно использовать как транспорт для туннелирования IPv6. Хорошая идея, никто не запрещает так делать, и реализации такие есть. Я ими не пользуюсь в повседневной жизни, но я знаю, что можно использовать. Мы же можем использовать туннельный режим IPsec IPv4, а внутри у нас зашифрованные будут ехать не пакеты IPv4, а пакеты IPv6. Это нормально, это здорово, модно, молодёжно, если нам надо как-то IPv6 передать поверх обычных сетей IPv4. Технологий туннелирования в принципе в сетевых технологиях дофига. Мы можем запаковать что угодно во что угодно в теории, как минимум. Но это нормальная, распространённая практика, когда внутри

IPsec может ехать практически любой протокол. Почему? Потому что всё зашифровано. Внутри этого ESP мы можем положить что захотим, и даже не будет понятно никому, что же там внутри едет. Тот же самый IPv6 туннелировать таким способом — хорошая идея. Так, и давайте теперь приступим к более практическим вещам. Мы IPsec чуть-чуть — я думаю, вы поняли, что к чему и что как с чем взаимодействует. Он не такой суперсложный для понимания. Теперь давайте посмотрим, как все компоненты IPsec будут применяться на практике. Мы прямо сейчас и будем на стенде это всё мучить.

Лабу — подождите, давайте сначала поговорим про то, как это конфигурируется. Как пример, мы возьмём операционную систему IOS, хотя я думаю, мы в лабе сейчас попробуем — не знаю, насколько удачно — мы сделаем IPsec: мы возьмём IOS с одной стороны и ASA с другой стороны, попробовать можем, никто нам не запрещает. Давайте, время позволяет. Значит, давайте. Начало про IOS. На самом деле ASA будет практически всё то же самое. Таких прям фундаментальных отличий там не будет. Давайте разбирать по кусочкам. Во-первых, что нужно учесть в настройке IPsec — это то, что сам трафик IPsec разрешён на интерфейсах. На интерфейсах нужно разрешить как трафик — ну да, мы сначала на интерфейсе — как трафик тех протоколов: ESP или AH, и

трафик IKE. Сейчас мы с вами поговорим подробнее немножечко. Дальше настраиваем первую фазу. Это будет именно политика IKE — ISAKMP, где мы эти самые HAGLE, то, что проговорили до этого, мы будем учитывать и будем настраивать. Дальше создаётся политика IPsec. Я уже говорил, что путаница происходит: вторая фаза — политика IPsec — имеется в виду именно вторая фаза, тот самый transform set. Transform set — это просто конструкция, в которой мы указываем, какие параметры использовать уже для боевого шифрования, для протоколов ESP или AH. Следующая конструкция, с которой мы познакомимся и которую нам нужно будет настроить, чтобы всё заработало, — это access list.

Crypto access list. На самом деле это самый обычный access list. Я говорил вчера, и мы убедились вчера, что Cisco одно и то же называет в разных контекстах по-разному. Это простой access list. Зачем он нужен? Нам необходимо будет определить трафик, который мы хотим шифровать, который мы будем «IPsec'ить». Есть такое слово — «IPsec'ить», мне оно не очень нравится. В общем, мы не всегда хотим шифровать весь трафик, который проходит через интерфейс, хотя, забегая вперёд, скажу, что такие случаи тоже бывают, и мы про это поговорим тоже обязательно и будем даже настраивать. Но в обычном классическом site-to-site мы с вами — сейчас, может быть, Роман забежит вперёд, начнёт про туннельные интерфейсы нам рассказывать — нет, сейчас мы не говорим про туннельные интерфейсы.

Обычный классический site-to-site IPsec — здесь не будет никаких туннельных интерфейсов, не будет никаких лишних абстракций. Будет просто трафик, который проходит через наш интерфейс, и определённый трафик мы будем шифровать, запаковывать, например, в ESP. А дальше у нас будет следующая конструкция — это crypto map. Это та самая связывающая конструкция, которая свяжет интерфейс с политикой IPsec. Сейчас совсем разберёмся, где уже будет прямо сказано, что конкретно делать на этом интерфейсе и как работать с трафиком. Первый шаг — разрешить трафик IPsec. Наверное, для экзамена тоже надо на 100% запомнить, что у нас есть два основных порта — это ISAKMP. 500 порт и 4500 порт, он ещё называется NAT-T ISAKMP, если указывать это словами.

Обратите внимание — 500 и ISAKMP он называется. Вот эти два порта, которые нужны для нормальной работы. Про NAT traversal я вам чуть-чуть сказал. Это ситуация, когда нам нужно пробросить через NAT, чтобы ничего не порушилось в наших пакетах. Те же самые SPI-шные при прохождении устройства с NAT — неплохо бы запаковать ещё в UDP, и неплохо запаковать ещё в UDP, ещё дополнительный IP-заголовок. Очень — хватит, там больше в принципе ничего не надо рассказывать про NAT traversal. Плюс я сказал, что разрешить ESP и AH протоколы — это всё делается обычным access-листом, который у нас вешается на интерфейс. И

здесь ошибка на слайде — не указано направление access-листа, но вы понимаете, что это в направлении in к нашему интерфейсу. Это первое, что нужно сделать для настройки site-to-site VPN. Дальше. Всё правильно, AHP должно быть написано. Я тоже скажу, что и у меня ни одного такого access-листа на моём железе нет, больше вам скажу, потому что я делаю всё чуть по-другому. Ладно, это мы, а что у меня — мы поговорим с вами в следующей серии. Дальше будет рассказ про то, чем пользуются нормальные люди. Не забегайте — я имею в виду про IPsec. Подождите, не забегайте вперёд. Давайте сначала нужно знать классику. Классика — это вот эти самые crypto map'ы. Я

стопудово уверен, что если кто-то их не видел до сегодняшнего дня, в своей дальнейшей работе с этими crypto map'ами столкнётся, с обычным site-to-site VPN'ом. Увидите ещё не раз. И Андрей тоже увидит, сейчас покажу crypto map'у. И надеюсь, никто не испугается. Ладно, первый шаг — трафик IPsec мы разрешили. Если мы это явно не разрешим — видите, здесь используются протоколы, это не permit там TCP, это всё своё. И поэтому просто роутер будет запрещать. Дальше — как создаётся политика IKE. Вот эти самые наборчики параметров, я уже говорил, они очень просто определяются. Crypto ISAKMP policy 10 — и там какой-то номер этого наборчика. И дальше будем говорить, что у нас какая аутентификация, шифрование, хэширование, группа Диффи-Хеллмана и

lifetime — время жизни. Вот этих политик может быть несколько, прямо пишем-пишем-пишем сколько нам нужно. Я по своему опыту скажу — у меня на одном из роутеров, по-моему, определено 6 или 7 разных политик, потому что у меня на тех концах туннелей стоит разное оборудование там от разных вендоров. И там ZyXEL есть, и MikroTik есть, и Windows есть. Короче, в повседневной жизни не надо много этих наборов определять. Роман говорит, что на ASA 20 можно только. На ASR'е да, можно много, я знаю. На самом деле я не знаю таких ситуаций, когда нужно больше 20.

Это если уж совсем используется какой-то зоопарк из оборудования на той стороне туннеля, либо — надо, точно. Роман говорит, что там был администратор клёвый, который просто копипастом делал одинаковые наборы. Да, если так — не знаешь. Я думаю, что мы дебаги с вами потом посмотрим. Когда будете траблшут какой-то делать, дебаг первой фазы он даст ответ практически на все вопросы — там всё-всё-всё будет написано, всё будет ясно. Мы сейчас с вами это увидим на лабе. Политику IKE мы создали. Обратите внимание, она называется crypto ISAKMP policy. Про IKE здесь слова нет. Как работает согласование? У нас на слайде, на предыдущем, несколько слайдов назад, была похожая картинка. Будет

такой алгоритм выбора: мы можем определить несколько, и роутер, который будет инициатором — один роутер будет всегда инициатором обязательно — он будет начинать согласование. Он будет просто выбирать все по порядку, сначала первый наборчик, отдавать, второй наборчик. Он прям так и будет отправлять туда, говоря, что у меня параметры такие-то. Этот роутер будет сверяться по своим наборам параметров до первого вхождения. Он отправил свой — вот эти номера политик, они не обязательно должны совпадать. Здесь видите 10, 20, здесь 100, 200 — это внутренние номера, локально значимые. Не имеет никакого значения. Как только роутер, который принял параметры, найдёт набор этих параметров, совпадающий — он говорит: всё нормально,

всё совпало, продолжаем дальше. Здесь нет, я думаю, никаких вопросов, тут всё очень очевидно. Приоритет policy — приоритет, да, он будет начинать отправлять сначала. Смотрите, если какие-то параметры не указаны, мы можем — но здесь всё будет очень сильно зависеть от платформы и от системы. Роман говорит, что если SHA-1 — здесь будет просто от версии IOS зависеть и от железа, потому что на каких-то платформах по умолчанию идёт SHA-1, на старых платформах где-то по умолчанию может быть MD5. Поэтому на умолчания лучше не закладываться. Но кстати, да, в show running если у нас будет совпадать с умолчанием, он просто не будет показываться.

Да, например, у нас на железке по умолчанию идёт AES-CBC 256, и в show run, по-моему, он не должен показать. Он просто покажет, что хэш не задан, а на самом деле он задан — просто совпало с умолчанием этой платформы. Умолчания везде разные. Дальше. Что сказать — у меня была мысль по поводу инициатора и того, кто отвечает. Смотрите, очень интересная вещь, на которой тоже спотыкаются новички. Очень часто случается такая штука, когда IPsec с двух сторон настроили полностью правильно, реально правильно настроили и там и там, crypto map'у — всё, а ничего нет, никаких туннелей не устанавливается. Бывает такая штука. Юрий правильно сказал, я думаю. Я просто говорю для тех, кто никогда не сталкивался:

пока у нас не будет трафика к конкретному назначению — пока роутер А не будет отправлять, не нужно ему будет отправлять никакой трафик на роутер Б — пока первый пакетик не пойдёт, никогда в жизни они не начнут ни о чём договариваться. На некоторых системах — Юрий говорит — но не в Juniper'е, не только в Juniper'е, кстати, это будет, когда задаёшь параметр, они сами начинают договариваться, там alive-пакеты на самом деле будут слать. Не обязательно. В MikroTik'ах не знаю, честно. Мы в пятницу пойдём на мероприятие MikroTik'а, надо там спросить. Я там — у меня накопились некоторые вопросы по MikroTik'у, надо будет узнать. На Cisco есть такая засада: когда всё настроили, но ничего не поднимается, просто трафика никакого нет, и

роутер сидит совершенно спокойно и ждёт, когда вы ему хоть один пакетик дадите, который нужно уже зашифровать, чтобы он начал согласовывать параметры. Давайте дальше. Как настраивается аутентификация. Аутентификация в нашем случае — мы здесь не будем рассматривать аутентификацию по сертификатам или по nonce'ам. Это не очень — геморрой, нам просто много конфигурации и ещё дополнительные нужны настройки какие-то. Мы на сессии тоже, не забывайте, мы рассматриваем общий ключ. Тем более я сказал, что общий ключ — это не всегда плохо, это тоже нормально. Настраивается очень просто. Я забыл сказать, что все настройки первой фазы они будут на crypto ISAKMP начинаться — такие заклинания. Смотрите, по поводу ключей.

Как правило, в нормальной практике общий ключ может использоваться только двумя участниками. У нас есть два участника, и мы придумаем для них общий ключ. Мы указываем не только ключ, а указываем и адрес, где сосед сидит, для которого этот общий ключ. Мы говорим, что для соседа с адресом 10.0.2.2 общий ключ будет такой-то. С другой стороны делаем зеркальную настройку, что для соседа 172.31.0.1 общий ключ будет такой. Зачастую можно схалтурить, но не то что можно — встречается такая халтура, когда делается вообще общий ключ для всех туннелей. Если у вас одна инфраструктура, если у вас, например, 10 туннелей — центральный какой-то роутер стоит, 10 филиалов, 10 туннелей — очень часто делают так, что общий ключ вообще для всех.

Здесь адрес можно не указывать, поставить адрес 0.0.0.0, и в таком случае этот ключ будет работать для всех. Имейте в виду, так тоже делают. Но не нужно — с точки зрения безопасности это не очень правильно. Но XAuth — XAuth-аутентификация — это дополнительная ещё возможность IPsec, когда мы можем добавить — я сейчас не ошибусь, если скажу — между первой и второй фазой можно ещё аутентификацию забабахать по логину и паролю. XAuth-аутентификация — это дополнительная ещё аутентификация, прямо реально по Triple-A можно. Например, так работает L2TP. L2TP —

он будет ещё дополнительную аутентификацию использовать, там же и логин, и пароль есть. И IPsec делается — если я всё правильно помню. XAuth-аутентификация она в site-to-site обычно не используется. Если сделать напрямую — зачем тогда поднимают? Сейчас я расскажу всё про туннельные интерфейсы, это будет обязательно. Мы про это ещё поговорим. Давайте дальше. Про аутентификацию по общему ключу, я думаю, всё ясно. Здесь никаких подводных камней вы не встретите, надо просто указать адреса. В этом тоже иногда ошибаются. Иногда люди, которые делают конфигурирование устройств методом копипаста из интернета — там, конечно, конечно, кирдык. Нет, COMMONKEY — это просто парольная фраза. Андрей, не заморачивайтесь, это

это не переменная, это просто парольная фраза и всё. Она может быть — нет ни ссылки на объект, ничего. Но я написал её немножечко неоднозначно, как оказалось. Смотрите, все параметры первой фазы IKE они будут у нас собственно выглядеть — в такой маленький кусочек конфигурации уложится. Ещё раз: policy — набор параметров и ключ. Больше для первой фазы ничего не нужно. Помните, что первая фаза — у нас согласование параметров, Диффи-Хеллман и ключ. Здесь всё указано: и для Диффи-Хеллмана у нас группа указана, и все параметры, ключ есть, аутентификация у нас прошла. Теперь политика IPsec — политика второй фазы. Будет такой объект, как transform set.

В конфигурации это как раз набор политик, которые нужны для второй фазы. Здесь мы будем указывать алгоритм шифрования, алгоритм хэширования и режим работы IPsec. Как он настраивается: crypto IPsec transform-set, и дальше будем указывать нужные параметры. Понятно, что он должен как-то называться. Если говорить про — если вернуться назад про политику IKE — здесь не именуются эти наборы никакие, хотя наверное было бы удобно, чтобы для каждого для каждого пира делать какие-то именованные наборы параметров. Нет, здесь просто идёт одним списком, наборы параметров перебираются. Здесь мы будем именно — этот набор параметров будет именованный, мы потом будем на него ссылаться уже.

Мы придумываем его имя, указываем алгоритм шифрования, указываем алгоритм хэширования. Всё. И потом ещё — там ещё есть некоторые настройки, которые сейчас мы не будем с вами трогать. И указывается режим работы. Здесь имеется в виду протокол ESP. Дальше про access-лист. Он называется везде в официальной документации, в учебной документации, в курсах — crypto access-лист. Сейчас, Андрей, ещё успеете переписать, мы сейчас будем это всё на лабе делать. Он называется crypto access-лист. Он необходим для отбора интересного трафика. Термин «интересный трафик» — это не мы придумали, когда курс делали. Это термин общепринятый. Интересный трафик — он так прямо везде называется, это трафик, который мы будем уже шифровать.

Надо помнить про зеркальные access-листы с двух сторон. Мы понимаем, что шифровать нужно не весь трафик. В данном случае трафик, который идёт из одной внутренней сети 192.168.50.0 в другую внутреннюю сеть 10.128.0.0 — только его нужно будет шифровать. Остальной трафик мы не трогаем. В access-листе мы будем прямо конкретно писать: permit ip 192.168.50.0 /24 маска к сети 10.128.0.0 /24 маска. Это называется crypto access-лист, crypto ACL. Бывает, да, что иногда пишут с указанием портов. Есть такие сценарии. Мы с вами говорили, помните, был разговор про зоны и про демилитаризованную зону. Кто спрашивал, я уже не помню — что делать, если из демилитаризованной зоны надо обращаться к

Active Directory. Роман, по-моему, спрашивал, не помню кто спрашивал, честно. И я накидывал мысль, что в принципе можно закрыть и IPsec'ом. Бывают такие ситуации, когда нам не нужно весь трафик между хостами или подсетями шифровать, а только определённого протокола. Мы в принципе можем здесь указать только трафик, который идёт TCP 80 порт — веб-трафик, и только его шифровать. Или там iSCSI-трафик, или что-то ещё. Можно и так. Мы очень точно можем отобрать трафик, который подвергается шифрованию, остальное не трогать. И для экономии ресурсов полезно в ряде случаев. И вообще гранулированные политики безопасности — это хорошо. С другой стороны, Роман говорит, что да, может быть геморрой. Честное слово, когда site-to-site у нас есть

какой-то IPsec, и мы шифруем только половину всего трафика, там при траблшутинге могут вылезти интересные какие-то особенности, когда шифруется только веб-трафик, и там администратор, который с этим разбирается, пытается ping и ICMP слать, а смотрит — а он не шифруется. И начинается — выяснять, что ж такое-то. Разные могут быть сюрпризы. Поэтому, если есть такая возможность — неплохо site-to-site сказать: весь этот трафик пусть шифруется. Обычно так и делают, обычно требуется зашифровать весь трафик, идущий из одной сети в другую. Если у кого-то есть примеры ещё, приводите. Обычно так. Нет, Андрей, в случае не site-to-site, между какими-то сегментами определённый трафик шифровать тоже так могут делать. Хотя я всё-таки

больше, наверное, сторонник того, что лучше делать шифрование на конечных хостах. Если требуется между двумя только двумя серверами какой-то трафик зашифровать, то почему нет — Андрей, можно на конечных хостах настроить IPsec, и пусть они сами шифруют свой трафик сколько им влезет. Не обязательно это на промежуточном сетевом оборудовании делать. Андрей так удивился, или возмутился, или что это было? Почему нет? Это тоже нормально, это нормальная практика. Если в таком сценарии — да, классно. Лучше пусть шифрованием занимается большой мощный сервер, чем маленький и какой-нибудь простенький роутер. Тоже всё нормально. Нет, а зачем на клиентах?

Это если, как Юрий сказал, если два устройства — в таких случаях не на клиентах. Crypto map? Нет. Зачем какие crypto map'ы в Windows? Вы видели crypto map'у или в Linux'е? Там это уже будет зависеть от реализации, всё там — реализация она будет совсем совершенно другая в других операционных системах. Мы сейчас про это не будем говорить, я просто говорю про саму организацию шифрования. Если на конечных хостах есть какой-то смысл делать шифрование — нормально. Давайте дальше смотреть про настройку. Теперь самое интересное — crypto map. Crypto map — это как раз механизм, с помощью которого будем собирать уже в одно единое все настройки IPsec. В этом crypto map'е мы будем говорить, какой трафик нам нужно защищать. Да, мы будем говорить, что трафик, который подпадает под access-лист такой-то — тот самый crypto access-лист — его надо шифровать. Как

защищается трафик, как его шифровать? Set transform-set — такая игра слов: set transform-set — установить transform set. Мы будем в crypto map'е говорить, какой transform set использовать для шифрования. Поэтому transform set здесь именованный, потому что мы к нему обращаемся с помощью crypto map'а. из крипто мапы мы будем ссылаться на конкретный трансформ сет дальше — куда отправлять защищённый трафик, какому пиру крипто мап применяется на интерфейсе ethernet 0/0 либо на саб-интерфейсе, именно на интерфейсе в крипто мапе можно для разных соседей написать разные инструкции, например для этого соседа который нормальный роутер, мы будем использовать такой трансформ сет, где и шифрование помощнее

и алгоритм хэширования более стойкий, а для какого-то малютки-роутера на другой стороне другой туннель — мы будем для этого соседа использовать другой трансформ сет, в крипто мапе у нас будет несколько строчек давайте смотреть как он конфигурируется длинная команда: крипто мап, имя его здесь похоже наверное на роутмап, с которым вы должны быть знакомы Кирилл говорит: можем ли мы для одного интерфейса с одним айпи создать более одного — конечно, хоть 100 туннелей, хоть тысячу, никто не запрещает вообще не проблема мы просто с помощью протокола IPsec будем шифровать пакет

прилеплять к нему, если туннельный режим, дополнительный айпи-заголовок, в котором в качестве исходящего адреса мы будем ставить адрес этого интерфейса дальше, про динамический крипто мап мы сейчас не будем говорить просто скажем, что есть ещё динамические крипто мапы, там всё немного более интересно — динамический крипто мап это крипто мап, в который не надо указывать соседа, мы сейчас говорим только про статический возможное количество — на один интерфейс можно повесить один крипто мап про динамические давать сейчас не будем, об этом вы узнаете в курсе CCCSMP

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

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

трансформ сет, посмотреть крипто мап самые полезные две команды, которые у нас есть, это show crypto isakmp sa и show crypto ipsec sa здесь посмотреть уже можно установленные туннели и эти самые SA — ещё раз повторюсь, security association это не что-то мифическое, это просто массив параметров, нужных для этого туннеля здесь проверка конфигурации, давайте это под запись расскажу, и эти состояния фазы 1 будут очень нужны при траблшутинге понимать, что происходит show crypto isakmp sa будет показывать состояние туннелей первой фазы — здесь будет показываться от кого кому и состояние

какие бывают: MM_NO_STATE — фаза первая создана, но ещё ничего не произошло начался только обмен, ещё ничего не согласовали MM_SA_SETUP — согласовали параметры ISAKMP SA MM_KEY_EXCH — аутентификация началась, ключи сгенерировали, Диффи-Хеллман отработал MM_KEY_AUTH — аутентификация завершилась успехом QM_IDLE — это значит первая фаза завершена, всё нормально, сейчас всё работает эти состояния я не думаю, что их будут спрашивать на экзамене, потому что это уже дополнительный материал в официальном руководстве честно не знаю, разбираются они или нет, я уже не помню но Андрей переписывает сейчас, пусть перепишет

записать — да, я про запись специально поговорил и при траблшутинге будет уже понятно, я думаю, на данном моменте если помнится, Андрей у меня в чатике спрашивал я ему сказал, что после курса в принципе всё разложится по полочкам сейчас уже у вас понятно — вы просто взглянули на состояние первой фазы и уже понимаете примерно, вы знаете, что за чем идёт, и понимаете, где остановилась у нас работа, что сейчас происходит мы понимаем, что сначала параметры согласовываются, генерируются ключи, Диффи-Хеллман отрабатывает, аутентификация ISAKMP — IKE работает не очень шустро, как ни странно как пример, в каких протоколах — не знаю, в том же OSPF иногда хрен уследишь, там очень быстро проскакивают все эти состояния до соседства, а здесь за ними можно понаблюдать

он неспешно согласовывает сначала параметры, потом ключи генерирует, особенно на виртуалках это заметно, я думаю, мы сейчас тоже это увидим что ещё из полезного — ладно, давайте сначала сделаем перерыв и немножечко полабим, я думаю, это будет полезно всё, я ставлю на паузу, пойдём на перерыв сначала давайте включим запись и подготовимся — мы с вами будем устанавливать site-to-site VPN между ASA и роутером несмотря на то что между ними прямой линк конечно в этой топологии не очень удобно, но ничего страшного, пусть будет так нам надо посмотреть, как поднимаются туннели, и посмотреть, будет ли шифрование работать

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

для начала мы попробуем убедиться, что айпи-связность у нас есть с роутера интерфейс, с которым мы будем работать — gigabit 0/0, пинг 10.1.1.2 — это ASA у меня дебаги выключим ASA у меня пингуется теперь давайте сделаем так сейчас я на паузу поставлю — смотрите, как мы сделаем: пока без ASA, пока только все будут устанавливать site-to-site с моим роутером, я правда задолбаюсь сейчас там писать крипто мап для всех — ну ладно, ничего страшного мы будем наши внешние интерфейсы 10.1.1.0 использовать для site-to-site

или попробуем всё-таки уже на ASA — ASA у всех поднялась, скажите пожалуйста? может быть с ASA уже сделаем просто мне очень много придётся писать на всех пиры — да, давайте с ASA делать сейчас настраиваем роутер сначала полностью, а потом будем ASA настраивать и посмотрим, как всё взлетит окей, занимаемся роутерами, вспоминаем всё, что мы смотрели с вами на слайдах у нас есть несколько задач первая задача — разрешить трафик IPsec вторая задача — создать политику для первой фазы, политику IKE потом создаём политику для второй фазы — трансформ сет потом отбираем интересный трафик, потом крипто мап, и всё связываем первый шаг я предлагаю пропустить для краткости

либо написать аксесс-лист — давайте пропустим, я просто ещё раз проговорю, у нас на слайдах это есть не будем тратить на это время — на том интерфейсе, где будет у нас site-to-site, необходимо разрешить трафик: во-первых, протокол ESP протокол Authentication Header, если мы его используем дальше для UDP разрешить порты 500 и 4500, если будет NAT traversal после этого у нас трафик IPsec разрешён почему без него не заведётся — у нас сейчас на роутерах ни одного аксесс-листа не применено, и всё будет работать смысл в этом аксесс-листе великий — у нас сейчас здесь запретов нет на стенде, а вот если что, имейте в виду, что трафик нужно разрешить явно это очень распространённая ошибка, когда всё настраивают, а забывают тупо разрешить трафик ISAKMP или ESP на интерфейсе

окей, давайте с крипто-настройками разберёмся второй шаг — нужно создать политику IKE, как она создаётся напоминаю: делаем набор параметров, которые потом будут согласовываться мы говорим: crypto isakmp policy, первый набор, начинаем с единицы или с десяти теперь параметры, которые мы указываем — помните акроним HAGLE сначала давайте настраивать хэш — хэш выберем самый простой, MD5, чтобы всё пошустрее у нас работало дальше буква A — это аутентификация, аутентификацию мы будем использовать PSK, pre-shared key, общий ключ

дальше буква G — это группа Диффи-Хеллмана, группу минимальную возьмём, первую, пусть будет первая в реальной жизни мы понимаем, что у нас есть стандарт безопасности, и никаких MD5-хэшей или первой группы Диффи-Хеллмана — про это даже речи не идёт но в наших лабораторных условиях, чтобы всё пошустрее ворочалось, берём первую группу Диффи-Хеллмана — Андрей может взять 24-ю, и у него ничего не срастётся кстати, ASA у нас умеет так — первую группу должна уметь дальше, если что, потом оттраблшутим lifetime — можно задать, можно оставить, 86400, пусть будет максимальный дальше, осталось у нас алгоритм шифрования — encryption, возьмём DES самые минимальные параметры, нам их будет достаточно

теперь следующий шаг следующий шаг — это настройка, мы ещё первую фазу пока настраиваем параметры задали, теперь сам ключ давайте определим сам ключ определяется командой crypto isakmp key ключ возьмём CISCO большими буквами, пусть будет так для адреса — здесь нам нужно указать нашего соседа, с которым мы будем строить IPsec мы будем с ASA делать, следовательно адрес у нас будет 10.1.<номер комплекта>.2, у меня будет 10.1.1.2, у кого-то будет 10.1.2.2 pre-shared key мы сделали, окей

смотрите какая штука — мы с вами в настройках первой фазы дофига чего указали, но у нас отображается только хэш и аутентификация почему — потому что остальные у нас заданы по умолчанию, умолчания будут совпадать encryption DES по умолчанию в этом роутере — странно можем посмотреть show crypto isakmp policy — ещё такая команда, которая нам покажет всё нормально: encryption-алгоритм, хэш-алгоритм, аутентификация, Диффи-Хеллман первой группой, lifetime, окей это мы настроили, с первой фазой разобрались

дальше настраиваем вторую фазу тот самый трансформ сет, в котором будем указывать все параметры уже боевого туннеля, где у нас всё будет шифроваться делается это командой crypto ipsec transform-set трансформ сет нам нужно как-то назвать, без разницы как, пусть будет ASA-TS, я так назвал называйте как хотите, главное — чтобы потом в крипто мапе сослаться именно на это название и мы указываем, как мы будем это шифровать сначала мы должны указать протокол, который будет использоваться для защиты данных — мы будем использовать ESP, и алгоритм шифрования будет esp-des обычный плюс нам нужно указать алгоритм хэширования — также будем использовать ESP, и хэш возьмём esp-md5-hmac и режим работы нашего IPsec — туннельный

туннельный режим, всё, этого достаточно для настройки второй фазы у нас есть тоже команда show crypto ipsec transform-set, который нам покажет — есть дефолтный трансформ сет, он будет использоваться, если мы вообще ничего не создали лучше всегда указывать, мы уже разобрались, в каких случаях и как у нас создаётся трансформ сет у меня он называется ASA-TS, где мы используем протокол ESP с шифрованием DES, и аутентификация для протокола ESP у нас будет MD5, туннельный режим продолжаем дальше нашу настройку со стороны роутера теперь тот самый крипто-аксесс-лист, давайте посмотрим на нашу схему

на роутере мы скажем: весь трафик, который будет идти из сети 10.1.0.1/0 в сеть, которая за спиной у ASA — 10.2.<номер комплекта>.0 — этот трафик будет у нас интересный мы говорим: ip access-list extended interesting — отбор интересного трафика — и говорим permit ip ещё раз сверяемся: 10.1.0.1/0 по /24 маске в сеть 10.2.<номер комплекта>.0 по /24 маске этот аксесс-лист и будет говорить нам, какой трафик шифровать, весь остальной трафик будет идти открытым текстом продолжаем, последний шаг — настройка крипто мап, в которой мы будем всё связывать

как создаётся крипто мап: crypto map, назовём её — у меня будет 7ASA, пусть так называется дальше номер условия, также как в роутмапе, и тип крипто мап — они бывают либо с ISAKMP, либо manual, но вручную без ISAKMP я думаю, что IPsec будет совсем грустно делать IPsec ISAKMP — дальше, до тех пор, пока мы не сконфигурируем соседа и аксесс-лист, мы не сконфигурируем крипто мап, она будет неактивна окей, теперь внутри крипто мап мы будем говорить, когда всё это дело у нас заведётся, когда крипто мап начнёт работать

мы говорим: match address — и указываем наш аксесс-лист interesting и теперь говорим, что делать: сосед — set peer — у нас будет, давайте сверимся со схемой, 10.1.<номер комплекта>.2, у ASA .2, помните — 10.1.1.2 теперь какой трансформ сет мы будем использовать для шифрования с этим соседом: set transform-set — как мы его назвали, я назвал его ASA-TS и можно указать ещё, сколько будет жить этот туннель: security association lifetime — здесь мы можем сказать либо в секундах, либо в килобайтах, либо даже в днях я уже сказал, что перегенерация ключей, переустановка этого туннеля, она будет происходить либо по времени, либо по количеству трафика, который будет проходить через нашу шифровалку

можем сказать в килобайтах — минимум 2560, 60 — ну ладно лучше задавать давайте в секундах, так будет проще — 86400 если вспомнить историю, которую рассказывал, с перегенерацией ключей — такой DoS-атакой своеобразной — операционная система не даёт нам поставить слишком маленькое количество трафика, после которого будет перегенерация мы понимаем, что если сказать два с половиной мегабайта, то через каждые пару мегабайт у нас будет Диффи-Хеллман отрабатывать — ну зачем этот параметр тоже должен совпадать, если я правильно помню, на обеих сторонах

так, крипто мап у нас настроена, если посмотреть show crypto map — вот она, настройка вся как на ладони у нас пир какой, аксесс-лист будет у нас применяться для отбора интересного трафика lifetime — смотрите, я lifetime задал сначала в килобайтах, потом в секундах, действительно можно сделать такую настройку что наступит раньше: либо раньше нужный объём трафика пройдёт, либо секунды протекут — и тогда он будет перегенерировать PFS — помните, я сказал Perfect Forward Secrecy — чтобы по-честному перегенерировать ключ дальше трансформ сет, интерфейсы, которые используют этот крипто мап — у нас пока интерфейсов нет

применяем крипто мап на интерфейсе — дефолтные настройки lifetime, разве дефолтный минимум стоит? Миш, я не уверен — 2560 килобайт у нас по дефолту стоит? нет, по дефолту здесь — вот сколько стоит lifetime, если его не задавать так, давайте на интерфейс всё это применять, я и время тоже задавал

я килобайты и время задал — всё, крипто мап сделана, мы связали все настройки вместе и идём на интерфейс gigabit 0/0, который смотрит в сторону ASA, и просто применяем крипто мап на интерфейсе: crypto map 7ASA — у меня так называется всё, после этого подсистема IKE ISAKMP сказала, что она работает, она включена полезные команды для проверки, ещё раз повторим: show crypto isakmp policy — посмотреть настройки первой фазы show crypto ipsec transform-set — посмотреть настройки второй фазы show crypto map — смотреть настройки крипто мап теперь информация о туннелях: show crypto isakmp sa, show crypto ipsec sa

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

разрешим проход между одинаковыми уровнями все правильно андрей говорит значит внешний интерфейс 10 1 у меня будет 12 окей интерфейс он у нас gigabit 00 gigabit 00 помните что нужно называть обязательно интерфейсы на оси мы назовем интерфейс ту роутер пусть будет так security level ему поставим 100 чтобы все через него работала айпи адрес будет 10 1 1 2 у меня у вас будет 10 1 номер комплекта 2 сделаем но ушат для него а блин на 5 до утра пингуется у меня роутер пингуется оса с другой стороны тоже пингуется поехали теперь настроим внутренний интерфейс осы интерфейс gigabit 01 у нас

будет правильно гигабит 01 с адресом 10 2 номер комплекта 1 api адрес 10 2 1 1 у вас будет 10 2 5 1 10 2 7 1 назовем мы его ну как-нибудь который смотрящий во внутреннюю сеть security level мы поставим столь ничек чтобы у нас не было проблем теперь разрешим проход трафика между интерфейсами с одинаковым уровнем помните я говорил что в новых операционных системах оса по умолчанию трафик между такими интерфейсами запрещен она ушат я забыл сделать да спасибо большое был дополнительный траблшутинг и говорим same security трафик пермит интер интерфейс все теперь у нас трафик будет проходить между интерфейсами

если не успеваете скажите я приторможу немножечко так следующее что нам нужно настроить это за спиной у осы внутреннюю сеть внутреннюю сеть у нас будет олицетворять наш коммутатор этого достаточно моему дадим какой-нибудь адрес из внутренней сети и ну и дальше потом дальше настроим наш коммутатор мы создадим у него адрес остался у меня не остался адрес я создам интерфейс вилан один задам ему адрес сети 10 2 1 0 10 2 1 ну пусть будет 100 сейчас но ушат внутренняя сеть в лице одного роутера настроена

проверим ping 10 2 1 оса 1 работает на роутер на еще зададим маршрут по умолчанию через нашу осу коммутатор в комплекте 0 не раб о в комплекте 8 не работает окей значит внутренняя сеть за осы настроена настраиваем есть жир пинасе чтобы они с роутером просто тупо обменились маршрут и мы не парились маршрутизации роутер и и джерпи 100 нетворк 0 0 0 0 хватит все значит как только вы настроили ей джерпи насе оса не будет здесь выводить вам влог число к сообщения по умолчанию но у меня все

настроено оса у меня роутер сказал что он увидел нового соседа оса приняла по и джерпи все маршруты которые знает наш роутер соответственно теперь с нашего коммутатора можно пропинговать внутреннюю сеть за роутером но лупбек на роутере с коммутатора она пингуется роутер пингует замечательно внутреннюю сеть блин что я нажал роутер замечательно пингует внутреннюю сеть за свой 10 я прошу прощения 1021 100 коммутатор все айпи связанность есть сейчас на данном моменте на данном этапе дебаги все выключаем на самом деле получилось очень прикольно потому что кто у нас на 10 комплекте сидит андрей еще пингует и

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

но во первых надо разрешить протокол айк на интерфейсе здесь ну да вообще работа протокола на интерфейсе и ней был блин я забыл как 7 не интерфейс называется так мы на оси все интерфейсы ну да все в гейджерпи а пусть будет все все вспомнили мы интерфейс и значит сначала надо разрешить айк версии один можно кстати и версии 2 тут разрешать версию 1 сейчас на интерфейсе ту роутер разрешили мы айк один и теперь настраиваем политику для первой фазы здесь не будет команд крипту и сака mp как было в роутере

здесь уже все по-человечески крипто айк версия один по лесе там пусть будет один или 10 опять настраиваем вот это самый хагли это все настройки первой фазы хэш у нас был м до 5 аутентификация у нас была при шаре ткей следующая группа у нас была на роутере первая поставлена lifetime 86 400 если я правильно помню что было на роутере ну-ка давайте к народ и посмотрим шоу клипта и сакимп полисе lifetime 86 400 дальше и последние encryption наше шифрование у нас народу 3ds первую фазу мы все параметры указали точно такие же как на роутере все должно взлететь хорошо теперь давайте просто повторим за мной настройки

здесь есть еще ну на оси у нас есть еще некоторые сущности все что у меня спрашиваете ну да да да настраивайте пока сейчас я покажу блин а здесь как здесь не показывает полисе здесь через шоуран смотреть так теперь теперь под запись значит как настраивается пир и ключ для него мы указываем туннель групп это грубо говоря настройка нашего пира говорим что тип пиры у нас будет сейчас туннель групп type ipsec туннель так началось а

мы его уже задали его задать второй раз не могу я просто тогда покажу что я в конфиге набил он не позволяет сначала указываем нашего пира и тип ему говорим о и писи культур или это сайта сайт и потом мы указываем команду туннель групп именно айпишник нашего пира и писек атрибут и внутри уже в контексте мы говорим при шарит кей айки айк версии один пришарит кейт cisco на этом первую фазу мы в принципе настраивает закончили на оси давайте теперь дальше разбираться настройки второй фазы здесь тоже будет transform set который настраивается более-менее похожим образом так настройку какую вот эту атрибута

и писем пришарит кейт cisco так давайте со второй фазы разбираться нам нужен transform transform set крипто и писи и кайк версии один transform set такая команда длинная немножечко назовем как мы называли там без разницы transform set один и теперь мы здесь то же самое как на роутере сначала указываем алгоритм шифрования потом алгоритм хэширования и spds у нас был да давайте сейчас на роутере посмотрю шоу крипто и писи и transform set espds и esp md5 espd с кейс p md5 и ищем все настройки для второй фазы у нас тоже есть теперь нам нужен access лист чтобы отобрать

интересный трафик со стороны ассо понимаем да что это трафик который будет проходить из сети за спиной у ассо в сеть роутера он должен быть зеркальный тому access листу который мы задали на роутере давайте писать с лист там назовем его не знаю крипту а цель расширенный и скажем permit айпи из нашей внутренней сети 10 2 1 0 у меня будет 10 2 блин стоять 10 210 мы помним что на оси access листы пишется не с валкардами не с обратными масками а с нормальными дальше к сети 1111 по 32 маски но мы будем шифровать только тот трафик который будет идти из нашей внутренней сети то есть от нашего коммутатора

на лоббек роутера access лист мы создали и теперь нам нужно связать все это воедино такая же конструкция как на роутере у нас есть криптомап криптомап здесь не так удобно может быть она пишется вот таким образом криптомап назовем ее там 71 fix не номер правила народ римы могли как написать народ 3 было удобно писать здесь не очень потому что там броутере конфиг более структурированные мы назвали номер правил написали дальше внутри уже пишем а здесь как как стандартных аксесс листах народ ряда мы все пишем каждый раз одно и то же строчку криптомап 7 110 и говорим для адреса адрес у нас ссылаемся на

аксесс лист крипто аксесс лист дальше опять все то же самое криптомап сиев теперь мы говорим сет пир какой у нас там пир 10 111 у меня будет 10 111 теперь мы говорим в криптомапе какой transform set использовать и киев версия сет забыл сеток версии 1 transform set у меня назывался тс-1 с 1 perfect forward secrecy мы не включали с вами если посмотреть в нашу криптомапу и осталось применить криптомап на интерфейсе роутер на интерфейсе осы прошу прощения это все делается здесь здесь в оси также как и access

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

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

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

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

адрес remote это адрес нашего соседа и будет вот он второй туннель отсюда начинаться так как посмотреть бегают ли пакетики вот они у нас inbound и сп и outbound здесь будет вот про туннель в одну сторону здесь будет протонет другую тут будет информация отдельно по ним написано и будет показано что какой transform set так это все тайминги тайминги тайминги тайминги самое главное еще вот здесь здесь настройки и вот здесь вот самое главное сколько пакетиков у нас было инкамсулирована сколько пакетиков было зашифровано для скольких пакетиков был посчитан хэш дайджест мы помним аутентификация

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

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

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

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

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

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

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

настраивали игры правда там же все элементарно мне вот очень хорошо с вашей группы работать потому что все были на сессийные и все прекрасно знают как настроить там гре туннель это это программ курса и синди два по моему а может быть даже один вот здесь в принципе будет похожая вещь мы создаем туннельный интерфейс вот так же как грей интерфейс мы создали до source destination там определили вот точно так же просто будет инкапсуляция другая указана и плюс мы потом этот туннель возьмем и скажем что этот туннель все что через него проходит защищать айпи секом фига x но предварительно надо понимать что нам нужно опять же айпи сек нуждается в настройке нам нужно создать политику айк создать для первой фазы для второй фазы то есть все эти настройки никто не отменял и шайпи сек живой человеческий

только здесь будет немножечко по-другому здесь криптомап не будем никакой создавать мы вот первый второй фазы настроили потом мы создали так называемый так называемый профиль айпи сек ну это профиль в котором мы указываем грубо говоря transform set который потом применять это такой как упрощенный криптомап и применяемой письмо туннельном интерфейсе вот одна команда самое главное где мы говорим что туннель protection защищать этот туннель с помощью и письмо вот с таким-то профилем который мы определили до этого а туннель мод вот режим туннеля мы можем поставить просто и письмо и у нас будет работать чистый письмо на самом деле можно взять гре туннель горы ешный и точно также на него навесить айпи си просто будет еще лишним капсуляция в горе но это необязательно делать то

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

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

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

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

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

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