Всех с пятницей и окончанием рабочей недели. Хочу порекомендовать вам посмотреть на досуге любопытный канал, который я недавно нашел и посмотрел несколько видео оттуда. Например, вот это.
https://www.youtube.com/watch?v=avl5rVi-HNo (ссылка тут для тематического превью к заметке 😁)
Автор, судя по всему, как-то связан с IT, так как много роликов из этой сферы, но не только. Я пока ехал с выставки малоэтажного домостроения, посмотрел его ролик, как собирать электрощит для частного дома и вынес для себя несколько полезных советов. Например, повесить на отдельный автомат холодильники. У меня их будет два. Это удобно, когда надо будет обесточить дом во время длительного отъезда, а холодильники оставить включенными.
Видео там на разные тематики, но где-то половина айтишные. Мне понравилась подача материала и сам автор. Есть ролики на тему мотивации, распорядка дня и т.д. Мне близка озвученная позиция.
По нашей теме тоже есть, что посмотреть. Например, наглядно показано как настроить доступ к локальному nextcloud, расположенному дома без внешнего IP, соединив его по vpn с арендуемой виртуальной машиной. Далее через nginx проксируем запросы на этот nextcloud по vpn, настроив доменное имя и https. Для меня всё это не новость, так как я так же к домашним серверам прокидываю доступы, но если вы не умеете это делать, то в видео наглядно все показано и доступно объяснено.
К сожалению, роликов не очень много и я понимаю, почему. Они очень качественно сделаны и отлично проработаны. Времени записать подобный материал надо много. Но с помощью youtube его не получится монетизировать и как-то окупить. А на одном энтузиазме регулярно записывать такие видео не будешь.
Если вы знаете какие-то классные каналы IT тематики, прошу поделиться. Мне кажется, я в ютубе уже все, что можно, разыскал и посмотрел по нашей теме. Люблю что-то познавательное и развивающее в русле своей профессии смотреть, но в ютубе, к сожалению, эта тематика слабо представлена.
#видео
https://www.youtube.com/watch?v=avl5rVi-HNo (ссылка тут для тематического превью к заметке 😁)
Автор, судя по всему, как-то связан с IT, так как много роликов из этой сферы, но не только. Я пока ехал с выставки малоэтажного домостроения, посмотрел его ролик, как собирать электрощит для частного дома и вынес для себя несколько полезных советов. Например, повесить на отдельный автомат холодильники. У меня их будет два. Это удобно, когда надо будет обесточить дом во время длительного отъезда, а холодильники оставить включенными.
Видео там на разные тематики, но где-то половина айтишные. Мне понравилась подача материала и сам автор. Есть ролики на тему мотивации, распорядка дня и т.д. Мне близка озвученная позиция.
По нашей теме тоже есть, что посмотреть. Например, наглядно показано как настроить доступ к локальному nextcloud, расположенному дома без внешнего IP, соединив его по vpn с арендуемой виртуальной машиной. Далее через nginx проксируем запросы на этот nextcloud по vpn, настроив доменное имя и https. Для меня всё это не новость, так как я так же к домашним серверам прокидываю доступы, но если вы не умеете это делать, то в видео наглядно все показано и доступно объяснено.
К сожалению, роликов не очень много и я понимаю, почему. Они очень качественно сделаны и отлично проработаны. Времени записать подобный материал надо много. Но с помощью youtube его не получится монетизировать и как-то окупить. А на одном энтузиазме регулярно записывать такие видео не будешь.
Если вы знаете какие-то классные каналы IT тематики, прошу поделиться. Мне кажется, я в ютубе уже все, что можно, разыскал и посмотрел по нашей теме. Люблю что-то познавательное и развивающее в русле своей профессии смотреть, но в ютубе, к сожалению, эта тематика слабо представлена.
#видео
YouTube
Как поднять домашний сервер со своим доменом своими руками?
Мой телеграмм бот: https://t.me/amatyashov_bot
Или: @amatyashov_bot
Мой сайт https://matiashov.ru
Телеграм канал https://t.me/amatyashov
#сервер #домены #сети #маршрутизатор #личноеоблако
В этом ролике мы своими руками поднимем файловый сервер, и настроем…
Или: @amatyashov_bot
Мой сайт https://matiashov.ru
Телеграм канал https://t.me/amatyashov
#сервер #домены #сети #маршрутизатор #личноеоблако
В этом ролике мы своими руками поднимем файловый сервер, и настроем…
Технический пост, который уже давно нужно было сделать, но всё руки не доходили. На канале много содержательных заметок по различным темам. Иногда сам через поиск ищу то, о чём писал. Ниже набор наиболее популярных тэгов по которым можно найти что-то полезное (и не очень).
#remote - все, что касается удалённого управления компьютерами
#helpdesk - обзор helpdesk систем
#backup - софт для бэкапа и некоторые мои заметки по теме
#zabbix - всё, что касается системы мониторинга Zabbix
#мониторинг - в этот тэг иногда попадает Zabbix, но помимо него перечислено много различных систем мониторинга
#управление #ITSM - инструменты для управления инфраструктурой
#devops - в основном софт, который так или иначе связан с методологией devops
#kuber - небольшой цикл постов про работу с kubernetes
#chat - мои обзоры на популярные чат платформы, которые можно развернуть у себя
#бесплатно - в основном подборка всяких бесплатностей, немного бесплатных курсов
#сервис - сервисы, которые мне показались интересными и полезными
#security - заметки, так или иначе связанные с безопасностью
#webserver - всё, что касается веб серверов
#gateway - заметки на тему шлюзов
#mailserver - всё, что касается почтовых серверов
#elk - заметки по ELK Stack
#mikrotik - очень много заметок про Mikrotik
#proxmox - заметки о популярном гипервизоре Proxmox
#terminal - всё, что связано с работой в терминале
#bash - заметки с примерами полезных и не очень bash скриптов или каких-то команд. По просмотрам, комментариям, сохранениям самая популярная тематика канала.
#windows - всё, что касается системы Windows
#хостинг - немного информации и хостерах, в том числе о тех, кого использую сам
#vpn - заметки на тему VPN
#perfomance - анализ производительности сервера и профилирование нагрузки
#курсы - под этим тэгом заметки на тему курсов, которые я сам проходил, которые могу порекомендовать, а также некоторые бесплатные курсы
#игра - игры исключительно IT тематики, за редким исключением
#совет - мои советы на различные темы, в основном IT
#подборка - посты с компиляцией нескольких продуктов, объединённых одной тематикой
#отечественное - обзор софта из реестра отечественного ПО
#юмор - большое количество каких-то смешных вещей на тему IT, которые я скрупулезно выбирал, чтобы показать вам самое интересное. В самом начале есть шутки, которые придумывал сам, проводил конкурсы.
#мысли - мои рассуждения на различные темы, не только IT
#разное - этим тэгом маркирую то, что не подошло ни под какие другие, но при этом не хочется, чтобы материал терялся, так как я посчитал его полезным
#дети - информация на тему обучения и вовлечения в IT детей
#развитие_канала - серия постов на тему развития данного telegram канала
Остальные тэги публикую общим списком без комментариев, так как они про конкретный софт, понятный из названия тэга:
#docker #nginx #mysql #postgresql #gitlab #asterisk #openvpn #lxc #postfix #bitrix #икс #debian #hyperv #rsync #wordpress #zfs #grafana #iptables #prometheus #1с #waf #logs #netflow
#remote - все, что касается удалённого управления компьютерами
#helpdesk - обзор helpdesk систем
#backup - софт для бэкапа и некоторые мои заметки по теме
#zabbix - всё, что касается системы мониторинга Zabbix
#мониторинг - в этот тэг иногда попадает Zabbix, но помимо него перечислено много различных систем мониторинга
#управление #ITSM - инструменты для управления инфраструктурой
#devops - в основном софт, который так или иначе связан с методологией devops
#kuber - небольшой цикл постов про работу с kubernetes
#chat - мои обзоры на популярные чат платформы, которые можно развернуть у себя
#бесплатно - в основном подборка всяких бесплатностей, немного бесплатных курсов
#сервис - сервисы, которые мне показались интересными и полезными
#security - заметки, так или иначе связанные с безопасностью
#webserver - всё, что касается веб серверов
#gateway - заметки на тему шлюзов
#mailserver - всё, что касается почтовых серверов
#elk - заметки по ELK Stack
#mikrotik - очень много заметок про Mikrotik
#proxmox - заметки о популярном гипервизоре Proxmox
#terminal - всё, что связано с работой в терминале
#bash - заметки с примерами полезных и не очень bash скриптов или каких-то команд. По просмотрам, комментариям, сохранениям самая популярная тематика канала.
#windows - всё, что касается системы Windows
#хостинг - немного информации и хостерах, в том числе о тех, кого использую сам
#vpn - заметки на тему VPN
#perfomance - анализ производительности сервера и профилирование нагрузки
#курсы - под этим тэгом заметки на тему курсов, которые я сам проходил, которые могу порекомендовать, а также некоторые бесплатные курсы
#игра - игры исключительно IT тематики, за редким исключением
#совет - мои советы на различные темы, в основном IT
#подборка - посты с компиляцией нескольких продуктов, объединённых одной тематикой
#отечественное - обзор софта из реестра отечественного ПО
#юмор - большое количество каких-то смешных вещей на тему IT, которые я скрупулезно выбирал, чтобы показать вам самое интересное. В самом начале есть шутки, которые придумывал сам, проводил конкурсы.
#мысли - мои рассуждения на различные темы, не только IT
#разное - этим тэгом маркирую то, что не подошло ни под какие другие, но при этом не хочется, чтобы материал терялся, так как я посчитал его полезным
#дети - информация на тему обучения и вовлечения в IT детей
#развитие_канала - серия постов на тему развития данного telegram канала
Остальные тэги публикую общим списком без комментариев, так как они про конкретный софт, понятный из названия тэга:
#docker #nginx #mysql #postgresql #gitlab #asterisk #openvpn #lxc #postfix #bitrix #икс #debian #hyperv #rsync #wordpress #zfs #grafana #iptables #prometheus #1с #waf #logs #netflow
На днях настраивал openvpn сервер по своей статье и решил поделиться информацией. Статья полностью актуальная, можно настраивать копипастом на любом клоне Centos. Помимо многих очевидных плюсов openvpn, о которых я так или иначе уже писал, хочу рассказать ещё об одном, за который люблю эту программу.
Openvpn без проблем запускает на одной и той же машине любое количество тоннелей с разными настройками. Просто кладёте рядом конфиг очередного сервера и запускаете через systemd новый экземпляр с этим конфигом.
У меня на одном сервере запросто живут следующие конфигурации openvpn:
▪ протокол udp с шифрованием для общих случаев, порт любой;
▪ протокол tcp для подключения микротиков, порт любой;
▪ протокол tcp и 443 порт для подключения из мест, где остальные порты закрыты.
и т.д.
Создаются одновременно любые конфигурации с разными протоколами, наличием или отсутствием сжатия, различными протоколами шифрования и т.д. SIP юзеров в один тоннель сажаем, админов в другой, обычных юзеров в третий, филиалы в четвёртый и т.д. У каждого тоннеля своя подсеть, под которую создаются правила firewall. Я стараюсь максимально сегментировать подключения. Так безопаснее и удобнее управлять.
Отмечу до кучи остальные особенности openvpn, за которые я её люблю:
◽ Простой и удобный механизм передачи маршрутов клиенту. Все настраивается и управляется централизованно с сервера. Считаю это основным преимуществом openvpn.
◽ Есть клиенты под все популярные платформы и системы. Конфигурация передается в одном файле.
◽ Популярный и проверенный временем продукт. Легко настраивается, легко решаются проблемы. Хорошее логирование на стороне клиента. Легко дебажить проблемы.
Для организации vpn всегда выберу openvpn, если он подходит под технические условия задачи. А вы на чём предпочитаете строить vpn сети?
#openvpn #vpn
Openvpn без проблем запускает на одной и той же машине любое количество тоннелей с разными настройками. Просто кладёте рядом конфиг очередного сервера и запускаете через systemd новый экземпляр с этим конфигом.
У меня на одном сервере запросто живут следующие конфигурации openvpn:
▪ протокол udp с шифрованием для общих случаев, порт любой;
▪ протокол tcp для подключения микротиков, порт любой;
▪ протокол tcp и 443 порт для подключения из мест, где остальные порты закрыты.
и т.д.
Создаются одновременно любые конфигурации с разными протоколами, наличием или отсутствием сжатия, различными протоколами шифрования и т.д. SIP юзеров в один тоннель сажаем, админов в другой, обычных юзеров в третий, филиалы в четвёртый и т.д. У каждого тоннеля своя подсеть, под которую создаются правила firewall. Я стараюсь максимально сегментировать подключения. Так безопаснее и удобнее управлять.
Отмечу до кучи остальные особенности openvpn, за которые я её люблю:
◽ Простой и удобный механизм передачи маршрутов клиенту. Все настраивается и управляется централизованно с сервера. Считаю это основным преимуществом openvpn.
◽ Есть клиенты под все популярные платформы и системы. Конфигурация передается в одном файле.
◽ Популярный и проверенный временем продукт. Легко настраивается, легко решаются проблемы. Хорошее логирование на стороне клиента. Легко дебажить проблемы.
Для организации vpn всегда выберу openvpn, если он подходит под технические условия задачи. А вы на чём предпочитаете строить vpn сети?
#openvpn #vpn
Для веб интерфейса OpenVPN сервера есть отличное родное решение - Access Server. У него есть только один минус - это платный продукт. Есть бесплатная версия с суровым ограничением - не больше двух vpn подключений к серверу. Это позволяет его использовать только для одной цели - личный сервер для единоличного использования. Да и то, лично мне двух подключений не хватит.
Если для вас такое ограничение не критично - то смело пользуйтесь. Ничего лучше нет. Можно установить на свой сервер или арендованную VPS. У многих хостеров есть готовые шаблоны, чтобы сразу развернуть установленный продукт и начать использовать.
Основные возможности:
- управление через веб интерфейс, cli, api
- создание нового клиента и конфигурации для него в один клик
- ограничение доступа клиентов по ip
- возможность настройки протокола и порта, на котором будет работать openvpn сервер
- логи с информацией о подключениях клиентов
- различные способы аутентификации: ldap, radius, AD, pam
Побудило меня написать эту заметку информация о том, что для данного решения есть лекарство, которое позволяет снять ограничение бесплатной версии. Я настоятельно не рекомендую использовать подобное где-то в продакшене. В этом нет большой необходимости, так как есть аналоги, а рисков возникает много. А для личного использования можно и попробовать.
Сайт - https://openvpn.net/access-server/
#openvpn #vpn
Если для вас такое ограничение не критично - то смело пользуйтесь. Ничего лучше нет. Можно установить на свой сервер или арендованную VPS. У многих хостеров есть готовые шаблоны, чтобы сразу развернуть установленный продукт и начать использовать.
Основные возможности:
- управление через веб интерфейс, cli, api
- создание нового клиента и конфигурации для него в один клик
- ограничение доступа клиентов по ip
- возможность настройки протокола и порта, на котором будет работать openvpn сервер
- логи с информацией о подключениях клиентов
- различные способы аутентификации: ldap, radius, AD, pam
Побудило меня написать эту заметку информация о том, что для данного решения есть лекарство, которое позволяет снять ограничение бесплатной версии. Я настоятельно не рекомендую использовать подобное где-то в продакшене. В этом нет большой необходимости, так как есть аналоги, а рисков возникает много. А для личного использования можно и попробовать.
Сайт - https://openvpn.net/access-server/
#openvpn #vpn
Вчера в комментариях к заметке об OpenVPN был упомянут любопытный российский продукт Рутокен VPN. Меня он очень заинтересовал, так что решил его сразу же проверить. Это Open Source продукт на базе OpenVPN с веб панелью для управления.
В репозитории есть инструкция по установке. В ней указано, что сервис предназначен для работы в Ubuntu 20. Не знаю, с чем связана привязка к конкретной системе. Наверное поленились оформить поддержку остальных. Хотя бы в Docker контейнер всё это поместили бы, чтобы работало на любом Linux.
Взял Ubuntu 20.04 и установил на неё по инструкции. Там всё очень просто и быстро, не буду приводить шаги по установке. После перезагрузки зашёл по внешнему IP на веб интерфейс. Указал типовые настройки, необходимые для работы сервера OpenVPN и сгенерировал корневой сертификат.
Далее создал пользователей. Там идея такая, что пользователи могут сами заходить на веб интерфейс, генерировать себе конфигурацию, скачивать её вместе с клиентом. Сам клиент тоже Open Source, называется Рутокен VPN клиент. Он нестандартный, так как поддерживает работу с фирменным USB токеном Рутокен ЭЦП. Веб интерфейс довольно простой, как и сам функционал. Можно менять настройки сервера и управлять клиентами. Хотя у всех примерно так же, потому что это типовой функционал OpenVPN Server.
Дальше меня ждал сюрприз. Когда зашёл новым пользователем в веб интерфейс, заметил, что мне предлагают подготовить Рутокен ЭЦП для установки на него сертификата, либо сделать конфиг для смартфона. То есть идея в том, что этот продукт заточен под работу со своими родными токенами.
Тут я немного приуныл, потому что привязка к токенам резко сужает круг вероятных пользователей. Хотя если вам нужно именно это, то решение отличное. Токен сейчас стоит порядка 2500р. Неплохое решение для удалённых корпоративных пользователей, которых, кстати, можно импортировать из AD.
Потом прикинул, что формат конфигов openvpn одинаковый, что для смартфона, что для компьютера. Сделал конфигурацию для смарта, поставил на комп обычный OpenVPN Client и скормил ему этот конфиг. Без проблем подключился к серверу и вышел в интернет с его ip адресом. Отправлять весь трафик клиента через VPN - опция, которую можно указать через веб интерфейс.
В целом, нормальное решение. Для использование токенов вообще отличное, потому что работает всё из коробки и ничего придумывать не надо. Для всего остального не лучше и не хуже, чем все другие. Базовый функционал есть - управление пользователями, отслеживание активных соединений, просмотр логов. Показывается трафик и ip адрес, с которого подключился клиент.
Всё это бесплатно и от разработчика в РФ.
Сайт - https://www.rutoken.ru/products/all/rutoken-vpn/
Исходники - https://github.com/AktivCo/Rutoken-VPN-Community-Edition-Server
#отечественное #openvpn #vpn
В репозитории есть инструкция по установке. В ней указано, что сервис предназначен для работы в Ubuntu 20. Не знаю, с чем связана привязка к конкретной системе. Наверное поленились оформить поддержку остальных. Хотя бы в Docker контейнер всё это поместили бы, чтобы работало на любом Linux.
Взял Ubuntu 20.04 и установил на неё по инструкции. Там всё очень просто и быстро, не буду приводить шаги по установке. После перезагрузки зашёл по внешнему IP на веб интерфейс. Указал типовые настройки, необходимые для работы сервера OpenVPN и сгенерировал корневой сертификат.
Далее создал пользователей. Там идея такая, что пользователи могут сами заходить на веб интерфейс, генерировать себе конфигурацию, скачивать её вместе с клиентом. Сам клиент тоже Open Source, называется Рутокен VPN клиент. Он нестандартный, так как поддерживает работу с фирменным USB токеном Рутокен ЭЦП. Веб интерфейс довольно простой, как и сам функционал. Можно менять настройки сервера и управлять клиентами. Хотя у всех примерно так же, потому что это типовой функционал OpenVPN Server.
Дальше меня ждал сюрприз. Когда зашёл новым пользователем в веб интерфейс, заметил, что мне предлагают подготовить Рутокен ЭЦП для установки на него сертификата, либо сделать конфиг для смартфона. То есть идея в том, что этот продукт заточен под работу со своими родными токенами.
Тут я немного приуныл, потому что привязка к токенам резко сужает круг вероятных пользователей. Хотя если вам нужно именно это, то решение отличное. Токен сейчас стоит порядка 2500р. Неплохое решение для удалённых корпоративных пользователей, которых, кстати, можно импортировать из AD.
Потом прикинул, что формат конфигов openvpn одинаковый, что для смартфона, что для компьютера. Сделал конфигурацию для смарта, поставил на комп обычный OpenVPN Client и скормил ему этот конфиг. Без проблем подключился к серверу и вышел в интернет с его ip адресом. Отправлять весь трафик клиента через VPN - опция, которую можно указать через веб интерфейс.
В целом, нормальное решение. Для использование токенов вообще отличное, потому что работает всё из коробки и ничего придумывать не надо. Для всего остального не лучше и не хуже, чем все другие. Базовый функционал есть - управление пользователями, отслеживание активных соединений, просмотр логов. Показывается трафик и ip адрес, с которого подключился клиент.
Всё это бесплатно и от разработчика в РФ.
Сайт - https://www.rutoken.ru/products/all/rutoken-vpn/
Исходники - https://github.com/AktivCo/Rutoken-VPN-Community-Edition-Server
#отечественное #openvpn #vpn
Регулярно вижу сообщения на тему того, что OpenVPN работает медленно. Чаще всего это результат каких-то локальных проблем, а не распространённого мнения о том, что openvpn это медленный туннель. Всё познаётся в сравнении, а максимальная производительность туннеля зачастую больше всего зависит от сложности шифрования, которое используется.
В общем случае, при канале интернет в 100-200 мегабит в секунду вы не заметите проблем со скоростью в туннеле OpenVPN, если он будет поднят на базе PC, а не какого-то роутера с маломощным железом. По крайней мере я не сталкиваюсь с проблемами, когда на виртуальных машинах использую OpenVPN для объединения сетей через интернет.
Если вы видите, что ваше OpenVPN соединение работает значительно ниже исходного канала в интернет, то проверять стоит следующие вещи:
▪ Сжатие. Попробуйте его отключить, если включено, и посмотрите, как это повлияет на скорость.
▪ Если у вас используется TCP транспорт, поменяйте на UDP и проверьте скорость.
▪ Попробуйте более простой шифр, например AES-128-CBC вместо AES-256-CBC. Для верности можно вообще что-то совсем простое поставить и проверить, действительно ли из-за шифра проседает скорость.
▪ Посмотрите загрузку ядер процессора во время тестирования канала. Есть вероятность упереться в производительность одного ядра.
Далее идут более сложные вещи, в которые можно погрузиться, чтобы решить проблему с быстродействием:
▪ Иногда могут возникать проблемы с буферами. Гуглите параметры sndbuf и rcvbuf. Пробуйте их менять или отключать управление со стороны OpenVPN. Тема большая, гуглится хорошо, всё найдёте. Не забудьте, что эти параметры можно не только поменять на сервере, но и передать их клиенту. Это суперспособность OpenVPN - передавать практически любые настройки клиенту.
▪ Попробуйте поменять MTU с помощью параметра tun-mtu. Часто в этом может быть причина неадекватно низкой скорости туннеля.
▪ Попробуйте поменять параметр длины очереди отправки txqueuelen. В общем случае дефолтное значение трогать не обязательно, но если ничего из вышеприведённого не помогло, можно попробовать изменить. Я видел ситуации, когда это помогало.
Само собой получился чек лист по исправлению проблем производительности OpenVPN туннеля. Можно забрать в закладки. Изначально хотел написать, как можно ускорить VPN туннели, в том числе и на базе OpenVPN, с помощью готового решения, но отложу это на завтра.
❓Почему я чаще всего использую OpenVPN - Подробный ответ.
#openvpn
В общем случае, при канале интернет в 100-200 мегабит в секунду вы не заметите проблем со скоростью в туннеле OpenVPN, если он будет поднят на базе PC, а не какого-то роутера с маломощным железом. По крайней мере я не сталкиваюсь с проблемами, когда на виртуальных машинах использую OpenVPN для объединения сетей через интернет.
Если вы видите, что ваше OpenVPN соединение работает значительно ниже исходного канала в интернет, то проверять стоит следующие вещи:
▪ Сжатие. Попробуйте его отключить, если включено, и посмотрите, как это повлияет на скорость.
▪ Если у вас используется TCP транспорт, поменяйте на UDP и проверьте скорость.
▪ Попробуйте более простой шифр, например AES-128-CBC вместо AES-256-CBC. Для верности можно вообще что-то совсем простое поставить и проверить, действительно ли из-за шифра проседает скорость.
▪ Посмотрите загрузку ядер процессора во время тестирования канала. Есть вероятность упереться в производительность одного ядра.
Далее идут более сложные вещи, в которые можно погрузиться, чтобы решить проблему с быстродействием:
▪ Иногда могут возникать проблемы с буферами. Гуглите параметры sndbuf и rcvbuf. Пробуйте их менять или отключать управление со стороны OpenVPN. Тема большая, гуглится хорошо, всё найдёте. Не забудьте, что эти параметры можно не только поменять на сервере, но и передать их клиенту. Это суперспособность OpenVPN - передавать практически любые настройки клиенту.
▪ Попробуйте поменять MTU с помощью параметра tun-mtu. Часто в этом может быть причина неадекватно низкой скорости туннеля.
▪ Попробуйте поменять параметр длины очереди отправки txqueuelen. В общем случае дефолтное значение трогать не обязательно, но если ничего из вышеприведённого не помогло, можно попробовать изменить. Я видел ситуации, когда это помогало.
Само собой получился чек лист по исправлению проблем производительности OpenVPN туннеля. Можно забрать в закладки. Изначально хотел написать, как можно ускорить VPN туннели, в том числе и на базе OpenVPN, с помощью готового решения, но отложу это на завтра.
❓Почему я чаще всего использую OpenVPN - Подробный ответ.
#openvpn
Расскажу вам про решение проблемы с Openvpn Client на Windows, которая меня донимала последний год примерно, может чуть меньше. Вчера терпение лопнуло и я разобрался с ней раз и навсегда.
Проблема плавающая и выражалась она в том, что время от времени одно из настроенных подключений openvpn не подключалось. Ошибка была примерно такая:
Ошибка возникала случайным образом на различных соединениях.
По тексту не очень понятно, в чём дело. Первое, что приходит в голову - указанный порт уже кем-то занят. Но netstat показывает, что ничего не занято. При этом любое другое подключение openvpn сработает нормально. А какое-то одно ни в какую. У меня около 5-ти подключений используется в разное время. Помогает только перезагрузка. Несколько раз пытался разобраться, но так как ошибка не очень информативна, быстро решить вопрос не получалось. Спасала банальная перезагрузка. Я думал, что она возможно как-то связана с тем, что у меня добавлено несколько сетевых интерфейсов для openvpn, а в дефолте обычно только одно устанавливается.
Дело вот в чём. После какого-то обновления Windows, она стала резервировать некоторые диапазоны портов для работы Hyper-V. Посмотреть эти диапазоны можно командой:
И как оказалось, там есть диапазон локальных портов, который пересекается с диапазоном, который использует OpenVPN. Решение вопроса - изменить его в OpenVPN GUI:
Settings ⇨ Advanced ⇨ Management interface ⇨ Port offset.
После этого проблема исчезла.
Такая вот ерунда сожрала кучу моего времени. В логах самой винды никакой информации нет. По логу openvpn невозможно понять, в чём дело. А оказывается винда каким-то своим механизмом бронирует целые диапазоны портов и не даёт их использовать. При этом никак в системе не помечает их занятыми, иначе бы ошибка была другая. Что-то в духе
#openvpn #windows #ошибка
Проблема плавающая и выражалась она в том, что время от времени одно из настроенных подключений openvpn не подключалось. Ошибка была примерно такая:
MANAGEMENT: Socket bind failed on local address [AF_INET]127.0.0.1:25349Ошибка возникала случайным образом на различных соединениях.
По тексту не очень понятно, в чём дело. Первое, что приходит в голову - указанный порт уже кем-то занят. Но netstat показывает, что ничего не занято. При этом любое другое подключение openvpn сработает нормально. А какое-то одно ни в какую. У меня около 5-ти подключений используется в разное время. Помогает только перезагрузка. Несколько раз пытался разобраться, но так как ошибка не очень информативна, быстро решить вопрос не получалось. Спасала банальная перезагрузка. Я думал, что она возможно как-то связана с тем, что у меня добавлено несколько сетевых интерфейсов для openvpn, а в дефолте обычно только одно устанавливается.
Дело вот в чём. После какого-то обновления Windows, она стала резервировать некоторые диапазоны портов для работы Hyper-V. Посмотреть эти диапазоны можно командой:
# netsh int ipv4 show excludedportrange tcpИ как оказалось, там есть диапазон локальных портов, который пересекается с диапазоном, который использует OpenVPN. Решение вопроса - изменить его в OpenVPN GUI:
Settings ⇨ Advanced ⇨ Management interface ⇨ Port offset.
После этого проблема исчезла.
Такая вот ерунда сожрала кучу моего времени. В логах самой винды никакой информации нет. По логу openvpn невозможно понять, в чём дело. А оказывается винда каким-то своим механизмом бронирует целые диапазоны портов и не даёт их использовать. При этом никак в системе не помечает их занятыми, иначе бы ошибка была другая. Что-то в духе
local address [AF_INET]127.0.0.1:25349 is busy. А тут просто ошибка, которая говорит о том, что сокет не поднимается. Причин этому может быть много. Банальная нехватка прав или что-то ещё.#openvpn #windows #ошибка
Существует необычный и полезный продукт - UDPspeeder, который способен улучшить качество связи VPN туннелей на каналах с большими задержками и потерями пакетов с помощью коррекции ошибок (Forward Error Correction).
Разработчики заявляют встроенную поддержку следующих VPN туннелей - OpenVPN, L2TP, ShadowVPN. Работает UDPspeeder следующим образом. Сначала организуете туннель с его помощью, а потом поверх пускаете тот же OpenVPN или что-то подобное.
В репозитории подробно описан принцип работы UDPspeeder. В основе лежит технология FEC (Forward Error Correction). С её помощью возможно обнаружить ошибки передачи данных и скорректировать их методом упреждения. Эффект реальный и очень заметный. В репозитории есть наглядный пример снижения количества потерянных пакетов без увеличения latency, что существенно увеличивает скорость передачи данных.
Сам я никогда UDPspeeder не использовал и даже не знал о нём, пока со мной не поделился информацией подписчик, за что ему большое спасибо. Продукт полезный и наверняка пригодится. Обязательно попробую, когда в очередной раз придётся настраивать VPN на мобильном интернете. Думаю именно в этой ситуации UDPspeeder проявит себя лучше всего.
Настраивается UDPspeeder максимально просто и быстро. Работает только под Linux, есть пакет для openwrt.
Все запросы к порту 3333 клиента будут переадресовываться на порт 7777 сервера. Есть отдельная инструкция по настройке связки UDPspeeder + OpenVPN.
Если вам нужна готовая реализация VPN туннеля на базе UDPspeeder для быстрого запуска, можете взять tinyfecVPN от этого же автора. Там в пару команд настраивается VPN Site-to-Site.
Исходники - https://github.com/wangyu-/UDPspeeder
#vpn #openvpn
Разработчики заявляют встроенную поддержку следующих VPN туннелей - OpenVPN, L2TP, ShadowVPN. Работает UDPspeeder следующим образом. Сначала организуете туннель с его помощью, а потом поверх пускаете тот же OpenVPN или что-то подобное.
В репозитории подробно описан принцип работы UDPspeeder. В основе лежит технология FEC (Forward Error Correction). С её помощью возможно обнаружить ошибки передачи данных и скорректировать их методом упреждения. Эффект реальный и очень заметный. В репозитории есть наглядный пример снижения количества потерянных пакетов без увеличения latency, что существенно увеличивает скорость передачи данных.
Сам я никогда UDPspeeder не использовал и даже не знал о нём, пока со мной не поделился информацией подписчик, за что ему большое спасибо. Продукт полезный и наверняка пригодится. Обязательно попробую, когда в очередной раз придётся настраивать VPN на мобильном интернете. Думаю именно в этой ситуации UDPspeeder проявит себя лучше всего.
Настраивается UDPspeeder максимально просто и быстро. Работает только под Linux, есть пакет для openwrt.
# Запускаем на сервере:./speederv2 -s -l0.0.0.0:4096 -r 127.0.0.1:7777 -f20:10# Запускаем на клиенте./speederv2 -c -l0.0.0.0:3333 -r 44.55.66.77:4096 -f20:10Все запросы к порту 3333 клиента будут переадресовываться на порт 7777 сервера. Есть отдельная инструкция по настройке связки UDPspeeder + OpenVPN.
Если вам нужна готовая реализация VPN туннеля на базе UDPspeeder для быстрого запуска, можете взять tinyfecVPN от этого же автора. Там в пару команд настраивается VPN Site-to-Site.
Исходники - https://github.com/wangyu-/UDPspeeder
#vpn #openvpn
Существуют программы, которые на основе типа трафика могут направлять его в разные направления. Расскажу вам про одну такую программу - SSLH. Её можно запустить на каком-то TCP порту, например 8080. Если на этот порт направить HTTP трафик, SSLH его перенаправит на веб сервер, если это SSH трафик - на SSH сервер, если OpenVPN, то на его сервер. Таким образом можно маскировать какие-то сервисы, оставляя их при этом полностью доступными.
С одним из вариантов использования подобного подхода я сталкивался сам. Допустим, есть у вас где-то в Америке VPS, там живёт веб сервер. А ещё вам хочется держать там же OpenVPN на 443 порту, чтобы использовать для обхода блокировок и проходить через сети, где всё закрыто, кроме HTTP и HTTPS портов. SSLH отлично решает эту задачу.
Она есть в базовых репозиториях Debian:
Далее запускаем:
Теперь, если зайти браузером на сервер, то запрос будет перенаправлен на 443 порт веб сервера, если SSH клиентом, то на 22-й порт, если OpenVPN клиентом, то на дефолтный 1194 порт openvpn сервера.
То же самое через Docker:
Более функциональный вариант через docker-compose. Пример конфига, где трафик уходит в разные контейнеры:
⇨ Исходники
#openvpn #webserver
С одним из вариантов использования подобного подхода я сталкивался сам. Допустим, есть у вас где-то в Америке VPS, там живёт веб сервер. А ещё вам хочется держать там же OpenVPN на 443 порту, чтобы использовать для обхода блокировок и проходить через сети, где всё закрыто, кроме HTTP и HTTPS портов. SSLH отлично решает эту задачу.
Она есть в базовых репозиториях Debian:
# apt install sslhДалее запускаем:
# sslh-select -f --listen 0.0.0.0:443 \--tls 127.0.0.1:443 \--ssh 127.0.0.1:22 \--openvpn 127.0.0.1:1194Теперь, если зайти браузером на сервер, то запрос будет перенаправлен на 443 порт веб сервера, если SSH клиентом, то на 22-й порт, если OpenVPN клиентом, то на дефолтный 1194 порт openvpn сервера.
То же самое через Docker:
docker run --rm -it sslh:latest \ --listen=0.0.0.0:443 \ --ssh=hostname:22 \ --tls=hostname:443--openvpn=hostname:1194Более функциональный вариант через docker-compose. Пример конфига, где трафик уходит в разные контейнеры:
version: "3"services: sslh: image: sslh:latest hostname: sslh ports: - 443:443 command: --listen=0.0.0.0:443 --tls=nginx:443 --openvpn=openvpn:1194 depends_on: - nginx - openvpn nginx: image: nginx openvpn: image: openvpn⇨ Исходники
#openvpn #webserver
GitHub
GitHub - yrutschle/sslh: Applicative Protocol Multiplexer (e.g. share SSH and HTTPS on the same port)
Applicative Protocol Multiplexer (e.g. share SSH and HTTPS on the same port) - yrutschle/sslh
Когда настраиваете OpenVPN сервер, обязательно обращайте внимание на срок жизни сертификатов. Я знаю, что раньше в наборе скриптов EasyRSA по умолчанию срок жизни сертификатов был 10 лет. Но даже с таким сроком мне один раз пришлось столкнуться с тем, что CA и сертификат сервера, который много раз переезжал на разные машины с сохранением настроек, протух и мне пришлось оперативно решать эту проблему без перевыпуска клиентских сертификатов. Даже статью об этом написал в то время.
Недавно со мной приключилась похожая история. Клиенты перестали подключаться к серверу. Причём я сам это заметил, когда переносил все настройки с одного ноута на другой. И примерно в это же время истёк срок действия сертификата сервера OpenVPN (не CA). Я долго не мог сообразить, в чём проблема. На клиентском сертификате ещё и пароль был. Я сначала думал, что перепутал его. Но потом уже, когда стал детальнее разбираться с ошибкой, понял, что дело не в пароле.
Пошёл на сервер и стал смотреть, в чём дело. Залез в скрипты EasyRSA и обнаружил, что там срок жизни CA так и остался 10 лет, а сгенерированных и подписанных сертификатов только 3 года. В итоге первым протух сертификат самого сервера, потом потихоньку начали клиенты отваливаться. Пришлось всё перевыпускать.
Так что когда настраиваете OpenVPN и выпускаете для него сертификаты, обязательно сморите, какой срок жизни для них установлен. Это поначалу кажется, что 3-5-10 лет это так много. А на деле неизвестно, как всё обернётся. Может оказаться, что время закончилось, а система всё ещё жива и используется. Тем более нет никаких проблем переносить сертификаты вместе с конфигурацией, а один и тот же CA может использоваться для разных задач много лет.
#openvpn
Недавно со мной приключилась похожая история. Клиенты перестали подключаться к серверу. Причём я сам это заметил, когда переносил все настройки с одного ноута на другой. И примерно в это же время истёк срок действия сертификата сервера OpenVPN (не CA). Я долго не мог сообразить, в чём проблема. На клиентском сертификате ещё и пароль был. Я сначала думал, что перепутал его. Но потом уже, когда стал детальнее разбираться с ошибкой, понял, что дело не в пароле.
Пошёл на сервер и стал смотреть, в чём дело. Залез в скрипты EasyRSA и обнаружил, что там срок жизни CA так и остался 10 лет, а сгенерированных и подписанных сертификатов только 3 года. В итоге первым протух сертификат самого сервера, потом потихоньку начали клиенты отваливаться. Пришлось всё перевыпускать.
Так что когда настраиваете OpenVPN и выпускаете для него сертификаты, обязательно сморите, какой срок жизни для них установлен. Это поначалу кажется, что 3-5-10 лет это так много. А на деле неизвестно, как всё обернётся. Может оказаться, что время закончилось, а система всё ещё жива и используется. Тем более нет никаких проблем переносить сертификаты вместе с конфигурацией, а один и тот же CA может использоваться для разных задач много лет.
#openvpn
Занимался вчера перенастройкой OpenVPN сервера. Потратил немало времени из-за маленького нюанса, про который забыл. Поделюсь информацией для тех, кто тоже использует OpenVPN. Всем остальным читать большого смысла нет.
Люблю OpenVPN Server за гибкость в настройках. У меня обычное дело, когда на небольшой виртуалке под VPN поднято несколько туннелей. Пример разделения.
1️⃣ В этот туннель заводим все устройства Mikrotik. Так как у них своеобразная реализация OpenVPN, для них приходится поднимать отдельный туннель со своими настройками.
2️⃣ Стандартный туннель на UDP для удалённых пользователей. Типовые настройки.
3️⃣ Тот же туннель, что и выше, только на 443 TCP порту для обхода некоторых ограничений.
4️⃣ Ещё один туннель для удалённых филиалов, только уже не на базе Mikrotik. Тут тоже свои настройки, маршруты и т.д.
Я обычно не боюсь сильно дробить абонентов по разным туннелям, так ими удобнее управлять. Главное сильно не переусложнить, иначе можно запутаться.
Я одних абонентов, за которыми есть свои подсети, к которым нужен доступ через VPN, пересадил с одного туннеля на другой. Добавил новый и подключил их к нему. Перенастроил клиентов, они подключились. На вид всё нормально. Но вижу, что к некоторым сеткам за этими клиентами не могу подключиться.
Начинаю всё проверять. Для начала проверил на всех сторонах firewall. Вроде всё правильно. Для надёжности включил логирование всех заблокированных пакетов, там моих пакетов нет. Из чего делаю вывод, что проблема в маршрутизации.
Смотрю внимательно на маршруты. Иногда это непростая задача, когда путь пакета длинный, особенно если проходит через несколько VPN, как было у меня. Хоть садись и схему пути рисуй, сопоставляя с маршрутами на каждом устройстве. Какое-то время не могу понять в чём проблема, но в итоге заметил.
Оказалось, что я ошибся в настройках туннелей и не полностью перенёс подсети, за которые отвечают абоненты из настроек одного туннеля в другой. Заметил это в маршрутах на сервере. Банально, подсеть 192.168.13.0/24 уехала на интерфейс tun4, а я её оставил в старом конфиге с tun2. В итоге OpenVPN все запросы отправлял в tun2 и они там пропадали.
Во время диагностики просто не обратил внимание на разные имена туннелей. Проверяю, что маршрут завёрнут в tun и на этом успокаиваюсь, ожидая, что OpenVPN сама разберётся в какой туннель отправить запрос. Но на самом деле нет. Надо аккуратно самому расписать, какой туннель за какую подсеть отвечает в конфигах сервера. В итоге всё перепроверил и аккуратно расписал все подсетки по своим туннелям. И трафик поехал как надо.
Я мало работал с другими реализациями VPN. Немного pptp делал, и на микротиках l2tp. На Linux всегда использую OpenVPN. Мне он нравится за простоту и удобство реализации. У каждого туннеля свой отдельный конфиг, где описаны все настройки и маршрутизация, относящаяся к этому туннелю. Удобно быстро оценить настройки, сделать копию туннеля, поменяв пару параметров. Можно по отдельности перезапускать туннели, не трогая остальные. При этом база пользователей со своими персональными сертификатами и настройками может быть общей для всех туннелей. Их можно спокойно перемещать между ними. Где-то ещё есть подобная реализация?
#openvpn
Люблю OpenVPN Server за гибкость в настройках. У меня обычное дело, когда на небольшой виртуалке под VPN поднято несколько туннелей. Пример разделения.
1️⃣ В этот туннель заводим все устройства Mikrotik. Так как у них своеобразная реализация OpenVPN, для них приходится поднимать отдельный туннель со своими настройками.
2️⃣ Стандартный туннель на UDP для удалённых пользователей. Типовые настройки.
3️⃣ Тот же туннель, что и выше, только на 443 TCP порту для обхода некоторых ограничений.
4️⃣ Ещё один туннель для удалённых филиалов, только уже не на базе Mikrotik. Тут тоже свои настройки, маршруты и т.д.
Я обычно не боюсь сильно дробить абонентов по разным туннелям, так ими удобнее управлять. Главное сильно не переусложнить, иначе можно запутаться.
Я одних абонентов, за которыми есть свои подсети, к которым нужен доступ через VPN, пересадил с одного туннеля на другой. Добавил новый и подключил их к нему. Перенастроил клиентов, они подключились. На вид всё нормально. Но вижу, что к некоторым сеткам за этими клиентами не могу подключиться.
Начинаю всё проверять. Для начала проверил на всех сторонах firewall. Вроде всё правильно. Для надёжности включил логирование всех заблокированных пакетов, там моих пакетов нет. Из чего делаю вывод, что проблема в маршрутизации.
Смотрю внимательно на маршруты. Иногда это непростая задача, когда путь пакета длинный, особенно если проходит через несколько VPN, как было у меня. Хоть садись и схему пути рисуй, сопоставляя с маршрутами на каждом устройстве. Какое-то время не могу понять в чём проблема, но в итоге заметил.
Оказалось, что я ошибся в настройках туннелей и не полностью перенёс подсети, за которые отвечают абоненты из настроек одного туннеля в другой. Заметил это в маршрутах на сервере. Банально, подсеть 192.168.13.0/24 уехала на интерфейс tun4, а я её оставил в старом конфиге с tun2. В итоге OpenVPN все запросы отправлял в tun2 и они там пропадали.
Во время диагностики просто не обратил внимание на разные имена туннелей. Проверяю, что маршрут завёрнут в tun и на этом успокаиваюсь, ожидая, что OpenVPN сама разберётся в какой туннель отправить запрос. Но на самом деле нет. Надо аккуратно самому расписать, какой туннель за какую подсеть отвечает в конфигах сервера. В итоге всё перепроверил и аккуратно расписал все подсетки по своим туннелям. И трафик поехал как надо.
Я мало работал с другими реализациями VPN. Немного pptp делал, и на микротиках l2tp. На Linux всегда использую OpenVPN. Мне он нравится за простоту и удобство реализации. У каждого туннеля свой отдельный конфиг, где описаны все настройки и маршрутизация, относящаяся к этому туннелю. Удобно быстро оценить настройки, сделать копию туннеля, поменяв пару параметров. Можно по отдельности перезапускать туннели, не трогая остальные. При этом база пользователей со своими персональными сертификатами и настройками может быть общей для всех туннелей. Их можно спокойно перемещать между ними. Где-то ещё есть подобная реализация?
#openvpn
Решил собрать в одну публикацию все варианты настройки и управления OpenVPN сервера через web интерфейс. Я напишу то, что знаю сам. Буду рад, если кто-то ещё поделится рабочими и удобными вариантами.
◽Access Server — родное решение от авторов OpenVPN. Это платный продукт, а бесплатная версия ограничена двумя пользователями. Для единоличного использования подходит. Если нужно больше, то есть лекарство, легко ищется. Если вас это не смущает, то можно пользоваться.
◽Pritunl — один из лучших веб интерфейсов для OpenVPN и Wireguard. К сожалению, платный. Бесплатная версия практически не имеет настроек, но при этом нет никаких ограничений по пользователям. В целом, если вам нужен базовый vpn сервер, то это нормальное решение. Возможно, лучшее.
◽Рутокен VPN — open source решение от авторов Рутокен. Настройки базовые, можно менять конфигурацию сервера и добавлять пользователей. Бонусом идёт свой клиент под Windows, который поддерживает аутентификацию через ключи рутокен. Только последним он и интересен, так как аналогов не видел.
◽Veeam PN — это было отличное бесплатное решение для организации vpn сервера от компании Veeam. Поддерживалась как OpenVPN, так и Wireguard. Когда писал эту заметку, с сожалением узнал, что этот проект закрыт, новых версий больше нет. Его интегрировали в платную версию DR Services.
◽Webmin + OpenVPN-admin — известная веб панель для управления сервером и модуль для OpenVPN. Решение удобно в том плане, что это будет обычный Linux сервер на ваш вкус, в который можно лазить и что-то доделывать, изменять вручную. Я не раз пользовался подобной связкой. Не скажу, что сильно удобно, но в целом нормально для управления пользователями, когда не хочется каждый раз лазить в консоль и скриптами генерить сертификаты и настройки.
◽PfSense, OPNSense, Clearos и т.д. — в этих продуктах тоже есть раздел для управления OpenVPN. С учётом того, что эти системы нетребовательны к ресурсам, можно поднять и для одной роли vpn сервера. Решение вполне нормальное, с заделом на больший функционал.
Отдельно отмечу полезный инструмент для нестабильных каналов связи, который может немного улучшить связь - UDPspeeder. В заметке рассказано для чего он и как работает.
#openvpn #подборка
◽Access Server — родное решение от авторов OpenVPN. Это платный продукт, а бесплатная версия ограничена двумя пользователями. Для единоличного использования подходит. Если нужно больше, то есть лекарство, легко ищется. Если вас это не смущает, то можно пользоваться.
◽Pritunl — один из лучших веб интерфейсов для OpenVPN и Wireguard. К сожалению, платный. Бесплатная версия практически не имеет настроек, но при этом нет никаких ограничений по пользователям. В целом, если вам нужен базовый vpn сервер, то это нормальное решение. Возможно, лучшее.
◽Рутокен VPN — open source решение от авторов Рутокен. Настройки базовые, можно менять конфигурацию сервера и добавлять пользователей. Бонусом идёт свой клиент под Windows, который поддерживает аутентификацию через ключи рутокен. Только последним он и интересен, так как аналогов не видел.
◽Veeam PN — это было отличное бесплатное решение для организации vpn сервера от компании Veeam. Поддерживалась как OpenVPN, так и Wireguard. Когда писал эту заметку, с сожалением узнал, что этот проект закрыт, новых версий больше нет. Его интегрировали в платную версию DR Services.
◽Webmin + OpenVPN-admin — известная веб панель для управления сервером и модуль для OpenVPN. Решение удобно в том плане, что это будет обычный Linux сервер на ваш вкус, в который можно лазить и что-то доделывать, изменять вручную. Я не раз пользовался подобной связкой. Не скажу, что сильно удобно, но в целом нормально для управления пользователями, когда не хочется каждый раз лазить в консоль и скриптами генерить сертификаты и настройки.
◽PfSense, OPNSense, Clearos и т.д. — в этих продуктах тоже есть раздел для управления OpenVPN. С учётом того, что эти системы нетребовательны к ресурсам, можно поднять и для одной роли vpn сервера. Решение вполне нормальное, с заделом на больший функционал.
Отдельно отмечу полезный инструмент для нестабильных каналов связи, который может немного улучшить связь - UDPspeeder. В заметке рассказано для чего он и как работает.
#openvpn #подборка
Вчера немного успел застать вебинара Ребрейн про OpenVPN. Попал на самый конец, но всё равно успел получить очень полезную для себя информацию, которой поделюсь с вами.
1️⃣ Первое прям открытие для меня — параметр ccd-exclusive. Если установлен этот параметр, то пользователь даже при наличие актуального сертификата сможет пройти аутентификацию только в том случае, если для него существует файл конфигурации пользователя в директории, заданной параметром client-config-dir.
Объясняю, зачем это может понадобиться. Чтобы запретить подключения какому-то пользователю, необходимо отозвать его сертификат, подготовить файл отозванных сертификатов и прописать их в конфигурации сервера с помощью параметра crl-verify. И после каждого отзыва файл надо перезаписывать.
С помощью ccd-exclusive можно отключать пользователей, просто удаляя их файл конфигурации. Я лично их почти всегда использую. Даже если там нет отдельных параметров, привык создавать эти файлы пустыми, чтобы для каждого пользователя был его файл конфигурации. На основе этих файлов делаю мониторинг подключений openvpn.
Да, сертификаты отключенных пользователей всё равно надо отзывать. Так правильно. Но можно это делать разово по регламенту, к примеру, раз в месяц. А если надо просто отключить пользователя, удаляем ему файл конфигурации и всё. Это намного проще и удобнее. Потом можно его снова вернуть и пользователь сможет подключиться с тем же сертификатом.
Лет 10 активно использую openvpn, а этот параметр никогда не попадался на глаза. Не знал, что так можно было сделать.
2️⃣ Работы по переводу OpenVPN из контекста пользователя в ядро Linux ведутся. Более того, модуль ядра уже написан и он реально работает. Пока ещё его не добавили в популярные дистрибутивы. Скорее всего это рано или поздно состоится. Уже сейчас можно скачать исходники модуля, скомпилировать их и всё заработает с некоторыми ограничениями по параметрам. К примеру, при обработке ядром не работает сжатие.
Поясню, в чём тут проблема. OpenVPN работает в пространстве пользователя, в отличите от WireGuard, которая обрабатывается напрямую в ядре Linux. Этим объясняется её быстродействие. Разработчики OpenVPN озадачились и решили тоже перенести обработку в ядро и написали свой модуль для этого. Так что в скором времени большой разницы в скоростях между OpenVPN и Wireguard не должно быть.
#openvpn
1️⃣ Первое прям открытие для меня — параметр ccd-exclusive. Если установлен этот параметр, то пользователь даже при наличие актуального сертификата сможет пройти аутентификацию только в том случае, если для него существует файл конфигурации пользователя в директории, заданной параметром client-config-dir.
Объясняю, зачем это может понадобиться. Чтобы запретить подключения какому-то пользователю, необходимо отозвать его сертификат, подготовить файл отозванных сертификатов и прописать их в конфигурации сервера с помощью параметра crl-verify. И после каждого отзыва файл надо перезаписывать.
С помощью ccd-exclusive можно отключать пользователей, просто удаляя их файл конфигурации. Я лично их почти всегда использую. Даже если там нет отдельных параметров, привык создавать эти файлы пустыми, чтобы для каждого пользователя был его файл конфигурации. На основе этих файлов делаю мониторинг подключений openvpn.
Да, сертификаты отключенных пользователей всё равно надо отзывать. Так правильно. Но можно это делать разово по регламенту, к примеру, раз в месяц. А если надо просто отключить пользователя, удаляем ему файл конфигурации и всё. Это намного проще и удобнее. Потом можно его снова вернуть и пользователь сможет подключиться с тем же сертификатом.
Лет 10 активно использую openvpn, а этот параметр никогда не попадался на глаза. Не знал, что так можно было сделать.
2️⃣ Работы по переводу OpenVPN из контекста пользователя в ядро Linux ведутся. Более того, модуль ядра уже написан и он реально работает. Пока ещё его не добавили в популярные дистрибутивы. Скорее всего это рано или поздно состоится. Уже сейчас можно скачать исходники модуля, скомпилировать их и всё заработает с некоторыми ограничениями по параметрам. К примеру, при обработке ядром не работает сжатие.
Поясню, в чём тут проблема. OpenVPN работает в пространстве пользователя, в отличите от WireGuard, которая обрабатывается напрямую в ядре Linux. Этим объясняется её быстродействие. Разработчики OpenVPN озадачились и решили тоже перенести обработку в ядро и написали свой модуль для этого. Так что в скором времени большой разницы в скоростях между OpenVPN и Wireguard не должно быть.
#openvpn
Любопытный проект для поднятия VPN сервера на базе OpenVPN в пару кликов — dockovpn. Собран на базе Docker, не хранит ни логов, ни своего состояния. То есть запустили, получили конфиг пользователя, попользовались, остановили контейнер, всё удалилось. При желании, конфиги можно сделать постоянными.
Запускаете вот так:
Если 80-й порт на хосте занят, выберите любой другой. Он нужен для того, чтобы после запуска контейнера на нём поднялся web сервер. Обратившись по его адресу, вы скачиваете конфиг клиента и после этого веб сервер завершает свою работу.
Далее отдаёте этот конфиг любому клиенту OpenVPN и подключаетесь. На сервере должен быть белый IP адрес. Dockovpn использует его для работы openvpn. Если не хотите, чтобы после остановки контейнера удалялся клиентский конфиг, запустите его с volume, где будут храниться конфигурации:
Я посмотрел исходники проекта. Там нет ничего особенного. Обычная настройка openvpn сервера, правил iptables и генерация сертификатов с помощью easy-rsa. В репозитории есть Dockerfile и все скрипты с конфигами. Можете собрать контейнер сами, если не доверяете готовому:
Идеальный инструмент для запуска в виртуалках с почасовой оплатой. Не задаёт никаких вопросов. Запустили, попользовались, погасили. Хотя для личного пользования можно и на постоянку оставить, если не хочется заморачиваться с установкой и настройкой. Там вполне адекватный конфиг, можно посмотреть в директории dockovpn/config. Используются DNS сервера OpenDNS. Можно их заменить на какие-то свои, если есть необходимость.
⇨ Исходники
#openvpn
Запускаете вот так:
# docker run -it --rm --cap-add=NET_ADMIN \-p 1194:1194/udp -p 80:8080/tcp \-e HOST_ADDR=$(curl -s https://api.ipify.org) \--name dockovpn alekslitvinenk/openvpnЕсли 80-й порт на хосте занят, выберите любой другой. Он нужен для того, чтобы после запуска контейнера на нём поднялся web сервер. Обратившись по его адресу, вы скачиваете конфиг клиента и после этого веб сервер завершает свою работу.
Далее отдаёте этот конфиг любому клиенту OpenVPN и подключаетесь. На сервере должен быть белый IP адрес. Dockovpn использует его для работы openvpn. Если не хотите, чтобы после остановки контейнера удалялся клиентский конфиг, запустите его с volume, где будут храниться конфигурации:
# docker run -it --rm --cap-add=NET_ADMIN \-p 1194:1194/udp -p 80:8080/tcp \-e HOST_ADDR=$(curl -s https://api.ipify.org) \-v openvpn_conf:/opt/Dockovpn_data \--name dockovpn alekslitvinenk/openvpnЯ посмотрел исходники проекта. Там нет ничего особенного. Обычная настройка openvpn сервера, правил iptables и генерация сертификатов с помощью easy-rsa. В репозитории есть Dockerfile и все скрипты с конфигами. Можете собрать контейнер сами, если не доверяете готовому:
# git clone https://github.com/dockovpn/dockovpn# cd dockovpn# # docker build -t dockovpn .Идеальный инструмент для запуска в виртуалках с почасовой оплатой. Не задаёт никаких вопросов. Запустили, попользовались, погасили. Хотя для личного пользования можно и на постоянку оставить, если не хочется заморачиваться с установкой и настройкой. Там вполне адекватный конфиг, можно посмотреть в директории dockovpn/config. Используются DNS сервера OpenDNS. Можно их заменить на какие-то свои, если есть необходимость.
⇨ Исходники
#openvpn
Популярный вопрос по поводу OpenVPN. Как на одном сервере с несколькими внешними IP адресами настроить независимую работу VPN на каждом IP адресе. Сделать это очень просто. Фактически, это штатная работа службы OpenVPN, даже ничего колхозить не придётся.
Настраиваете OpenVPN как обычно для одного IP адреса. Допустим, вся конфигурация у вас описана в
Теперь добавим ещё один сервер и запустим 2 экземпляра OpenVPN, каждый на своём внешнем ip. Для этого в конфигурацию
Копируем этот конфиг для запуска второго сервера:
В него добавляем свои параметры:
Все остальные настройки могут быть как идентичными первому серверу, в том числе использовать те же сертификаты и CA, так и совершенно разными. Они между собой никак не будут связаны. Это будут два отдельных сервера OpenVPN. Запускаем второй сервер:
Проверяем:
Таким же образом вы можете копировать конфигурации сервера и запускать разные туннели на разных портах, с разным шифрованием, настройками и т.д. Если у вас есть возможность докупать внешние IP на VPS, то вы сможете настроить многофункциональный VPN сервер под любые запросы. Это очень удобно. К тому же просто и быстро настраивается. И так же потом обслуживается. Каждый туннель можно настроить на свой лог файл, свою статистику и т.д. Всё это мониторить, анализировать, ограничивать доступ к каким-то туннелям, настраивать для них правила файрвола, разным туннелям пушить разные маршруты, разные настройки пользователям. В общем, красота. Я не знаю, где ещё подобные вещи настраиваются так же легко и просто.
#openvpn #vpn
Настраиваете OpenVPN как обычно для одного IP адреса. Допустим, вся конфигурация у вас описана в
/etc/openvpn/server/server1.conf. Запускаете вы этот сервер так (если установили в Debian из базовых реп):# systemctl start openvpn-server@server1.serviceТеперь добавим ещё один сервер и запустим 2 экземпляра OpenVPN, каждый на своём внешнем ip. Для этого в конфигурацию
server1.conf добавляем параметр local, указав внешний IP адрес, и сразу обозначим tun интерфейс, на котором он будет работать и адресное пространство этого туннеля:local 1.2.3.4dev tun1server 10.8.1.0 255.255.255.0Копируем этот конфиг для запуска второго сервера:
# cp server1.conf server2.confВ него добавляем свои параметры:
local 4.3.2.1dev tun2server 10.8.2.0 255.255.255.0Все остальные настройки могут быть как идентичными первому серверу, в том числе использовать те же сертификаты и CA, так и совершенно разными. Они между собой никак не будут связаны. Это будут два отдельных сервера OpenVPN. Запускаем второй сервер:
# systemctl start openvpn-server@server2.serviceПроверяем:
# ip a | grep 'global tun' inet 10.8.1.1/24 scope global tun1 inet 10.8.2.1/24 scope global tun2# netstat -tulnp | grep openvpnudp 0 0 1.2.3.4:1194 0.0.0.0:* 1330/openvpn udp 0 0 4.3.2.1:1194 0.0.0.0:* 1321/openvpn Таким же образом вы можете копировать конфигурации сервера и запускать разные туннели на разных портах, с разным шифрованием, настройками и т.д. Если у вас есть возможность докупать внешние IP на VPS, то вы сможете настроить многофункциональный VPN сервер под любые запросы. Это очень удобно. К тому же просто и быстро настраивается. И так же потом обслуживается. Каждый туннель можно настроить на свой лог файл, свою статистику и т.д. Всё это мониторить, анализировать, ограничивать доступ к каким-то туннелям, настраивать для них правила файрвола, разным туннелям пушить разные маршруты, разные настройки пользователям. В общем, красота. Я не знаю, где ещё подобные вещи настраиваются так же легко и просто.
#openvpn #vpn
В современном интернете очень активно используется протокол шифрования TLS. Чаще всего с ним сталкиваешься в HTTPS, VPN, STARTTLS (imap и smtp в основном). В Linux (и Unix в целом) этот протокол в основном реализован посредством OpenSSL. Это библиотека libssl и утилита командной строки openssl. Работа с этой утилитой настоящий вынос мозга. Там море всяких ключей, длиннющих конструкций и команд. Сталкиваться с этим напрямую приходится, например, при настройке своего OpenVPN сервера.
Чтобы упростить задачу управления сертификатами с помощью OpenSSL, придумали набор скриптов EasyRSA, которые даже в винду портировали. Именно с ними я всегда взаимодействовал, когда нужно было создать CA, серверные и клиентские ключи для OpenVPN (вот пример из моей статьи). Да и не только. Для всех подобных задач использовал EasyRSA и не знал, что есть инструменты проще.
В одном из комментариев увидел информацию, что есть CFSSL. Это утилита от cloudflare, с помощью которой можно создать и управлять CA, только без лишних костылей и подпорок. У неё вполне простой и понятный CLI, которым пользоваться в разы удобнее и проще, чем у openssl. Покажу сразу на примере создания CA и выпуска сертификатов для нужд OpenVPN сервера. Использую потом эту заметку при очередном обновлении статьи (уже назрело).
CFSSL это просто бинарник, скомпилированный из исходников на GO. В репозиториях Debian 12 он живёт под названием
Версия почему-то очень древнючая - 1.2.0, когда в репе уже 1.6.4 есть. Можно вручную скачать свежий бинарник.
Для cfssl нужно готовить конфиги в формате json. Сделать это нужно будет 1 раз. Интерактивного ввода, как у easyrsa, как я понял, нет. Готовим простой конфиг для выпуска СА:
Сохранили с именем
Генерируем ключ для CA:
Получили 3 файла:
▪ ca-key.pem - приватный ключ для подписи сертификатов
▪ ca.pem - сам сертификат удостоверяющего центра
▪ ca.csr - запрос на сертификат
Подготовим конфиг профилей, которые нужны будут для сертификата сервера и клиентов:
Сохранили с именем ca.json. И делаем конфиг для запроса, такой же как для CA, только секцию с CA убираем:
Сохранили с именем csr.json. Выпускаем сертификат сервера:
Получили 3 файла:
Выпускаем сертификат для клиента:
Проверяем:
Вот и всё. Подготовили удостоверяющий центр и выпустили сертификаты клиента и сервера. Выглядит действительно удобнее и проще EasyRSA.
#security #openvpn
Чтобы упростить задачу управления сертификатами с помощью OpenSSL, придумали набор скриптов EasyRSA, которые даже в винду портировали. Именно с ними я всегда взаимодействовал, когда нужно было создать CA, серверные и клиентские ключи для OpenVPN (вот пример из моей статьи). Да и не только. Для всех подобных задач использовал EasyRSA и не знал, что есть инструменты проще.
В одном из комментариев увидел информацию, что есть CFSSL. Это утилита от cloudflare, с помощью которой можно создать и управлять CA, только без лишних костылей и подпорок. У неё вполне простой и понятный CLI, которым пользоваться в разы удобнее и проще, чем у openssl. Покажу сразу на примере создания CA и выпуска сертификатов для нужд OpenVPN сервера. Использую потом эту заметку при очередном обновлении статьи (уже назрело).
CFSSL это просто бинарник, скомпилированный из исходников на GO. В репозиториях Debian 12 он живёт под названием
golang-cfssl:# apt install golang-cfsslВерсия почему-то очень древнючая - 1.2.0, когда в репе уже 1.6.4 есть. Можно вручную скачать свежий бинарник.
Для cfssl нужно готовить конфиги в формате json. Сделать это нужно будет 1 раз. Интерактивного ввода, как у easyrsa, как я понял, нет. Готовим простой конфиг для выпуска СА:
{ "CN": "My Root CA", "key": { "algo": "rsa", "size": 2048 }, "ca": { "expiry": "87600h" }, "names": [ { "C": "RU", "L": "Moscow", "O": "Serveradmin Company", "OU": "OpenVPN", "ST": "Moscow" } ]}Сохранили с именем
ca-csr.json. Тут срок действия стоит 10 лет. Кажется, что много. Но на самом деле у меня лично был случай, когда 10-ти летний CA протух.Генерируем ключ для CA:
# mkdir keys && cd keys# cfssl gencert -initca ca-csr.json | cfssljson -bare caПолучили 3 файла:
▪ ca-key.pem - приватный ключ для подписи сертификатов
▪ ca.pem - сам сертификат удостоверяющего центра
▪ ca.csr - запрос на сертификат
Подготовим конфиг профилей, которые нужны будут для сертификата сервера и клиентов:
{ "signing": { "profiles": { "server": { "expiry": "87600h", "usages": [ "digital signature", "key encipherment", "server auth" ] }, "client": { "expiry": "87600h", "usages": [ "signing", "client auth" ] } } }}Сохранили с именем ca.json. И делаем конфиг для запроса, такой же как для CA, только секцию с CA убираем:
{ "CN": "My Root CA", "key": { "algo": "rsa", "size": 2048 }, "names": [ { "C": "RU", "L": "Moscow", "O": "Serveradmin Company", "OU": "OpenVPN", "ST": "Moscow" } ]}Сохранили с именем csr.json. Выпускаем сертификат сервера:
# cfssl gencert -ca=ca.pem -ca-key=ca-key.pem \-config=ca.json -profile="server" \-cn="openvpn.server.local" -hostname="openvpn" \csr.json | cfssljson -bare serverПолучили 3 файла:
# ls | grep serverserver.csrserver-key.pemserver.pemВыпускаем сертификат для клиента:
# cfssl gencert -ca=ca.pem -ca-key=ca-key.pem \-config=ca.json -profile="client" \-cn="client01" -hostname="User 01" \csr.json | cfssljson -bare client01Проверяем:
# ls | grep client01client01.csrclient01-key.pemclient01.pemВот и всё. Подготовили удостоверяющий центр и выпустили сертификаты клиента и сервера. Выглядит действительно удобнее и проще EasyRSA.
#security #openvpn
Сколько лет использую OpenVPN, а только недавно случайно узнал, что он умеет в маршрутах использовать не только ip адреса, но и fqdn, то есть доменные имена. Для этого есть параметр allow-pull-fqdn.
Увидел упоминание этого параметра случайно. Решил сразу попробовать, как он работает. И так, и сяк его на сервере применял, не работает. Оказалось, что это параметр клиента и автоматически передать его через push нельзя. То есть надо явно в конфиг клиента прописать:
И после этого ему можно пушить маршруты с сервера в таком виде:
При подключении к openvpn серверу клиент получит маршруты и если там будет указан домен, автоматически отрезолвит этот домен в IP адрес и добавит его в таблицу маршрутизации. Так что никакой магии тут нет, openvpn в реальности не умеет оперировать доменами в маршрутах. Он просто чуть упрощает задачу, делая автоматически резолв. Тем не менее, даже в таком виде это довольно удобно. Буду применять.
Для тех, кто не знаком с OpenVPN, поясню подробнее, что это такое. Вы можете на сервере в настройках клиента, каждому в отдельности настраивать маршруты, по которым он будет ходить через vpn сервер. Это очень удобная возможность, так как не надо менять конфигурацию клиента. Всё управление маршрутами происходит централизованно на сервере. А с помощью описанного параметра, вы любому клиенту можете указать, что на такой-то сайт ходи через vpn сервер. Самому клиенту при этом ничего настраивать не надо. Он просто переподключится и получит обновлённые маршруты. У WireGuard такой возможности нет. Ему надо каждый раз конфиг обновлять, когда вносятся изменения в маршрутизацию.
#openvpn
Увидел упоминание этого параметра случайно. Решил сразу попробовать, как он работает. И так, и сяк его на сервере применял, не работает. Оказалось, что это параметр клиента и автоматически передать его через push нельзя. То есть надо явно в конфиг клиента прописать:
allow-pull-fqdnИ после этого ему можно пушить маршруты с сервера в таком виде:
push "route whoer.net 255.255.255.255"При подключении к openvpn серверу клиент получит маршруты и если там будет указан домен, автоматически отрезолвит этот домен в IP адрес и добавит его в таблицу маршрутизации. Так что никакой магии тут нет, openvpn в реальности не умеет оперировать доменами в маршрутах. Он просто чуть упрощает задачу, делая автоматически резолв. Тем не менее, даже в таком виде это довольно удобно. Буду применять.
Для тех, кто не знаком с OpenVPN, поясню подробнее, что это такое. Вы можете на сервере в настройках клиента, каждому в отдельности настраивать маршруты, по которым он будет ходить через vpn сервер. Это очень удобная возможность, так как не надо менять конфигурацию клиента. Всё управление маршрутами происходит централизованно на сервере. А с помощью описанного параметра, вы любому клиенту можете указать, что на такой-то сайт ходи через vpn сервер. Самому клиенту при этом ничего настраивать не надо. Он просто переподключится и получит обновлённые маршруты. У WireGuard такой возможности нет. Ему надо каждый раз конфиг обновлять, когда вносятся изменения в маршрутизацию.
#openvpn
Для OpenVPN на первый взгляд кажется, что существует много различных веб панелей. Но когда начинаешь в них разбираться, оказывается, что одна платная, а бесплатная версия урезана, другая уже давно не поддерживается, третья в какой-то своей логике всем управляет и хранит данные. На деле выбирать особо то и не из чего. Я когда-то давно собрал список известных мне панелей:
⇨ Управление OpenVPN сервером через web интерфейс
Сегодня покажу ещё один вариант, который поначалу показался каким-то костыльным из-за недостатка документации, но когда немного разобрался, решение понравилось. Речь пойдёт про open source проект от известного аутсорсера flant - ovpn-admin.
📌 У ovpn-admin следующие возможности:
◽️Запуск через одиночный бинарник с передачей всех параметров через ключи. Есть готовый контейнер для автоматического запуска. Я тестировал в нём.
◽️Веб интерфейс для добавления и удаления пользователей, просмотра статуса их подключения и передачи маршрутов
◽️Экспортер для Prometheus и шаблон для Grafana с метриками: срок жизни сертификата, кол-во подключенных пользователей, информация о подключенных пользователях (время подключения, ip адрес, трафик)
◽️Подключение пользователем с использованием пароля или без, возможность скачать готовый конфиг сразу с включённым в него сертификатом
◽️Helm чарт для запуска в Kubernetes, собственно, продукт оптимизирован для запуска в кубере, может хранить сертификаты в секретах
Мне понравилось это решение тем, что оно, во-первых, полностью автоматизирует запуск сервера, а во-вторых, максимально похоже на администрирование стандартного openvpn сервера, установленного вручную. Тут всё на своих местах: конфиг сервера, шаблон конфига пользователей, директория с сертификатами, с настройками пользователей. Для тех, кто знаком с openvpn сервером не будет никаких проблем с тем, чтобы разобраться, как это всё работает.
Показываю, как запустить ovpn-admin в рабочем режиме. Не знаю, почему в самой репе не оставили краткой инструкции. Либо я её не нашёл. В общем, сделал в итоге так:
Теперь правим некоторые параметры
Остальные параметры я оставил по умолчанию. Собираем и запускаем контейнер:
Дожидаемся запуска и идём в веб интерфейс управления: http://1.2.3.4:8080/. Он будет доступен без аутентификации. Его нужно закрыть либо файрволом, либо basic_auth на прокси.
Расскажу про несколько полезных директорий и файлов:
-
-
-
-
Структура и расположение файлов типичны для openvpn сервера. На эту панель легко переехать с работающего сервера, либо наоборот съехать, если не понравится, забрав все настройки и пользователей. Можно спокойно залезть в какие-то файлы и руками поправить параметры. Это ничего не сломает, так как всё состояние хранится только в них.
Я всё это запустил, настроил, попробовал. Добавил метрики Прома, установил шаблон Графаны. Забрать можно тут. У меня заработало сразу. На деле вроде бы и ничего особенного, но задачу по управлению и тем более мониторингу сильно упрощает. Не нужно самому парсить статус лог сервера. Там хоть и ничего сложного, я парсил для Zabbix, но тут это сделали за нас.
⇨4️⃣ Исходники
#openvpn
⇨ Управление OpenVPN сервером через web интерфейс
Сегодня покажу ещё один вариант, который поначалу показался каким-то костыльным из-за недостатка документации, но когда немного разобрался, решение понравилось. Речь пойдёт про open source проект от известного аутсорсера flant - ovpn-admin.
📌 У ovpn-admin следующие возможности:
◽️Запуск через одиночный бинарник с передачей всех параметров через ключи. Есть готовый контейнер для автоматического запуска. Я тестировал в нём.
◽️Веб интерфейс для добавления и удаления пользователей, просмотра статуса их подключения и передачи маршрутов
◽️Экспортер для Prometheus и шаблон для Grafana с метриками: срок жизни сертификата, кол-во подключенных пользователей, информация о подключенных пользователях (время подключения, ip адрес, трафик)
◽️Подключение пользователем с использованием пароля или без, возможность скачать готовый конфиг сразу с включённым в него сертификатом
◽️Helm чарт для запуска в Kubernetes, собственно, продукт оптимизирован для запуска в кубере, может хранить сертификаты в секретах
Мне понравилось это решение тем, что оно, во-первых, полностью автоматизирует запуск сервера, а во-вторых, максимально похоже на администрирование стандартного openvpn сервера, установленного вручную. Тут всё на своих местах: конфиг сервера, шаблон конфига пользователей, директория с сертификатами, с настройками пользователей. Для тех, кто знаком с openvpn сервером не будет никаких проблем с тем, чтобы разобраться, как это всё работает.
Показываю, как запустить ovpn-admin в рабочем режиме. Не знаю, почему в самой репе не оставили краткой инструкции. Либо я её не нашёл. В общем, сделал в итоге так:
# git clone https://github.com/flant/ovpn-admin.git# cd ovpn-adminТеперь правим некоторые параметры
docker-compose.yaml:OVPN_PASSWD_AUTH: "true" # включена аутентификация по паролю, можно отключить, если не надоOVPN_SERVER: "1.2.3.4:7777:tcp" # ip адрес, на котором запущен сервер и к которому будут подключаться клиенты, соответственно порт и протокол, по которому будут подключатьсяOVPN_METRICS_PATH: "/metrics" # url, на котором будут жить метрики PrometheusОстальные параметры я оставил по умолчанию. Собираем и запускаем контейнер:
# ./start.shДожидаемся запуска и идём в веб интерфейс управления: http://1.2.3.4:8080/. Он будет доступен без аутентификации. Его нужно закрыть либо файрволом, либо basic_auth на прокси.
Расскажу про несколько полезных директорий и файлов:
-
.ovpn-admin/easyrsa_master/pki - сертификаты пользователей-
.ovpn-admin/ccd_master - файлы конфигурации пользователей-
.ovpn-admin/setup/openvpn.conf - параметры сервера openvpn-
.ovpn-admin/templates - шаблон конфигурации клиента, настроек ccdСтруктура и расположение файлов типичны для openvpn сервера. На эту панель легко переехать с работающего сервера, либо наоборот съехать, если не понравится, забрав все настройки и пользователей. Можно спокойно залезть в какие-то файлы и руками поправить параметры. Это ничего не сломает, так как всё состояние хранится только в них.
Я всё это запустил, настроил, попробовал. Добавил метрики Прома, установил шаблон Графаны. Забрать можно тут. У меня заработало сразу. На деле вроде бы и ничего особенного, но задачу по управлению и тем более мониторингу сильно упрощает. Не нужно самому парсить статус лог сервера. Там хоть и ничего сложного, я парсил для Zabbix, но тут это сделали за нас.
⇨
#openvpn
Please open Telegram to view this post
VIEW IN TELEGRAM
Продолжу начатую утром тему OpenVPN. В Linux без проблем можно запустить сколько угодно экземпляров сервера и клиента. Достаточно копировать конфигурационный файл, указывать разные tun или tap интерфейсы, порты и запускать каждый экземпляр службы со своим конфигом.
В Windows несколько сложнее. Про сервер ничего не скажу, я его на винде никогда не поднимаю. А вот для запуска нескольких подключений клиента, чтобы иметь возможность одновременно подключаться к нескольким OpenVPN серверам, нужно добавить дополнительные сетевые адаптеры в систему. Сделать это несложно.
Запускаем консоль cmd с правами администратора и делаем там следующее:
В Панели управления, в списке сетевых адаптеров должен появиться ещё один TAP-Windows Adapter V9 #2, #3 и так далее, если нужно больше двух. Теперь можно одновременно подключиться к разным OpenVPN серверам.
Добавлю несколько ссылок на полезные и неочевидные возможности OpenVPN сервера:
▪️ Маршруты для клиента на основе url, а не ip адреса
▪️ Запуск OpenVPN сервера на разных внешних IP адресах
▪️ Блокировка подключения пользователя без отзыва сертификата
▪️ Диагностика низкой скорости через OpenVPN
▪️ Запускаем OpenVPN сервер за 443 портом веб сервера
Подход из последней ссылки недавно помог восстановить хождение трафика на зарубежные VPS по OpenVPN. Просто поменял порт на 443 TCP и всё заработало.
Предвещая вопросы на тему того, зачем сейчас использовать OpenVPN, сразу оставлю ссылку, так как много раз отвечал на него. И добавлю, что OpenVPN использую в первую очередь для объединения и доступа к сетям, а не обхода блокировок.
#openvpn #windows
В Windows несколько сложнее. Про сервер ничего не скажу, я его на винде никогда не поднимаю. А вот для запуска нескольких подключений клиента, чтобы иметь возможность одновременно подключаться к нескольким OpenVPN серверам, нужно добавить дополнительные сетевые адаптеры в систему. Сделать это несложно.
Запускаем консоль cmd с правами администратора и делаем там следующее:
> cd C:\Program Files\OpenVPN\bin> tapctl.exe createВ Панели управления, в списке сетевых адаптеров должен появиться ещё один TAP-Windows Adapter V9 #2, #3 и так далее, если нужно больше двух. Теперь можно одновременно подключиться к разным OpenVPN серверам.
Добавлю несколько ссылок на полезные и неочевидные возможности OpenVPN сервера:
▪️ Маршруты для клиента на основе url, а не ip адреса
▪️ Запуск OpenVPN сервера на разных внешних IP адресах
▪️ Блокировка подключения пользователя без отзыва сертификата
▪️ Диагностика низкой скорости через OpenVPN
▪️ Запускаем OpenVPN сервер за 443 портом веб сервера
Подход из последней ссылки недавно помог восстановить хождение трафика на зарубежные VPS по OpenVPN. Просто поменял порт на 443 TCP и всё заработало.
Предвещая вопросы на тему того, зачем сейчас использовать OpenVPN, сразу оставлю ссылку, так как много раз отвечал на него. И добавлю, что OpenVPN использую в первую очередь для объединения и доступа к сетям, а не обхода блокировок.
#openvpn #windows
Занимался на днях в очередной раз перенастройкой своих VPN каналов. Честно говоря уже надоело этим заниматься, но внешние обстоятельства постоянно меняются. Хочу рассказать об одной особенности OpenVPN, которую я постоянно использую, и которая видится мне весьма полезной и функциональной.
OpenVPN сервер умеет управлять маршрутами внутри своих VPN сетей. Это получается второй контур маршрутизации поверх системного. Расскажу кратко, как это работает.
Допустим, у вас есть OpenVPN сервер, к которому подключаются разные клиенты. Будь то динамические подключения от удалённых сотрудников, либо другие одиночные сервера, маршрутизаторы своих внутренних подсетей. На сервере у вас указано, что все запросы к подсетям:
Отправляются в VPN сеть, конкретно в tun0 интерфейс. Настроить это можно сразу в конфиге openvpn для туннеля tun0:
OpenVPN сервер при запуске добавляет указанные маршруты в систему. Это можно сделать и вручную. Сервер при старте просто использует
За каждую указанную выше подсеть у нас отвечают разные клиенты VPN. Это может быть указано в его конфигурационном файле. Делается это так:
При подключении клиента с этой настройкой OpenVPN сервер понимает, что весь трафик в эту подсеть стоит адресовать этому клиенту. Если клиент поменяется, то эта настройка может переехать к другому.
Глобально настройки сервера и других VPN клиентов не меняются. Они просто подключаются и получают общую маршрутизацию. А по каким маршрутам внутри VPN побегут пакеты определяют настройки отдельных клиентов, которые выполняют роль маршрутизаторов. И этих клиентов можно легко заменить без необходимости менять какие-либо ещё настройки.
Подробнее об этом можно прочитать в документации. Искать по параметру
Мне пришлось заменить одного клиента на другого, через которого ходил трафик в youtube. Настройки остальных пользователей трогать не пришлось. У меня используется схема с единым OpenVPN сервером в РФ, к которому подключаются все клиенты. А он уже раскидывает трафик в зависимости от потребностей.
Набросал ниже схему, чтобы было понятно, о чём идёт речь.
#openvpn
OpenVPN сервер умеет управлять маршрутами внутри своих VPN сетей. Это получается второй контур маршрутизации поверх системного. Расскажу кратко, как это работает.
Допустим, у вас есть OpenVPN сервер, к которому подключаются разные клиенты. Будь то динамические подключения от удалённых сотрудников, либо другие одиночные сервера, маршрутизаторы своих внутренних подсетей. На сервере у вас указано, что все запросы к подсетям:
10.1.3.0/2410.1.4.0/2410.1.5.0/24Отправляются в VPN сеть, конкретно в tun0 интерфейс. Настроить это можно сразу в конфиге openvpn для туннеля tun0:
route 10.1.3.0 255.255.255.0route 10.1.4.0 255.255.255.0route 10.1.5.0 255.255.255.0OpenVPN сервер при запуске добавляет указанные маршруты в систему. Это можно сделать и вручную. Сервер при старте просто использует
/sbin/ip route add для добавления маршрутов.За каждую указанную выше подсеть у нас отвечают разные клиенты VPN. Это может быть указано в его конфигурационном файле. Делается это так:
iroute 10.1.3.0 255.255.255.0При подключении клиента с этой настройкой OpenVPN сервер понимает, что весь трафик в эту подсеть стоит адресовать этому клиенту. Если клиент поменяется, то эта настройка может переехать к другому.
Глобально настройки сервера и других VPN клиентов не меняются. Они просто подключаются и получают общую маршрутизацию. А по каким маршрутам внутри VPN побегут пакеты определяют настройки отдельных клиентов, которые выполняют роль маршрутизаторов. И этих клиентов можно легко заменить без необходимости менять какие-либо ещё настройки.
Подробнее об этом можно прочитать в документации. Искать по параметру
--iroute для внутренней маршрутизации и --client-config-dir для персональных настроек клиентов. Мне пришлось заменить одного клиента на другого, через которого ходил трафик в youtube. Настройки остальных пользователей трогать не пришлось. У меня используется схема с единым OpenVPN сервером в РФ, к которому подключаются все клиенты. А он уже раскидывает трафик в зависимости от потребностей.
Набросал ниже схему, чтобы было понятно, о чём идёт речь.
#openvpn