Страницы

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


※※※

понедельник, 30 апреля 2018 г.

IPv6 over OpenVPN в VPS Ubuntu 16.04.3 LTS

Для сервера на Ubuntu 16.04.3 LTS, со статическим IP-адресом (ради чего и  затевалось) достаточно просто  настроить IPv6 адресацию, посредством автоматического туннеля 6to4.
Далее, можно выданные подсети IPv6 распространить на тунельное подключение OpenVPN.
Клиенты OpenVPN смогут получить маршрутизируемые IPv6 адреса и стать доступными из сети Интернет.
Таким образом, обойдя NAT/NAT/NAT в цепочке подключения к ip-сети в своём городе, можно получить подключение к настоящей сети Интернет.
Настоящая сеть Интернет, даёт возможность оставить дома включённый компьютер, дисковый массив или камеру, уехать на край света и беспроблемно получить доступ - будь то VNC, FTPS, webdav - да что угодно.

В российской мобильной индустрии уже начали предлагать доступ к IPv6. Некоторые провайдеры тоже обеспечивают выдачу клиенту желаемого, но не всегда так, как хотелось бы - пока экспериментируют, смотрят.
Стоп, а что-же я жду и не бегу за 4g модемом и подключением. А ну да, отсутствует конкурентное тарифное предложение.


Итак, единственная трудность для подключения автоматического туннеля ipv6 - это как раз преобразование статического IP-адреса в шестнадцатиричный вид, чтобы поместить его в ipv6-префикс.
Но для этого есть сервисная страница по адресу:  6to4.version6.ru

А дальше, в файл /etc/network/interfaces вносится определение туннеля, полученное по ссылке выше на основе IP-адреса сервера, вот так:


auto tun6to4
iface tun6to4 inet6 v4tunnel
    pre-up modprobe ipv6
    address 2002:XXXX:XXXX::1
        netmask 16
    gateway ::192.88.99.1
    endpoint any
    local XX.XXX.XX.XXX


# If you have set up an IPv6-capable firewall (and you should),
# it can be enabled by using an "up" rule, such as the example below.
#       up /usr/local/sbin/ipv6firewall.sh tun6to4


local XX.XXX.XX.XXX - это IPv4-адрес сервера.
2002: - это префикс для туннелей 6to4.
XXXX:XXXX - IPv4-адрес сервера, в шестнадцатиричном формате.

После этого, стартуертся интерфейс:

ifup tun6to4


Для клиентов OpenVPN делается правка (3 строчки) для поддержки IPv6 в туннеле:

# OpenVPN server KVM1
# Open Virtual Private Network server test configuration
# server: kvm1
# date: april 28, 2018

port 1194
proto tcp
dev tun

# Certificate Authority (CA) - public key
ca /etc/openvpn/authorities/authority.crt
# Certificate - public key of the server, signed with CA private key via request
cert /etc/openvpn/keys/testserver.crt
# Private key (key) - secret data, private key of server
key /etc/openvpn/keys/testserver.key

# Diffie Hellman parameters
# openssl dhparam -out dh2048.pem 2048

dh /etc/openvpn/keys/dh2048.pem

# IP-address of the server
local 81.177.6.229

keepalive 10 120

topology subnet
server 192.168.6.0 255.255.255.0
push "route 192.168.6.0 255.255.255.0"
push "redirect-gateway def1"

# IPv6 support
server-ipv6 2002:XXXX:XXXX:abcd::/64
push "route-ipv6 2000::/3"
push "dhcp-option DNS 2001:4860:4860::8888"


abcd - это префикс, выделенный (придуманный мной) для подсети клиентов openvpn.

Это пока не полная конфигурация openvpn на стороне сервера, т.к. там ещё много всяких фишек, которые можно применить для своих задач. Учебная конфигурация.

После получение IPv6-адресов, настольные компьютеры становятся беззащитными. Но они, пока ещё в разряде тех, кто никому не нужен.

Для каждого надо настроить защиту от подключений и пр.
Это позже.

Также замечу, что нужно настроить форвардинг пакетов (IPv4 и IPv6 в туннель. Маскарад и пр. правила netfilter.


P.S. Всё меньше и меньше мне нравится Mikrotik. Своей замшелостью и запутанностью интерфейса, неявными проблемами. Не могу пока настроить его в качестве openvpn-клиента к vps-серверу, так, чтобы и клиенты роутера получали доступ к настоящей сети Интернет. IPv4 режим работает, а IPv6 где-то засада.


P.P.S. Раньше я как-то обходился без сторонних собственных серверов, но теперь жизнь заставляет, поэтому просьба о финансовой поддержке добавлена справа вверху. Я конечно не ожидаю сюрпризов, но рубль к рублику - сервер будет жить.

※※※

суббота, 28 апреля 2018 г.

OpenVPN certificates. Подготовка ключей и сертификатов туннеля для Ubuntu 16.04.3 LTS

В учебных целях исследования openvpn сервиса был запущен выделенный сервер у хостинг-провайдера. Был установлен сервис OpenVPN для исследования возможностей туннелей.

Место хранения сертификатов и ключей на виртуальном сервере

Нужно определить где на виртуальном частном сервере будут хранится
ключи.
Здесь существует дыра в безопасности, т.к. поставщик
виртуального частного сервера может иметь доступ к приватному, закрытому ключу сервера.
Поставщик всегда имеет доступ уровня root. Это часто прямо написано в
пользовательском соглашении. Там же написано и об юридической ответственности пользователя за всё.

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

Пусть авторитетные сертификаты будут лежать в папке /etc/openvpn/authorities
Пусть приватный и публичный ключ (сертификат) сервера будут лежать в папке /etc/openvpn/keys

mkdir /etc/openvpn/authorities
mkdir /etc/openvpn/keys

В принципе, виртуальный частный сервер надо условно считать частным.

Старая максима - "что знают двое, знает и свинья". В свете этой мудрости,
когда для преобразования сообщения используется два ключа... Мда...

Очень интересно, где та свинья, которая знает.

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

※※※

Частный удостоверяющий центр Certificate Authority (CA)


Минимально, частный удостоверяющий центр сводится к двум файлам - частному (секретному) ключу и общественному (открытому) самоподписанному сертификату частного удостоверяющего центра.

Местом хранения данных частного удостоверяющего центра (CA) можно выбрать usb-накопитель и хранить его в труднодоступном месте, после использования.

Генерация ключа и самоподписанного сертификата (genrsa) собственного удостоверяющего центра, на 10 дней (под root-пользователем):

openssl genrsa -out authority.key 4096
openssl req -x509 -new -key authority.key -days 10 -out authority.crt

Для шифрования (шифром -idea) частного ключа собственного удостоверяющего центра и неинтерактивной генерации:
openssl genrsa -idea -out authority.key 4096
openssl req -x509 -new -key authority.key -days 10 -out authority.crt -subj '/C=RU/ST=SPBFC/L=SPB/CN=Private Authority'
Возможна утечка персональных данных, через сертификат собственного удостоверяющего центра.

Для большей анонимности можно опустить заполнение полей опции -subj. Кто выпустил, зачем выпустил?
Не надо упрощать работу читателю сертификатов. Цифры. Только цифры и ничего более.
Каждый день отсрочки - ценен.

Генерация SSL-ключей сервера и клиентов


Для подписи публичных ключей openvpn-сервера и openvpn-клиента,
надо сформировать 2 запроса на подпись (CSR).
Один с использованием частного ключа сервера, второй с использованием частного ключа клиента.
В примере 3 запроса.

Запрос на подпись (CSR) передаваемый в частный удостоверяющий центр, содержит оттрытый публичный ключ запрашивающего.

Генерация незашифрованных закрытых ключей (genrsa) сервера и клиентов:

openssl genrsa -out testserver.key 2048
openssl genrsa -out client1.key 2048
openssl genrsa -out client2.key 2048

или
Генерация шифрованных (-des -des3 -idea) закрытых ключей (genrsa) сервера и клиентов:
openssl genrsa -idea -out testserver.key 2048
openssl genrsa -idea -out client1.key 2048
openssl genrsa -idea -out client2.key 2048


Генерация запросов на подпись (CSR) для сервера и клиентов (команда req):
Дабы избежать интерактивности при генерации используется опция -subj
Одновременно, в файлы сертификатов сохраняются и открытые ключи. Каждая команда одной строкой:

openssl req -new -key testserver.key -out testserver.csr -subj '/C=RU/ST=SPBFC/L=SPB/CN=mytestserver.ru/emailAddress=admin@mytestserver.ru'

openssl req -new -key client1.key -out client1.csr -subj '/C=RU/ST=SPBFC/L=SPB/CN=test.client1.ru'

openssl req -new -key client2.key -out client2.csr -subj '/C=RU/ST=SPBFC/L=SPB/CN=test.client2.ru'
mytestserver.ru - это доменное имя, тут нужно указать то, которое привязано к серверу.
Подписываение запросов на подпись (CSR) и создание подписанных сертификатов (команда x509), на их основе, выполняется в частном удостоверяющем центре - в выделенной папке usb-накопителя, желательно отдельного компьютера. Для пущей безопасности можно выбрать специальное аппаратное устройство хранения ключей и сертификатов. Также можно использовать TPM-модуль в компьютере. 

openssl x509 -req -in testserver.csr -CA authority.crt -CAkey authority.key -CAcreateserial -out testserver.crt -days 10

openssl x509 -req -in client1.csr -CA authority.crt -CAkey authority.key -CAcreateserial -out client1.crt -days 10

openssl x509 -req -in client2.csr -CA authority.crt -CAkey authority.key -CAcreateserial -out client2.crt -days 10


Дополнительный секретный ключ TLS и настройка для OpenVPN

Сгенерировать специальные параметры алгоритма:
openssl dhparam -out dh2048.pem 2048

Сгенерировать специальный общий закрытый ключ (pre-shared key) для TLS надо на сервере.

root@testserver# openvpn --genkey --secret psk.key

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

Распространение ключей OpenVPN


Итак, после всего этого нам нужны файлы, которые мы раскладываем по папкам:

В папку удостоверяющего центра на флешке и храним в сейфе:
authority.key
authority.crt


В папки на сервере /etc/openvpn/authorities:
authority.crt

В папки на сервере /etc/openvpn/keys
testserver.key
testserver.crt
dh2048.pem

psk.key

В папку на клиенте №1:
authority.crt
testserver.crt
client1.key
client1.crt

psk.key
 
В папку на клиенте №2:
authority.crt
testserver.crt
client2.crt
client2.key

psk.key
 
Также в папке частного удостоверяющего центра (CA) можно завести журнал, в виде текстового файла, в который записывать что и когда было сделано.  Это поможет освежить историю, спустя 10 лет.
※※※

Фишки для удобства OpenVPN


Генерирование и вывод в один файл частного и общественного ключей, без шифрования:
openssl req \
-x509 -nodes -days 10 -sha256 \
-newkey rsa:2048 -keyout test.pem -out test.pem


Упаковка частного ключа и сертификата сервера, а также сертификата удостоверяющего частного центра в контейнер формата pkcs12:

openssl pkcs12 -aes256 -export -in  testserver.crt -inkey testserver.key -certfile authority.crt -name "PKCS12" -out testserver.p12
При этом, опция в настройках OpenVPN указывает на один файл-контейнер pkcs12.
pkcs12 /etc/openvpn/keys/testserver.p12
Удобно, вместо 3 файлов оперировать одним.


Копирование файла на сервер по протоколу scp:

scp -2  authority.crt root@XX.XXX.X.XXX:/etc/openvpn/authorities/authority.crt
scp -2 testserver.key root@XX.XXX.X.XXX:/etc/openvpn/keys/testserver.key
scp -2 testserver.crt root@XX.XXX.X.XXX:/etc/openvpn/keys/testserver.crt

Копирование файла с сервера на клиент по scp:

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

- точка в конце - это текущий каталог где лежат клиентские все ключи

※※※

Простейшая тестовая настройка на стороне сервера OpenVPN


Простейшая тестовая настройка сервера OpenVPN даёт возможность проверить соединение сервера и клиента, убрав лишние конфигурационные настройки, которые часто ухудшают поиск причин падения туннеля.
Приведённая настройка не даёт доступа к интернету, т.к. надо настроить маршруты и пр. Отваливается по таймауту. Нет IPv6.
Это позже.
Содержимое файла: /etc/openvpn/home.conf
Его надо сформировать в редакторе nano.


# OpenVPN server KVM1
# Open Virtual Private Network server configuration
# server: kvm1
# date: april 28, 2018

port 1194
proto udp
dev tun

# Certificate Authority (CA) - public key
ca /etc/openvpn/authorities/authority.crt
# Certificate - public key of the server, signed with CA private key via request
cert /etc/openvpn/keys/testserver.crt
# Private key (key) - secret data, private key of server
key /etc/openvpn/keys/testserver.key

# Diffie Hellman parameters
# openssl dhparam -out dh2048.pem 2048

dh /etc/openvpn/keys/dh2048.pem

topology subnet
server 192.168.6.0 255.255.255.0


Или кратко, без комментариев:

port 1194
proto udp
dev tun
ca /etc/openvpn/authorities/authority.crt
cert /etc/openvpn/keys/testserver.crt
key /etc/openvpn/keys/testserver.key
dh /etc/openvpn/keys/dh2048.pem
topology subnet
server 192.168.6.0 255.255.255.0

Для проверки запуска сервиса OpenVPN надо зайти по SSH на сервер
и запустить сервис OpenVPN:

openvpn --config  /etc/openvpn/home.conf


При этом на клиенте надо установить BC-CBC, SHA1, в настройках графического клиента, т.к. это включено на сервере по-умолчанию.
※※※

Ресурсы




※※※

Свежий OpenVPN на Ubuntu 16.04 LTS Xenial

Для поднятия тестового VPN сервера для интрасети, нужно приобрести VPS-сервер KVM у поставщика, а затем установить свежую версию OpenVPN из официального репозитория OpenVPN.
Это даст возможность, при обнаружении некоторых проблем безопасности с openvpn, получить обновления openvpn-сервера от производителя.

Подключение сторонних репозиториев стандартно (под учётной записью root):
1. Получение подписи репозитория и внесение его в apt.
wget -O - https://swupdate.openvpn.net/repos/repo-public.gpg|apt-key add -
2. Сформировать указание для пакетного менеджера apt на репозиторий openvpn
echo "deb http://build.openvpn.net/debian/openvpn/release/2.4 xenial main" > /etc/apt/sources.list.d/openvpn-aptrepo.list

Теперь надо обновить список пакетов и установить OpenVPN 2.4:
3.Обновляем список пакетов
apt-get update
4. Установить пакет openvpn
apt-get install openvpn

Там может встретиться проблема с подписью, но у меня не встретилась, а если встретилась, то смотреть по ссылке [1].


Конфигурационный файл OpenVPN: /etc/openvpn/server.conf
Специфическое конфигурирование OpenVPN, позже.

※※※

Ресурсы


1. https://community.openvpn.net/openvpn/wiki/OpenvpnSoftwareRepos

 ※※※
 ※

пятница, 27 апреля 2018 г.

The People’s Communication Charter note. О непредоставлении доступа в сеть Интернет

Мне не предоставляют доступ в сеть Интернет, а именно, не выделяют корректный IP-адрес из диапазона IPv4.
Мне не предоставляют доступ в сеть Интернет, а именно, не выделяют корректный IP-адрес из диапазона IPv6.

Мне предоставляют доступ в некую телекоммуникационную сеть, построенную по образцу ip-сети.
Мне выделяют каждый раз разный ip-адрес.

И это уже давно.
Из-за этого всё трудности с Linux и с прогрессом в области телекоммуникаций на территории г. Санкт-Петербурга.

Итого, полное нарушение права человека на свободу ассоциаций и союзов.

Ну а про цифровые права, расширяющие обычные права человека, можно глянуть и осознать в The People’s Communication Charter.

Ресурсы:

http://www.waag.org/pcc


воскресенье, 22 апреля 2018 г.

RIPE database query

Существует такой ресурс в ipv4-сети, как RIPE database. RIPE https://www.ripe.net/ - сетевой координационный центр (RIPE NCC). Эта организация наблюдает за куском сети Интернет куда входит Европа и пока ещё другая территория.
Полезность её в том, что это база данных, во-первых, - актуальная база-данных, во-вторых,  - уникальная актуальная база данных ip-сетей, в-третьих, а других таких нету в открытом доступе, в-четвёртых.

Как база данных RIPE по сетям может быть полезна простым гражданам, страдающим от постоянных проблем с интернет-связью?

Итак, допустим есть web-ресурс, пользователи которого, постоянно мешают нормальному функционированию сервера.
Нужно сделать так, чтобы не мешали. Одно из решений - ограничить доступ к собственному серверу, со стороны некоторой подсети.
Порядок:
1. Определяем ip-адрес, web-ресурса. Для этого используем встроенную в Linux команду nslookup.
nslookup domain
где domain - доменное имя веб-ресурса.
В качестве ответа получим один или несколько ip-адресов.

2. Идём на сайт RIPE в раздел запросов к базе данных RIPE. https://apps.db.ripe.net/db-web-ui/#/query
и ищём по ip-адресам из первого пункта.

3. Анализируем ответы базы данных RIPE. Потерпевших пользователей интересует строки inetnum, netname, descr.
inetnum - это диапазон ip-адресов, выданных посети netname, с человеческим описанием descr.

4. Идём в интерфейс нашего сервера, роутера и чего-ещё-там-есть у обычного пользователя и вносим полученную подсеть (диапазон ip-адресов) в ip-фильтр входящих соединений. Устанавливаем правило отбрасывать все соединения исходящие из этой вредной подсети.

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

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