IPsec — сложный стек протоколов. На клиентской стороне он обычно автоматизирован, что в сочетании с его названием легко может вызвать у пользователя ощущение полной безопасности. Однако не всегда оправданное. Только IPsec из протоколов, пригодных для организации VPN, поддерживают все сетевые ОС, поэтому у тебя есть неплохой шанс с ним столкнуться. И чтобы быстро настраивать соединения и правильно оценивать их безопасность, нужно понимать, как работает протокол.
Из чего состоит IPsec?
IPsec — это не один протокол, а три или четыре, смотря как считать. В OpenVPN и других решениях на основе TLS все просто: устанавливается соединение по TCP или UDP, согласовываются параметры, а затем передаются данные.
В IPsec за согласование параметров и собственно передачу данных отве‐ чают разные протоколы. В Linux, BSD и многих специализированных ОС маршрутизаторов туннель можно настроить вручную, без помощи управляющего протокола.
главная
— Статьи — Mikrotik
Дата обновления: 04.02.2022
Теги: VPN сервер Mikrotik
В этой инструкции описана настройка VPN сервера IKEv2 на Mikrotik на базе ключей, без паролей. Это максимально безопасный вариант VPN, подбирать пароль в этом случае бессмысленно. Это затрудняет начальную настройку сервера, требует отправки клиенту сформированных сертификатов, что в некоторых случаях может быть менее удобным. Но, как и всегда, действует правило «вам шешчки или ехать?» — больше безопасности — меньше удобства. Это верно почти всегда.
IKE означает «Internet Key Exchange» и чтобы было, чем обмениваться, это надо сначала настроить. В общем, весь процесс настройки VPN сервера состоит из двух частей, по большому счету: выпуск и экспорт ключей и сертификатов и настройка IPSec. Дополнительно приведен пример firewall. Итак, есть микротик, VPN IKEv2 будем «вешать» на IP адрес 1.2.3.4. Можно и по доменному имени, а можно по публичному IP-адресу, без доменного имени. Рассмотрю вариант, когда доменного имени нет.
UPD: Можно также использовать сервис sn.mynetname.net (url микротика станет вроде 12345.sn.mynetname.net, где 12345 — серийный номер вашего микротика) но, честно говоря, просто не пользовался этим сервисом сам в течении длительного времени, поэтому рекомендовать этот вариант доменного имени не стал.
- K9 говорит о том что шифрование разрешено но верить все написанному нельзя Един,
Serb (?), 06:06 , 06-Ноя-19, (1)
- Откройте для себя фичанавигатор https cfn cloudapps cisco com ITDIT CFN jsp ,
fantom (??), 11:17 , 06-Ноя-19, (2)
- Это же авито, там всё что угодно может быть PS На антициско брал генератор лиц,
abi (?), 11:21 , 06-Ноя-19, (3)
- ASA и ISRv2 это совсем разные железки, так для справки Внутри — ничего общего ,
Pofigist (?), 11:29 , 06-Ноя-19, (4)
- Просите у продавца вывод show version, show license feat, show inventory По резу,
Andrey (??), 15:37 , 06-Ноя-19, (5)
- Без разницы что там есть, главное чтобы железо было рабочим 1 Залить софт без с,
BJ (ok), 09:46 , 10-Ноя-19, (6)
- Спасибо, большое Сделали по общему ключу, вот теперь думаю сделать аутентифик,
Enot (??), 10:23 , 16-Ноя-19, (7)
- Аутентификация по сертификатам работает предельно просто Если циски имеют серти,
BJ (ok), 22:05 , 16-Ноя-19, (8)
- А ц Вас есть прошивка для этого роутера https www vtkt ru catalog localarea ro,
Enot (??), 19:33 , 19-Ноя-19, (9)
| 1. «IPSec лицензия» | +/– |  |
| Сообщение от Serb (?), 06-Ноя-19, 06:06 | ||
|
||
| Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору | ||
 |
||
| 2. «IPSec лицензия» | +/– | |
| Сообщение от fantom (??), 06-Ноя-19, 11:17 | ||
|
||
| Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору | ||
| 3. «IPSec лицензия» | +/– | |
| Сообщение от abi (?), 06-Ноя-19, 11:21 | ||
|
||
| Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору | ||
|
||
| 4. «IPSec лицензия» | +/– | |
| Сообщение от Pofigist (?), 06-Ноя-19, 11:29 | ||
|
||
| Ответить | Правка | ^ к родителю #3 | Наверх | Cообщить модератору | ||
| 5. «IPSec лицензия» | +/– | |
| Сообщение от Andrey (??), 06-Ноя-19, 15:37 | ||
|
||
| Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору | ||
| 6. «IPSec лицензия» | +/– |  |
| Сообщение от BJ (ok), 10-Ноя-19, 09:46 | ||
|
||
| Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору | ||
|
||
| 7. «IPSec лицензия» | +/– | |
| Сообщение от Enot (??), 16-Ноя-19, 10:23 | ||
|
||
| Ответить | Правка | ^ к родителю #6 | Наверх | Cообщить модератору | ||
|
||
| 8. «IPSec лицензия» | +/– | |
| Сообщение от BJ (ok), 16-Ноя-19, 22:05 | ||
|
||
| Ответить | Правка | ^ к родителю #7 | Наверх | Cообщить модератору | ||
|
||
| 9. «IPSec лицензия» | +/– | |
| Сообщение от Enot (??), 19-Ноя-19, 19:33 | ||
|
||
| Ответить | Правка | ^ к родителю #7 | Наверх | Cообщить модератору | ||
Введение в сертификаты IPSec и настройка Racoon (ipsec openssl crypt security)
Ключевые слова: ipsec, openssl, crypt, security, (найти похожие документы)
From: Сгибнев Михаил Date: Mon, 20 Sep 2004 18:21:07 +0000 (UTC) Subject: Введение в сертификаты IPSec и настройка Racoon Оригинал: http://www.dreamcatcher.ru/docs/ipsec2_bsd.html Введение в сертификаты IPSec Автор: Mike DeGraw-Bertsch Перевод: Сгибнев Михаил В предыдущей статье нами было рассмотрено, как соединить два хоста с помощью предопределенных ключей. Хотите двигаться дальше, в сторону сертификатов X.509? Это хорошая идея, так как ничего сложного в этом вопросе нет и тем более, что метод предопределенных ключей может быть исключен из IPSec версии 2. Все просто, но только в том случае. если Вы знакомы с OpenSSL, в противном случае Вы можете получить немало печальных минут. В данной статье предполагается, что сертификаты формируются между различными хостами и туннельным сервером, но функциональные возможности и установка также идентичны и для транспортного режима. Быстрый обзор Давайте определим список используемых сокращений и определений. Сетрификаты X.509 базируются на методе шифрования с открытым ключом. Каждый сертификат наряду с другой информацией (сроком действия, именем владельца и т.п.) содержит публичный ключ. Секретный ключ владелец сохраняет в отдельном файле. Сертификаты подписываются Certificate Authority (CA), что позволяет подтвердить подлинность сертификата, информации, содержащейся в сертификате и, в конечном итоге, удаленного хоста. Подлинность CA проверяется в соответствии с его свидетельством, которое является общедоступным. Для получения более подробной информации относительно сертификатов X.509 - смотри здесь: http://java.sun.com/products/jdk/1.2/docs/guide/security/cert3.html#inside Требования Выполнение идентификации IPSec на основе сертификатов требует двух вещей. Наличии racoon, по возможности, самой последней версии (смотри в /usr/ports/security/racoon) и OpenSSL, версия 0.9.5a или выше. Версия, идущая с FreeBSD по умолчанию не имеет такого полезного сценария CA.pl, так что Вы должны загрузить и установить последнюю версию OpenSSL, которая по умолчанию поместит CA.pl в/usr/local/ssl/misc/CA.pl. Создание собственного CA С OpenSSL, Вы можете создать ваши собственные сертификаты и даже Certificate Authority - это значит, что Вы можете создать, подписать и распространить свой сертификат по всему миру. В этом случае вся мировая общественность не сможет опознать Вас как CA ("я хочу принять сертификат ООО "Хренсгоры"? Нет!"), но позволяет идентифицировать уникальный хост. И это - все, что Вам необходимо для двух хостов, соединяющихся с вашим туннельным сервером. Вы можете захотеть создать свой CA на туннельном сервере, а можете и не захотеть. Вам решать. Для начала, входите на любой хост, который будет играть роль CA и создайте каталог, где Вы будете хранить свои сертификаты. Создать подкаталоги CA (demoCA), можно запустив следующий сценарий: Когда будет запрошено имя сертификата CA, нажмите Enter. Затем будет запрошен пароль на защиту секретного ключа CA. Очень важно озаботиться безопасностью этого пароля, иначе любой человек сможет подписывать сертификаты от Вашего имени. Затем, будет запрошена информация о вашем местоположении, компании, общем имени, и адресе электронной почты. Все это понятно, кроме "общего имени". Это - принудительный бит однозначного определения данных, типа полностью уточненного имени домена Вашего хоста или Вашего имени. После ввода требуемой информации, подкаталог demoCA будет создан. При большом желании можно дать chmod к файлу частного ключа (demoCA/private/cakey.pem), разрешив его на чтение только для root. Но это не должно быть необходимым, ведь Вы указали хороший пароль? Вы можете игнорировать большинство содержания demoCA, но в ближайшем будущем Вы будете должны использовать demoCA/cacert.pem. Создание и установка сертификатов Теперь, когда все готово для подписи сертификатов, Вы можете создавать их для всех хостов Вашей сети. Есть несколько простых шагов, одинаковых для каждого удаленного хоста и туннельного сервера. Первый шаг должен создать публичный ключ и запрос сертификата. На сервере СА выполните: openssl req -new -nodes -newkey rsa:1024 -sha1 -keyform PEM \ -keyout privkey.pem -outform PEM -out newreq.pem Затем, сертификат должен быть подписан. Проще всего это сделать с помощью команды CA.pl -sign. Укажите пароль СА, затем ответьте "y" на подсказки, указав, что Вы хотите подписать сертификат. В результате Вы будете теперь иметь три файла, чтобы скопировать их на соответствующую машину: demoCA/cacert.pem, newcert.pem, и privkey.pem. Поместите их в /usr/local/etc/racoon/cert на конфигурируемом клиенте. Удостоверьтесь, что только root может читать его! Заключительный шаг заключается в том, что мы должны позволить хосту распознавать другие сертификаты, подписанные нашим СА. Заходим на машину и выполняем: cd /usr/local/etc/racoon/cert ln -s cacert.pem `openssl x509 -noout -hash -in cacert.pem`.0 Символическая ссылка позволяет OpenSSL находить сертификат Вашего СА, основанного на его хэше, таким образом проверяя, что сертификат является подлинным и приемлемым. Все вышеуказанные шаги повторить для всех хостов, соединяющихся с туннельным сервером. Конфигурирование racoon Нашей последней задачей является конфигурирование racoon, таким образом, чтобы он принимал сертификаты. Начинаем править файл конфигурации, обычно это /usr/local/etc/racoon/racoon.conf. Проверяем путь хранения сертификатов6 path certificate "/usr/local/etc/racoon/cert" ; Затем предстоит изменить блок "remote" для принятия и использования сертификатов. my_identifier asn1dn - говорит, что racoon должен идентифицировать себя используя Distinguished Name (DN), как определено в соответствии с его сертификатом. peers_identifier asn1dn определяет, что удаленный хост должен идентифицировать себя с отличительным именем его сертификата. verify_identifier on гарантирует, что посылаемый тип идентификации - тот же самый, который определен в peers_identifier; в этом случае это - asn1dn. Строка certificate_type указывает racoon использовать сертификацию X.509. cert.pem - имя файла сертификата локального хоста, в то время как key.pem - его секретный ключ. Эти имена файла должны быть изменены на данные Вами. Последняя строка, которая была изменена, authentication_method rsasig, говорит racoon, что он должен использовать идентификацию на основе сертификатов для других хостов. Запуск и поиск неисправностей Остановите racoon на клиентах и сервере. Перезапустите их и просмотрите log-файл. Пропингуйте один хост с другого. В конце лог-файла должны обнаружиться примерно такие строки: Если это не так то в первую очередь проверьте все пути в racoon.conf, затем правильность создания символической ссылки, проверьте политики безопасности.
Жизнь – штука коварная и достаточно сложная. Постоянно озадачивает чем-нибудь. На сей раз она озадачила вопросом безопасных коммуникаций через интернет и внутри предприятия. Задача звучит донельзя просто – обеспечить безопасную коммуникацию двух некоторых узлов для одного сервиса. В условиях задачи помимо шифрования так же требуется обеспечить взаимную проверку участников обмена данными. Тут за решением далеко ходить не надо – это IPSec. На первый взгляд всё просто, но в процессе реализации пришлось столкнуться с некоторыми не всегда очевидными и интересными моментами.
Итак, имеется домен Active Directory и два узла внутри домена. На узле А размещёна некоторая служба (будь то терминальные службы, будь то незащищённый FTP). Узел Б должен быть единственным узлом, который имеет право доступа к службе на условном сервере. При этом весь трафик данной службы подлежит обязательному шифрованию и проверке целостности/неизменности пакетов во время передачи данных. В первую очередь предстояло подумать на предмет надёжной аутентификации обоих узлов. Если говорить про IPSec, то он предлагает 3 варианта аутентификации:
- Kerberos
- Certificates
- Shared Key
Kerberos в данном случае не поможет, т.к. он позволит аутентифицировать любой компьютер в сети, для которого есть разрешённая учётная запись в Active Directory. Shared Key – просто и гламурно, но не сильно безопасно. Вариант с цифровыми сертификатами в данном случае выглядит более предпочтительным, но и наиболее сложным в плане реализации и поддержке. Для этих целей потребуется развернуть (если его ещё нету) или использовать существующий Enterprise Certification Authority (Enterprise CA). Посредством этого CA необходимо издать для обоих компьютеров сертификат, у которого в поле Purposes указано Server/Client Authentication. Для этого достаточно с каждого компьютера запустить оснастку Certificates для локального компьютера, в меню View выбрать Options и там выставить переключатель в Certificate Purpose. После чего нажать правой кнопкой на Server или Client Authentication (в зависимости от роли компьютера) и выбрать Request New Certificate. В списке доступных шаблонов можно выбрать шаблон IPSec, который идеально подходит для наших целей. Если данный шаблон не предлагается в мастере, то необходимо зайти в оснастку Certification Authority выделить Certificate Templates. Далее Action -> New -> Certificate Template to Issue. Для проверки, что сертификаты выданы можно просмотреть секцию Issued Certificates в оснастке Certification Authority. Напомню, если кто-то не знает, то IPSec может работать только с сертификатами компьютеров, т.к. он работает на сетевом уровне модели OSI, который находится ниже уровня пользователя и приложений. Поэтому работа IPSec для пользователя полностью прозрачна.
Теперь можно приступать к реализации политики IPSec. В рамках данной статьи для защиты был выбран протокол RDP (вместо него можно использовать любой другой). Для запуска консоли IPSec можно запустить консоль secpol.msc и в самом низу будет IP Security Policies. В правой секции нажимаем правой кнопкой и выбираем создание новой политики. Копками Next-Next проходим создание политики, по ходу заполняя нужные поля. Назовём эту политику Custom. Создавать Default Response Rule не обязательно. После создания новой политики мы получим примерно такое окно:
Как известно, по умлочанию дефолтное правило IPSec – запрещено всё, что не разрешено. Поэтому для начала нужно разрешить протекание всего трафика для компьютера, иначе сеть работать не будет. Поэтому в основном окне политики нажимаем кнопку Add и кнопками Next двигаемся вперёд. В окне Tunnel Endpoint указываем, что данное правило не использует туннель IPSec, далее в списке IP Filter List выбираем уже готовое правило All ICMP Traffic и выбираем для него действие Permit (разрешить). Ту же самую процедуру проделываем и для правила All IP Traffic (в списке IP Filter List). В результате мы должны получить вот такую картину:
если оставить всё как есть, то после применения политики ничего не изменится, т.к. весь трафик разрешён, как IP, так и ICMP. Эту операцию необходимо выполнить на обоих компьютерах-участников защищённого соединения. Теперь нужно создать правило прохождения трафика RDP. Сначала возьмём условный сервер. Возвращаемся к окну редактирования основной политики. Для этого снова нажимаем Add и доходим до окна IP Filter List без изменений. В окне IP Filter List нажимаем кнопку Add. В окне редактора правил вводим созвучное название правилу, например, RDP Server и сбоку ещё раз нажимаем Add. В окне IP Filter Description and Mirrored property убеждаемся, что выставлен чек-бокс напротив Mirrored. Суть этой галочки в том, что она позволяет как получать запрос, так и отправлять ответ используя одно и то же правило. В нашем примере RDP трафик для сервера описывается следующими характеристиками:
- Source Address = указать конкретный адрес клиента, которому разрешено (или нужное выбрать из списка)
- Destination Address = My IP Address. Т.к. этот компьютер является сервером, то получать основные запросы будет он.
- Protocol Type = TCP (в списке протоколов есть RDP, но это совсем не то, о чём вы подумали 🙂 )
- Source Port = Any
- Destination Port = по дефолту 3389 для RDP
применяем все изменения и возвращаемся снова в окно IP Filter List, где выбираем новое правило – RDP Server. Переходим кнопкой Next на окно действия фильтра. Можно выбрать Require Security, но для практики мы создадим самое жёсткое действие – HardSecurity, поэтому нажимаем кнопку Add, вводим название, далее шаблон действия – Negotiate Security, следующее окно пропускаем без изменений и доходим до окна IP Traffic Seccurity. Здесь мы можем выбрать режим защиты. Можно выбрать следующее:
- Integrity and Encryption – обеспечивает максимальную защищённость, как шифрование, проверка подлинности, проверка целостности пакетов, проверка очереди отправки пакетов и т.д. Для шифрования будет использоваться метод 3DES (Triple Data Encryption Standart), а целостность и проверка подлинности пакетов будет проводиться за счёт алгоритма SHA1 (Secure Hash Algoritm).
- Integrity only – обеспечивает проверку целостности, подлинности, очерёдности следования пакетов. Обеспечивается алгоритмом SHA1
- Custom – можно вручную настроить алгоритмы проверки целостности и подписания пакетов и алгоритмы шифрования.
В условиях статьи использовался Integrity and Encryption. Когда создание действия фильтра сделано, в окне Filter Action (куда мы вернёмся после создания нового действия фильтра) и нажимем Next. Т.к. мы выбрали Negotiate Security (согласование безопасности), то в окне Authentication Metod нужно выбрать метод аутентификации участников соединения. Т.к. мы находимся в домене, где есть Enterprise CA и для компьютеров уже изданы сертификаты, то выбираем метод аутентификации сертификатами. При нажатии кнопки Browse откроется список всех доступных CA, для которых на локальном компьютере есть корневые сертификаты и которым данный компьютер доверяет. Поэтому сертификаты компьютерам может выдавать не только доменный Enterprise CA, но и любой доверенный. Т.к. сертификаты для компьютеров выдал доменный CA, то в списке нужно указать именно его. Если всё сделано правильно, то основное окно политики должно выглядеть примерно так:
Ту же самую процедуру проделываем и на клиенте за одной лишь разницей: при создании нового фильтра в отличии от сервера меняются местами Source Address и Destination Address. Всё остальное делается точно так же. Когда всё будет завершено кнопкой Ok закрываем основное окно редактора политики. Применить политику легко – правой кнопкой на политику и нажать Assign. Следует отметить, что политика применяется мгновенно. Если применить политику только на одном компьютере, то коммуникации по протоколу RDP не произойдёт, поскольку второй участник соединения не будет знать как согласовывать безопасность и его подлинность не удастся проверить. Если теперь применить созданную политику на всех компьютерах-участниках защищённого соединения, то RDP трафик станет шифрованный с проверкой подлинности каждого пакета. Пользователь не будет знать, что RDP трафик защищён, всё будет предельно прозрачно для пользователя.
Теперь можно перейти к насущным вопросам реализации IPSec
Необходимо понимать, что на пути между двумя узлами не должно быть NAT-маршрутизаторов. Дело в том, что NAT изменяет заголовки пакетов (а соответственно новые контрольные суммы не будут совпадать с контрольными суммами в шифрованном пакете), после чего пакеты по мнению IPSec будут считаться повреждёнными и будут дропаться. Для Windows XP SP2, Windows Server 2003, а для Windows 2000 в виде отдельного обновления есть возможность использования NAT-Traversal (NAT-T), который обеспечивает прохождение IPSec трафика через NAT-маршрутизаторы.
И немного о сертификатах
Если сертификат компьютера в CA будет по каким-то причинам отозван, то в теории коммуникация посредством этого сертификата будет невозможна. Но на практике всё не совсем так. Дело в том, что даже если зайти в CA домена и отозвать один из сертификатов, которые были изданы для IPSec (или оба сертификата), то защищённое соединение будет установлено с использованием отозванного сертификата! Как так? Здесь нужно учитывать два момента:
- если сертификат отозван, то он незамедлительно помещается в список отозванных сертификатов – CRL (Certificate Revocation List). Но компьютеры в сети смогут узнать о том, что сертификат отозван не ранее очередного времени публикации полного списка CRL или инкрементального списка DeltaCRL. По умолчанию полный список CRL в Windows Server 2003 публикуется раз в неделю. А Delta CRL – раз в сутки. До времени публикации одного из списков CRL отозванный сертификат можно будет ещё использовать. К слову говоря, Windows 2000 не умеет считывать Delta CRL, поэтому для Windows 2000 можно будет использовать отозванный сертификат до очередной публикации полного списка CRL (по дефолту может занять до недели). Чтобы принудительно опубликовать список CRL вне расписания нужно зайти в консоль CA и на разделе Revoked Certificates на жать Publish. После чего выбрать какой тип CRL (полный или только дельта) публиковать.
- особенности проверки компьютерами списков CRL. Вот тут остановлюсь подробнее.
Как работают различные системы со списками CRL при проверке сертификата (адреса, по которым доступны списки CRL публикуются в самом сертификате):
- Windows 2000 – при проверке сертификата по умолчанию НЕ проверяет списки CRL на предмет отозванности сертификата и руководствуется только содержимым самого сертификата.
- Windows XP/Windows Server 2003/Windows Vista – по умолчанию проверяют списки CRL на предмет отозванности сертификатов. Но, при недоступности этого списка для проверки сертификата руководствуются только содержимым самого сертификата!
Для того, чтобы включить принудительную проверку списков CRL и блокировать использование сертификата при недоступности списка CRL можно пойти двумя путями:
netsh ipsec dynamic set config strongcrlcheck value=2
данная команда включит принудительную проверку списков CRL только на момент текущей сесси. После перезагрузки компьютера вновь будет использоваться дефолтное значение. Чтобы использовать строгую проверку постоянно нужно отредактировать (или создать, если не существует) следующее значение реестра:
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\PolicyAgent\Oakley
необходимо изменить (или создать, если отсутствует) параметр типа DWORD с именем StrongCRLCheck. Значение этого параметра может принимать 3 значения:
- 0 – списки CRL не проверяются. Решение о принятии/отклонении сертификата принимается на основе только самого сертификата.
- 1— списки CRL проверяются. Если же список CRL недоступен, то решение о принятии/отклонении сертификата принимается на основе только самого сертификата.
- 2 – списки CRL проверяются. Если список CRL будет недоступен на момент проверки сертификата – сертификат будет отклонён и признан как недействительный.
Вот, в принципе, и всё, о чём я хотел сегодня рассказать. Может, несколько сумбурно, просто старался акцентировать внимание на наименее очевидные моменты реализации развёртывания IPSec с использованием цифровых сертификатов.
Автор:т Vadims Podāns
Источник
Точное время
Настройка времени важна для любого VPN, поэтому сразу проверим/настроим часовой пояс и синхронизацию времени:
В терминале:
/system clock set time-zone-name=Europe/Moscow
/system ntp client set enabled=yes server-dns-names=0.ru.pool.ntp.org,1.ru.pool.ntp.org
Сертификаты и ключи
Наш микротик будет:
а) выдавать и удостоверять ключи для себя (сервер VPN) и удаленных клиентов, для чего сначала будет настроен CA («удостоверяющий центр»),
б) выполнять роль VPN-сервера.
CA («удостоверяющий центр» — выдает заверенные сертификаты сервера и клиентов):
В терминале:
/certificate add name=cacert organization=»Bozza.ru» common-name=»cacert» key-size=4096 days-valid=3650 key-usage=crl-sign,key-cert-sign trusted=yes
/certificate sign cacert
Серверный сертификат:
В терминале:
/certificate add name=Mikrotik organization=»Bozza.ru» common-name=»1.2.3.4″ subject-alt-name=IP:»1.2.3.4″ key-size=4096 days-valid=3650 key-usage=tls-server
/certificate sign Mikrotik ca=»cacert»
Клиентский сертификат:
Внимательно и аккуратно заполняйте поля Common Name и Subject Alt. Name — на основании этих полей на клиенте будет происходить проверка пользователя! Если допустить опечатку на этом месте, потом придется перевыпускать этот сертификат, а это немного заморочный процесс — выпуск, экспорт, скопировать, перенести и т.д.
В терминале:
/certificate add name=»vpnuser1@1.2.3.4″ organization=»Bozza.ru» common-name=»vpnuser1@1.2.3.4″ key-size=4096 days-valid=1095 key-usage=tls-client subject-alt-name=email:vpnuser1@1.2.3.4
/certificate sign vpnuser1 ca=»cacert»
В итоге, у нас есть ключи и сертификаты «cacert» (CA, выпускает и подписывает сертификаты), «Mikrotik» (VPN сервер), «vpnuser1» (клиент).
Экспорт ключей
Для установки на клиентский компьютер/смартфон надо экспортировать сертификат и ключ клиента, защитив пакет паролем:
В терминале:
/certificate export-certificate vpnuser1@1.2.3.4 type=pkcs12 export-passphrase=p@ssw0rd555
и сертификат CA «cacert» (только сертификат, БЕЗ ПРИВАТНОГО КЛЮЧА!):
На картинке опечатка закралась, экспорт происходит именно cacert, а не Mikrotik.
В терминале:
/certificate export-certificate cacert type=pem
Скачайте из Files файлы «cert_export_cacert.crt» и «cert_export_vpnuser1@1.2.3.4.p12» на клиентский компьютер и импортируйте сертификат и закрытый ключ в Личные сертификаты (если это Windows). Сертификат «ca» надо установить в «Доверенные корневые центры сертификации».
Сертификат должен стать для клиента VPN (неважно, Mac, Win, iPhone, Android) ДОВЕРЕННЫМ! Для этого и нужно экспортировать cacert и сделать его доверенным сертификатом CA на клиенте.
На iPhone можно отправить письмо с вложенными файлами сертификатов и установить их через Профили.
IKE VPN
3.1) Pool:
Клиентам VPN лучше всегда давать отдельные IP-адреса, отличные от основного диапазона. Создадим пул адресов для VPN:
В терминале:
/ip pool add name=»ike_vpn_pool» ranges=»10.0.100.2-10.0.100.30″
3.2) Modeconfig:
В терминале:
/ip ipsec mode-config add name=»modeconfig_ikev2″ address-pool=»ike_vpn_pool» address-prefix-length=32 split-include=0.0.0.0/0 static-dns=10.0.100.1 system-dns=no
Вариации:
/ip ipsec mode-config add address-pool=»ike_vpn_pool» address-prefix-length=32 name=»modeconfig_ikev2″ split-include=192.168.88.0/24 static-dns=10.0.100.1 system-dns=no
где 192.168.88.0/24 — сеть, маршрут к которой будет передан клиенту. Т.е. после установки VPN соединения клиент сможет сразу обращаться к ресурсам этой сети.
Если клиенты после подключения к удаленной сети должны иметь возможность обращаться к ресурсам удаленной сети не по IP, а по имени (например, server.office.local, а не 192.168.88.146), то надо передать клиенту не только маршрут до сети, но и сообщить ему адрес DNS сервера, отвечающего за разрешение имен в удаленной сети:
/ip ipsec mode-config add address-pool=»ike_vpn_pool» address-prefix-length=32 name=»modeconfig_ikev2″ split-include=192.168.88.0/24 static-dns=192.168.88.1 system-dns=no
где 192.168.88.1 — IP-адрес DNS-сервера (в данном случае, это IP самого микротика).
3.3) Profile:
Касается т.н. фазы 1 (Phase 1, Security Association, SA), на которой согласовываются тип аутентификации, группа Diffie-Hellman, алгоритм шифрования. SA (фазы 1) существует определенное время, в течение которого устройства должны завершить вторую фазу. Если не успевают, то повторяется фаза 1.
В терминале:
/ip ipsec profile add name=»profile_ikev2″ dh-group=modp1024,modp1536,modp2048 enc-algorithm=aes-128,aes-192,aes-256 hash-algorithm=sha256 nat-traversal=yes proposal-check=obey
3.4) Peer (кого и куда принимаем):
В терминале:
/ip ipsec peer add name=»peer_ikev2″ exchange-mode=ike2 address=0.0.0.0/0 local-address=1.2.3.4 passive=yes send-initial-contact=yes profile=»profile_ikev2″
— принимаем всех (0.0.0.0/0) на внешний адрес микротика (1.2.3.4) — адресов-то может быть много и не обязательно это будет публичный IP.
3.5) Proposal:
В терминале:
/ip ipsec proposal add name=»proposal_ikev2″ auth-algorithms=sha1,sha256,sha512 enc-algorithms=aes-128-cbc,aes-128-ctr,aes-128-gcm,aes-192-ctr,aes-192-gcm,aes-256-cbc,aes-256-ctr,aes-256-gcm lifetime=1h pfs-group=none
Относится к так называемой второй фазе (Phase 2, IPSec SA), когда устанавливается, как будет проходить шифрование и аутентификация (проверка, что получены именно те данные, которые были отправлены) данных, а также частота обновления ключей. По-умолчанию, ключи обновляются каждые 8 часов (это время можно менять параметром lifetime).
3.6) Policy group:
В терминале:
/ip ipsec policy group add name=group_ikev2
3.7) Policy:
В терминале:
/ip ipsec policy add src-address=0.0.0.0/0 dst-address=10.0.100.0/24 protocol=all template=yes group=»group_ikev2″ action=encrypt ipsec-protocols=esp proposal=»proposal_ikev2″
3.8) Identity (для каждого пользователя — свой):
Внимательно и аккуратно выбирайте параметры. Для сертификата «vpnuser1@1.2.3.4» указывается Remote ID «vpnuser1@1.2.3.4» и проверка того, имеет ли право удаленный пользователь подключиться или нет, будет происходить на основании данных из сертификата:
"Remote ID Type"определяет, какой ID ожидается от удаленного клиента. Например, тип «user fqdn«, доступный только в IKEv2, позволяет указать полное имя удаленного клиента в виде «vpnuser1@1.2.3.4»."Match By"определяет, с чем сравнивать «peers identity» (ID удаленного клиента) — с сертификатом (из Remote Certificate) или с данными из поля Remote ID. Не все клиенты могут прислать кастомный ID. Например, встроенный VPN клиент в Windows не позволяет указать Remote ID, а просто предлагает «использовать сертификат компьютера».
В терминале:
/ip ipsec identity add auth-method=digital-signature certificate=Mikrotik remote-certificate=vpnuser1@1.2.3.4 generate-policy=port-strict match-by=certificate mode-config=»modeconfig_ikev2″ peer=»peer_ikev2″ policy-template-group=»group_ikev2″ remote-id=user-fqdn:vpnuser1@1.2.3.4
Дальше надо настроить firewall.
FIREWALL
Сферический firewall в вакууме, нужно аккуратно адаптировать эти правила в ваш firewall.
INPUT (разрешить входящие на 500/udp И 4500/udp):
/ip firewall filter
add action=drop chain=input comment=»invalid» connection-state=invalid
add action=accept chain=input comment=»established» connection-state=established
add action=accept chain=input comment=»related» connection-state=related
add action=accept chain=input connection-state=new dst-port=500 protocol=udp
add action=accept chain=input connection-state=new dst-port=4500 protocol=udp
…
add action=drop chain=input comment=»drop everything else»
ЗЫ: еще пишут в примерах, что надо разрешить протокол ipsec-esp, но я проверял 🙂 отключение ни чему не мешает, поэтому и добавлять лишнее не будем.
FORWARD:
/ip firewall filter
add action=drop chain=forward comment=»invalid» connection-state=invalid
add action=accept chain=forward comment=»established» connection-state=established
add action=accept chain=forward comment=»related» connection-state=related
add action=accept chain=forward comment=»in:ipsec» ipsec-policy=in,ipsec
add action=accept chain=forward comment=»VPN-to-LAN» dst-address=\
192.168.88.0/24 ipsec-policy=in,ipsec src-address=10.0.100.0/24
NAT
Чтобы VPN-клиенты могли выходить в интернет, настроим NAT:
/ip firewall nat
add action=src-nat chain=srcnat ipsec-policy=out,none out-interface=ether1-gateway src-address=10.0.100.0/24 to-addresses=1.2.3.4
add action=masquerade chain=srcnat comment=»default» out-interface=ether1-gateway
Настройка клиентов
iPhone
Передать сертификаты в iPhone можно следующими способами:
1) по email (сертификаты как вложение), открыть вложенный cacert и vpnclient1 программой Mail и установить профиль;
2) по ссылке открыть в Safari и установить профиль
3) передать по AirDrop с MacBook, к примеру.
Стоит подумать, как лучше, потому что в данном случае передается ключ для доступа, а не какая-то ерунда. При отправке по email потом надо удалить письмо из отправленных, входящих, из корзины и еще где там может осесть письмо — автоархив какой-нить. Если передать надо удаленному клиенту, вариантов не много. Но если настраивается устройство, доступное локально — стоит заморочиться.
Например, можно на компе открыть микро-веб сервер, например, с помощью Python:
cd c:\certs\
python -m http.server 8080
и с iPhone в Safari открыть http://ip-address-компа
Установите сертификаты и ключ через профили (там все интуитивно, описывать, думаю, не стоит). А саму настройку VPN IKEv2 — просто приведу картинку-скрин экрана:
Обратите внимание на то, что локальный ID повторяет имя (Name, Common Name, Subject Alternative Name) клиентского сертификата.
Аутентификация пользователя происходит автоматически, на основании данных из сертификата.
MacOS
Суть процесса: открываете «Связка ключей», в ней импортируете сначала cacert (доверенный центр сертификации), а потом сертификат vpnuser1. В «Системные настройки» в пункте «Сеть» добавляете VPN подключение, тип IKEv2, поля заполняете так же как в iOS (картинка выше), выбираете сертификат и все. Готово.
Windows 7/10
Суть такая — сертификат устанавливается в учетную запись компьютера, а не пользователя (по-умолчанию, certmgr.msc предлагает именно Пользователя). mmc.exe — Сертифкаты — Учетная запись компьютера.
Там уже добавляете в доверенные корневые cacert, а в Личные — vpnuser1 (Сертификаты — Личное — Сертификаты, правой мышкой — Все задачи — Импорт).
Ну и настраиваете IKEv2 VPN стандартно.
В общем, все, если все верно, VPN должен подключиться. На самом деле, совсем не факт, что все сразу заработает, логи и светлая голова вам в помощь. Спрашивайте в комментариях, если что-то вызываает вопросы, может, где очепятка, а я не заметил. Но в целом материал проверен руками, не раз. Удачи!
Авторизуйтесь для добавления комментариев!
AH и ESP
Три основных компонента безопасности — доступность, аутентичность и конфиденциальность. IPsec может обеспечивать аутентичность, при этом ничего не делая для конфиденциальности.
Протокол AH (Authentication Header) добавляет в пакет специальный заголовок с контрольной суммой. На практике он используется редко, поскольку никак не способствует конфиденциальности.
Тем не менее его можно встретить в приложениях, где важна только аутентичность. К примеру, протокол маршрутизации OSPFv2 использовал пароли и суммы MD5 для защиты от поддельных анонсов, а его наследник OSPFv3 не включает никакой функциональности для защиты — вместо этого предлагается использовать IPsec в транспортном (прозрачном) режиме и с одной подписью AH без шифрования.
ESP (Encapsulated Security Payload) шифрует содержимое пакета и добавляет хеши. Его можно использовать в двух режимах — транспортном и туннельном. Это сейчас в сетях IPv4 любой VPN немыслим без маршрутизации частных (серых) адресов через туннель, поскольку со внешним миром хосты общаются через NAT. Но IPsec старше NAT и изначально шифровал только полезную нагрузку пакетов, не трогая заголовки, — это и есть транспортный режим.
В туннельном режиме ESP шифрует весь пакет и передает его как полезную нагрузку, на другой стороне он извлекается, расшифровывается и маршрутизируется дальше.
Что интересно, оба они не работают поверх TCP или UDP, а используют отдельные номера протоколов IP. Во всяком случае, по умолчанию — ESP может быть инкапсулирован в UDP для работы через NAT, но об этом позже.
Фреймворк для управляющих протоколов — ISAKMP
Общие принципы согласования настроек безопасности описывает ISAKMP (Internet Security Association and Key Management Protocol). Он описан в RFC 2408.
ISAKMP не является законченным сетевым протоколом. Это фреймворк, который описывает требования к безопасной работе протоколов обмена настройками безопасных соединений, терминологию и общий формат пакетов, но ничего не говорит о конкретных протоколах обмена ключами, шифрования и прочего — это остается на совести реализаций.
Именно из ISAKMP происходят термины Phase 1 и Phase 2, которые часто можно встретить в интерфейсе настройки маршрутизаторов и в описаниях настроек для подключения. Phase 1 — согласование параметров безопасного обмена данными о настройках. Phase 2 — согласование параметров собственно защиты передаваемого трафика хостов или приложений.
Самая популярная и практически единственная реализация ISAKMP — IKE.
Управляющий протокол — IKE
IKE (Internet Key Exchange) — реальный управляющий протокол IPsec на основе ISAKMP. На практике можно сказать, что Phase 1 — согласование настроек IKE, а Phase 2 — согласование настроек ESP.
В UNIX‐подобных системах IKE — это единственная часть стека IPsec, которая работает в виде обычного процесса. Само шифрование реализовано в ядре, и демон IKE передает ему параметры после согласования со второй стороной. В Linux это происходит через netlink или команды ip xfrm.
Подсистема XFRM в Linux обычно ассоциируется с IPsec, но может выполнять и другие преобразования, например сжатие полезной нагрузки.
Популярные пакеты «для IPsec» вроде StrongSWAN и LibreSWAN реализуют именно IKE.
Согласование настроек шифрования
В IKE есть возможность предложить второй стороне несколько вариантов на выбор, и соединение будет установлено, если у обеих сторон найдется хотя бы один совпадающий вариант. Это общий принцип работы протоколов обмена ключами, TLS работает так же, но в TLS периодически удаляют поддержку устаревших алгоритмов. В IKE безопасность выбора алгоритмов остается на совести пользователя. Заведомо уязвимые DES и MD5 из протокола официально не исключены и до сих пор поддерживаются многими реализациями.
С каждым туннелем ассоциировано одно или несколько «предложений» (proposals). Предложения обрабатываются до первого совпадения. Отсюда следствие: вполне возможна ситуация, когда зловредный (или безответственно настроенный) сервер предложит клиенту устаревшие алгоритмы, а неаккуратно настроенный клиент согласится. У некоторых клиентов вообще может не быть возможности выбрать алгоритмы вручную, а особо ленивые админы любят делать для всех клиентов один большой proposal со всеми мыслимыми алгоритмами. Сортировать алгоритмы по надежности стандарт не обязывает, и стороны вполне могут договориться на шифр полувековой давности.
Более того, официально поддерживается null cipher — опция не шифровать трафик вообще.
Чтобы убедиться в безопасности настроек, в идеале нужно немного понимать принципы криптографии и следить за новостями. Тем не менее можно привести ряд рецептов.
- Ни в коем случае нельзя соглашаться ни на что, что кончается на ecb. ECB (Electronic Code Book) — чрезвычайно небезопасный режим работы блочных шифров. Суть проблемы наглядно демонстрирует знаменитый ECB penguin. Хороший шифр в неверном режиме — плохой шифр. AES‐128‐ CBC — хорошо, AES‐128‐ECB — плохо.
- 3DES и Blowfish до недавнего времени считались надежными, но уязвимость SWEET32 показала, что это не так. AES‐128, AES‐256, Twofish и другие шифры с 128‐битными блоками — все еще разумный выбор.
- Группы для алгоритма Диффи-Хеллмана DH1024 (group 2) и DH1536 (group 5) также признаны уязвимыми. Нужно использовать DH2048 (group 14) или группы на эллиптических кривых.
В IKE вполне можно использовать разные наборы алгоритмов для Phase 1 и Phase 2. Смысла в этом немного, но возможность имеется.
Diffie-Hellman и PFS
Параметр PFS ранее я оставил без внимания, так как эта штука была мне не совсем понятна, когда рассказывал про объединение сетей с помощью L2TP/IPsec на Mikrotik и Keenetic Ultra II. Восполним недостающие знания.
PFS (Perfect Forward Secrecy) — рекомендуемая опция, которую многие оставляют выключенной, а зря, особенно если используется pre‐shared key.
В этом режиме из ключей обеих сторон генерируется периодически обновляемый сессионный ключ и согласуется с помощью алгоритма Диффи-Хеллмана (DH). В предельно упрощенной формулировке он основан на том, что возвести число в степень просто, а вычислить логарифм гораздо сложнее. При использовании PFS, если кто‐то получит доступ к общему ключу, он не сможет расшифровать им перехваченный трафик, в этом и суть forward secrecy. Подобранный ключ от одной сессии также не поможет рас‐ шифровать последующие, при условии, что числа достаточно большие, именно поэтому DH1024 и DH1536 стали небезопасны — современное железо уже достаточно быстрое для их взлома.
Параметр Phase2 lifetime (ESP lifetime) указывает, как часто должен меняться ключ. Время жизни ключа — чисто локальный параметр, который не согласуется через IKE и может оказаться разным на разных сторонах. Если твои туннели IPsec сначала передают трафик, а потом вдруг перестают работать, проверь, совпадает ли время жизни ключа на обеих сторонах.
Security Associations (SA)
В отличие от OpenVPN или wireguard, IPsec сам по себе не создает никаких виртуальных интерфейсов. Во времена его зарождения у каждого хоста в интернете был публичный адрес и никакой потребности в виртуальных сетях с отдельной адресацией просто не было. Виртуальными интерфейсами занимаются отдельные протоколы, например L2TP или GRE, а IPsec только шифрует их трафик. Многие платформы поддерживают VTI — ассоциированный с соединением IPsec виртуальный интерфейс, но на деле это всего лишь автоматизированная настройка IPIP поверх IPsec.
Вместо туннелей IPsec оперирует еще более абстрактными сущностями — security associations. Они не являются сетевыми соединениями, это просто наборы параметров, которые указывают, какой трафик и как шифровать. К примеру, «трафик из 192.168.1.0/24 в 10.1.0.0/24 зашифровать AES‐128 и добавить сумму SHA1».
Security associations существуют на обеих сторонах независимо и не могут оборваться сами по себе, в отличие от сетевых соединений. Если ты видишь на своей стороне живую SA, это еще не значит, что трафик нормально пойдет на вторую сторону туннеля. Не забывай проверять, что все на самом деле работает. Чтобы вторая сторона могла узнать, что у тебя происходит, нужно настроить dead peer detection (для IKEv1) или использовать IKEv2, где есть liveness check.
В случае с dead peer detection не забывай проверять, что параметры на обеих сторонах совпадают, иначе можно надолго остаться с туннелем, который только выглядит как живой.
NAT TRAVERSAL
IPsec появился до NAT и в своем чистом виде работать за NAT не может. Эту возможность к нему прикрутили позже. Сам ESP — отдельный протокол IP с номером 50. Для работы за NAT его инкапсулируют в UDP. В этом случае IKE и инкапсулированный ESP используют один порт — UDP/4500.
Изначально от NAT страдали пользователи клиентских соединений вроде L2TP и IPsec. Популярность облачных платформ, где вместо присвоения хостам публичных адресов эти адреса раздают через 1:1, NAT сделала эту проблему актуальной и для соединений между маршрутизаторами.
При этом может возникнуть неожиданная проблема: если на другой стороне туннель настроен на фиксированный адрес, даже если NAT traversal поддерживается, соединение не заработает.
Дело в том, что в пакетах IKE присутствует идентификатор хоста. По умолчанию большинство реализаций используют в качестве идентификатора адрес интерфейса, с которого отправляются пакеты, и в случае с NAT он перестает совпадать с адресом источника, когда пакеты доходят до второй стороны.
Решение простое: никто не обязывает использовать идентификатор по умолчанию. В него можно прописать вообще любую строку, иногда даже необходимо, к примеру если у второй стороны нет фиксированного адреса или используется x.509.
Например, в StrongSWAN:
conn mypeer left=%defaultroute leftid="192.0.2.10"
IKEv1 vs IKEv2
У IKE есть две версии — IKEv1 и IKEv2. IKEv2 получила сколько‐нибудь широкое распространение только в последние несколько лет, и то не везде, но у нее есть ряд ощутимых преимуществ.
- Окончательная стандартизация работы через NAT — в большинстве случаев она теперь просто работает.
- Livenesscheck — двусторонний keepalived для проверки, живы ли SA.
- Возможность совместить несколько критериев шифрования трафика в одной SA.
В IKEv1 на каждую пару локальных и удаленных адресов нужна была отдельная SA. К примеру, если хостам 192.168.1.1 и 192.168.1.2 нужен доступ через туннель к 10.1.0.1 и 10.1.0.2, демон IKE создаст четыре отдельные SA. IKEv2 в этом смысле более гибкая.
В IKEv2 также окончательно удален aggressive mode, в котором параметры Phase 1 и Phase 2 передавались одновременно. Значительная часть реализаций, впрочем, давно перестала его поддерживать и в IKEv1 из‐за очевидных проблем с безопасностью такого подхода.
Если обе стороны поддерживают IKEv2, лучше использовать именно ее. Если интересно почитать стандарт, она описана в RFC 5996.
Заключение
Надеюсь, если IPsec был для тебя загадочным, теперь принципы его работы стали понятнее. Не забывай, что безопасность параметров шифрования на твоей совести и что не все конфликты настроек обнаружатся автоматически.
Если тебе будет интересно, в следующий раз я напишу о типичных ошибках в настройке и способах определить, что пошло не так, даже если конфиг второй стороны недоступен, а админы некомпетентны.
/ статья из журнала ХАКЕР (06) 2019 /
Подписывайтесь на канал
Яндекс.Дзен
и узнавайте первыми о новых материалах, опубликованных на сайте.
Установка пакетов для работы
За основу инструкции по настройке сервера была взята следующая инструкция.
В первую очередь поставим все необходимые пакеты для работы:
sudo apt update # пакеты для работы strongSwan VPN сервера sudo apt-get install strongswan strongswan-pki libcharon-extra-plugins libcharon-extauth-plugins # пакеты для работы со смарт-картами и токенами (чтобы создать ключевую пару и сертификаты на Рутокене) sudo apt install opensc libengine-pkcs11-openssl1.1
Генерация ключевых пар и сертификатов УЦ и сервера
# инициализируем директорию для хранения ключей и сертификатов
mkdir -p ~/pki/{cacerts,certs,private}
chmod 700 ~/pki
# создание ключевой пары УЦ
pki --gen --type rsa --size 4096 --outform pem > ~/pki/private/ca-key.pem
# создание корневого сертификата
pki --self --ca --lifetime 3650 --in ~/pki/private/ca-key.pem \
--type rsa --dn "CN=VPN root CA" --outform pem > ~/pki/cacerts/ca-cert.pem
# создание ключевой пары сервера
pki --gen --type rsa --size 4096 --outform pem > ~/pki/private/server-key.pem
# получение сертификата сервера
# обратите внимание, что аргументы --dn и --san нужно будет заменить на свои
pki --pub --in ~/pki/private/server-key.pem --type rsa \
| pki --issue --lifetime 1825 \
--cacert ~/pki/cacerts/ca-cert.pem \
--cakey ~/pki/private/ca-key.pem \
--dn "CN=server.astradomomain.ad" --san server.astradomain.ad \
--flag serverAuth --flag ikeIntermediate --outform pem \
> ~/pki/certs/server-cert.pem
# копируем полученные сертификаты в директорию strongSwan
sudo cp -r ~/pki/* /etc/ipsec.d/
Настройка strongSwan
Сохраним предыдущую конфигурацию:
sudo mv /etc/ipsec.conf{,.original}
Откроем файл /etc/ipsec.conf и вставим туда следующее содержимое:
config setup
charondebug="ike 1, knl 1, cfg 0"
uniqueids=no
conn ikev2-vpn
auto=add
compress=no
type=tunnel
keyexchange=ikev2
fragmentation=yes
forceencaps=yes
dpdaction=clear
dpddelay=300s
rekey=no
left=%any
# доменное имя сервера нужно будет заменить на свое
leftid=@server.astradomain.ad
leftcert=server-cert.pem
leftsendcert=always
leftsubnet=0.0.0.0/0
right=%any
rightid=%any
# активация аутентификации по сертификатам
rightauth=eap-tls
rightsourceip=10.10.10.0/24
rightdns=8.8.8.8,8.8.4.4
rightsendcert=never
eap_identity=%identity
ike=chacha20poly1305-sha512-curve25519-prfsha512,aes256gcm16-sha384-prfsha384-ecp384,aes256-sha1-modp1024,aes128-sha1-modp1024,3des-sha1-modp1024!
esp=chacha20poly1305-sha512,aes256gcm16-ecp384,aes256-sha256,aes256-sha1,3des-sha1!
Укажем какой ключ использовать серверу для аутентификации себя клиенту /etc/ipsec.secrets:
Настройка firewall
sudo ufw allow OpenSSH sudo ufw enable sudo ufw allow 500,4500/udp
Узнаем имя интерфейса, к которому подключен сервер. Данное имя нам потребуется при настройке firewall. Это можно сделать с помощью команды:
ip route show default # вывод данной команды будет примерно следующим: # default via your_server_ip dev eth0 proto static # Имя интерфейса -- eth0
Добавим в файл настроек firewall /etc/ufw/before.rules следующие строки:
# Добавим этот блок # Не забудьте поменять имя интерфейса *nat -A POSTROUTING -s 10.10.10.0/24 -o eth0 -m policy --pol ipsec --dir out -j ACCEPT -A POSTROUTING -s 10.10.10.0/24 -o eth0 -j MASQUERADE COMMIT # Добавим этот блок # Не забудьте поменять имя интерфейса *mangle -A FORWARD --match policy --pol ipsec --dir in -s 10.10.10.0/24 -o eth0 -p tcp -m tcp --tcp-flags SYN,RST SYN -m tcpmss --mss 1361:1536 -j TCPMSS --set-mss 1360 COMMIT # Этот блок остается без изменений *filter :ufw-before-input - [0:0] :ufw-before-output - [0:0] :ufw-before-forward - [0:0] :ufw-not-local - [0:0] # Добавим этот блок -A ufw-before-forward --match policy --pol ipsec --dir in --proto esp -s 10.10.10.0/24 -j ACCEPT -A ufw-before-forward --match policy --pol ipsec --dir out --proto esp -d 10.10.10.0/24 -j ACCEPT
Добавим в файл /etc/ufw/sysctl.conf следующие строки:
net/ipv4/ip_forward=1 net/ipv4/conf/all/accept_redirects=0 net/ipv4/conf/all/send_redirects=0 net/ipv4/ip_no_pmtu_disc=1
Перезагрузка firewall
sudo ufw disable sudo ufw enable
Добавление нового клиента со смарт-картой
Модуль pkcs11 для работы со смарт-картами
Необходимо использовать модуль opensc-pkcs11.so из состава OpenSC.
Отформатируем смарт-карту, сгенерируем на ней ключи и получим сертификат.
# форматирование и инициализация
pkcs15-init --erase-card -p rutoken_ecp
pkcs15-init --create-pkcs15 --so-pin "87654321" --so-puk ""
pkcs15-init --store-pin --label "User PIN" --auth-id 02 --pin "12345678" --puk "" --so-pin "87654321" --finalize
# генерация ключей
ID=45
pkcs15-init -G rsa/2048 --auth-id 02 --label "My Private Key" --public-key-label "My Public Key" --id $ID
# генерация заявки на сертификат
openssl
> engine dynamic -pre SO_PATH:/usr/lib/x86_64-linux-gnu/engines-1.1/pkcs11.so -pre ID:pkcs11 -pre LIST_ADD:1 -pre LOAD -pre MODULE_PATH:opensc-pkcs11.so
# не забудьте заменить идентификатор сертификата
> req -engine pkcs11 -new -key 45 -keyform engine -out req.csr -subj "/C=RU/CN=user"
> exit
# выдадим сертификат по заявке
pki --issue --lifetime 1825 \
--cacert ~/pki/cacerts/ca-cert.pem \
--cakey ~/pki/private/ca-key.pem \
--in req.csr --type pkcs10 --outform pem \
> ~/pki/certs/client-cert.pem
# загрузим сертификат на токен
pkcs15-init --store-certificate ~/pki/certs/client-cert.pem --auth-id 02 --id $ID --format pem
Убедиться, что сертификат и ключи загружены на токен можно с помощью команды:
Теперь Рутокен готов к работе и его можно отдать клиенту.
Установка пакетов
Установим необходимые пакеты для работы:
sudo apt update # пакеты для работы strongSwan VPN сервера sudo apt-get install strongswan libstrongswan-extra-plugins libcharon-extra-plugins # пакеты для работы со смарт-картами (чтобы создать ключевую пару и сертификаты на токене) sudo apt install opensc libengine-pkcs11-openssl1.1
Настройка strongSwan
Корневой сертификат сервера положим в директорию /etc/ipsec.d/cacerts:
sudo cp /path/to/ca-cert.pem /etc/ipsec.d/cacerts
Настроим файл конфигурации strongSwan /etc/ipsec.conf:
config setup
conn ikev2-rw
# измените адрес сервера на свой
right=server.astradomain.ad
rightid=@server.astradomain.ad
rightsubnet=0.0.0.0/0
rightauth=pubkey
leftsourceip=%config
# имя пользователя для которого выдан сертификат
leftid=user
leftcert=%smartcard:45
leftauth=eap
eap_identity=%identity
auto=start
Настроим файл паролей аутентфикации strongSwan /etc/ipsec.secrets и укажем, какой ключ нужно использовать для аутентификации по смарт-карте:
# Формат следующий #: PIN %smartcard:<keyid> <pin code> : PIN %smartcard:45 "12345678"
Более подробно о способах задания паролей смарт-карт можно почитать здесь.
Настройка модуля pkcs11
Настроим использование pkcs11 модулей в strongSwan. Для этого откроем файл конфигурации /etc/strongswan.d/charon/pkcs11.conf и отредактируем настройки модулей pkcs11:
modules {
opensc-pkcs11 {
# Whether to automatically load certificates from tokens.
# load_certs = yes
# Whether OS locking should be enabled for this module.
# os_locking = no
# Full path to the shared object file of this PKCS#11 module.
path = /usr/lib/x86_64-linux-gnu/opensc-pkcs11.so
}
Подключение к сети
Подключите смарт-карту и инициализируйте подключение c помощью команды:
sudo systemctl stop strongswan-starter sudo systemctl start strongswan-starter
Проверить, что соединение прошло успешно, можно, например, выведя список своих ip адресов С помощью команды:
Среди них появится ваш виртуальный ip:
