Fedora Server 28. OpenVPN FAILURE. Отказ запуска через systemd

При настройке туннелей на VPS сервере Fedora Server 28, я столкнулся с неявными особенностями конфигурации.

1. Конфигурационный файл /etc/openvpn/server/server.conf

Ошибка вида:
systemd[1]: Failed to start OpenVPN service for server ...

Подготовленный конфигурационный файл надо сохранять в папку /etc/openvpn/server, под именем server.conf.
Это обеспечивает управление запуском и остановкой сервера OpenVPN посредством команды systemctl.

# systemctl enable openvpn-server@server.service
# systemctl start openvpn-server@server.service
# systemctl status openvpn-server@server.service

Все остальные трудности - это в конкретной конфигурации.

Примечание: В Ubuntu 18.04 LTS server - другое место конфигурационного файла - /etc/openvpn/server.conf

2. Для открытия доступа к VPN надо настроить Firewall

Просмотр некоторых сведений о Firewall.

# firewall-cmd --list-services | grep openvpn
# firewall-cmd --get-default-zone

Добавить службу openvpn в зону по умолчанию. На сервере, зоной по умолчанию является "FedoraServer"

# firewall-cmd --add-service=openvpn


Добавить возможность принимать openvpn-подключения по протоколу tcp, на стандартном порту 1194.

# firewall-cmd --permanent --service=openvpn --add-port 1194/tcp




Добавить возможность NAT
 
# firewall-cmd --permanent --add-masquerade
 
# firewall-cmd --reload

※※※

※

Fedora Workstation 28 systemd control. Под капотом операционки

Fedora Workstation уже давно использует систему инициализации Systemd. Это удобно, позволяет иметь единую входную точку управления - systemctl. Единый формат конфигурационных файлов (units).


Утилиты: systemctl, networkctl, journalctl

Конфигурация: /etc/systemd
Конфигурация сети: /etc/systemd/network


$ systemctl status

● red
    State: running
     Jobs: 0 queued
   Failed: 0 units
    Since: Thu 2018-05-10 20:43:56 MSK; 2h 59min left

Зелёное пятнышко слева свидетельствует что все запущенные модули (systemd units) работают и не выходят с кодом ошибки.

● red
    State: running
     Jobs: 0 queued
   Failed: 3 units
    Since: Thu 2018-05-10 20:43:56 MSK; 2h 59min left

Красное пятнышко слева свидетельствует, что у некоторых запущенных модулей произошли ошибки и требуется их исправить, чтобы опять всё зазеленело.
Failed - сообщает о количестве сломанного.


У меня, возникло красное пятнышко и я полез смотреть, что не так. Оказалось, что проблема с сервисом журналирования , проблема с аппаратным генератором случайных чисел (в AMD-процессоре отсутствует) и ещё с одним.

Чтобы посмотреть состояние конкретного сломанного модуля используется команда systemctl status конкретный.service

$ systemctl status abrt-xorg.service

 ● abrt-xorg.service - ABRT Xorg log watcher
   Loaded: loaded (/usr/lib/systemd/system/abrt-xorg.service; enabled; vendor preset: enabled)
   Active: active (running) since Thu 2018-05-10 17:43:58 MSK; 25min ago
 Main PID: 903 (abrt-dump-journ)
    Tasks: 1 (limit: 4915)
   Memory: 5.5M
   CGroup: /system.slice/abrt-xorg.service
           └─903 /usr/bin/abrt-dump-journal-xorg -fxtD

мая 10 17:43:58 red systemd[1]: Started ABRT Xorg log watcher.

Сейчас он уже исправлен, светит зелёным глазом, а светил красным и в его последних строчках лога был код выхода (EXIT CODE).
Из которых я и узнал, что проблема кроется в журналах.

Проверку системных журналов, выполнил:



$ journalctl --verify

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

С журналами, накопившимися за приличное время, я поступил так - посмотрел занимаемый объём (--disk-usage) очистил и ограничил их размер по времени 30 днями.

$ journalctl --disk-usage
Archived and active journals take up 40.0M in the file system.

$ sudo journalctl --vacuum-time=30days

Vacuuming done, freed 0B of archived journals from /var/log/journal/393e16c51f6....

После этого, перезапустил первый сервис, который падал из-за ошибок в журналах.

$ sudo systemctl restart abrt-xorg.service
$ systemctl status abrt-xorg.service

 ● abrt-xorg.service - ABRT Xorg log watcher
   Loaded: loaded (/usr/lib/systemd/system/abrt-xorg.service; enabled; vendor preset: enabled)
   Active: active (running) since Thu 2018-05-10 17:43:58 MSK; 25min ago
 Main PID: 903 (abrt-dump-journ)
    Tasks: 1 (limit: 4915)
   Memory: 5.5M
   CGroup: /system.slice/abrt-xorg.service
           └─903 /usr/bin/abrt-dump-journal-xorg -fxtD
Приступил затем к следующим сервисам - я их отключил, т.к. из-за аппаратуры, они не пригодны.

$ sudo systemctl disable конкретный.service

※※※

※

OpenVPN network troubleshoot. Сетевая точка отказа туннеля Ubuntu - Fedora

При подключении и настройки openvpn-сервера часто возникает проблема с подключением клиента.

Основные точки отказа - это проблемы с конфигурационными опциями, с сетевой подсистемой - включен firewall, недоступны ключи и сертификаты, несоответствие ключей и сертификатов серверу.

Проблема в сетевом подключении?

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

Подразумевается, что имеется доступ к серверу по протоколу SSH.

Server (Ubuntu 18.04 LTS):

Системный openvpn сервис должен быть выключен.
# systemctl stop openvpn@server

Генерация ключа:
# mkdir /etc/openvpn/keys
# openvpn --genkey --secret /etc/openvpn/keys/psk.key

Предварительно сгенерированный секретный ключ хранится на сервере в файле: /etc/openvpn/keys/psk.key
Серверный конец туннеля, будет иметь ip-адрес: 192.168.6.1
На сервере запускается тестовый openvpn с параметрами: 

# openvpn  --secret /etc/openvpn/keys/psk.key 0 --dev tun --local XXX.XX.XX.XX --ifconfig 192.168.6.1 192.168.6.2

XXX.XX.XXX.XX - внешний статически IP-адрес сервера.

Client (Fedora 28):

На клиенте надо получить с сервера общий секретный ключ командой scp.

$ scp -2  root@XXX.XX.XXX.XX:/etc/openvpn/keys/psk.key .

. - это текущий каталог, в котором будет лежать общий секретный ключ.
На клиенте запускается клиент и конфигурируется ip-адрес точки туннеля на стороне клиента.
Клиентский конец туннеля, будет иметь ip-адрес: 192.168.6.2

$ sudo openvpn  --secret psk.key 1 --dev tun --remote XXX.XX.XXX.XX --ifconfig 192.168.6.2 192.168.6.1
Обратить внимание на цифру после ключа: 0 - для сервера, 1 - для клиента. В принципе, их можно опустить.
sudo - нужно для формирования нового сетевого интерфейса tun0.
После установки связи, должны быть доступны по ping концы туннеля, как с клиента, так и сервера.
$ ping 192.168.6.1
PING 192.168.6.1 (192.168.6.1) 56(84) bytes of data.
64 bytes from 192.168.6.1: icmp_seq=1 ttl=64 time=159 ms
64 bytes from 192.168.6.1: icmp_seq=2 ttl=64 time=170 ms
64 bytes from 192.168.6.1: icmp_seq=3 ttl=64 time=162 ms
....

Поднятый туннельный интерфейс tun0:
$ ifconfig
tun0: flags=4305<UP,POINTOPOINT,RUNNING,NOARP,MULTICAST>  mtu 1500
inet 192.168.6.2  netmask 255.255.255.255  destination 192.168.6.1
Для расширенного понимания что происходит надо добавить разговорчивости серверу, опцией --verb 4

Проблема в аутентификации графического клиента Fedora NetManager OpenVPN?

Столкнулся с багом - нельзя использовать русские имена в папках, где храняться ключи openvpn.

Для просмотра журнала того, что происходит при соединении графического клиента OpenVPN NetManager в Fedora 28 используется команда journalctl:

$ journalctl -r -t nm-openvpn

мая 08 15:45:51 red nm-openvpn[26544]: Options error: Please correct these errors.
мая 08 15:45:51 red nm-openvpn[26544]: Options error: --key fails with '/home/gimmor/%D0%94%D0%BE%D0%BA%D1%83%D0%BC%D0%B5%D0%BD%D1%82%D1%8B/server/client1.key': No such file or directory
мая 08 15:45:51 red nm-openvpn[26544]: WARNING: cannot stat file '/home/gimmor/%D0%94%D0%BE%D0%BA%D1%83%D0%BC%D0%B5%D0%BD%D1%82%D1%8B/server/client1.key': No such file or directory
 мая 08 15:45:51 red nm-openvpn[26544]: Options error: --cert fails with '/home/gimmor/%D0%94%D0%BE%D0%BA%D1%83%D0%BC%D0%B5%D0%BD%D1%82%D1%8B/server/client1.crt
мая 08 15:45:51 red nm-openvpn[26544]: Options error: --ca fails with '/home/gimmor/%D0%94%D0%BE%D0%BA%D1%83%D0%BC%D0%B5%D0%BD%D1%82%D1%8B/server/authority.crt': No such file or directory
 мая 08 15:43:30 red nm-openvpn[26481]: Use --help for more information.
В консольном режиме, подключался, а в графическом - бага.


P.S. Не успела Ubuntu 18.04 LTS выйти, как уже доступна у облачного хостинга - вот это оперативность.

※※※

※

Fedora Workstation 27->28 upgrade fail. Сбой обновления

Ну что же, сегодня день был странный. Начал обновление операционной системы Fedora Workstation, с прежней 27-ой версии, на только что вышедшую 28-ю версию.
И как назло - сбой. После перезагрузки не смог попасть в рабочий стол.
Ладно, надо разбиратся, полез в консоль, после кнопки ресет.

Для загрузки в консоль надо установить runlevel 3, в параметрах загрузки GRUB2.


Обычно указывается в строке linux ...., в конце просто числом 3.

Загрузился в консоль. Вошёл. Нет нормального русского языка. Отображаются квадратики. Ладно. Это видимо вечная проблема. Пропустим.


1. Удаляю группу пакетов GNOME desktop environment.

$ sudo -s
# dnf group remove "GNOME desktop environment"

2. Перемещаю (переименовывая) папки конфигурации .local  и .config в домашней папке пользователя. Сохраняю, так как там все настройки всяких программ. Потом отдельно с каждой разберусь. Если несколько пользователей, соответственно несколько повторов пункта 2.

# mv -r /home/user/.local  /home/user/.local-old
# mv -r /home/user/.config /home/user/.config-old

# reboot

Любители экспериментов, могут попробывать без удаления настроек, но я не стал.

3. Также, после удаления среды GNOME (пункт 2) вход в консольный многопользователский режим с поддержкой сети (runlevel 3).

4. В принципе, после удаления, можно устанавливать. Требуется подключение к интернет-сети.
Обновляю пакеты, смотрю чтобы репозитории не глючили и пр.

# dnf update --refresh



5. Устанавливаю окружение Fedora Workstation (тоже группа пакетов).

# dnf group install "Fedora Workstation"

после успешной установки пакетов - перезагрузка.
# reboot

6. Опять попадаю в консоль. Но, зайдя под пользователем - доступен запуск командой startx.

$ startx

Попадаю на рабочий стол.
Говорит спасибо, что обновились. Пожалуйста.
Осматриваю потери. Фон поменялся. 

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


# systemctl enable gdm.service
 Created symlink /etc/systemd/system/display-manager.service → /usr/lib/systemd/system/gdm.service
# systemctl set-default graphical.target
# systemctl restart gdm.service 
# reboot


8. Заработало. Теперь перенос настроек программ, и по возможности их переустановка.

P.S. Много ребутов - это по старой привычке от Windows. Reboot - это святое, прочищает много настроек системы.

P.P.S. Последовательное обновление системы, с версии где-то 24 до 28. Сломалась под тяжестью настроек.

※※※

※

 

Mikrotik simple IPv6 ULA Unique local addresses. Простое правило планирования приватных сетей

Когда нет возможности нормально использовать глобальную сеть IPv6 - провайдер не предоставляет глобальные IPv6-префиксы, а поддержку и отладку сервисов на совместимость с IPv6 надо, то самое разумное (определённое стандартом rfc4193) использовать уникальные локальные адреса IPv6 - Unique local addresses (ULA).

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

В принципе, это можно не делать, но подтянуть свою домашнюю инфраструктуру к готовности к IPv6 уже надо бы. 2018 год на дворе.

Префикс ULA начинается с FD. FD00::/8. F - сразу становится понятно FICTION - фиктивый.

Итак, сложное - это генерация 56-битной части префикса ULA. Её 40-бит Global ID и 16-бит Subnet-ID.
Но для этого есть калькулятор, доступный в web: https://www.ultratools.com/tools/rangeGenerator

После нажатия кнопки GO, выдаётся несколько строк, которые можно сохранить в блокноте.

Prefix/L:  fd

Global ID:  2b96cddd52

Subnet ID:  f1ad

Combine/CID:  fd2b:96cd:dd52:f1ad::/64

IPv6 addresses:  fd2b:96cd:dd52:f1ad::/64:XXXX:XXXX:XXXX:XXXX

Start Range:  fd2b:96cd:dd52:f1ad:0:0:0:0

End Range:  fd2b:96cd:dd52:f1ad:ffff:ffff:ffff:ffff

No. of hosts:  18446744073709551616

Заметка, не об этом, а о том, как подключить их в Mikrotik.

Итак, Mikrotik RouterOS 6.40.1.

Идеальная последовательность настройки IPv6 в Mirkotik RouterOS у меня сложилась в несколько шагов.

1. GROUP. Сгруппировать подсети устройств. Обычно, все проводные и беспроводные клиенты подключены в один мост. Я же делаю несколько мостов и подсетей, а между ними маршруты и пр. Это вкладки bridge, interfaces.

2. GET ULAs. Далее понять, что для каждой подсети (группы устройств) нужен свой ipv6-префикс, сгенерированный на сайте. Выделен жёлтым: fd2b:96cd:dd52:f1ad::/64
Тут кроется ошибка многих российских провайдеров - считать роутер клиента - одним устройством с /64 префиксом. Ан нет. У клиента в роутере набилось несколько потребителей /64 префиксов.


3.  POOL. Начать настройку лучше всего, с занесения выделенных префиксов в разделе IPv6/Pool. Сколько подсетей, минимум столько и пулов. Полученное значение ipv6-префикса заносится в поле Prefix, длина остаётся - 64, тогда работает протокол автоконфигурации SLAAC.

4. ADDRESS. Добавить IPv6-адрес из пула, привязав его к каждому выбранному мосту. У меня мост (bridge) для проводных клиентов. мост для беспроводных и другие подсети (по функциям).

5. ADVERTISE. Разрекламировать с помошью встроенного агента RADVD на конкретных интерфейсах (мостах), в разделе IPv6/ND (Neighbor Discovery). Клиенты подключенные к мостам сразу получат адреса с этими префиксами.





Т.е. принцип, заложенный в web-интерфейс - это в начале всё подготовить, все данные, залезая вглубь вкладок, а затем настроить на главных вкладках конечно. Master-Slave.
Такая схема, в туннелях и т.п.

※※※

※