binfmts для exe-файлів

В попередній статті я частково вже зачепив тему binfmts.

Що це за приблуда, що це за звір такий?

update-binfmts — maintain registry of executable binary formats

Тобто в Debian (та й інших дистрибутивах Linux) ми можемо запускати бінарні файли на виконання, навіть якщо це не ELF. Просто для цього треба навчити Linux їх запускати.

Для початку можна подивитися на вже встановлені зв'язки. Виглядатиме це приблизно так:

$ sudo update-binfmts --display
cli (enabled):
     package = mono-runtime
        type = magic
      offset = 0
       magic = MZ
        mask = 
 interpreter = /usr/bin/cli
    detector = /usr/lib/cli/binfmt-detector-cli
jar (enabled):
     package = oracle-java16
        type = magic
      offset = 0
       magic = PK\x03\x04
        mask = 
 interpreter = /usr/lib/jvm/java-16-oracle/lib/jexec
    detector = 
python2.7 (enabled):
     package = python2.7
        type = magic
      offset = 0
       magic = \x03\xf3\x0d\x0a
        mask = 
 interpreter = /usr/bin/python2.7
    detector = 
python3.9 (enabled):
     package = python3.9
        type = magic
      offset = 0
       magic = \x61\x0d\x0d\x0a
        mask = 
 interpreter = /usr/bin/python3.9
    detector = 

Як бачимо то тут встановлено зв'язки для бінарних (скопмільованих) форматів - cli (exe), jar, python 2.7 та 3.9.

Якщо раптом закортить додати запуск exe (MZ) не через wine то достатньо просто додати наступну конфігурацію:

$ sudo update-binfmts --package wine --install wine /usr/bin/wine --magic 'MZ'

Дивимося:

$ sudo update-binfmts --display
cli (enabled):
     package = mono-runtime
        type = magic
      offset = 0
       magic = MZ
        mask = 
 interpreter = /usr/bin/cli
    detector = /usr/lib/cli/binfmt-detector-cli
jar (enabled):
     package = oracle-java16
        type = magic
      offset = 0
       magic = PK\x03\x04
        mask = 
 interpreter = /usr/lib/jvm/java-16-oracle/lib/jexec
    detector = 
python2.7 (enabled):
     package = python2.7
        type = magic
      offset = 0
       magic = \x03\xf3\x0d\x0a
        mask = 
 interpreter = /usr/bin/python2.7
    detector = 
python3.9 (enabled):
     package = python3.9
        type = magic
      offset = 0
       magic = \x61\x0d\x0d\x0a
        mask = 
 interpreter = /usr/bin/python3.9
    detector = 
wine (enabled):
     package = wine
        type = magic
      offset = 0
       magic = MZ
        mask = 
 interpreter = /usr/bin/wine
    detector = 

Все, після цього можна "прозоро" запускати exe-файли через wine. Наприклад:

$ chmod +x ./winbox-3.40.exe
$ ./winbox-3.40.exe

Якщо ж хочеться встановити коректне відображення кодування CP1251 то можна виконати запуск наступним чином:

$ LANG=ru_RU.cp1251 luit winbox.exe

Видалити конфігурацію binfmts так само легко як і встановити:

$ sudo update-binfmts --package wine --remove wine /usr/bin/wine

Ось така магія ;)

Java 21 & Debian (Ubuntu)

Нарешті! Нарешті це сталося!

Oracle почала випускати deb-пакети з Java. Принаймні Java 21 вже можна завантажити як deb-пакет. А далі все стає просто і без зайвих танців з бубном. За потреби, видаляємо залишки openjdk:

sudo apt purge openjdk-17-jre-headless

Також, переда встановленням deb-пакету з Java 21, краще видалити binfmts для попередньої версії (в моєму випадку це openjdk-17):

sudo update-binfmts --display
sudo update-binfmts --package openjdk-17 --remove jar /usr/bin/jexec

Встановлюємо пакет:

sudo dpkg -i jdk-21_linux-x64_bin.deb

Все ;)

Viber 21.0.0.1 на Debian 11.8 (Bullseye)

 Зіткнувся з проблемою при оновленні версії Viber, а саме - припинив запускатися. При запуску в консолі виводить наступне:

$ /opt/viber/Viber
qt.qpa.plugin: Could not load the Qt platform plugin "xcb" in "" even though it was found.
This application failed to start because no Qt platform plugin could be initialized. Reinstalling the application may fix this problem.

Available platform plugins are: wayland, eglfs, minimalegl, minimal, offscreen, vnc, linuxfb, wayland-egl, xcb.

З'ясувалося, що лікується доволі просто, хоч і не очевидно. Встановлюємо пакет libxcb-cursor0:

$ sudo apt install libxcb-cursor0

Після встановлення Viber "ожив".

Неочевидність полягає саме в тому, що встановлення самого по собі пакету xcb не допомагає. Більше того, для роботи Viber, його можна й не встановлювати.

Debian 11: deb uses unknown compression for member

 Звісно, що вже є Debian 12, але подекуди доводиться використовувати старіші версії. Так от трапилося й у мене. Debian 11 "матюгнувся":

$ sudo dpkg -i apache-netbeans_20-1_all.deb
dpkg-deb: error: archive 'apache-netbeans_20-1_all.deb' uses unknown compression for member 'control.tar.zst', giving up
dpkg: error processing archive apache-netbeans_20-1_all.deb (--install):
 dpkg-deb --control subprocess returned error exit status 2
Errors were encountered while processing:
 apache-netbeans_20-1_all.deb

Ну, нічого страшного. Просто доведеться перепакувати deb-пакет з тим методом компресії, який відомий Debian 11.

$ ar x apache-netbeans_20-1_all.deb

$ zstd -d < control.tar.zst | xz > control.tar.xz

$ zstd -d < data.tar.zst | xz > data.tar.xz

$ ar -m -c -a sdsd /tmp/apache-netbeans_20-1_all.deb debian-binary control.tar.xz data.tar.xz

$ rm debian-binary control.tar.xz data.tar.xz control.tar.zst data.tar.zst

$ sudo dpkg -i /tmp/apache-netbeans_20-1_all.deb
(Reading database ... 398738 files and directories currently installed.)
Preparing to unpack .../apache-netbeans_20-1_all.deb ...
Unpacking apache-netbeans (20-1) over (19-1) ...
Setting up apache-netbeans (20-1) ...
Processing triggers for gnome-menus (3.36.0-1) ...
Processing triggers for desktop-file-utils (0.26-1) ...
Processing triggers for mailcap (3.69) ...
Processing triggers for hicolor-icon-theme (0.17-2) ...

Незручність лише в тому, що така конвертація займає певний час та місце.

Встановлення Zabbix-агента на Windows

1. Завантажуємо https://cdn.zabbix.com/zabbix/binaries/stable/6.4/6.4.7/zabbix_agent-6.4.7-windows-amd64.zip
2. Розпаковуємо архів zabbix_agent-6.4.7-windows-amd64.zip, наприклад, в c:\zabbix
3. Відкриваємо на редагування C:\Zabbix\conf\zabbix_agentd.conf і правимо:
1. LogFile=c:\Zabbix\zabbix_agentd.log
2. Server=127.0.0.1, 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16 - тут через кому перераховуємо мережі з яких буде доступним Zabbix-агент, точніше мережі на запити з яких він буде відповідати, якщо ці запити надійдуть
3. Hostname=Windows host - тут замість "Windows host" пишемо свою назву, головне щоб вона збігалася з тою з якою ми будемо реєструвати цей хост на Zabbix-сервері
4. В cmd, в режимі адміністратора, виконуємо:
1. C:\Zabbix\bin\zabbix_agentd.exe --config C:\Zabbix\conf\zabbix_agentd.conf --install
2. C:\Zabbix\bin\zabbix_agentd.exe --config C:\Zabbix\conf\zabbix_agentd.conf --start
5. В cmd, в режимі адміністратора, та виконуємо:
1. netsh advfirewall firewall add rule name="Open Zabbix agentd port 10050 inbound" dir=in action=allow protocol=TCP localport=10050
2. netsh advfirewall firewall add rule name="Open Zabbix agentd port 10050 outbound" dir=out action=allow protocol=TCP localport=10050
3. (опціонально) netsh advfirewall firewall add rule name="Open Zabbix trapper port 10051 inbound" dir=in action=allow protocol=TCP localport=10051
4. (опціонально) netsh advfirewall firewall add rule name="Open Zabbix trapper port 10051 outbound" dir=out action=allow protocol=TCP localport=10051

Встановлення з'єднання wireguard між Mikrotik та Linux (Debian)

Linux

Встановлюємо пакети wireguard та wireguard-dkms:

# apt install wireguard wireguard-dkms

Створюємо пару ключів:

# cd /etc/wireguard
# wg genkey > private-key
# wg pubkey > public-key < private-key

Скоріш за все, після цього, не зможете отримати доступ з під поточного користувача до файлів /etc/wireguard/private-key та /etc/wireguard/public-key. Хтось грається з заміною користувача та/або групи для каталогу /etc/wireguard, але я пропоную/практикую інший шлях:

$ sudo setfacl -m u:username:r-x /etc/wireguard
$ sudo setfacl -m u:username:r-x /etc/wireguard/private-key
$ sudo setfacl -m u:username:r-x /etc/wireguard/public-key

Отримуємо/дивимося на пару ключів:

$ cat /etc/wireguard/public-key
$ cat /etc/wireguard/private-key

Mikrotik

Тут все простіше:

/interface wireguard
add listen-port=13231 mtu=1420 name=wireguard1
/interface wireguard peers
add allowed-address=0.0.0.0/0 endpoint-address=10.10.10.11 endpoint-port=13231 interface=wireguard1 persistent-keepalive=30s public-key="…public key from /etc/wireguard/public-key…"
/ip address
add address=10.3.2.1/30 interface=wireguard1

Linux NetworkManager

Файл /etc/NetworkManager/system-connections/wireguard1.nmconnection при цьому може виглядати якось так:

[connection]
id=wireguard1
uuid=6b31553d-8782-4952-98e2-739ef4a05a87
type=wireguard
autoconnect=false
interface-name=wireguard1
permissions=
timestamp=1696251106

[wireguard]
listen-port=13231
private-key=…private key from /etc/wireguard/private-key…

[wireguard-peer.…public key from Mikrotik…]
endpoint=10.10.10.10:13231
persistent-keepalive=30
allowed-ips=10.3.2.0/24;192.168.88.0/24;

[ipv4]
address1=10.3.2.2/30
dns-search=
method=manual

[ipv6]
addr-gen-mode=stable-privacy
dns-search=
method=ignore

[proxy]

Після чого активуємо інтерфейс:

$ sudo nmcli con up wireguard1

Все просто й доступно.

Як ввімкнути rc.local в Debian?

Якщо ви запускаєте дистрибутив Linux з використанням Systemd, то можете помітити, що при завантаженні системи інструкції з файлу /etc/rc.local не виконуються. Далі в статті йдеться про те як це виправити.

Якщо раптом при виконанні команди sudo systemctl status rc.local  побачите подібне повідомлення:

$ sudo systemctl status rc-local
○ rc-local.service - /etc/rc.local Compatibility
     Loaded: loaded (/lib/systemd/system/rc-local.service; static)
    Drop-In: /usr/lib/systemd/system/rc-local.service.d
             └─debian.conf
     Active: inactive (dead)
       Docs: man:systemd-rc-local-generator(8)

Або інше, відмінне від "Active: active", а sudo systemctl enable rc-local  видасть

$ sudo systemctl enable rc-local
The unit files have no installation config (WantedBy=, RequiredBy=, Also=,
Alias= settings in the [Install] section, and DefaultInstance= for template
units). This means they are not meant to be enabled using systemctl.
 
Possible reasons for having this kind of units are:
• A unit may be statically enabled by being symlinked from another unit's
  .wants/ or .requires/ directory.
• A unit's purpose may be to act as a helper for some other unit which has
  a requirement dependency on it.
• A unit may be started when needed via activation (socket, path, timer,
  D-Bus, udev, scripted systemctl call, ...).
• In case of template units, the unit is meant to be enabled with some
  instance name specified.

То можна виконати наступні інструкції, які мають виправити ситуацію:

$ echo "[Unit]
Description=/etc/rc.local Compatibility
ConditionPathExists=/etc/rc.local

[Service]
Type=forking
ExecStart=/etc/rc.local start
TimeoutSec=0
StandardOutput=tty
RemainAfterExit=yes
SysVStartPriority=99

[Install]
WantedBy=multi-user.target" | sudo tee /etc/systemd/system/rc-local.service > /dev/null

$ printf '%s\n' '#!/bin/bash' 'exit 0' | sudo tee -a /etc/rc.local
#!/bin/bash
exit 0

$ sudo chmod +x /etc/rc.local

$ sudo systemctl enable rc-local
Created symlink /etc/systemd/system/multi-user.target.wants/rc-local.service → /etc/systemd/system/rc-local.service.

$ sudo systemctl start rc-local.service

І отримати результат:

$ sudo systemctl status rc-local.service
* rc-local.service - /etc/rc.local Compatibility
     Loaded: loaded (/etc/systemd/system/rc-local.service; enabled; preset: enabled)
    Drop-In: /usr/lib/systemd/system/rc-local.service.d
             `-debian.conf
     Active: active (exited) since Mon 2023-09-25 13:38:53 EEST; 15min ago
    Process: 34112 ExecStart=/etc/rc.local start (code=exited, status=0/SUCCESS)
        CPU: 1ms

Sep 25 13:38:53 oghome systemd[1]: Starting rc-local.service - /etc/rc.local Compatibility...
Sep 25 13:38:53 oghome systemd[1]: Started rc-local.service - /etc/rc.local Compatibility.

За мотивами статті How to Enable /etc/rc.local with Systemd.

OpenOffice Calc - IPv4-адреса (з маскою) в число + маска

 Припустимо, що в стовпці A у нас знаходяться ip-адреси з маскою, в форматі: n.n.n.n/m

В стовпці B ми хочемо отримати десятичне число, яке відповідає ip-адресі n.n.n.n, а в стовпці C, відповідно, маску мережі m.

Дві формули.

Для стовпця B:

=VALUE(LEFT($A1;FIND(".";$A1)-1))*256^3+VALUE(MID($A1;FIND(".";$A1)+1;FIND(".";$A1;FIND(".";$A1)+1)-FIND(".";$A1)-1))*256^2+VALUE(MID($A1;FIND(".";$A1;FIND(".";$A1)+1)+1;FIND(".";$A1;FIND(".";$A1;FIND(".";$A1)+1)+1)-FIND(".";$A1;FIND(".";$A1)+1)-1))*256^1+VALUE(MID($A1;FIND(".";$A1;FIND(".";$A1;FIND(".";$A1)+1)+1)+1;FIND("/";$A1;FIND(".";$A1;FIND(".";$A1;FIND(".";$A1)+1)+1)+1)-FIND(".";$A1;FIND(".";$A1;FIND(".";$A1)+1)+1)-1))

Для стовпця C:

=VALUE(MID($A1;FIND("/";$A1)+1;FIND("/";$A1)-1))

Як результат, маємо щось накшталт:

За основу взято статтю [Solved] IP address sorting.

Поговоримо трохи про whois

Список AS що входять в as-set:

ASSET=AS-UKRHUB; whois -r ${ASSET} | awk '$1~/^members:/ && $2~/^AS[0-9]+/ { print $2 }'

AS які супроводжує mnt-by:

MNTBY=YZ42-RIPE-MNT; whois -r -i mnt-by ${MNTBY} -T aut-num | awk '$1~/^aut-num:/ { print $2 }'

Які IPv4-мережі анонсує AS?

AS=AS12593; whois -K -r -i origin ${AS} | awk '$1~/^route:$/ { print $2 }'

Які IPv6-мережі анонсує AS?

AS=AS12593; whois -K -r -i origin ${AS} | awk '$1~/^route6:$/ { print $2 }'

Отримати інформацію по організації AS:

AS=AS12593; whois -r $( whois -r ${AS} | awk '$1~/^org:$/ { print $2 }' )

Список діапазонів мереж які супроводжує mnt-by:

MNTBY=YZ42-RIPE-MNT; whois -r -i mnt-by ${MNTBY} -T inetnum | awk '$1~/^inetnum:$/ { print }'

Список IPv4-мережі які супроводжує mnt-by:

MNTBY=YZ42-RIPE-MNT; whois -r -i mnt-by ${MNTBY} -T route | awk '$1~/^route:$/ { print $2 }'

Список IPv6-мережі які супроводжує mnt-by:

MNTBY=YZ42-RIPE-MNT; whois -r -i mnt-by ${MNTBY} -T route6 | awk '$1~/^route6:$/ { print $2 }'

Список as-set які супроводжує mnt-by:

MNTBY=YZ42-RIPE-MNT; whois -r -i mnt-by ${MNTBY} -T as-set | awk '$1~/^as-set:/ { print $2 }'

AS по org:

ORG=ORG-SE1-RIPE; whois -r -i org ${ORG} -T aut-num

Клієнт DNS over HTTPS (DoH)

DNS over HTTPS (DoH) — це протокол для виконання DNS-запитів через протокол HTTPS. Надає певні переваги в захисті DNS-запитів. Якщо звичайний запит по 53/udp доволі легко перехопити і проаналізувати через, наприклад, Wireshark то з запитом через HTTPS цей "фокус" стає не таким вже й тривіальним. Mikrotik дозволяє нам налаштувати DNS over HTTPS (DoH) з тими чи іншими службами, наприклад з Google або Cloudflare.

Завантажуємо та імпортуємо сертифікат:

/tool fetch url=https://cacerts.digicert.com/DigiCertGlobalRootCA.crt.pem
/certificate import file-name=DigiCertGlobalRootCA.crt.pem passphrase=""

Далі, в DHCP-клієнті вимикаємо отримання DNS-серверів, наприклад, від провайдера, а також видаляємо використання будь-яких користувацьких налаштувань щодо DNS-серверів:

/ip dns set servers=""
/ip dhcp-client set [ find ] use-peer-dns=no

Ну й налаштовуємо DNS over HTTPS (DoH) для Google:

/ip dns set use-doh-server=https://8.8.8.8/dns-query verify-doh-cert=yes

або Cloudflare:

/ip dns set use-doh-server=https://1.1.1.1/dns-query verify-doh-cert=yes

Після цього можна скинути наявний кеш і перевірити, що DNS over HTTPS (DoH) працює:

/ip dns cache flush
/ping meta.ua count=4
/ip dns cache print without-paging

ovpn-файл до статті "Налаштування OpenVPN-сервера на Mikrotik"

Вступ

Нещодавно в статті Налаштування OpenVPN-сервера на Mikrotik (метод 2) було наведено вміст ovpn-файла, для OpenVPN-клієнта Windows/Linux, в той самий час в статті Налаштування OpenVPN-сервера на Mikrotik було розглянуто лише налаштування OpenVPN-клієнта в RouterOS. Спробуємо виправити ситуацію.

Експорт сертифікатів

Нарешті ми налаштували OpenVPN-сервер на Mikrotik і тепер хочемо роздати нашим клієнтам ovpn-файл, щоб вони підключалися до сервера.

Експортуємо ca та клієнтський сертифікати. Тут все просто:

/certificate export-certificate ca file-name=ca-v1 type=pem 
/certificate export-certificate ovpn-muter file-name=ovpn-client-v1 type=pem export-passphrase="passphrase"

Створюємо ovpn-файл

client
dev tun
remote <ip address or dns name of the ovpn server> 1194 tcp
nobind
persist-key
persist-tun
remote-cert-tls server
data-ciphers AES-256-CBC
cipher AES-256-CBC
auth-user-pass
auth SHA1
redirect-gateway def1
verb 1
<ca>
-----BEGIN CERTIFICATE-----
вставляємо вміст з експортованого файла ca-v1.crt
-----END CERTIFICATE-----
</ca>
<cert>
-----BEGIN CERTIFICATE-----
вставляємо вміст з експортованого файла ovpn-client-v1.crt
-----END CERTIFICATE-----
</cert>
<key>
-----BEGIN ENCRYPTED PRIVATE KEY-----
вставляємо вміст з експортованого файла ovpn-client-v1.key
-----END ENCRYPTED PRIVATE KEY-----
</key>

Налаштування OpenVPN-сервера на Mikrotik (метод 2)

Вступ

Вже був розповідав як налаштувати OpenVPN-сервер на Mikrotik (назвемо його - метод 1). В тому методі ми налаштували сервер де організували з кожним клієнтом point-to-point канал і маршрутизували трафік. Але подекуди нам зустрічаються локальні мережі в яких працює специфічний софт, який "не любить" маршрутизацію і чи зовсім не працює з нею, чи працює лише після танців з бубном. В таких випадках нам зможе допомогти другий метод налаштування OpenVPN-сервера, коли клієнт входить безпосередньо в бродкаст домен (bridge-інтерфейс) локальної мережі.

Сертифікати

В цьому другому методі нам теж треба згенерувати сертифікати, але з іншими правами. Якщо генерувати сертифікати в тими правами, що були у попередньому методі, нічого не буде працювати. Це важливо.

Генеруємо корневий сертифікат нашого "сертифікаційного центру":

/certificate add name=ca-v2 country="UA" state="KY" locality="Locality" organization="Organization" unit="Unit" common-name="ca-v2" key-size=2048 days-valid=3650 key-usage=digital-signature,key-encipherment,data-encipherment,key-cert-sign,crl-sign
/certificate sign ca-v2

Створюємо сертифікат та закритий ключ для OpenVPN-сервера:

/certificate add name=ovpn-server-v2 country="UA" state="KY" locality="Locality" organization="Organization" unit="OpenVPN-server-v2" common-name="ovpn-server-v2" key-size=2048 days-valid=3650 key-usage=digital-signature,key-encipherment,data-encipherment,key-cert-sign,tls-server
/certificate sign ovpn-server-v2 ca=ca-v2

Генеруємо клієнтський сертифікат:

/certificate add name=ovpn-client-v2 country="UA" state="KY" locality="Locality" organization="Organization" unit="OpenVPN-client-v2" common-name="ovpn-client-v2" key-size=2048 days-valid=3650 key-usage=tls-client
/certificate sign ovpn-client-v2 ca=ca-v2

Сервер

З сертифікатами поки закінчили, тепер налаштуємо сам OpenVPN-сервер.

/ppp profile add bridge=bridge bridge-learning=yes local-address=192.168.0.1 name=profile-ovpn remote-address=default-dhcp use-ipv6=no
/interface ovpn-server server set auth=sha1 certificate=OVPN-server cipher=aes256 default-profile=profile-ovpn enabled=yes mode=ethernet require-client-certificate=yes

Тут важливо розуміти що на відміну від метода 1 тут ми вводимо клієнтів безпосередньо в бродкаст домен (bridge-інтерфейс) локальної мережі, відповідно для сервера вказуємо mode=ethernet, а в профілі використовуємо наявний для локальної мережі dhcp-діапазон адрес і локальним адресом вказуємо адресу на bridge-інтерфейсі.

Далі додаємо користувачів

/ppp secret add name=USERNAME password=PASSWORD profile=ovpn service=ovpn

та не забуваємо відкрити OpenVPN-сервер для доступу:

/ip firewall filter add action=accept chain=input dst-port=1194 protocol=tcp

Клієнт

Тепер давайте створимо ovpn-файл для OpenVPN-клієнта. Спочатку експортуємо ca та клієнтський сертифікати. Тут все просто:

/certificate export-certificate ca-v2 file-name=ca-v2 type=pem 
/certificate export-certificate ovpn-client-v2 file-name=ovpn-client-v2 type=pem export-passphrase="passphrase"

Важливо! Для клієнтського сертифіката необхіжно вказати бодай якусь passphrase, інакше не буде експортовано закритий ключ, а він нам необхідний.

Сам вміст ovpn-файла може бути приблизно таким.

client.ovpn:

client
dev tap
proto tcp
remote <ip address or dns name of the ovpn server> 1194
nobind
persist-key
persist-tun
remote-cert-tls server
data-ciphers AES-256-CBC
cipher AES-256-CBC
auth-user-pass
keepalive 10 120
verb 1
auth SHA1
<ca>
-----BEGIN CERTIFICATE-----
вставляємо вміст з експортованого файла ca-v2.crt
-----END CERTIFICATE-----
</ca>
-----BEGIN CERTIFICATE-----
вставляємо вміст з експортованого файла ovpn-client-v2.crt
-----END CERTIFICATE-----
</cert>
<key>
-----BEGIN ENCRYPTED PRIVATE KEY-----
вставляємо вміст з експортованого файла ovpn-client-v2.key
-----END ENCRYPTED PRIVATE KEY-----
</key>

Якщо OpenVPN-клієнт для Windows дозволяє запам'ятати введену passphrase та ім'я та пароль користувача то для Linux такої можливості немає, але в сам ovpn-файл можна додати опції:

auth-user-pass auth.cfg
askpass store.pass

а в самих файлах розмістити, відповідно, ім'я користувача з паролем та passphrase.

auth.cfg:

USERNAME
PASSWORD

store.pass:

passphrase

Ось і все, щодо метода 2.

Налаштування wifiwave2 на hAP ax² (C52iG-5HaxD2HaxD).

Так вже сталося, що потрапив мені в руки Mikrotik hAP ax². Перша, й характерна, відмінність, від того до чого звик, це WiFi 6 і пакет wifiwave2. Що хочеться сказати: все, що знали про налаштування WiFi на Mikrotik до wifiwave2 — забудьте! Все, що знали про налаштування CAPsMAN на Mikrotik до wifiwave2 — забудьте!

Одразу хочу сказати, що не стану тут пересказувати статтю WifiWave2 з офіційного джерела Mikrotik-а. Стаття гарна і висвічує майже всі аспекти. Я просто розповім про свої митарства і про позитивний досвід.

Спочатку, так як залізо було новим, спробував подивитися, що та як налаштовує Quick Set і, як це зазвичай буває, мені це не дуже сподобалося. Ні, звісно, що працювати якось буде, але… ну не те.

Не помітив улюбленого пункту меню CAPsMAN… Хм… Пішов до меню Wireless і одразу побачив схожість вкладок до меню CAPsMAN попередніх версій. Ну, думаю, супер! Адже CAPsMAN мені дуже подобається, особливо коли мова йдре про масштабування wifi-мережі. Але не все так сталося як гадалося. Функціонал попередніх версій CAPsMAN подекуди докорінно відрізнявся від того, що побачив тут. Окрім того, тут, назвемо так, "гібрідний функціонал". Тобто можна налаштовувати через меню Wireless як безпосередньо wifi-інтерфейси так і задіяти для того самого CAPsMAN.

Так як треба було все налаштувати швидко то налаштував через winbox два інтерфейси у вкладці WiFi Wawe 2. Запрацювало. Добре. Але… але не подобалося, от якось не те, хотілося, прямо кортіло, задіяти функціонал CAPsMAN

Треба сказати, що грішив від самого початку на версію прошивки. Factory Firmware була 7.6, а на той час як hAP ax² потрапив до рук, то актуальною stable-версією була 7.9. Раз підхід. Два підхід. Ну не виходить кам'яна квітка… Повернувся до налаштувань WiFi Wawe 2 без CAPsMAN і "забув".

Все змінилося, коли вийшла stable-версія прошивки 7.10.2, до якої прямо було написано

wifiwave2 - fixed interface hangs on IPQ6010-based boards (introduced in v7.9)

Далі без лірики. Далі практика.

Оновлюємося до прошивки не меншої за 7.10.2, щоб успішно задіяти функціонал CAPsMAN пакету wifiwave2.

Відкриваємо консоль. І робимо дві магічні команди, бо без них подальші дії будуть схожі на шаманські танці з бубном, але результату буде мало. Так от, робимо:

/interface/wifiwave2/remove [ find ]
/interface/wifiwave2/reset [ find ]

таким чином ми видаляємо всі наявні "підлеглі" wifi-інтерфейси і скидаємо налаштування щодо "основних".

Після цього все стає не просто, а занадто просто:

/interface wifiwave2 channel
add disabled=no name=channel2 width=20/40mhz-Ce
add disabled=no name=channel5 skip-dfs-channels=disabled
/interface wifiwave2 datapath
add bridge=bridge disabled=no interface-list=LAN name=datapath1
/interface wifiwave2 security
add authentication-types=wpa2-psk,wpa3-psk passphrase=p@ssw0rd disabled=no group-encryption=ccmp name=sec1
/interface wifiwave2 configuration
add channel=channel5 country="United States" datapath=datapath1 disabled=no name=5ghz security=sec1 ssid=SampleWiFi tx-power=32
add channel=channel2 country=Ukraine datapath=datapath1 disabled=no name=2ghz security=sec1 ssid=SampleWiFi tx-power=32
add channel=channel5 country="United States" datapath=datapath1 disabled=no name=5ghz.5 security=sec1 ssid=SampleWiFi.5
add channel=channel2 country=Ukraine datapath=datapath1 disabled=no name=2ghz.2 security=sec1 ssid=SampleWiFi.2
/interface wifiwave2 cap
set discovery-interfaces=bridge enabled=yes
/interface wifiwave2 capsman
set enabled=yes interfaces=bridge upgrade-policy=none
/interface wifiwave2 provisioning
add action=create-dynamic-enabled disabled=no master-configuration=5ghz name-format=wifi1-5G-%I slave-configurations=5ghz.5 supported-bands=5ghz-n,5ghz-a,5ghz-ac,5ghz-ax
add action=create-dynamic-enabled disabled=no master-configuration=2ghz name-format=wifi2-2G-%I slave-configurations=2ghz.2 supported-bands=2ghz-n,2ghz-g,2ghz-ax

Ну от в принципі і все. Після цього починає нормально працювати CAPsMAN з пакета wifiwave2. Ну а всі інші налаштування — на власний розсуд. Не забуваємо дати команду:

/interface/wifiwave2/radio/provision [ find ]

Також зверну увагу, про що написано й в документації WifiWave2, що WifiWave2 CAPsMAN може керувати лише інтерфейсами WifiWave2, а WifiWave2 CAP може приєднуватися лише до WifiWave2 CAPsMAN, так само, CAPsMAN попередніх версій підтримує лише не-WifiWave2 пристрої.

Окреме зауваження щодо country. Для 5ГГц діапазона обрано United States. Чому? Скоріш за все за звичкою. Бо колись, коли тільки почали з'являтися 5ГГц-пристрої, iPhone погано "дружив" з  Mikrotik-ами на цьому діапазоні, ащо країна відрізнялася від United States. Час плине, можливо зараз все змінилося, але звичка залишилася.

Ще раз скажу, що документація щодо налаштувань WifiWave2 з офіційного джерела Mikrotik-а заслуговує на увагу, як і всі інші статті. Якщо у вас щось не виходить то це не тому, що Mikrotik такий прямо ну поганий і кривий, можливо просто в дзеркалі щось не так. Нічого не маю проти інших вендорів, але за критеріями ціна-якість-можливості, вважаю, що Mikrotik це всюдихід, який можна налаштувати майже під будь-які потреби… хіба що HTCPCP не підтримує ;)

Як з консолі перевірити термін дії SSL-сертифікату на ресурсі (наприклад https)

$ echo "GET / " | openssl s_client -servername att.privatbank.ua -connect att.privatbank.ua:443 | openssl x509 -noout -dates
depth=2 C = US, O = Amazon, CN = Amazon Root CA 1
verify return:1
depth=1 C = US, O = Amazon, CN = Amazon RSA 2048 M01
verify return:1
depth=0 CN = oteroprod.lnt.cl
verify return:1
DONE
notBefore=May 30 00:00:00 2023 GMT
notAfter=Jun 28 23:59:59 2024 GMT

Ось ці строчки і показують з якого і по який час сертифікат буде дійсним:

notBefore=May 30 00:00:00 2023 GMT
notAfter=Jun 28 23:59:59 2024 GMT