Vpn ikev2 настройка iphone

Мы занимаемся разработкой, изготовлением и продажей тестеров для хеш-плат асиков Antminer S9, S9i, S9j. Готовые устройства можно приобрести лично в офисе в г. Иркутск. Если Вы попали на этот сайт — вероятнее всего Вы уже купили тестер. Скоро здесь будет информация по нему

WordPress — правильные права на файлы и папки

ubuntu install php7.4

Добавить репозиторий, обновить список пакетов, установить новые пакеты (самые популярные)

Как выйти из docker контейнера

Допустим Вы подключились к консоли запущенного docker контейнера командой

где fb15408fd3b0 — id docker контейнера, который можно узнать командой «docker ps».

Django disable CSRF for view

Можно использовать декоратор csrf_exempt (You can use decorator csrf_exempt)

Django — rename a model field

Как переименовать поле модели в django (пример команд).

Обновление до Ubuntu 18.04 — кривой шрифт

Многопоточный RSYNC

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

Неровный график в cacti

Вот такого вида график рисовал cacti после первоначальной установки и настройки. Он врядли похож на рваный график, данные все таки приходят в моменты падений, но они явно какие то некорректные. Первое что нужно сделать для исправления ситуации это установить spine

Цели ZEN (ZenCash) на 2018 год

Из публичного чата в телеграме стащил цитату планов на 2018 год у команды ZEN. Читаем, вникаем, закупаемся монеткой. Или майним и копим. Сейчас в обороте уже 2.8 млн. из 21 млн. (для сравнения в bitcoin эта цифра 16.7 млн. из 21 млн.) Continue Reading

Жеcткая перезагрузка linux

Аналог кнопки reset. Можно выполнить удаленно через ssh. Выполняет жесткую перезагрузку системы.

Проверка жесткого диска в Ubuntu

Раньше я пользовался утилитой MHDD для проверки дисков. Но оказалось, что ее функционал вполне может заменить утилита e2fsck с некоторыми ключами. Задача найти битые сектора и указать системе не использовать эти области. Continue Reading

linux запуск скрипта от имени пользователя

Когда требуется запустить bash скрипт от имени другого пользователя, можно использовать следующую конструкцию

bash script pause

Use the sleep command.

device descriptor read/64, error -110

При попытке установить Ubuntu с флешки показывалась эта ошибка и намертво зависала установка.

Вся проблема оказалась в том, что в BIOS был отключен IOMMU. После включения проблема исчезла.

Материнская плата Gigabyte GA-990FXA-UD3

Nvidia GTX 1080 — установка и настройка для майнинга на Ubuntu 16.04

Поставил на древнее железо (LGA 775, intel 1 core, 2Gb DDR2) Ubuntu 16.04 Desktop. Однако после перезагрузки система не загрузилась. по сети была недоступна. Если загружать в recovery mode и затем выбирать resume — система загружалась.

После нескольких часов опытов я вывел формулу успеха: добавил опцию в меню grub + установил драйвера с сайта nvidia. В итоге система начала загружаться, и как ни странно успешно майнить ewbf майнером на 2 Гб оперативной памяти. Ниже распишу все по шагам.

Обратный туннель ssh

На клиенте за NAT (на который хотим попадать) связываем 22 локальный порт с портом 5444 на сервере (с белым ip):

*Подставьте свой user и server, например root@80.47.143.56

yii2 — миграции

В Yii 2 есть механизм миграций. По сути миграции в БД это изменение структуры.
Пример использования:

Работа со swap в linux (Ubuntu)

Основные команды для управления swap файлом.

Выгрузить содержимое swap в оперативную память

Источник

IKEv2 и Flex VPN средствами Cisco IOS. Синтаксис и логика работы

В настоящей статье я попробовал в максимально доступном и сжатом виде описать что такое IKEv2, FlexVPN и как это реализовано в IOS маршрутизаторов Cisco. Для наилучшего понимания содержания, нужно чтобы читателя, на момент ознакомленимя с нижеприведенным текстом, не пугали такие слова как VPN, IPSec, ISAKMP, ISAKMP Profile и т.д. Кроме того, желательно иметь хорошее представление о том, как настраиваются различные типы VPN с использованием VTI интерфейсов (или GRE over IPSec) на оборудовании Cisco, поскольку статья в значителной степени опирается на знание этих вопросов.

Предисловие

Коротко об основных особенностях и отличиях IKEv2 от своего предшественника

Тезисно перечислю наиболее значимые на мой взгляд вещи:

1. Оба протокола работают по UDP/500(4500 в случае с NAT-T), но между собой несовместимы, т.е. не получится так, чтобы на одном конце туннеля был IKEv1, а на другом – IKEv2. При этом один и тот же роутер может терминировать на себе и IKEv2 и IKEv1 туннели одновременно. В заголовках IKEv1 и 2 достаточно различий для того, чтобы роутер смог определить с чем имеет дело, несмотря на одни и те же порты.

2. В IKEv2 больше нет таких понятий как aggressive/main mode, что является одним из аспектов, делающих протокол более простым для понимания.

3. В IKEv2 термин фаза1 заменен на IKE_SA_INIT (обмен двумя сообщениями, обеспечивающий согласование протоколов шифрования/хеширования и генерацию DH ключей), а фаза2 – на IKE_AUTH (тоже два сообщения, реализующие непосредственно аутентификацию пиров и генерацию ключей для ESP). Обмен данными в IKE_AUTH всегда зашифрован с помощью SA, сформированными IKE_SA_INIT. Isakmp SA теперь называются ikev2 sa, а ipsec sa — Child SA.

4. в IKEv2 метод аутентификации между пирами больше не согласовывается автоматически и не привязан к тем или иным политикам IKEv2. Т.е. если раньше в IKEv1 каждой isakmp policy была строка authentication, где указывалось, каков будет тип аутентификации, в случае если будет выбрана именно эта policy, то теперь метод аутентификации задается вручную и явно определяется что вот с этим пиром будет аутентификация по сертификатам, а вот с этим – по pre-shared key. Кроме того, в IKEv2 стала возможна ассимметричная аутентификация. Т.е. можно сделать так, что эндпоинт A будет аутентифицировать эндпоинт B по сертификатам, в то время как B будет аутентифицировать A по pre-shared ключу. Или же А аутентифицирует B с помощью pre-shared key1, в то время как B аутентифицирует A с помощью pre-shared key2. Возможны и другие варианты, в т.ч. аутентификация с использованием различных методов EAP.

5. Mode Config (то, что в ikev1 называлось phase 1.5 и используется для настройки удаленных подключений RAVPN/EasyVPN), NAT-T и keepalives теперь непосредственно описаны в спецификации протокола и являются его неотъемлемой частью. Раньше же эти вещи реализовывались вендорами по своему по мере необходимости.

6. в IKEv2 добавился дополнительный механизм защиты control-plane (services plane) от DoS атак. Суть его в том, что прежде чем отвечать на каждый запрос в установлении защищенного соединения (IKE_SA_INIT) IKEv2 VPN-шлюз шлет источнику такого запроса запроса некий cookie, и ждет, что тот ответит тем же. Если источник ответил – отлично, можно начинать с ним генерацию DH. Если же источник не отвечает (в случае с DoS атакой так и происходит, — это по сути сравнимо с TCP SYN flood attack), VPN-шлюз просто забывает о нем. Без этого механизма, при каждом запросе IKE_SA_INIT IKEv2 от кого угодно VPN-шлюз бы пытался сгенерировать DH ключ (что, как известно, весьма ресуроемкий процесс) и вскоре бы остался с убитой (пусть временно) control-plane.

Что такое FlexVPN?

FlexVPN — это фреймворк, реализющий IKEv2 в IOS маршрутизаторов Cisco. Т.е. это IKEv2+IPSec в синтаксисе команд IOS. Не более того.

Основная фишка, FlexVPN (ключевое слово Flex – Flexible), которую Cisco позиционирует как отличительную особенность FlexVPN, это то, что одна и та же конфигурация VPN-шлюза позволяет цеплять к нему разные типы туннелей – Remote Access, Site-to-Site, etc. Хотя, на мой взгляд, той же (ну или почти той же) flexibility можно добиться и в традиционной IKEv1 настройке, если использовать VTI интерфейсы. Ну да ладно, это все мое ИМХО.

Далее разберем сейчас разберем как выглядит синтаксис FlexVPN, какие комнды он использует, что они означают, для чего нужны, как соотносятся с аналогичными командами в IKEv1.

Синтаксис FlexVPN в части настройки IKEv2

Итак, основные (и, ИМХО, все) компоненты IKEv2 в Cisco IOS, это:

1. Proposal
2. Policy
3. Keyring
4. Profile

Далее о каждом по порядку.

IKEv2 proposal пределяет какие алгоритмы будут задействованы для установления/защиты IKE_SA_INIT фазы. По сути своей – это аналог crypto isakmp policy в IKEv1, хотя и не в полной мере.
Выглядит так:

Первое отличие от isakmp policy в том, что в один proposal можно засунуть сразу несколько алгоритмов/длины ключей шифрования/DH/хеширования. Второе отличие, о чем упоминалось ранее – нет строки authentication, поскольку теперь аутентификация – это отдельный вопрос. Третье отличие – proposal не является самостоятельной частью конфига и должен быть помещен в policy.

IKEv2 Policy – это контейнер для proposal, и не только. Тут сначала пример, а потом поясню:

Как видно, policy ссылается на proposal. Но, кроме этого, она добавляет возможность выбрать тот или иной proposal в зависимости от того, 1) в каком VRF находится интерфейс, к которому подключается удаленный пир; 2) к какому локальному адресу подключается удаленный пир. Если сравнить это crypto isakmp policy в IKEv1, то там crypto isakmp policy были глобальными для всех подключений. В принципе отсутствовала возможность сделать так, что для части пиров могут быть использваны только policy 1,2,3 а для другой части 4.5.6. Тут такая возможность есть, хотя и не уверен, что в этом есть большая практическая польза. Но, тем не менее…

Таким образом, еще раз подчеркну:
Crypto ikev2 policy + crypto ikev2 proposal в IKEv2 выполняют ту же роль, что и crypto isakmp policy в IKEv1.

IKEv2 Keyring – это репозиторий, в котором хранятся pre-shared ключи. Очевидно, что keyring используется и имеет смысл только если выбран метод аутентификации по pre-shared ключам. В случае, если для аутентификации используется PKI, нужно настраивать не keyring, a Trustpoint. Если провести аналогию с IKEv1, там в самом простом случае для задания pre-shared ключей использовалась такая конструкция:

Т.е. pre-shared ключи были самостоятельными элементами конфигурации, каждый сам по себе. В IKEv2 же появился своеобразный контейнер, keyring, благодаря чему конфиг выглядит более структурированным, + добавляются некоторые дополнительные возможности.
Пример того, как может выглядеть keyring vpn-шлюза, установленного в HQ, для взаимодействия с двумя удаленными площадками (в отсутствии глубоких навыков рисования таблиц в html, вставил в виде картинки):

IKEv2 profile лежит в основе FlexVPN и является основной его составляющей. Он определяет «политику» удаленного доступа к VPN-шлюзу. По своему назначению IKEv2 profile – полностью аналогичен IKEv1 isakmp profile в Cisco IOS или tunnel-group (connection profile) если вспомнить ASA, но имеет больше возможностей и более гибок в настройке. Это своеобразный репозиторий параметров, которые не согласовываются участниками VPN-взаимодействия автоматически, а определяются статически. Какие именно функции он выполняет? В процессе установки VPN-соединения, а в частности IKE_INIT_SA VPN-шлюзу нужно знать (цифры в скобках — это не ссылки на список использованной литературы, а ссылки на строки конфига, приведенного ниже):

1. Как аутентифицировать подключающийся пир (PKI? Pre-shared keys?). В IKEv2 тип аутентификации, как я раньше упоминал, – not negotiated, и должен быть явно определен. Во FlexVPN для этого используется ikev2 profile (1).

2. Каковы должны быть параметры dead-peer detection (DPD). В IKEv2 таймеры DPD также не согласовываются автоматически, а задаются вручную в настройках ikev2 profile (2) (хотя могут быть определены глобально).

3. Какой keyring должен быть использован для аутентификации удаленного пира в случае с аутентификацией по pre-shared ключам – это тоже параметр ikev2 profile (3).

4. Какой trustpoint использовать для аутентификации удаленного пира, в случае с PKI-аутентификацией – тоже параметр ikev2 profile (4).

5. Как представить себя удаленному пиру, что выбрать в качестве собственного IKEv2_ID – тоже параметр ikev2 profile (5).

6. В какой iVRF – поместить трафик, после того, как он будет расшифрован (VRF-aware IPSec) – параметр ikev2 profile (6).

Пример IKEv2 профиля:

crypto ikev2 profile profile_name
&nbsp &nbspmatch local_address|certificate map|FVRF|IKEv2_ID of remote peer
&nbsp &nbspauthentication > (1)
&nbsp &nbspdpd interval retry-interval (2)
&nbsp &nbspidentity local (5)
&nbsp &nbspkeyring name (3)
&nbsp &nbspivrf name (6)
&nbsp &nbsppki trustpoint label [sign | verify] (4)
&nbsp &nbspvirtual-template number

Т.е. профиль IKEv2 определяет множество параметров VPN-подключения. И таких профилей в конфигурации может быть множество, и каждый может определять различных набор параметров, в зависимости от того, кто/что подключается к шлюзу (или к кому подключается шлюз). И вот это «в зависимости» определяется директивой match (директив match в одном профиле может быть несколько).

Например, имеем два профиля:

С такой настройкой, когда удаленный пир с Src IP = 1.1.1.1 подключится к локальному шлюзу, к нему (пиру) будут применены параметры, описанные в PROFILE1. Когда к локальному шлюзу подклчючится пир с fqdn=remotepeer2.someorg.com – к нему будут применены параметры, описанные в PROFILE2.

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

Что дальше?

Так вот, эти четыре продемонстрированные выше конструкции (policy,proposal,keyring,profile) определяют настройку того, что в IKEv1 называлось phase1. В IKEv2 — это IKE_SA_INIT, но суть абсолютно та же.
Что делать после того, как IKE_SA_INIT настроены? Правильно. Нужно настроить профиль IPSec, определить какой трафик будет ходить через тунель (proxy-ACL или тунельный интерфейс — VTI, где за это отвечает маршрутизация), т.е. выполнить то, что в IKEv1 называлось настройками второй фазы. Эта часть настроек в IKEv1 и в IKEv2 абсолютно идентична. Как выглядит конфиг целиком, приведу ниже на простом примере.

Чтобы совсем не думать

Необходимо упомянуть, что FlexVPN в IOSпо дефолту преднастроен так, что требует минимум действий со стороны администратора для быстрой настройки VPN, если администратору не сильно хочется/лень вникать как все это работает и выполнять какие-то умные настройки. Для этого предназначены так называемые smart-defaults. Smart-defaults – это заранее сконфигурированные дефолтные ikev2 proposal/policy/profile, ipsec profile, etc. Объективно smart-defaults могут быть весьма полезны и имеют право на существование. Зачем постоянно вбивать одни и те же настройки, если они уже есть в конфиге? Посмотреть на них можно выполнив команду sh run all | s crypto. Вывод команды будет примерно такой (часть вывода опущена за ненадобностью):

Т.е. видно, что в конфиге по дефолту настроеные и IKEv2 proposal и IKEv2 policy, и IPSec transform-set и IPSec profile. Причем сконфигурированы они так, что высший приоритет имеют наиболее серьезные алгоритмы, что нас вполне устраивает. Естественно, что наибольшую предсказуемость работы VPN обеспечит только ручная настройка всех параметров, но как last-resort — могут быть использованы и дефолтные.

Пример

Дальше рассмотрим достаточно простой пример Site-to-Site VPN с pre-shared аутентификацией. Топология выглядит так:

Нужно настроить IPSec/IKEv2 тунель между маршрутизаторами Site1Router и Site2Router и обеспечить взаимную доступность лупбеков каждого из маршрутизаторов через туннель с использованием динамического протокола муршрутизации.
Конфиг каждого из роутеров в данном случае будет таким:

В данном примере конфиг имеющий отношение к настройке IKEv2 и IPSec выделен цветом. В примере задействованы те самые smart-defaults (см. вывод sh run all выше — т.е. можно просто взять и мысленно дорисовать эти настройки к конфигу каждого роутера), которые задают параметры по умолчанию для IKEv2 policy/proposal, IPSec transform-set. IPSec profile тоже используется дефолтный. В конфиге он ссылается на профиль ikev2 и вешается на туннельный интерфейс для его защиты. В результате конфиг получается довольно компактный и легко читаемый. Как видно из примера, настройка всего, что в IKEv1 имело отношение ко 2 фазе, аналогична таковой в IKEv1. Т.е. создается такой же crypto ipsec transform set (тут взят дефолтный), этот transform-set вместе с ikev2 профилем привязывается к ipsec профилю, ipsec-профиль вешается на интерфейс, работающий в режиме ipsec ipv4 (VTI).

Некоторые команды show

После того, как туннель успешно установился, посмотрим вывод некоторых команд:

Site1Router#sh crypto ipsec sa

Вывод sh crypto ipsec sa такой же, как если бы мы настраивали традиционный Ikev1, поскольку ESP все равно, кто для него подготавливает ключевую информацию — IKEv2 или IKEv1. Далее:

Site1Router#sh crypto ikev2 sa detailed

Тут уже видим специфичную для IKEv2 информацию — использованные алгоритмы шифрования/хеширования/DH группы. Видно также что IKEv2 профиль не был привязан к специфичным VRF (поскольку использовались smart-default). Видно, что инициатором соединения был Site2Router.

Site1Router#sh crypto engine connections active

Тут опять ничего нового. Имеем два unidirectional IPSec SA (строки, начинающиеся с 11 и 12) и один bidirectional IKEv2 SA.

Вывод sh crypto isakmp sa, как и ожидается, ничего не показывает:

Site1Router#sh crypto isakmp sa

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

Источник