Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 97
А можно вопрос — чем ваша статья лучше, чет 100500 уже опубликованных по этой же теме, в т.ч. и на Хабре?
В этой статье хотя бы разъясняется что, что, где и для чего, в других же примерах учат только копипасту.
Вот это — только копипаста? Или всё-таки с подробным объяснением, какая настройка что делает?
habrahabr.ru/post/67238/
А вообще сам я сейчас считаю, что руководства man openvpn более чем достаточно.
habrahabr.ru/post/67238/
А вообще сам я сейчас считаю, что руководства man openvpn более чем достаточно.
Я старался отразить в статье свой реальный опыт изучения этой технологии и ее реализации на практике.
Больше внимания уделил тому, с чем сам долго разбирался — терминология, сертификаты, ключи, удостоверяющий центр, подписывание сертификатов. Реально попробовал OpenVPN в разных ОС, которые у нас используются.
Надеюсь, с этой статьи можно начинать изучение и практические эксперименты с OpenVPN, не обращаясь к поиску и другим статьям.
Больше внимания уделил тому, с чем сам долго разбирался — терминология, сертификаты, ключи, удостоверяющий центр, подписывание сертификатов. Реально попробовал OpenVPN в разных ОС, которые у нас используются.
Надеюсь, с этой статьи можно начинать изучение и практические эксперименты с OpenVPN, не обращаясь к поиску и другим статьям.
Просто статья вышла ооочень длинная. Наверное, лучше было бы разбить ее на несколько частей
Кому-то нравится та статья, кому-то эта, кому-то вообще man или офф. сайт.
Всё равно человек постарался и заслужил плюсик :)
Всё равно человек постарался и заслужил плюсик :)
Здравствуйте. Возникло у меня желание поднять VPN. И хотелось мне сделать быстро. Ввел «ubuntu vpn server». Меня не интересовали особенности построения приватных сетей, хотелось простенько, по-домашнему. Вторая ссылка в google:
habrahabr.ru/post/153855/
Отлично, думаю, то что надо.
Читаю, начинаю выполнять, хотя в голове крутится вопрос «Что происходит?».
«cd /usr/share/doc/openvpn/examples/easy-rsa/2.0/» — опа, нету такой директории. Ну ладно, надо хотя бы узнать что там должно быть.
Выясняю, что easy-rsa убран из дистрибутива. Есть вопрос в тостере и ответ на него: toster.ru/q/95623#answer_item_298527
Хороший ответ, мне понравился.
Туповатый запрос «openvpn easy rsa схема» приводит меня на эту страницу. И, судя по всему, я нашел нужную мне информацию.
Спасибо автору.
habrahabr.ru/post/153855/
Отлично, думаю, то что надо.
Читаю, начинаю выполнять, хотя в голове крутится вопрос «Что происходит?».
«cd /usr/share/doc/openvpn/examples/easy-rsa/2.0/» — опа, нету такой директории. Ну ладно, надо хотя бы узнать что там должно быть.
Выясняю, что easy-rsa убран из дистрибутива. Есть вопрос в тостере и ответ на него: toster.ru/q/95623#answer_item_298527
Хороший ответ, мне понравился.
Прежде всего уясните себе что машина с easy-rsa это машина которая только подписывает ключи. И по логике безопасности должна быть отдельной машиной. Не стоит хранить генератор ключей и в особенности приватный CA на самом VPN сервере.— этот текст в очередной раз напоминает о том что, следуя инструкциям в мануалах, можно в целом здорово накосячить. И пусть в моем случае это не критично, но уже хочется знать как все делать правильно и по уму. И понимая что происходит. Пригодится.
Туповатый запрос «openvpn easy rsa схема» приводит меня на эту страницу. И, судя по всему, я нашел нужную мне информацию.
Спасибо автору.
А мне статья понравилась: всё чётко и понятно для меня - человека не из мира IT.
Да, но OpenVPN Access Server стоит денег.
Конечно, коммерческие решения обычно удобнее бесплатных. Но у меня изначально стояла цель внедрения именно бесплатной технологии. На самом деле при использовании готовых конфигурационных файлов установка и настройка OpenVPN не так уж и сложна. На мой взгляд, с ней справится любой системный администратор или программист. Главное, разобраться в терминологии и технологии.
100$ — час работы средней руки админа?
Т.е. в месяц средний админ получает: 100$ * 36р. * 8ч. * 21д. => 604 800 р.?
Т.е. в месяц средний админ получает: 100$ * 36р. * 8ч. * 21д. => 604 800 р.?
Здесь еще помимо ежегодных платежей напрягает невозможность купить «вечную» лицензию. В теории может получиться, что в один прекрасный момент по какой-либо причине продлить лицензию не удастся.
Он не нужен.
VPN-сервер конфигурируется один раз и используется годами. Ради этого не стоит платить 100 долларов за 10 сотрудников в год — дешевле нанять человека, который пару дней почитает доки и настроит community.
Тем более, что openvpn community ставится отлично в openwrt на мелких железках и мы получаем vpn-маршрутизатор за 1000р (утрировано, на самом деле мы используем для этого в продакшне tp-link 3600nd за 2500р).
VPN-сервер конфигурируется один раз и используется годами. Ради этого не стоит платить 100 долларов за 10 сотрудников в год — дешевле нанять человека, который пару дней почитает доки и настроит community.
Тем более, что openvpn community ставится отлично в openwrt на мелких железках и мы получаем vpn-маршрутизатор за 1000р (утрировано, на самом деле мы используем для этого в продакшне tp-link 3600nd за 2500р).
чтобы удобней было передавать ключи и конфиги клиентам, можно использовать openvpn inline в таком виде клиенту надо отдать всего один файл в котором будут и конфиг и сертификаты
Насколько я понимаю, из соображений безопасности ключи передавать нельзя, особенно по электронной почте. Можно обмениваться только сертификатами.
Ну случается, что лично в руки ключи отдавать не получается. Но почта, не лучший вариант, согласен. Я обычно на приватном файловом хранилище кладу. Даю ссылку в скайпе, как только скачают удаляю.
Вообще по технологии ключи передавать не требуется, они создаются на узлах одновременно с запросом на подпись сертификата.
А запросы и сертификаты не секретные, их передавать можно.
Насчет файловых хранилищ и скайпа — стараюсь ничего конфиденциального, типа паролей, там не хранить и через них не передавать.
А запросы и сертификаты не секретные, их передавать можно.
Насчет файловых хранилищ и скайпа — стараюсь ничего конфиденциального, типа паролей, там не хранить и через них не передавать.
Посомтрите в сторону www.tinc-vpn.org. Единственный минус, его нет на мобильных платформах и нет красивых конфигурялок. Из плюсов, можно сделать довольно быстро mech vpn сеть.
Добавил оглавление и сделал заголовки более заметными, чтобы они не сливались с текстом.
Статья хорошо написана, однако, не поднимает некоторых довольно важных вещей:
Не совсем одобряю использование easy-rsa 3. Он все-таки еще не релизнулся и имеет известные проблемы. Пока лучше использовать easy-rsa 2, причем, у него тоже проблемы имеются, например, с common name в UTF-8.
- Чем отличаются TUN и TAP
- Какой MTU ставить на интерфейс VPN
- Что делать клиентам, у которых MTU не 1500 (например, которые уже за VPN сидят)
- Как бороться с медленной скоростью по TCP
Не совсем одобряю использование easy-rsa 3. Он все-таки еще не релизнулся и имеет известные проблемы. Пока лучше использовать easy-rsa 2, причем, у него тоже проблемы имеются, например, с common name в UTF-8.
Да, подумываю о второй статье про тонкую настройку OpenVPN. Уже есть материал насчет MTU, у одного удаленного программиста пришлось настраивать.
Зачем вы используете OpenVPN, который требует установки отдельного ПО на всех клиентах, когда есть PPP и L2TP VPN, из коробки поддерживаемые во всех операционках и смартфонах?
Позволю себе ответить, как пользователю OpenVPN. Основное его преимущество в том, что он пролазит в сетях, в которых PPTP(наверно Вы его имели ввиду) и L2TP не пролазят.
Кстати вот
Кстати вот
Мне было интересно изучать OpenVPN, и он подходил под все наши требования. У него довольно гибкие настройки. А установка отдельного ПО не вызвала у нас никаких особых затруднений, там нет ничего сложного. Есть еще статья PPTP vs L2TP vs OpenVPN vs SSTP, довольно интересны комментарии.
Не увидел в конфигах параметр cipher, как будет определяться алгоритм шифрования с вашей версией конфиг-файлов?
Пока черновой план второй статьи такой:
— особенности TUN/TAP;
— проблемы с MTU и их решение;
— безопасность и шифрование;
— скорость передачи данных;
— мониторинг сервера OpenVPN
— особенности TUN/TAP;
— проблемы с MTU и их решение;
— безопасность и шифрование;
— скорость передачи данных;
— мониторинг сервера OpenVPN
Я идею подкину(посажу в сознании не только Вашем, но и всех прочитавших) — детектирование того, что сертификат был скомпрометирован. Мне это интересно, а как это сделать времени разбираться нет, а штука важная. Нисколько не настаиваю, но тема интересная.
Детектировать это? Как? Вот про списки отзыва и вообще OSCP и подобное в приложении к OpenVPN — стоит. (Встроенной проверки нет, но можно написать скрипты и подвесить их к многочисленным хукам.)
А проблемы с MTU он умеет решать сам. Мы даже делали MTU 65535 — в туннеле всё выглядит как один нефрагментированный пакет, хотя по каналу связи передаётся конечно их несколько.
А проблемы с MTU он умеет решать сам. Мы даже делали MTU 65535 — в туннеле всё выглядит как один нефрагментированный пакет, хотя по каналу связи передаётся конечно их несколько.
В OpenVPN есть параметр
После этого сертификаты всех клиентов будут проверятся по этому CRL.
Так как каждый CRL содержит срок действия, то достаточно просто написать скрипт, который подгружает свежий CRL незадолго до истечения старого.
crl-verify, для него надо указать актуальный файл с CRL в формате PEM (base64).После этого сертификаты всех клиентов будут проверятся по этому CRL.
Так как каждый CRL содержит срок действия, то достаточно просто написать скрипт, который подгружает свежий CRL незадолго до истечения старого.
Не забудьте включить ccd и роутинг. Каталог для конфигов клиентов, я смотрю, уже создали.
Жаль что статья так и не вышла в свет
Есть ли у OpenVPN возможность сбора статистики по подключениям? Больше всего интересует количество входящего/исходящего трафика для каждого пользователя.
Например, было бы достаточно возможности в момент закрытия сессии передать в скрипт сбора статистики такие параметры как id пользователя (по сертификату), количество входящего/исходящего трафика, продолжительность сессии.
Например, было бы достаточно возможности в момент закрытия сессии передать в скрипт сбора статистики такие параметры как id пользователя (по сертификату), количество входящего/исходящего трафика, продолжительность сессии.
Да. Именно так и сделано — есть куча хуков (коннект/дисконнект/запуск/аутентификация и т. д.), к которым подвешиваются скрипты и которым сообщается информация — кто, когда, что и сколько. И можно из скрипта делать много всего. Я например делал регистрацию клиента во внутреннем динамическом DNS из такого скрипта.
читайте man openvpn, это исчерпывающая документация. Реально, после прочтения этого мана хаутушки не нужны.
читайте man openvpn, это исчерпывающая документация. Реально, после прочтения этого мана хаутушки не нужны.
Есть возможность, как сказал merlin-vrn, использовать хуки на подключение/отключение/аутентификацию, а есть еще возможность подключать плагины. У меня используется radiusplugin, который всю статистику radius-серверу перенаправляет. Довольно удобно.
Статья писалась исходя из реальной задачи:
Теперь нам нужно организовать доступ сотрудников к защищенным ресурсам компании через прокси-сервер, установленный на сервер OpenVPN. В этом случае рабочие станции сотрудников с динамическими адресами IP смогут подключаться к ресурсам компании, для которых разрешен доступ с фиксированного адреса IP сервера OpenVPN.Верно? Т.е. с учетом необходимости squid'а доступ требуется к конкретным http/https/ftp сервисам во внутренней сети из вне?
Не совсем. У нас имеются ресурсы во внешней сети, на наших и арендованных серверах, размещенных в датацентре. Эти ресурсы должны быть доступны из Интернета, но доступ к ним ограничен файерволом.
Для офисной сети мы прописали в файерволах правила, разрешающие доступ. Но у сотрудников, которые работают дома, адреса IP динамические, и не всегда имеется возможность приобрести фиксированные адреса у локальных провайдеров Интернета.
Squid позволяет нам организовать доступ сотрудников через сеть OpenVPN и через сервер OpenVPN, имеющий фиксированный адрес IP, на наши закрытые ресурсы в Интернете. Для проксирования используется адрес из сети OpenVPN, поэтому не имеет значения, что у сотрудника динамический IP.
Для офисной сети мы прописали в файерволах правила, разрешающие доступ. Но у сотрудников, которые работают дома, адреса IP динамические, и не всегда имеется возможность приобрести фиксированные адреса у локальных провайдеров Интернета.
Squid позволяет нам организовать доступ сотрудников через сеть OpenVPN и через сервер OpenVPN, имеющий фиксированный адрес IP, на наши закрытые ресурсы в Интернете. Для проксирования используется адрес из сети OpenVPN, поэтому не имеет значения, что у сотрудника динамический IP.
Для задачи доступа с динамического адреса сотруднику было бы достаточно использовать динамический ssh туннель. В таком случае на промежуточном jump-хосте был бы не нужен ни vpn ни squid, достаточно было бы просто дефолтной установки любой unix системы.
Доступ SSH у нас разрешен только с избранных адресов IP.
Доступ SSH у нас разрешен только с избранных адресов IP.Имеется ввиду доступ к консоли через ssh?
Можно запретить парольную аутентификацию на jump-хосте и открыть доступ к ssh, вместо установки openvpn+squid, тем более, что от последнего вам нужна только функция проксирования )
Фильтрация доступа через файервол по SSH надежнее, т.к. даже по ключу не будет доступа с неавторизованных хостов. Мало ли у кого ключ завалялся…
Ну а проблем с установкой Squid никаких — там все очень просто.
Ну а проблем с установкой Squid никаких — там все очень просто.
Ключи от openvpn не защищеннее от «заваливания у кого-то» ключей от ssh ;)
Просто консольный доступ вы можете очень гибко контролировать через authorized_keys, там указываете from для избранных IP, остальным прикручиваете no-pty. Кроме того sshd нормально через pam привязывается к чему угодно хоть к radius, хоть к tacacs, хоть к AD. OpenVPN в этом плане с его openvpn-plugin-auth-pam более топорный, добиться от него передачи адреса клиента через pam_tacplus так и не получилось.
Просто консольный доступ вы можете очень гибко контролировать через authorized_keys, там указываете from для избранных IP, остальным прикручиваете no-pty. Кроме того sshd нормально через pam привязывается к чему угодно хоть к radius, хоть к tacacs, хоть к AD. OpenVPN в этом плане с его openvpn-plugin-auth-pam более топорный, добиться от него передачи адреса клиента через pam_tacplus так и не получилось.
На самом деле мы используем авторизацию по ключам для упрощения доступа обычных пользователей-разработчиков, и в некоторых других случаях, но ограничение по IP для SSH применяем тоже для большей защищенности и запрета сканирования.
Считаю, что незачем открывать то, что можно не открывать — принцип минимального доступа )
Что касается radius, tacacs и AD, то мы этим не пользуемся, нам просто незачем.
Считаю, что незачем открывать то, что можно не открывать — принцип минимального доступа )
Что касается radius, tacacs и AD, то мы этим не пользуемся, нам просто незачем.
Понятно )
На самом деле openvpn очень хорошо использовать для создания распределенной сетевой инфраструктуры любой сложности, с возможностью проксирования, трансляции, обхода сетевых фильтров провайдеров (port 443 + port-share в конфиге этому весьма способствуют). На этом поприще у него нет бесплатных конкурентов. К сожалению отсутствует только функционал доступа через SSL VPN без предустановленного клиента…
Проброс порта через openvpn+squid это как установка photoshop для задачи ресайза фотографий )
На самом деле openvpn очень хорошо использовать для создания распределенной сетевой инфраструктуры любой сложности, с возможностью проксирования, трансляции, обхода сетевых фильтров провайдеров (port 443 + port-share в конфиге этому весьма способствуют). На этом поприще у него нет бесплатных конкурентов. К сожалению отсутствует только функционал доступа через SSL VPN без предустановленного клиента…
Проброс порта через openvpn+squid это как установка photoshop для задачи ресайза фотографий )
Отличная статья. Сколько не читал статей по OpenVPN подобных не находил. Тут и теория и практика, все подробно и качественно.
Спасибо, добавил к себе в избранное.
Спасибо, добавил к себе в избранное.
Тоже думал написать статейку о самописном веб интерфейсе для мониторинга VPN клиентов, генерации ключей и конфигов, отзыва сертификатов. По тестам у себя в компании очень хорошо показала себя.
Напишите о вашем интерфейсе, думаю будет интересно и пригодится. Остальные вопросы уже популярно раскрыл автор этой статьи и многие другие.
Интересные темы, особенно про мониторинг клиентов. Пишите ;)
У нас сделано тривиально до безобразия. OpenVPN умеет каждые n секунд писать файлик со статусом, в котором список подключенных клиентов, сколько времени подключен и сколько байтов прокачано на сей момент. Он кладёт файлик в место, доступное вебсерверу, а доступ к файлику через веб ограничен в настройках веб-сервера. Файлик вытягивает и обрабатывает заббикс.
Думаю завтра возьмусь за это) просто хочется еще допилить, прежде чем показывать. Ведь это делалось в процессе изучения Django и Python.
Подправил статью. Большое спасибо zlyoha за то что он взял на себя труд ее отредактировать!
/etc/init.d/openvpn start
Starting virtual private network daemon: serverEnter Private Key Password:
failed!
какой пароль он требует?
Starting virtual private network daemon: serverEnter Private Key Password:
failed!
какой пароль он требует?
Пароль от приватного ключа сервера. Тот, который вы вводили при генерации ключа командой build-key-server.
А вообще зря вы пароль на ключ сервера поставили. Можно ничего не ломая просто сделать ещё один ключ сервера с другим именем (как вариант, отозвать этот и сгенерировать новый с таким же именем) и не указывать для него пароль, тогда ключ будет не зашифрован. Нет смысла его шифровать — если вы уж получили доступ к ключу, то значит и получили рутовый доступ к серверу VPN.
А вообще зря вы пароль на ключ сервера поставили. Можно ничего не ломая просто сделать ещё один ключ сервера с другим именем (как вариант, отозвать этот и сгенерировать новый с таким же именем) и не указывать для него пароль, тогда ключ будет не зашифрован. Нет смысла его шифровать — если вы уж получили доступ к ключу, то значит и получили рутовый доступ к серверу VPN.
При установке OpenVPN на Debian 8.1 столкнулся с проблемой — не поднялся TUN. Обновил статью, добавил решение:
При установке OpenVPN на Linux с новыми ядрами, начиная с 2.6, интерфейс TUN может не появится. При этом в логах появляется ошибка:
Чтобы избавиться от проблемы, добавьте в файл /etc/modprobe.d/dist.conf строку:
Если такого файла нет, его следует создать. После внесения изменений в файл /etc/modprobe.d/dist.conf перезагрузите ОС.
При установке OpenVPN на Linux с новыми ядрами, начиная с 2.6, интерфейс TUN может не появится. При этом в логах появляется ошибка:
Loading kernel module for a network device with CAP_SYS_MODULE (deprecated). Use CAP_NET_ADMIN and alias netdev-tun instead
Чтобы избавиться от проблемы, добавьте в файл /etc/modprobe.d/dist.conf строку:
alias netdev-tun tun
Если такого файла нет, его следует создать. После внесения изменений в файл /etc/modprobe.d/dist.conf перезагрузите ОС.
у меня кстати на debian 8.1 тоже случилась трабла: openvpn отказывался стартовать через service openvpn start
Пришлось стартовать так: service openvpn@server start
И в автозагрузку: systemctl enable openvpn@server.service
где server — имя конфига (без .conf)
Решение нарыто тут: uname.pingveno.net/blog/index.php/post/2015/05/23/Migrate-an-OpenVPN-configuration-to-Debian-8-%28Jessie%29-with-systemd
Пришлось стартовать так: service openvpn@server start
И в автозагрузку: systemctl enable openvpn@server.service
где server — имя конфига (без .conf)
Решение нарыто тут: uname.pingveno.net/blog/index.php/post/2015/05/23/Migrate-an-OpenVPN-configuration-to-Debian-8-%28Jessie%29-with-systemd
Проясните пожалуйста ситуацию. Вы пишите касательно server.key:
А ниже, приводя файл настройки клиента, виден этот самый server.key. Как это понимать?
req: /home/vpnoperator/easy-rsa-master/easyrsa3/pki/reqs/server.req
key: /home/vpnoperator/easy-rsa-master/easyrsa3/pki/private/server.key
Первый из этих файлов нам нужно передать на сервер удостоверяющего центра CA, он не секретный. Второй файл — секретный, и он не должен покидать пределы сервера OpenVPN
А ниже, приводя файл настройки клиента, виден этот самый server.key. Как это понимать?
key "/usr/local/etc/openvpn/server.key"
Конечно, приватный ключ сервера никак не может использоваться в конфигурации клиента. Если это есть в статье, это ошибка.
Мне влом перечитывать статью, я просто опишу правильную диспозицию здесь :)
Самая страшная вещь — CA. Имея [приватный ключ] CA, можно нагенерировать валидных ключей сколько угодно, а чтобы это прекратить — придётся всё переделывать. Поэтому, приватный ключ CA храним как зеницу ока. А публичный — на то и публичный, что его скрывать нет совершенно никакой причины, он должен быть у всех клиентов, чтобы они могли проверять подписи (валидность) друг друга.
В остальном, X.509 PKI, который и используется в OpenVPN, предполагает такой подход:
0. Распространяем сертификат CA среди клиентов.
1. Генерируем приватный ключ + запрос сертификата (req) на той станции, где он будет применяться. Может быть, в токене. Ни один приватный ключ не покидает свою станцию, а если у нас токен — он просто для того и создан, чтобы не дать ключу покинуть место генерации.
2. Передаём req по незащищённому каналу на CA.
3. CA по req-файлу (в котором публичный ключ, соответствующий нашему приватному, а также дополнительная информация) генерирует и подписывает [своим приватным ключом] сертификат для этого клиента. Обязательно использует публичный ключ из req (собственно, именно его и подписываем), а дополнительную информацию может и проигнорировать.
В результате получается crt-файл, содержащий публичный ключ клиента и информацию о нём (что-то вроде LDAP DN), в которой важное поле — commonName (CN), а также дата начала и конца действия ключа, может быть «человекочитаемое» имя клиента, e-mail и так далее. Набор инструментов EasyRSA, который идёт «в комплекте» с OpenVPN, считает, что там должен быть набор «страна-область-город-организация-отдел», но это можно переопределить, поменяв openssl.cnf, желательно перед генерацией CA (некоторые поля после генерации менять будет уже нельзя). Также туда попадает уникальный серийный номер сертификата (в случае с EasyRSA, это порядковый номер).
4. Этот сертификат также публичный, мы по незащищённому каналу передаём его на нашу станцию. Он будет использоваться теперь каждый раз в процессе проверке подлинности (станции). Если речь шла про токен, то необходимо встроить сертификат в токен, чтобы у токена он был (вообще-то именно для работы асимметричного алгоритма в токене сертификат не нужен).
Эти четыре шага совершенно одинаковы для серверов и клиентов. То есть,
— сертификат CA распространяем среди потенциальных участников способом, исключающим подмену или порчу (например, сверяя отпечаток ключа)
— приватный ключ участника генерируем непосредственно на сервере (или клиенте) и он никогда не покидает пределы сервера (или клиента)
— req с защитой от подмены передаём в CA, а он любым способом (на этот раз совершенно любым — подделку можно будет распознать) возвращает нам crt
Мне влом перечитывать статью, я просто опишу правильную диспозицию здесь :)
Самая страшная вещь — CA. Имея [приватный ключ] CA, можно нагенерировать валидных ключей сколько угодно, а чтобы это прекратить — придётся всё переделывать. Поэтому, приватный ключ CA храним как зеницу ока. А публичный — на то и публичный, что его скрывать нет совершенно никакой причины, он должен быть у всех клиентов, чтобы они могли проверять подписи (валидность) друг друга.
В остальном, X.509 PKI, который и используется в OpenVPN, предполагает такой подход:
0. Распространяем сертификат CA среди клиентов.
1. Генерируем приватный ключ + запрос сертификата (req) на той станции, где он будет применяться. Может быть, в токене. Ни один приватный ключ не покидает свою станцию, а если у нас токен — он просто для того и создан, чтобы не дать ключу покинуть место генерации.
2. Передаём req по незащищённому каналу на CA.
3. CA по req-файлу (в котором публичный ключ, соответствующий нашему приватному, а также дополнительная информация) генерирует и подписывает [своим приватным ключом] сертификат для этого клиента. Обязательно использует публичный ключ из req (собственно, именно его и подписываем), а дополнительную информацию может и проигнорировать.
В результате получается crt-файл, содержащий публичный ключ клиента и информацию о нём (что-то вроде LDAP DN), в которой важное поле — commonName (CN), а также дата начала и конца действия ключа, может быть «человекочитаемое» имя клиента, e-mail и так далее. Набор инструментов EasyRSA, который идёт «в комплекте» с OpenVPN, считает, что там должен быть набор «страна-область-город-организация-отдел», но это можно переопределить, поменяв openssl.cnf, желательно перед генерацией CA (некоторые поля после генерации менять будет уже нельзя). Также туда попадает уникальный серийный номер сертификата (в случае с EasyRSA, это порядковый номер).
4. Этот сертификат также публичный, мы по незащищённому каналу передаём его на нашу станцию. Он будет использоваться теперь каждый раз в процессе проверке подлинности (станции). Если речь шла про токен, то необходимо встроить сертификат в токен, чтобы у токена он был (вообще-то именно для работы асимметричного алгоритма в токене сертификат не нужен).
Эти четыре шага совершенно одинаковы для серверов и клиентов. То есть,
— сертификат CA распространяем среди потенциальных участников способом, исключающим подмену или порчу (например, сверяя отпечаток ключа)
— приватный ключ участника генерируем непосредственно на сервере (или клиенте) и он никогда не покидает пределы сервера (или клиента)
— req с защитой от подмены передаём в CA, а он любым способом (на этот раз совершенно любым — подделку можно будет распознать) возвращает нам crt
Секретный ключ должен оставаться на сервере, а клиенту передается только публичный ключ.
У каждого клиента на своем хосте должен быть сгенерирован свой секретный ключ, и он не должен никуда передаваться.
На самом деле файл /usr/local/etc/openvpn/server.key не упоминается в конфигурации клиента:
dev tun
proto udp
remote 192.168.0.54 1194
client
resolv-retry infinite
ca "/etc/openvpn/ca.crt"
cert "/etc/openvpn/developer1.crt"
key "/etc/openvpn/client.key"
tls-auth "/etc/openvpn/ta.key" 1
remote-cert-tls server
persist-key
persist-tun
comp-lzo
verb 3
status /var/log/openvpn/openvpn-status.log 1
status-version 3
log-append /var/log/openvpn/openvpn-client.log
У каждого клиента на своем хосте должен быть сгенерирован свой секретный ключ, и он не должен никуда передаваться.
На самом деле файл /usr/local/etc/openvpn/server.key не упоминается в конфигурации клиента:
dev tun
proto udp
remote 192.168.0.54 1194
client
resolv-retry infinite
ca "/etc/openvpn/ca.crt"
cert "/etc/openvpn/developer1.crt"
key "/etc/openvpn/client.key"
tls-auth "/etc/openvpn/ta.key" 1
remote-cert-tls server
persist-key
persist-tun
comp-lzo
verb 3
status /var/log/openvpn/openvpn-status.log 1
status-version 3
log-append /var/log/openvpn/openvpn-client.log
Упоминается под спойлером. И это сбивает с толку
Содержимое файла server.conf для клиента OpenVPN
Да, у нас этот файл называется одинаково и на сервере, и на клиенте:
«Файл openssl.cnf, определяющий конфигурацию OpenSSL, используйте точно такой же, как и для сервера OpenVPN. Что касается файла server.conf для клиента OpenVPN, то для начала возьмите его из нашей статьи.»
Возможно, не лучшее решение.
«Файл openssl.cnf, определяющий конфигурацию OpenSSL, используйте точно такой же, как и для сервера OpenVPN. Что касается файла server.conf для клиента OpenVPN, то для начала возьмите его из нашей статьи.»
Возможно, не лучшее решение.
Дело не сколько в названии, сколько в наличии секретного файла server.conf в конфиге, следовательно и на хосте, клиента.
Прошу поправить в статье данный факт, если Вам не трудно.
Прошу поправить в статье данный факт, если Вам не трудно.
Да нет, файл server.conf не содержит никаких секретов, там только пути к ключам и сертификатам.
Похоже мы не понимаем друг друга.
Вроде бы говорим об одном файле server.conf для OpenVPN клиента. В нем указан путь до server.key. Как не содержит, не понимаю.
Вроде бы говорим об одном файле server.conf для OpenVPN клиента. В нем указан путь до server.key. Как не содержит, не понимаю.
Да, у нас файл конфигурации для клиента называется server.conf, как и для сервера.
Но в версии для клиента в нем нет пути до server.key. Вместо этого там есть: key "/etc/openvpn/client.key".
Т.е. когда вы создаете файл конфигурации для клиента, в нем должен быть путь к файлу ключа клиента, а не сервера. Именно такие примеры конфигураций для клиента приведены в статье.
Название файла конфигурации server.conf для клиента, возможно, не слишком удачное, но так уже мы сделали в нашем примере.
Еще раз, файл server.conf содержит:
— для сервера — путь к ключу сервера;
— для клиента — путь к ключу клиента.
Иначе оно вообще работать не будет.
Но в версии для клиента в нем нет пути до server.key. Вместо этого там есть: key "/etc/openvpn/client.key".
Т.е. когда вы создаете файл конфигурации для клиента, в нем должен быть путь к файлу ключа клиента, а не сервера. Именно такие примеры конфигураций для клиента приведены в статье.
Название файла конфигурации server.conf для клиента, возможно, не слишком удачное, но так уже мы сделали в нашем примере.
Еще раз, файл server.conf содержит:
— для сервера — путь к ключу сервера;
— для клиента — путь к ключу клиента.
Иначе оно вообще работать не будет.
Вот фрагмент файла server.conf для сервера:
А вот фрагмент файла server.conf для клиента:
Как видите, там прописаны пути к разным ключам. На сервере — это путь к файлу ключа сервере server.key, а на клиенте — к файлу ключа client.key.
port 1194
proto udp
dev tun
user openvpn
group openvpn
cd /etc/openvpn
persist-key
persist-tun
tls-server
tls-timeout 120
dh /etc/openvpn/dh.pem
ca /etc/openvpn/ca.crt
cert /etc/openvpn/vpn-server.crt
key /etc/openvpn/server.key
...
А вот фрагмент файла server.conf для клиента:
dev tun
proto udp
remote 192.168.0.54 1194
client
resolv-retry infinite
ca "/etc/openvpn/ca.crt"
cert "/etc/openvpn/developer1.crt"
key "/etc/openvpn/client.key"
tls-auth "/etc/openvpn/ta.key" 1
...
Как видите, там прописаны пути к разным ключам. На сервере — это путь к файлу ключа сервере server.key, а на клиенте — к файлу ключа client.key.
Здравствуйте, у меня такой вопрос. CA поднят на ubuntu, запрос на подпись генерирую на Win2012. Генерируется файл .csr, мой СА такой не понимает, ему .req подавай. где ошибся?
Опишите в деталях, как именно вы создаете запрос на подпись и как создаете сертификат. Я пробовал это на Windows 7 по инструкции из статьи, все получилось.
1. Установил GUI
2. Запустил cmd от админа, сменил рабочую папку на easy-rsa
3. init-config -> clean-all
4. Поправил vars (кстати в нем были строки, о которых тут ничего не сказано: set PKCS11_MODULE_PATH=changeme
set PKCS11_PIN=1234, их не менял)
5. запустил vars.bat
6. build-ca -> build-key client (тут создались три файла — client.key, client.crt, client.csr)
7. Взял client.csr и перенес на свой СА, а дальше с ним что делать не пойму.
2. Запустил cmd от админа, сменил рабочую папку на easy-rsa
3. init-config -> clean-all
4. Поправил vars (кстати в нем были строки, о которых тут ничего не сказано: set PKCS11_MODULE_PATH=changeme
set PKCS11_PIN=1234, их не менял)
5. запустил vars.bat
6. build-ca -> build-key client (тут создались три файла — client.key, client.crt, client.csr)
7. Взял client.csr и перенес на свой СА, а дальше с ним что делать не пойму.
А дальше, как в статье в разделе Установка и запуск ПО клиента OpenVPN
Т.е. вам нужно на машине CA сделать из запроса сертификат и перенести сертификат на рабочую станцию.
Процесс создания сертификата многоступенчатый, любая ошибка приведет к неудаче.
Постарайтесь следовать инструкции из статьи как можно точнее.
Как здесь
Импортируйте запрос в PKI, используя в качестве короткого имени developer1:
$ cd /home/ca/easy-rsa-master/easyrsa3
$ ./easyrsa import-req /mnt/flash/client.req developer1
Далее подпишите запрос на получение сертификата:
$ ./easyrsa sign-req client developer1
После ввода подтверждения и пароля приватного ключа CA будет создан сертификат:
/home/ca/easy-rsa-master/easyrsa3/pki/issued/developer1.crt
Запишите файл developer1.crt на USB флэш-диск, чтобы перенести его на хост клиента OpenVPN.
$ cd /home/ca/easy-rsa-master/easyrsa3
$ ./easyrsa import-req /mnt/flash/client.req developer1
Далее подпишите запрос на получение сертификата:
$ ./easyrsa sign-req client developer1
После ввода подтверждения и пароля приватного ключа CA будет создан сертификат:
/home/ca/easy-rsa-master/easyrsa3/pki/issued/developer1.crt
Запишите файл developer1.crt на USB флэш-диск, чтобы перенести его на хост клиента OpenVPN.
Т.е. вам нужно на машине CA сделать из запроса сертификат и перенести сертификат на рабочую станцию.
Процесс создания сертификата многоступенчатый, любая ошибка приведет к неудаче.
Постарайтесь следовать инструкции из статьи как можно точнее.
Спасибо за статью. Пригодилась команда для создания клиента без пароля
$ ./easyrsa build-client-full client2 nopass
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Руководство по установке и настройке OpenVPN