HowTo, linux

OpenVPN: Настройка на собственном сервере. Часть 4 — конфигурация клиента.

 

 

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

В первой части было сказано, что клиенту потребуются следующие файлы ключей:

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

Скопируем их в отдельный каталог. Так же в этом каталоге создадим файл connect.ovpn следующего содержания:

client
dev tun
proto udp
remote X.X.X.X 1194
tls-client
ca "ca.crt"
tls-auth "ta.key" 1
cert "User.crt"
key "User.key"
remote-cert-tls server
comp-lzo
tun-mtu 1500
mssfix 1450
verb 3
nobind

Где X.X.X.X — это айпишник вашего сервера.

Передаем пять этих файлов пользователю и теперь на клиенте можно подключаться:

$ sudo openvpn connect.ovpn
HowTo, linux

OpenVPN: Настройка на собственном сервере. Часть 3 — iptables

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

Как сказали на одном из формумов: в сети есть множество руководств по iptables для openvpn, но ни одно из них не работает.

В продолжении еще одно 🙂

Разрешаем коннекты к серверу (в прошлый раз мы настроили дефолтный впн через udp. Поэтому здесь мы открываем только подключение udp.

iptables -I INPUT -i eth0 -m state --state NEW -p udp --dport 1194 -j ACCEPT

Обратите внимание, что нужно использовать модификатор -I, который добавит это правило первым к цепочке. Если же использовать -A как рекомендуют некоторые, то правило будет добавлено к цепочке последним. А как мы знаем — последним правилом в цепочке стоит reject. И это значит, что добавляй после него или не добавляй правила — ничего не заработает.

Кстати из-за подобной ошибки (способа добавления правила в цепочку можно порой у некоторых видеть такую ошибку:

TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
TLS Error: TLS handshake failed

Это как раз значит, что сервер не смог ответить на «рукопожатие». Т.е. порт заблокирован или где-то на пути к серверу не работает форвардинг пакетов.

Теперь разрешим интерфейсу tun коммуникацию с другими интерфейсами в системе.

iptables -I FORWARD -i tun+ -j ACCEPT
iptables -I FORWARD -i tun+ -o eth0 -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -I FORWARD -i eth0 -o tun+ -m state --state RELATED,ESTABLISHED -j ACCEPT

Включим nat (как вы помните из предыдущей части — сервер настроен в режиме роутера, а не моста — поэтому nat обязателен).

iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADE

В цепочке POSTROUTE чаще всего нет reject. Поэтому смело используем -A.

И последний шаг — разрешить исходящий трафик на tun-инмерфейсе.

iptables -A OUTPUT -o tun+ -j ACCEPT

Теперь самый важный шаг: проверить, что все заработало

$ sudo nmap -sU -p1194 X.X.X.X

Starting Nmap 7.00 ( https://nmap.org ) at 2016-01-24 21:33 MSK
Nmap scan report for X.X.X.X
Host is up (0.089s latency).
PORT     STATE         SERVICE
1194/udp open|filtered openvpn

Nmap done: 1 IP address (1 host up) scanned in 1.08 seconds

Если у вас похожий вывод — сохраняем правила iptables и генерируем клиентский конфиг в следующей части.

$ sudo /usr/libexec/iptables.init save

Ниже конфиг /etc/sysconfig/iptables, который я приведу для сравнения (если у вас что-то не заработало).

*nat
:PREROUTING ACCEPT [80:8210]
:INPUT ACCEPT [0:0]
:OUTPUT ACCEPT [24:11832]
:POSTROUTING ACCEPT [24:11832]
-A POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADE
COMMIT
*filter
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [66:10292]
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -p icmp -j ACCEPT
-A INPUT -i lo -j ACCEPT
-A INPUT -i eth0 -p udp -m state --state NEW -m udp --dport 1194 -j ACCEPT
-A INPUT -p tcp -m state --state NEW -m tcp --dport 22 -j ACCEPT
-A INPUT -i tun+ -j ACCEPT
-A INPUT -j REJECT --reject-with icmp-host-prohibited
-A FORWARD -i tun+ -j ACCEPT
-A FORWARD -i tun+ -o eth0 -m state --state RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -i eth0 -o tun+ -m state --state RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -j REJECT --reject-with icmp-host-prohibited
-A OUTPUT -o tun+ -j ACCEPT
COMMIT
HowTo, linux

OpenVPN: Настройка на собственном сервере. Часть 2 — конфигурация сервера.

 

 

Ключи сгенерировали. Теперь можно запускать сервер.

Обращаю внимание, что дальше речь пойдет о дефолтной настройке openvpn в режиме роутера. Это тот режим, когда вам нет необходимости интегрировать подключенных клиентов в локальную сеть.

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

Поддробнее про разные режимы работы можно почитать в официальной документации: https://community.openvpn.net/openvpn/wiki/BridgingAndRouting.

Копируем конфиг сервера

$ sudo cp /usr/share/doc/openvpn-*/sample/sample-config-files/server.conf /etc/openvpn

Теперь нужно отредактировать этот конфиг поправив следующие параметры

# пути к сертификатам ставим свои
ca /etc/openvpn/keys/ca.crt
cert /etc/openvpn/keys/vpn-server.crt
key /etc/openvpn/keys/vpn-server.key  # This file should be kept secret
dh /etc/openvpn/keys/dh.pem

# заставляем клиент направлять весь трафик через сервер (чтобы избежать всяких учечек днс-запросов)
push "redirect-gateway def1 bypass-dhcp"

# пропишем собственные dns
push "dhcp-option DNS 8.8.8.8"
push "dhcp-option DNS 8.8.4.4"

# защита от флуда
tls-auth /etc/openvpn/keys/ta.key 0 # This file is secret

# сразу после запуска у сервера будут отобраны рутовые права (безопасности больше)
user nobody
group nobody

Если есть желание — можно поправить порт.

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

$ sudo systemctl -f enable openvpn@server.service
$ sudo systemctl start openvpn@server.service
HowTo, linux

OpenVPN: Настройка на собственном сервере. Часть 1 — сертификаты.

 

 

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

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

  • Корневой сертификат (назовем его для простоты 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.

Ссылки:

HowTo, linux

OpenVPN: Настройка на собственном сервере. Часть 0 — подготовка системы.

 

 

В этих туториалах я опишу как поднять собственный 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

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

linux

XMonad, Qt и LibreOffice — проблемы рендеринга приложений

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

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

xmonad-qt_without_icons

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

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

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

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

export XDG_CURRENT_DESKTOP=KDE

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

xmonad-qt_without_icons_with_fix

 

linux

Linux: связываем приложение с типами файлов

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

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

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

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

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

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

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

Путь Предназначение
$HOME/.config/$desktop-mimeapps.list Пользовательские ассоциации. Специфичные для рабочего стола $desktop
$HOME/.config/mimeapps.list Пользовательские ассоциации (независимы от рабочего стола)
/etc/xdg/$desktop-mimeapps.list Глобальные ассоциации. Предоставляются администратором. специфичные для рабочего стола $desktop
/etc/xdg/mimeapps.list Глобальные ассоциации, предоставляемые админом и вендорами ПО.
$HOME/.local/share/applications/$desktop-mimeapps.list Глобальные системные ассоциации. Специфичны для рабочего стола $desktop. Запрещен к использованию. Будет удален в новых редакциях стандарта.
$HOME/.local/share/applications/mimeapps.list Глобальные системные ассоциации. Запрещен к использованию. Будет удален в новых редакциях стандарта.
/usr/local/share/applications/$desktop-mimeapps.list and
/usr/share/applications/$desktop-mimeapps.list
Набор ассоциаций, которые предоставляются мейнтейнерами дистрибутива. Специфичны для рабочего стола $desktop.
/usr/local/share/applications/mimeapps.list and
/usr/share/applications/mimeapps.list
Набор ассоциаций, которые предоставляются мейнтейнерами дистрибутива.

Таблица описывает файлы в том порядке, в котором они обрабатываются системой. Переменная $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

А теперь самое главное — привязываем приложения к своим типам файлов. И заодно посмотрим, что происходит под капотом.

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

$ 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.

Почитать:
https://wiki.archlinux.org/index.php/Default_applications
https://wiki.archlinux.org/index.php/Desktop_entries