Ubuntu - telepacs.com.ua

Справочный материал о настройке NFS на сервере и подключении к нему виртуальных машин KVM.

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

На хосте устанавливается сервер NFS.

Настраиваем брандмауэр, чтобы открыть порт NFS-сервера 2049 для клиентов из виртуальной сети 192.168.122.0/24:

sudo ufw allow from 192.168.122.0./24 to any port nfs

Устанавливаем пакет NFS:

sudo apt update 
sudo apt install nfs-kernel-server

Создаем на хосте каталог, который предполагаем сделать доступным для виртуальных машин.

mkdir /home/pacs/dicomarchive

Для безопасности NFS преобразует любые операции root на клиенте в операции с учетными данными nobody:nogroup. В связи с этим, нам необходимо изменить владельца каталога для соответствия этим учетным данным.

sudo chown nobody:nogroup /home/pacs/dicomarchive

Открываем и редактируем файл /etc/exports:

sudo mcedit /etc/exports

Файл содержит комментарии, показывающие общую структуру каждой строки конфигурации. Синтаксис выглядит следующим образом:
directory_to_share client(share_option1,...,share_optionN)
Добавляем в него строчку:

/home/pacs/dicomarchive 192.168.122.0/24(rw,sync,no_root_squash,no_subtree_check)

Здесь /home/pacsadmin/dicomarchive - каталог, который мы "шарим" для всех виртуальных машин из сети 192.168.122.0/24 с такими опциями:
rw: эта опция дает клиенту доступ к чтению и записи на соответствующем томе. sync: эта опция принудительно заставляет NFS записывать изменения на диске, прежде чем отправлять ответ. В результате мы получаем более стабильную и согласованную среду, поскольку в ответе отражается фактическое состояние удаленного тома. Однако при этом снижается скорость операций с файлами. no_subtree_check: данная опция предотвращает проверку вложенного дерева, когда хост проверяет фактическую доступность файла в экспортированном дереве при каждом запросе. Это может вызвать много проблем в случае переименования файла, когда он открыт на клиентской системе. Проверку вложенного дерева в большинстве случаев лучше отключить. no_root_squash: по умолчанию NFS преобразует запросы удаленного пользователя root в запросы пользователя без привилегий на сервере. Это предназначено для обеспечения безопасности, чтобы пользователь root клиентской системы не мог использовать файловую систему хоста с правами root. Опция no_root_squash отключает такое поведение для определенных общих ресурсов.
После сохранения изменений закрываем файл и перезапускаем сервер:

sudo systemctl restart nfs-kernel-server

На клиентских машинах устанавливаем клиентский пакет NFS:

sudo apt install nfs-common

Создаем каталог для монтирования общего сетевого ресурса:

mkdir -p /home/dicom/archive

Монтируем:

sudo mount 192.168.122.1:/home/pacs/dicomarchive /home/dicom/archive

Если всё выполнено без ошибок, то можно убедиться, что сетевой ресурс промонтирован командой

df -h

Для того, чтобы сетевой диск монтировался автоматически при запуске виртуальной машины, создаем на ней два файла (имена файлов = название каталога в который монтируется NFS-шара, где вместо слеша — дефис) с таким содержимым.

sudo mcedit /etc/systemd/system/home-dicom-archive.mount

[Unit] 
Description=NFS 
Requires=network-online.target 
After=network-online.service
 [Mount] 
Where=/home/dicom/archive 
What=192.168.122.1:/home/pacs/dicomarchive 
Type=nfs 
[Install] 
WantedBy=remote-fs.target

sudo mcedit /etc/systemd/system/home-dicom-archive.automount

[Unit] 
Description=NFS 
Requires=network-online.target 
After=network-online.service 
[Automount] 
Where=/home/dicom/archive 
[Install] 
WantedBy=remote-fs.target

Сохраняем файлы. Включаем автозапуск:

sudo systemctl daemon-reload 
sudo systemctl enable home-dicom-archive.automount 
sudo systemctl enable home-dicom-archive.mount

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

Справочный материал по установке сервера OpenVPN на операционную систему Ubuntu Server 20.04

Настройка сети и брандмауэра

Здесь и далее предполагается, что на сервере установлен пакет коммандера mc с редактором mcedit.

В первую очередь разрешим нашему серверу пересылку пакетов на уровне ядра:

sudo mcedit /etc/sysctl.conf

Находим и раскоментируем следующий параметр:

net.ipv4.ip_forward=1

Сохраняем изменения, закрываем редактор. Затем применяем сделанные изменения:

sudo sysctl -p

Далее настроим брандмауэр для правильной маршрутизации и маскарадинга трафика.

Перед тем, как мы перейдём к добавлению правил брандмауэра, необходимо указать политику по умолчанию, если это не было сделано ранее. Какие действия будут применяться к пакетам, если они не подпадают под созданные правила ufw. Все входящие пакеты будем отклонять:

sudo ufw default deny incoming

А все исходящие разрешим:

sudo ufw default allow outgoing

Разрешаем подключения к нашему серверу по протоколу SSH:

sudo ufw allow 22

или

sudo ufw allow OpenSSH

Далее разрешим входящие соединения на порт OpenVPN, в нашей конфигурации это будет стандартный порт 1194 и протокол udp:

sudo ufw allow 1194/udp

В параметрах UFW разрешим пересылку пакетов по умолчанию

sudo mcedit /etc/default/ufw

Заменим строчку DEFAULT_FORWAD_POLICY="DROP" на DEFAULT_FORWAD_POLICY="ACCEPT"

Добавим правила маскарадинга в таблицу NAT, чтобы клиенты могли выходит в интернет используя наш сервер как шлюз по умолчанию:

sudo mcedit /etc/ufw/before.rules

Добавим после последнего знака «#» таблицу nat и правила к нашей openvpn сети (имеющиеся правила НЕ УДАЛЯТЬ), вместо eth0 нужно подставить название вашей сетевой карты. узнать можно выполнив команду ip route | grep default

*nat

:POSTROUTING ACCEPT [0:0]

-A POSTROUTING -s 10.188.0.0/24 -o enp0s3 -j MASQUERADE

COMMIT

Здесь 10.188.0.0/24 - адреса сети OpenVPN, которые мы зададим позже в файле конфигурации сервера, а enp0s3 - сетевой интерфейс нашего сервера, через который он общается с внешним миром.

Сохраняем и закрываем файл.

Запустим наш брандмауэр (возможно потребуется подтверждение запуска, нажать «y»):

sudo ufw enable

Настройка центра сертификации EasyRSA

Сервер и клиенты OpenVPN используют сертификаты для установления и соединений и шифрования трафика, поэтому нам потребуется собственный центр сертификации. В рекомендациях OpenVPN указано что центр сертификации должен находиться на отдельном физическом сервере, но мы установим его вместе с серером OpenVPN.

sudo apt install openvpn easy-rsasudo mkdir /etc/openvpn/easy-rsasudo cp -R /usr/share/easy-rsa /etc/openvpn/

cd /etc/openvpn/easy-rsa/

Создадим файл с настройками переменных:

sudo cp vars.example vars

Раскоментируем значения переменных, при желании их можно изменить, но нельзя оставлять незаполненными:

sudo mcedit vars

Начнем с опции EASYRSA_DN, она предусматривает два режима: упрощенный cn_only, при котором сертификат содержит только CN (имя того, кому выдан сертификат) и традиционный org, при котором заполняются все реквизиты организации. Для OpenVPN можно использовать любой режим. Мы установим традиционный:

set_var EASYRSA_DN "org"

Удалите знак «#» у следующих ключей и измените значения на свои:

set_var EASYRSA_REQ_COUNTRY «UA»

set_var EASYRSA_REQ_PROVINCE «Kharkov Region»

set_var EASYRSA_REQ_CITY «Kharkov»

set_var EASYRSA_REQ_ORG «Copyleft Certificate Co»

set_var EASYRSA_REQ_EMAIL «admin@example.net»

set_var EASYRSA_REQ_OU «My Organizational Unit

Заметьте, что если вы оставили cn_only, то редактировать вышеуказанные опции не имеет смысла.

Параметр EASYRSA_KEY_SIZE указывает размер ключа, на сегодняшний день безопасным считается размер начиная с 2048, если вы ставите на первое место безопасность, то можете увеличить его до 3072 или 4096. Если криптографическая стойкость не играет роли, например, туннель будет использован для доступа в интернет и предполагается использование слабых устройств, то можно уменьшить размер ключа до 1024.

Опции EASYRSA_CA_EXPIRE и EASYRSA_CERT_EXPIRE задают срок действия корневого сертификата CA и сертификатов пользователей (сервера и клиентов), их значения установлены в днях как 3650 (10 лет) и 1080 (5 лет), опция EASYRSA_CERT_RENEW задает количество дней до истечения сертификата, когда становится доступным его продление, по умолчанию это 30 дней. При необходимости вы можете изменить эти значения.

Сохраните и закройте файл.

Инициализируем центр сертификации:

sudo ./easyrsa init-pki

sudo ./easyrsa build-ca nopass

sudo ./easyrsa gen-dh

sudo openvpn --genkey --secret /etc/openvpn/easy-rsa/pki/ta.key

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

sudo ./easyrsa gen-crl

Будет создан файл ./pki/crl.pem

Настройка серверной части OpenVPN

Для создания сертификатов, которые будут использоваться сервером надо выполнить команду:sudo ./easyrsa build-server-full server nopassСкопируем сертификаты сервера и центра сертификации и ключи в каталог нашего OpenVPN сервера:

sudo cp ./pki/ca.crt /etc/openvpn/ca.crt
sudo cp ./pki/dh.pem /etc/openvpn/dh.pem
sudo cp ./pki/crl.pem /etc/openvpn/crl.pem
sudo cp ./pki/ta.key /etc/openvpn/ta.key
sudo cp ./pki/issued/server.crt /etc/openvpn/server.crt
sudo cp ./pki/private/server.key /etc/openvpn/server.key

Создадим конфигурационный файл нашего OpenVPN сервера:

sudo zcat /usr/share/doc/openvpn/examples/sample-config-files/server.conf.gz | sudo tee /etc/openvpn/server.conf

Редактируем файл конфигурации:

sudo mcedit /etc/openvpn/server.conf

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

ca /etc/openvpn/ca.crt
cert /etc/openvpn/server.crt
key /etc/openvpn/server.key # This file should be kept secret
dh /etc/openvpn/dh.pem

tls-auth /etc/openvpn/ta.key 0 # This file is secret

Задаём диапазон адресов для сети:

server 10.188.0.0 255.255.255.0

Убираем комментирование (точка с запятой) со строк и правим их при необходимости изменить пути:

topology subnet

client-to-client

client-config-dir /etc/openvpn/ccd

log /var/log/openvpn/openvpn.log

Если у на сервере присутствуют виртуальные машины, которые используют свою виртуальную сеть, например с адресами 192.168.122.0/24, то можно дать к ним доступ для клиентов ВПН-сети, прописав в конфигурации строку

push "route 192.168.122.0 255.255.255.0"

На этом настройки конфигурации закончены и можно запустить сервис OpenVPN:

sudo systemctl start openvpn@server

Проверяем, что сервер запустился. Смотрим список сетевых интерфейсов:

ip a

В списке должен появиться интерфейс tun0 с адресом сервера 10.188.0.1:

Если что-то пошло не так, то смотрим лог /var/log/openvpn/openvpn.log или статус сервиса. Например, в случае, показанном ниже, сервер не запустился из-за отсутствия каталога /etc/openvpn/ccd, который был указан в конфигурации сервера, как каталог клиентских конфигураций:

sudo systemctl status openvpn@server

После устранения этого недостатка всё пошло:

Создание сертификатов клиентов

Нужно перейти в каталог /etc/openvpn/easy-rsa/

cd /etc/openvpn/easy-rsa/

И выполнить команду:

sudo ./easyrsa build-client-full client_name nopass

Здесь client_name - имя сертификата и ключа клиента.

Если необходимо, чтобы клиент с именем client_name получал всегда статический адрес, например, 10.188.0.10, то в каталоге /etc/openvpn/ccd нужно создать файл с таким именем

sudo mcedit /etc/openvpn/ccd/client_name

В нем нужно прописать такую строку:

ifconfig-push 10.188.0.10 255.255.255.0

Это будет верно в случае, если ранее в конфигурационном файле сервера была раскомментирована строка topology subnet. Иначе вид строки должен быть таким:

ifconfig-push 10.188.0.10 10.188.0.9,

а диапазон присваиваемых адресов будет ограничен определенными сочетаниями пар адресов.

Для создания этой статьи использовались следующие материалы, спасибо их авторам:

https://komyounity.com/openvpn-ubuntu/

https://losst.ru/nastrojka-openvpn-v-ubuntu

https://losst.ru/nastrojka-ufw-ubuntu

Метка: Ubuntu

Установка NFS на Ubuntu Server 20.04 и подключение клиентов

Установка сервера OpenVPN на Ubuntu Server 20.04 и подключение клиентов на Windows

Настройка сети и брандмауэра

Настройка центра сертификации EasyRSA

Настройка серверной части OpenVPN

Создание сертификатов клиентов