Страницы

суббота, 12 мая 2018 г.

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

※※※

четверг, 10 мая 2018 г.

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


※※※

вторник, 8 мая 2018 г.

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 выйти, как уже доступна у облачного хостинга - вот это оперативность.
※※※


среда, 2 мая 2018 г.

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. Сломалась под тяжестью настроек.

※※※
 

вторник, 1 мая 2018 г.

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.
Такая схема, в туннелях и т.п.


※※※