• OpenVPN: Настройка на собственном сервере. Часть 0 — подготовка системы.
• OpenVPN: Настройка на собственном сервере. Часть 1 — сертификаты.
• OpenVPN: Настройка на собственном сервере. Часть 2 — конфигурация сервера.
• OpenVPN: Настройка на собственном сервере. Часть 3 — iptables
• OpenVPN: Настройка на собственном сервере. Часть 4 — конфигурация клиента.

Первоначальная настройка успешно завершена и нам необходимо позаботится о безопасности. Т.е. о сертификатах, с которыми будут работать клиенты и сервер.

Для этого нужно три компонента:

• Корневой сертификат (назовем его для простоты CA), которым будут подписываться ключи клиента и сервере. Крайне желательно чтобы он был на отдельной машине.
• Сертификат сервера, который будет подписан корневым доверительным сертификатом.
• Сертификат для каждого из клиентов, который тай жэ будет подписан CA

Корневой сертификат и сертификат сервера

Создаем корневой центр собственной сертификации (лучше делать это не на той машине, где запуен openvpn и там должен быть установлен пакет easy-rsa)

$ cp -R /usr/share/easy-rsa/3.0.0/ ~/CA  
$ cp /usr/share/doc/easy-rsa/vars.example ~/CA/vars  
$ cd ~/CA

Нужно отредактировать vars и поправить те параметры, которые будут вам интересны. Это имя домена, имя сервера и прочее - все подробно прокомментировано в файле.

Инициализировать PKI (Public Key Infrastructure — Инфраструктура открытых ключей):

$ ./easyrsa init-pki

Создать корневой сертификат. Common Name сервера вводить на ваше успотрение. (лучше придумать что-то вроде vpn-server). Сложный пароль ключа обязателе. Не менее 128 бит.

$ ./easyrsa build-ca

Создать ключи Диффи-Хелмана

$ ./easyrsa gen-dh

Создать запрос на сертификат для сервера OVPN. Обращаю внимание, что сертификат будет незапаролен (параметр nopass), иначе при каждом старте OpenVPN будет запрашивать этот пароль.

$ ./easyrsa gen-req vpn-server nopass

Создать и подписать сертификат

$ ./easyrsa sign-req server vpn-server

Скопировать полученные ключи в рабочий каталог openvpn

$ sudo mkdir -p /etc/openvpn/keys  
$ sudo mkdir cp ~/CA/pki/ca.crt /etc/openvpn/keys  
$ sudo mkdir cp ~/CA/pki/issued/vpn-server.crt /etc/openvpn/keys  
$ sudo mkdir cp ~/CA/pki/private/vpn-server.key /etc/openvpn/keys  
$ sudo mkdir cp ~/CA/pki/dh.pem /etc/openvpn/keys

Создать «HMAC firewall» для защиты от DoS аттак и флуда UDP порта.

$ cd /etc/openvpn/keys/  
$ sudo openvpn --genkey --secret ta.key

Генерация пользовательских ключей

Создание запроса запароленного ключа для клиента (потребуется вводить при каждом подключении) с именем User

$ cd ~/CA  
$ ./easyrsa gen-req User

User - это имя пользователя для которого вы генерируете ключ.

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

Если вам не требуется такого уровня. Или авторизация будет осуществляться иными методами, то генерируйте ключ без пароля.

$ ./easyrsa gen-req User nopass

Теперь ключ надо подписать

$ ./easyrsa sign-req client User

Дефолтно ключ выдается на 10 лет. Можно ограничить время. И ключи придется только перевыпускать по завершению работы.

$./easyrsa sign-req client User -days 90

Клиенту потребуется следующий набор файлов

 ~/CA/pki/issued/User.crt  
 ~/CA/pki/private/User.key  
 ~/CA/pki/ca.crt  
 /etc/openvpn/keys/ta.key

Отзывы сертификатов

Герируем файл отозванных ключей

$ cd ~/CA  
$ ./easyrsa gen-crl

Если вы все же сделали центр сертификации на той же машине, на которой у вас сервер, то можете слинковать файл отозванных ключей. Но лучше скопировать. И эту операцию нужно повторять каждый раз при отзыве ключей.

$ sudo cp ~/CA/pki/crl.pem /etc/openvpn/keys

В /etc/openvpn/server.conf добавить строку

crl-verify /etc/openvpn/keys/crl.pem

Отзыв сертификата пользователя User

$ ./easyrsa revoke User

Каждый раз при отзыве сертификата необходимо обновлять crl.pem, чтобы внести в него изменения

$ ./easyrsa gen-crl

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

failed to update database  
Easy-RSA error:  
signing failed (openssl output above may have more detail)

Для исключения возможности mitm атаки, ошибка которого так выглядит в логах клиента как показано ниже служит параметр remote-cert-tls server в конфиге клиента.

WARNING: No server certificate verification method has been enabled. See http://openvpn.net/howto.html#mitm for more info.

Ссылки:

• https://wiki.archlinux.org/index.php/Create_a_Public_Key_Infrastructure_Using_the_easy-rsa_Scripts
• http://notessysadmin.com/quickstart-openvpn-server
• https://wiki.archlinux.org/index.php/OpenVPN

• OpenVPN: Настройка на собственном сервере. Часть 0 — подготовка системы.
• OpenVPN: Настройка на собственном сервере. Часть 1 — сертификаты.
• OpenVPN: Настройка на собственном сервере. Часть 2 — конфигурация сервера.
• OpenVPN: Настройка на собственном сервере. Часть 3 — iptables
• OpenVPN: Настройка на собственном сервере. Часть 4 — конфигурация клиента.

В этих туториалах я опишу как поднять собственный openvpn на vds/vps.

В качестве базовой системы рассматривается Fedora/RedHat/CentOS. Для других систем шаги будут несколько отличаться.

Для начала нам нужно подготовить сервер: поставить необходимые пакеты.

Управлять доступом мы будем через iptables, а не firewalld. Так же если ваш сервер не использует ipv6, то ip6tables вам не нужен.

Важно: ни в коем случае не отключайтесь от сервера до оконччания настройки iptables. Иначе доступ к серверу будет потерян.

$ sudo dnf install iptables-services openvpn easy-rsa  
$ sudo systemctl mask firewalld  
$ sudo systemctl enable iptables  
$ sudo systemctl enable ip6tables  
$ sudo systemctl restart iptables  
$ sudo systemctl restart ip6tables

После установки и запуска нужных сервисов необходимо разрешить доступ по ssh для новых подключений.

Вообще правила iptables изначально поставляются с возможностью доступа по ssh.

Для проверки можно заглянуть в /etc/sysconfig/iptables (и /etc/sysconfig/ip6tables для ipv6). Там будет строчка вроде

-A INPUT -p tcp -m state --state NEW -m tcp --dport 22 -j ACCEPT

Если она там есть, то проверьте с другого терминала, что доступ к ssh возможен.

Так же, если сервис висит на нестандартном порту, то стоит изменить номер порта в этих файлах.

Если же доступа к ssh нет, то нужно добавить его вручную

$ sudo iptables -I INPUT -p tcp -m state --state NEW -m tcp --dport 22 -j ACCEPT

и сохранить правила.

$ sudo /usr/libexec/iptables/iptables.init save

Дальше перезагружаем таблицы еще раз

$ sudo systemctl restart iptables  
$ sudo systemctl restart ip6tables

Проверяем с другого терминала тот факт, что доступ к ссх не пропал (или наоборот появился) и на этом предварительная настройка окончена.

Многие пользователи сталкиваются с тем, что за пределами kde или гнома у приложений qt пропадают иконки. Но это не единственная проблема.

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

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

Самый простой способ решить проблему - указать, из какого окружения нужно брать настройки - выставить переменную окружения XDG_CURRENT_DESKTOP в значение KDE или GNOME (а может быть XFCE - такое значение тоже возможно). Все зависит от того, каким de должен прикидываться ваш wm :)

Сходу мне не попалась спецификация по этой переменной окружения. Поэтому ссылок не вставляют.

Для своей конфигурации xmonad я прописал в .xinitrc

export XDG_CURRENT_DESKTOP=KDE

И все нормально работает. В приложениях qt появились значки, а libreoffice пропали лаги отрисовки.

Статья дополнена 2022-03-08

Не секрет, что для новичков в никсах существует лишь один путь для выбора приложения, которым будет открываться какой-либо тип файлов: конфигуратор его рабочей среды (кеды, гном, xfce или иное).
Однако то, что происходит за кадром пользователю остается неизвесным. И как только юный падаван попадает в голые иксы с запущенным xterm или голым, но от этого не менее дружелюбным, оконным менеджером (openbox, fluxbox, xmonad и т.д.) - у него сразу возникает куча проблема.

• почему все мои файловые ассоциации, которые я так долго настраивал исчезли?
• Почему в mc все картинки и видео вдруг начинают открываться в браузере?
• почему они вообще открываются через mc?
• почему firefox при выборе пункта “открывать файл” вместо сохранить открываеть его непонятно где или вообще не открывает?

И новичок это гиблое дело забрасывает и возвращается в удобные кеды, гном или что-то еще.

Но на самом деле не все так страшно.

Современные стандарты freedesktop указывают нам на то, что запуск приложений осуществляется с помощью *.desktop файлов, которые описывают все, что необходимо для работы приложения.

А чтобы связать тип файла с приложением, которое будет запускаться введен стандарт Association between MIME types and applications.

Этот стандарт описывает ряд файлов, которые отвечают за связь меджу типом файла и приложением.

Таблица описывает файлы в том порядке, в котором они обрабатываются системой. Переменная $desktop представляет из себя имя рабочего стола в нижнем регистре (kde, gnome, xfce, …).

Данные файлы представляют из себя набор записей вида

[Default Applications]  
mimetype1=default1.desktop;default2.desktop

mimetype - описание формата. Что-то вроде audio/ogg. Стандарт описания mimetype можно глянуть в соответствующих RFC.
*.desktop есть файл запуска вашего приложения. Обрабатывается список файлов последовательно до первого встреченного существующего приложения. Либо система перейдет к обработке следующего файла.

Помимо основной секции стандарт оговаривает две дополнительных секции.

[Added Associations]  
mimetype1=foo1.desktop;foo2.desktop;foo3.desktop  
mimetype2=foo4.desktop  
[Removed Associations]  
mimetype1=foo5.desktop  

Секция “added associations” добавляет к выбранным mime-типам указанные приложения в начало списка. Секция “removed association” соотственно удаляет указанные приложения из ассоциации к выбранному mime-типу.

Все. с теорией покончено.

Как было сказано выше - в “дружелюбном окружении уже существует какая-нибудь утилита, которая позволяет пользователю изменить ассоциации.

Но гораздо проще делать это в консоли.

Существует инструмент под названием xdg, который как раз отвечает за работу со списками ассоциаций. И большинство приложений как раз используют его api дабы открывать файлы (mc, nautilus, firefox, …).

Попробуем сделать в консоли

$ xdg-open ~/some_path_to_image.jpg

Вы увидите, что картинка откроется при помощи стандартного вьювера для вашего рабочего стола.

А теперь попробуйте сделать

$ xdg-mime query default image/jpg

Вы увидите что-то вроде

eog.desktop;

xdg-mime - инструмент, который входит в комплект поставки любого дистрибутива. Им можно как просматривать, так и изменять ассоциации файлов.

Для примера узнаем, как система распознает какую-нибудь картинку.

% xdg-mime query filetype wallpaper.jpg

Увидим

image/jpeg

Shared MIME database

Это спецификация, которая позволяет приложениям легче прописывать в систему информацию о том, какими расширениями файлов они могут манипулирвать.

Для целей статьи это неинтересно, но почитать можно тут.

Как работает привязка файлов в ручном режиме

Посмотрим, что происходит под капотом. Сейчас это не самый лучший способ. О более простом варианте речь пойдет чуть дальше.

Допустим, что у нас свежезаведенный профиль.

$ cat ~/.local/share/applications/mimeapps.list  
[Default Applications]  

У вас этого файла может не быть, либо он может содержать какие-то дефолтные значения.

А теперь мы хотим, чтобы файлы mp4 открывались при помощи vlc.

$ xdg-mime default vlc.desktop video/mp4  
$ cat ~/.local/share/applications/mimeapps.list

[Default Applications]  
video/mp4=vlc.desktop

Как видим - используется vlc. И если мы попробуем сделать

$ xdg-open path_to_mp4_file.mp4

Файл откроется уже в vlc.

Автоматизированный способ привязки

Сначала нам нужно понять, какие приложения поддерживают нужный mime.

Каждый *.desktop-файл содержит записи mime-типов, которые он поддерживает.

$ cat /usr/share/applications/pcmanfm.desktop | grep -i mime
MimeType=inode/directory;

Теперь нам нужно лишь грепнуть все desktop чтобы найти, что нам надо.

Допустим, что нам хочется переопределить приложение для открытия папок. Найдем, кто их может открывать.

$ rgrep "inode/directory" /usr/share/applications
/usr/share/applications/mimeinfo.cache:inode/directory=org.gnome.baobab.desktop;pcmanfm.desktop;ranger.desktop;
/usr/share/applications/org.gnome.baobab.desktop:MimeType=inode/directory;
/usr/share/applications/mimeapps.list:inode/directory=org.gnome.Nautilus.desktop
/usr/share/applications/pcmanfm.desktop:MimeType=inode/directory;
/usr/share/applications/gnome-mimeapps.list:inode/directory=org.gnome.Nautilus.desktop
/usr/share/applications/ranger.desktop:MimeType=inode/directory;

Тут мы видим, что папками манипулируют ranger, baobab и pcmanfm.

Для привязки приложения и типа нам так же поможет xdg-mime.

xdg-mime default application mimetype(s)

$ xdg-mime default pcmanfm.desktop inode/directory

Тем самым мы связали тип inode/directory с приложением pcmanfm. Стоит заметить, что указывать путь до *.desktop не надо. Он будет разыскиваться по стандартным путям, которые мы обсудили выше.

Замечания

Искать кто может открыть какой-то файл долго и сложно. Можно воспользоваться утилитой lsdesktopf.

Литература:

• XDG MIME Applications
• https://wiki.archlinux.org/index.php/Default_applications
• https://wiki.archlinux.org/index.php/Desktop_entries

Сегодня столкнулся с совершенно с чудовищным по своей странности багом.

Есть код. Простейший.

$a = array('' => 'value');

$key = '';  
$falseKey = false;  
$falseKey = (string)$falseKey; // $falseKey === '' будет true

var_dump(isset($a[$key]));  
var_dump(isset($a[$falseKey]));

Вы думаете, что в обоих случаях код выведет true?
А вот и нет.

Существуют какие-то глюки в связке модуля пхп и апача, которые приводят к тому, что во втором случае код выдаст false.

Это не вылечилось перезагрузкой апача. Вылечилось лишь его полной остановкой и запуском.

Любопытно, что данный баг воспроизвелся лишь на одном сервере. На других абсолютно идентичных он не воспроизводился.

UPD (13.12.2015):
Таки “автором” этого глюка выступило расширение xdebug. К сожалению детального разбора проблемы я не осуществлял. Просто если вы встретились с неверным пониманием языком типов переменных, то смотрите в сторону xdebug.