Страницы

понедельник, 1 января 2024 г.

Остановка процесса Niklaus Wirth

1 января 2024 года остановились базовые биологические процессы создателя семейства типизированных языков программирования Pascal, Modula, Oberon - профессора высшей технической школы Цюриха - Никлауса Вирта.

Niklaus Wirth/  Copyright by ETH

 

Сообщение о событии размещено на сайте Eidgenössische Technische Hochschule Zürich - https://ethz.ch/en/news-and-events/eth-news/news/2024/01/computer-pioneer-niklaus-wirth-has-died.html

 

К сожалению, на сайте высшей технической школы Цюриха перестали сохранять наследие профессора Никлауса Вирта. Удалены страницы относящиеся к его достижениям в области компьютерных наук, списаны в утиль модели его компьютеров.

А среди наследия Никлауса Вирта есть такие вещи как  Oberon system, с его TUI - текстовым пользовательским интерфейсом, объединяющим текст с исполняемыми объектами кода - посильнее Linux консоли.

Oberon system - прекрасная реализация идей профессора Вирта, недооценённых нынешним временем. Компактная однопользовательская операционная система написанная на одном языке высокого уровня Oberon. Язык, система, прикладное ПО - мощная концептуальная штука и всё на одном языке. Открытый исходный код, однако. Прекрасная идейная основа для современных персональных программных окружений, для микрокомпьютерных приложений (Oberon RISC). Небольшой размер кода позволяет охватить всю систему одним человеком и это её главное достоинство. Отличный инструмент любителей всё делать с нуля - то, что нужно подрастающему поколению инженеров.


Аминь.







 



 

 


четверг, 16 ноября 2023 г.

Настройка и использование 4G LTE модема Quectel EC25 на микросервере в режиме MBIM mode

Для подключения микросервера к сети Интернет по протоколу IPv6 можно воспользоваться особенностями подключения сотового провайдера MTS, выдающего клиентскому устройству (модему) динамические глобально доступные IPv6-адреса.

Клиентское устройство - модем Quectel EC25, в форме Mini-PCIe, подключенное через USB-mini-PCIe адаптер Kroks-Cse PCI. При подключении к микросерверу, создаёт символьное устройство /dev/cdc-wdm0 и 4 устройства /dev/ttyUSB0, /dev/ttyUSB1, /dev/ttyUSB2, /dev/ttyUSB3.

Выкопировка из вывода команды dmesg: 

[   25.713111] usbcore: registered new interface driver usbserial_generic
[   25.713136] usbserial: USB Serial support registered for generic
[   26.165617] usbcore: registered new interface driver cdc_wdm
[   26.175326] usbcore: registered new interface driver cdc_ether
[   26.184329] usbcore: registered new interface driver qmi_wwan
[   26.189100] usbcore: registered new interface driver cdc_ncm
[   26.225016] cdc_mbim 1-2:1.4: cdc-wdm0: USB WDM device
[   26.225389] cdc_mbim 1-2:1.4 wwan0: register 'cdc_mbim' at usb-0000:00:12.2-2, CDC MBIM, f1:f2:f3:f4:f5:f6
[   26.225540] usbcore: registered new interface driver cdc_mbim
[   26.282997] usbcore: registered new interface driver option
[   26.283023] usbserial: USB Serial support registered for GSM modem (1-port)
[   26.283123] option 1-2:1.0: GSM modem (1-port) converter detected
[   26.284695] usb 1-2: GSM modem (1-port) converter now attached to ttyUSB0
[   26.284793] option 1-2:1.1: GSM modem (1-port) converter detected
[   26.284924] usb 1-2: GSM modem (1-port) converter now attached to ttyUSB1
[   26.284987] option 1-2:1.2: GSM modem (1-port) converter detected
[   26.285092] usb 1-2: GSM modem (1-port) converter now attached to ttyUSB2
[   26.285151] option 1-2:1.3: GSM modem (1-port) converter detected
[   26.285236] usb 1-2: GSM modem (1-port) converter now attached to ttyUSB3

 

Драйвер (модуль ядра) cdc_mbim поддерживает USB устройства соответствующие спецификации “Universal Serial Bus Communications Class Subclass Specification for Mobile Broadband Interface Model”. Модем видимо был ранее сконфигурирован в режиме MBIM.

 

Выкопировка из вывода команды lsusb:

Bus 001 Device 002: ID 2c7c:0125 Quectel Wireless Solutions Co., Ltd. EC25 LTE modem


Также создаётся сетевой интерфейс с именем wwan0, не сконфигурированный.

Выкопировка из вывода команды ip addr:

3: wwan0: <BROADCAST,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UNKNOWN group default qlen 1000

Как пишется в ряде руководств - дальнейшее конфигурирование выполняется с помощью программ пользовательского окружения mbimcli, mbim-network.

Для их установки в систему микросервера, а это в моменте - Ubuntu 22.04 LTS на ядре linux 5.15.0-88-generic, выполняется установка следующего пакета - libmbim-utils.

apt-get install libmbim-utils


Конфигурирование настроек провайдера

Для команды mbim-network нужно создать и заполнить файл /etc/mbim-network.conf. В данном случае, для сотового провайдера MTS.

root@microserver:/# cat /etc/mbim-network.conf
APN=internet.mts.ru
APN_USER=mts
APN_PASS=mts
APN_AUTH=mschapv2
PROXY=yes


PROXY - чем-то важен, без него модем странно реагирует на команды.


Проверка первого подключения

Для начала, выполнив команду mbimcli --help-all, показывающую все доступные опции, можно растеряться, т.к. непонятно, в какой последовательности их надо выполнять. Эту головную боль снимает скрипт-команда mbim-network.

Для начала посмотрим что выдаёт команда --query-device-caps

--query-device-caps. Опция -p важна! (--device-open-proxy).

root@microserver:/home/macibuki# mbimcli --device /dev/cdc-wdm0 --device-open-proxy --query-device-caps

или

root@microserver:/# mbimcli -d /dev/cdc-wdm0 -p --query-device-caps
[/dev/cdc-wdm0] Device capabilities retrieved:
          Device type: 'remote'
       Cellular class: 'gsm'
          Voice class: 'no-voice'
            SIM class: 'removable'
           Data class: 'gprs, edge, umts, hsdpa, hsupa, lte'
             SMS caps: 'pdu-receive, pdu-send'
            Ctrl caps: 'reg-manual'
         Max sessions: '8'
    Custom data class: 'unknown'
            Device ID: '0000'
        Firmware info: 'EC25ECGAR06A09M1G'
        Hardware info: 'QUECTEL Mobile Broadband Modul'

 

Device ID - содержит чувствительную информацию и не приводится.

Что выдаёт команда --query-subscriber-ready-status.

root@microserver:/# mbimcli -d /dev/cdc-wdm0 -p --query-subscriber-ready-status
[/dev/cdc-wdm0] Subscriber ready status retrieved:
          Ready state: 'initialized'
        Subscriber ID: '000000000000000'
            SIM ICCID: '00000000000000000000'
           Ready info: 'none'
    Telephone numbers: (1) '+79100000000'


Вывод команды содержит чувствительную информацию по SIM-карте, абоненту, номеру телефона.


Важная проверка состояния радио, перед запуском mbim-network - команда --query-radio-state

root@microserver:/# mbimcli -d /dev/cdc-wdm0 -p --query-radio-state
[/dev/cdc-wdm0] Radio state retrieved:
         Hardware radio state: 'on'
         Software radio state: 'off'


Так и есть, обычно "Software radio state: Off" и тогда надо включить радио командой --set-radio-state=on

root@microserver:/# mbimcli -d /dev/cdc-wdm0 -p --set-radio-state=on
[/dev/cdc-wdm0] Radio state retrieved:
         Hardware radio state: 'on'
         Software radio state: 'on'


Проверка состояния PIN-кода:

root@microserver:/# mbimcli -d /dev/cdc-wdm0 -p   --query-pin-state
[/dev/cdc-wdm0] PIN info:
             PIN state: 'unlocked'

Если PIN-код в состоянии 'locked', то его можно ввести командой --enter-pin, отключить ввод PIN-кода командой --disable-pin (придётся ввести один раз).


Также можно посмотреть выводы команды --query-registration-state (состояние регистрации), --query-signal-state (состояние сигнала).

root@microserver:/# mbimcli -d /dev/cdc-wdm0 -p --query-registration-state
[/dev/cdc-wdm0] Registration status:
             Network error: 'none'
            Register state: 'home'
             Register mode: 'automatic'
    Available data classes: 'lte'
    Current cellular class: 'gsm'
               Provider ID: '25001'
             Provider name: 'MTS RUS'
              Roaming text: 'unknown'
        Registration flags: 'packet-service-automatic-attach'
root@microserver:/# mbimcli -d /dev/cdc-wdm0 -p --query-visible-providers
error: operation failed: Busy
root@microserver:/# mbimcli -d /dev/cdc-wdm0 -p --query-signal-state
[/dev/cdc-wdm0] Signal state:
              RSSI [0-31,99]: '11'
         Error rate [0-7,99]: '99'
    Signal strength interval: '5'
              RSSI threshold: '2'
        Error rate threshold: 'unspecified'
root@microserver:/#


Можно посмотреть состояние соединения (приведёно рабочее состояние):

root@microserver:/# mbimcli -d /dev/cdc-wdm0 -p  --query-connection-state
[/dev/cdc-wdm0] Connection status:
          Session ID: '0'
    Activation state: 'activated'
    Voice call state: 'none'
             IP type: 'ipv4v6'
        Context type: 'internet'
       Network error: 'none'

(не рабочее состояние):

[/dev/cdc-wdm0] Connection status:
          Session ID: '0'
    Activation state: 'deactivated'
    Voice call state: 'none'
             IP type: 'default'
        Context type: 'none'
       Network error: 'none'


Итак, пришло время запустить соединение командой mbim-network, если выводы команд ориентировочно похожи  на примеры в этой статье.

mbim-network /dev/cdc-wdm0 start

...

Если устройство определилось в системе, если включено радио, то по идее должно работать.

Посмотрим, для начала рабочее состояние, каким оно должно быть:

root@microserver:/# mbim-network /dev/cdc-wdm0 status
Loading profile at /etc/mbim-network.conf...
    APN: internet.mts.ru
    APN auth protocol: mschapv2
    APN user: mts
    APN password: mts
    mbim-proxy: yes
Getting status with 'mbimcli -d /dev/cdc-wdm0 --query-connection-state --device-open-proxy'...
Status: activated

 

Однако, если посмотреть ip addr, то можно продолжить смотреть на не настроенный интерфейс wwan0.

Присвоение IP-адресов сетевому интерфейсу wwan0

Важная особенность состоит в том, что даже получив работающее (activated) состояние на предыдущем этапе, надо получить у провайдера ip-адреса и настроить интерфейс wwan0 вручную или с помощью какого-либо скрипта.

Для соединений такого типа (mbim) не работает стандартный клиент dhcp - dhclient и ip-адреса получаются специфической командой --query-ip-configuration, которая выводит их просто в консоль, в текстовом виде, после чего их можно использовать для ручного конфигурирования командой ip.

root@microserver:/# mbimcli -d /dev/cdc-wdm0 -p --query-ip-configuration

[/dev/cdc-wdm0] IPv4 configuration available: 'address, gateway, dns, mtu'
     IP [0]: '10.191.000.00/30'
    Gateway: '10.191.000.01'
    DNS [0]: '213.87.142.84'
    DNS [1]: '213.87.142.85'
        MTU: '1500'

[/dev/cdc-wdm0] IPv6 configuration available: 'address, gateway, dns, mtu'
     IP [0]: '2a00:1fa0:000:0000:0000:0000:0000:0002/64'
    Gateway: '2a00:1fa0:000:000:0000:000:0000:0001'
    DNS [0]: '2a00:1fa0:3e00::1'
    DNS [1]: '2a00:1fa0:7e00::1'
        MTU: '1500'

Странно то, что при каждом запросе --query-ip-configuration возвращает новые адреса, особенно ipv6. Это не позволяет проверить текущую ip конфигурацию модема, что может привести и приводит к неработоспособности сети. Т.е. нельзя после установки соединения выполнять команду  --query-ip-configuration, т.к. модем будет иметь одну настройку ip, а интерфейс wwan0 другую, отличающуюся, старую.

Присвоение IPv4-адреса

Обычно, скрипт делает очистку адресов на конфигурируемом интерфейсе, перед новым присвоением.

root@microserver:/# ip addr flush dev wwan0

Взяв в строке IP [0]: адрес  с маской, выполним команду ip addr add ... и присвоим полученный ipv4-адрес интерфейсу wwan0.

root@microserver:/# ip addr add 10.191.000.02/30 dev wwan0 broadcast +


Присвоение IPv6-адреса

root@microserver:/# ip addr add 2a00:1fa0:000:0000:0000:0000:0000:0002/64 dev wwan0



Настройка маршрута по-умолчанию через шлюз (gateway), для сетевого интерфейса wwan0

Так как микросервер уже имеет маршрут по-умолчанию настроенный через сетевой интерфейс enp2s0, то надо удалить старый маршрут по-умолчанию (default) и добавить новый, но уже через сетевой интерфейс wwan0.

Вывод команды ip route до настройки нового маршрута:

root@microserver:/# ip route
default via 192.168.88.1 dev enp2s0
default via 192.168.88.1 dev enp2s0 proto dhcp src 192.168.88.3 metric 1024
192.168.88.0/24 dev enp2s0 proto kernel scope link src 192.168.88.3 metric 1024
192.168.88.1 dev enp2s0 proto dhcp scope link src 192.168.88.3 metric 1024

Удаление старого маршрута (можно удалить 2 раза):

root@microserver:/# ip route del default via 192.168.88.1 dev enp2s0


Добавление нового маршрута по-умолчанию:

root@microserver:/# ip route add default via 10.191.000.01 dev wwan0

 

root@microserver:/# ip route
default via 10.191.000.01 dev wwan0
10.191.000.02/30 dev wwan0 proto kernel scope link src 10.191.000.02
192.168.88.0/24 dev enp2s0 proto kernel scope link src 192.168.88.3 metric 1024
192.168.88.1 dev enp2s0 proto dhcp scope link src 192.168.88.3 metric 1024 

 

Настройка разрешения доменных имён с помощью команды resolvectl

Кое-что забыли, а именно добавить к интерфейсу wwan0 адреса DNS-серверов провайдера или иных публично открытых DNS-серверов.

Делается это с помощью команды resolvectl, которая входит в systemd-resolved.

Первоначальный запуск resolvectl показывает, что определение имён привязано к интерфейсу  enp2s0, а для wwan0 не настроено.

root@microserver:/# resolvectl status
Global
       Protocols: -LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
resolv.conf mode: foreign
      DNS Domain: home

Link 2 (enp2s0)
    Current Scopes: DNS
         Protocols: +DefaultRoute +LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
Current DNS Server: 192.168.88.1
       DNS Servers: 192.168.88.1
        DNS Domain: home

Link 3 (wwan0)
Current Scopes: none
     Protocols: -DefaultRoute +LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported

Добавим адрес DNS-сервера провайдера к интерфейс wwan0:

root@microserver:/# resolvectl dns wwan0 213.87.142.84

Что изменилось?

root@microserver:/# resolvectl status wwan0
Link 3 (wwan0)
Current Scopes: DNS
     Protocols: +DefaultRoute +LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
   DNS Servers: 213.87.142.84

 

Запросы на разрешение имён продолжают идти через интерфейс  enp2s0, т.к. он тоже помечен как +DefaultRoute.

root@microserver:/# resolvectl query google.com
google.com: 2a00:1450:4010:c02::8a             -- link: enp2s0
            2a00:1450:4010:c02::8b             -- link: enp2s0
            2a00:1450:4010:c02::64             -- link: enp2s0
            2a00:1450:4010:c02::66             -- link: enp2s0
            74.125.205.139                     -- link: enp2s0
            74.125.205.113                     -- link: enp2s0
            74.125.205.101                     -- link: enp2s0
            74.125.205.100                     -- link: enp2s0
            74.125.205.138                     -- link: enp2s0
            74.125.205.102                     -- link: enp2s0

-- Information acquired via protocol DNS in 26.2ms.
-- Data is authenticated: no; Data was acquired via local or encrypted transport: no
-- Data from: network

Отключаем у интерфейса enp2s0 опцию default-route (относящуюся именно к запросам DNS по-умолчанию).


root@microserver:/# resolvectl default-route enp2s0 no

Что изменилось?


root@microserver:/# resolvectl query google.com
google.com: 2a00:1450:4010:c02::8b             -- link: wwan0
            2a00:1450:4010:c02::66             -- link: wwan0
            2a00:1450:4010:c02::64             -- link: wwan0
            2a00:1450:4010:c02::8a             -- link: wwan0
            108.177.14.139                     -- link: wwan0
            108.177.14.101                     -- link: wwan0
            108.177.14.102                     -- link: wwan0
            108.177.14.138                     -- link: wwan0
            108.177.14.113                     -- link: wwan0
            108.177.14.100                     -- link: wwan0

-- Information acquired via protocol DNS in 173.8ms.
-- Data is authenticated: no; Data was acquired via local or encrypted transport: no
-- Data from: network

Запросы на разрешение имён стали просачиватся через интерфейс  wwan0.

Если повторно запросить разрешение имени google.com, то запрос возвратит ответ из dns-cache, об этом скажет строка "Data from: cache".  Кэш отключается опцией --cache=no.

Кэш всех dns-записей очищается командой - resolvectl flush-caches.

Есть полезная команда revert, чтобы восстановить настройки интерфейса enp2s0 (встроенная сетевая карта ethernet), после всех внесённых изменений скрипта или пользователя.

root@microserver:/# resolvectl revert enp2s0


Автоматизация настройки с помощью модифицированного скрипта mbim-set-ip

Скрипт mbim-set-ip содержит настройку dns с помощью команды systemd-resolve, которая не присутствует в поставке Ubuntu 22.04 LTS, поэтому настройка заменена на resolvectl, который присуствует как в Ubuntu 22.04 LTS так и Fedora 39.

Скрипт скачан с репозитория: https://github.com/elementzonline/GSMModem/tree/master/SIM7600/mbim-set-ip

Закоментировать (#) строки с systemd-resolve в скрипте mbim-set-ip:

# printf "systemd-resolve -4 --interface=$DEV --set-dns=%s\n" "${ipv4_dns[@]}" >>$execfile

и заменить их на resolvectl:

printf "resolvectl dns $DEV %s\n" "${ipv4_dns[@]}" >>$execfile

И для ipv6:

# printf "systemd-resolve -6 --interface=$DEV --set-dns=%s\n" "${ipv6_dns[@]}" >>$execfile

printf "resolvectl dns $DEV %s\n" "${ipv6_dns[@]}" >>$execfile

Скрипт mbim-set-ip не делает за администратора работу по настройки сетевого окружения при наличии нескольких интерфейсов. Идея заложенная в скрипт mbim-set-ip предполагает, что LTE-модем является единственным выходом в Интернет.

В приципе, для своих целей и своего микросервера, скрипт mbim-set-ip можно упростить.

Автоматизация подключения с помощью собственного скрипта systemd

Цель - получить управление модемным подключением посредством systemd, т.к. на микросервере только консольный текстовый режим.

Интерфейс пользователя (администратора) будет содержать несколько стандартных команд (enable, start, status, stop, restart, disable).

systemctl enable modem4.service

systemctl start modem4.service

systemctl status modem4.service

systemctl stop modem4.service

systemctl restart modem4.service

systemctl disable modem4.service

enable, disable - включает подключение таким образом, что при нормальной загрузке устанавливается подключение к IPv6-сети.

start,stop - позволяет управлять состоянием подключения, при наличии ещё одного подключения к микросерверу.

status -  отображает состояние подключения, в том числе ip-адреса и прочее.

Согласно Filesystem Hierarchy Standard (FHS), администратор может расположить свои собственные скрипты (modem4.sh) и команды как в домашней директории, так и в общей системе, например /opt, настройки в /etc/opt и т.п.

Файл описания сервиса modem4.service разумно расположить в /etc/systemd/system

При выполнении команды enable - скрипт modem4 должен проверить наличие установленных утилит mbimcli и библиотек, проверить наличие в системе модема, по его PID-VID, возможно по серийному номеру, наличие символьного устройства (/dev/cdc-wdm0) и т.п.

Проверка наличия установленной поддержки MBIM:

root@microserver:/# apt list libmbim*
Вывод списка… Готово
libmbim-glib-dev/jammy-updates 1.28.0-1~ubuntu20.04.1 amd64
libmbim-glib-dev/jammy-updates 1.28.0-1~ubuntu20.04.1 i386
libmbim-glib-doc/jammy-updates,jammy-updates 1.28.0-1~ubuntu20.04.1 all
libmbim-glib4/jammy-updates,now 1.28.0-1~ubuntu20.04.1 amd64 [установлен, автоматически]
libmbim-glib4/jammy-updates 1.28.0-1~ubuntu20.04.1 i386
libmbim-proxy/jammy-updates,now 1.28.0-1~ubuntu20.04.1 amd64 [установлен, автоматически]
libmbim-proxy/jammy-updates 1.28.0-1~ubuntu20.04.1 i386
libmbim-utils/jammy-updates,now 1.28.0-1~ubuntu20.04.1 amd64 [установлен]
libmbim-utils/jammy-updates 1.28.0-1~ubuntu20.04.1 i386

 

Проверка наличия установленной поддержки QMI (Qualcomm MSM Interface):

root@microserver:/# apt-cache search libqmi
libqmi-glib5 - библиотека работы с протоколом Qualcomm MSM Interface (QMI)
libqmi-proxy - прокси для работы с QMI-портами
gir1.2-qmi-1.0 - GObject introspection data for libqmi-glib
libqmi-glib-dev - Header files for adding QMI support to applications that use glib
libqmi-glib-doc - API documentation for libqmi-glib
libqmi-utils - Utilities to use the QMI protocol from the command line

 

root@microserver:/# apt list libqmi*
Вывод списка… Готово
libqmi-glib-dev/jammy-updates 1.32.0-1ubuntu0.22.04.1 amd64
libqmi-glib-dev/jammy-updates 1.32.0-1ubuntu0.22.04.1 i386
libqmi-glib-doc/jammy-updates,jammy-updates 1.32.0-1ubuntu0.22.04.1 all
libqmi-glib5/jammy-updates 1.32.0-1ubuntu0.22.04.1 amd64
libqmi-glib5/jammy-updates 1.32.0-1ubuntu0.22.04.1 i386
libqmi-proxy/jammy-updates 1.32.0-1ubuntu0.22.04.1 amd64
libqmi-proxy/jammy-updates 1.32.0-1ubuntu0.22.04.1 i386
libqmi-utils/jammy-updates 1.32.0-1ubuntu0.22.04.1 amd64
libqmi-utils/jammy-updates 1.32.0-1ubuntu0.22.04.1 i386


Проверка наличия подключения модема конкретного типа, такого как Quectel EC25:

root@microserver:/# lsusb | grep "ID 2c7c:0125"
Bus 001 Device 002: ID 2c7c:0125 Quectel Wireless Solutions Co., Ltd. EC25 LTE modem

root@microserver:/# lsusb -d 2c7c:0125
Bus 001 Device 002: ID 2c7c:0125 Quectel Wireless Solutions Co., Ltd. EC25 LTE modem

root@microserver:/# echo $?

lsusb -d 2c7c:0125 возвращает 0 при наличии устройства с VID=2c7c и PID = 0125 и 1 при отсутствии указанного устройства.

 

Проверка наличия символьного устройства (/dev/cdc-wdm0) из командной строки:

root@microserver:/# if [ -c "/dev/cdc-wdm0" ]; then echo "True"; else echo "False"; fi

True

Проверка драйвера привязанного к символьному устройству /dev/cdc-wdm0:

cdc_mbim - драйвер (модуль ядра) поддерживающий протокол MBIM (Mobile Broadband Interface Model) для сотового модема.

qmi_wwan - драйвер (модуль ядра) поддерживающий протокол QMI (Qualcomm MSM interface) для сотового модема.

root@microserver:/# basename $(realpath /sys/class/usbmisc/cdc-wdm0/device/driver)
cdc_mbim

В данном случае, MBIM режим сотового модема.

Также можно подключиться в специальный порт /dev/ttyUSB2 предназначенный для AT-команд и запросить текущую конфигурацию протокола. Подразумевается, что в системе нет других устройств, захвативших /dev/ttyUSB2 и этот порт привязан к модему. Потребуется команда minicom (apt-get install minicom).

root@microserver:/# minicom -D /dev/ttyUSB2

AT
OK
AT+QCFG="usbnet"
+QCFG: "usbnet",2

OK

+QCFG: "usbnet",2 - подразумевает, что используется MBIM протокол.

+QCFG: "usbnet",1 - подразумевает, что используется ECM протокол.

+QCFG: "usbnet",0 - подразумевает, что используется QMI протокол.


Сам сервисный файл modem4.service (его надо создать в папке /etc/systemd/system) достаточно прост - всю работу делают скрипты startmodem4.sh и stopmodem4.sh

 

root@microserver:/etc/systemd/system# cat modem4.service
[Unit]
Description=LTE Module preparation and configuration
Documentation=man:microserver
After=network.target
Before=network-online.target

[Service]
Type=oneshot
ExecStart=/home/gimmor/startmodem4.sh
ExecStop=/home/gimmor/stopmodem4.sh
RemainAfterExit=yes
 

[Install]
WantedBy=network.target

Из особенностей, для того чтобы наблюдать красивый зелёный сигнал при выводе systemctl status modem4, используется опция RemainAfterExit=yes
 
startmodem4.sh - что-то такое, как например:
 
root@microserver:/home/gimmor# cat startmodem4.sh
#!/bin/bash
# сервер: microserver.local
# 16 ноября 2023 года
# startmodem4.sh - скрипт для настройки LTE модема с помощью systemd

modemdevice="/dev/cdc-wdm0"

if [ -c $modemdevice ]; then echo "Found character device..."; else echo "Not found character device..."; exit 19; fi


driver=$(realpath /sys/class/usbmisc/cdc-wdm0/device/driver)
drivertype=$(basename $driver)
if [ $drivertype == "cdc_mbim" ]; then echo "Found MBIM driver..."; else echo "Unknown driver: $drivertype"; exit 38; fi
if [ $drivertype == "qmi_wwan" ]; then echo "Found QMI driver..."; echo "QMI protocol not supported"; exit 93; fi

# check SIM card PIN state
mbimcli -d /dev/cdc-wdm0 --device-open-proxy --query-pin-state | grep "unlocked"
if [ $? == 0 ]; then echo "PIN code unlocked and no need to enter one" else echo "PIN locked and need to be provided. Aborting..."; exit 1; fi

# check PID&VID - можно пропустить такую проверку
lsusb -d 2c7c:0125
if [ $? == 0 ]; then echo "Found EC25 LTE modem..."; else echo "No modem..."; exit 19; fi

mbimcli -d /dev/cdc-wdm0 -p --set-radio-state=on
echo "LTE modem radio is on"
mbim-network /dev/cdc-wdm0 start
echo "Setting ip configuration ..."
/home/gimmor/mbim-set-ip /dev/cdc-wdm0 wwan0

# Configure DNS resover
resolvectl default-route enp2s0 no
resolvectl default-route wwan0 yes
echo "DNS resolver configured."
echo "LTE modem configured."

stopmodem4.sh - скрипт для остановки подключения через LTE модем.

root@microserver:/home/gimmor# cat stopmodem4.sh
#!/bin/bash

echo "Stopping LTE modem..."
mbim-network /dev/cdc-wdm0 stop
echo "Disabling radio modem off..."
mbimcli -d /dev/cdc-wdm0 -p --set-radio-state=off

ip addr flush dev wwan0
resolvectl revert wwan0
echo "LTE modem stopped"

 

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



четверг, 2 ноября 2023 г.

Опознание портов устройств автоматизации Home Assistant в домашней сети

    При появлении какого-либо нового устройства в домашней сети с системой Home Assistant в качестве умного дома, возникает потребность определить открытые ip-порты на устройстве. Часто это бывает какая-либо IP-камера (IPC), устройство с wi-fi и т.п. С определением состояния открытости вполне справляется известный инструмент nmap. Однако, описания портов часто вводят в заблуждение тем, что не соответствуют в понимании домашнего администратора тому, что должно быть. "Unknown " - это не очень информативно.

    Выход есть в создании файла описания открытых портов - nmap-services. Этот файл, при указании опции --datadir подключается утилитой nmap и она берёт оттуда описание обнаруженного порта. 

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

    Использование такого файла позволяет быстро выявлять открытые порты разнообразных служб и документировать их в этом файле. После этого, утилита nmap становиться очень информативной в домашней сети. Также можно переименовывать уже известные порты (см. например порт 22).

    Отсканировав все домашние устройства по портам, можно выявить непознанное и поступить с ним соответственно.

# Local services
# 2.11.2023
homeassistant                8123/tcp            # Home Assistant web interface
homeassistant-observer       4357/tcp            # Home Assistant observer
mqtt                         1883/tcp            # MQTT broker
mqtt-ssl                     8883/tcp            # MQTT broker ssl port
go2rtc                       1984/tcp            # Home Assistant go2rtc web interface
llmnr                        5355/tcp            # Link-local Multicast Name Resolution
go2rtc-rtsp                  8554/tcp            # Home Assistant go2rtc rtsp protocol
go2rtc-webrtc                8555/tcp            # Home Assistant go2rtc webrtc
ssdp-upnp                    1900/tcp            # Port 1900 is SSDP Discovery and uPNP
mdns                         5353/udp            # mutlicast DNS
mikrotik-winbox              8291/tcp            # Mikrotik Winbox
mikrotik-api                 8728/tcp            # Mikrotik API interface
mikrotik-api-ssl             8729/tcp            # Mikrotik API SSL interface
ws-discovery                 3702/tcp            # Web Services Dynamic Discovery
ws-discovery                 3702/udp            # Web Services Dynamic Discovery
net-ups-tool                 3493/tcp            # Network UPS tool
net-ups-tool                 3493/udp            # Network UPS tool
openssh                        22/tcp            # Secure shell

# Additonal ports from sonoff camera
sonoff1                      7101/tcp            # open  unknown
sonoff2                      7103/tcp            # open  unknown
sonoff3                      8080/tcp            # open  http-alt
sonoff4                     65530/tcp            # open  unknown

# Additional ports from icsee camera
onvif                        8899/tcp            # ONVIF port
icsee-backdoor               9530/tcp            # xmhdipc camera backdoor
icsee2                      12901/tcp            # open  unknown
icsee3                      34567/tcp            # Media port

# Additional ports from esphome firmware
esphome-ota-update           3232/tcp            # EspHome ESP32 Over-The-Air update
esphome-api                  6053/tcp            # EspHome API port
esphome-ota-update           8266/tcp            # EspHome ESP8266  Over-The-Air update
esphome-ota-update           2040/tcp            # EspHome RP2040 Over-The-Air update

# Some other ports
article1                    34599/tcp            # Mobile monitoring port


    Есть возможность сохранить настройки описания портов указанием переменной окружения NMAPDIR для всех пользователей, отредактировав файл /etc/environment и добавив строку: NMAPDIR="/home/username",  либо временно: EXPORT NMAPDIR="/home/username".

    После этого, утилита nmap подхватит файл пользовательского описания и будет сообщать об открытых портах то, что внесено в файл /home/username/nmap-services

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

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

    Перекрытие по портам разных служб (например - порт 8080) остаётся на усмотрение домашнего администратора.

    Собранная информация является удобным подспорьем для настройки межсетевого экрана (firewall).

 P.S. Слова "Unknown" - не должно быть в домашней сети, но оно есть и избавиться от него сложно.





понедельник, 21 января 2019 г.

Poisk 1. Компьютер Поиск 1. Сбор информации

В закромах старого комода откопал некоторую информацию о некогда имевшемся компьютере Поиск 1.
Отсканировал, в память. Листы были сброшюрованы.

Надеюсь разобраться, по новой.
Ссылка на загрузку альбома схем для Поиск 1 : Поиск 1. Альбом схем
Ссылка на загрузку ряда изображений модулей расширения компьютера Поиск 1:  Поиск 1. Модули
Ссылка на загрузку сканированной брошюры НГМД, В-504, модуля расширения компьютера Поиск 1: https://yadi.sk/d/RTmrRuiTEBN-lA

Ресурсы

1. Поиск 1. Альбом схем. https://yadi.sk/d/nFFKBQ-KoshfxQ
2. Поиск 1. Модули. https://yadi.sk/d/yB0b98idL5eTDg
3. Поиск 1. Модуль НГМД. https://yadi.sk/d/RTmrRuiTEBN-lA

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

Ресурсы




※※※