Получая ошибку «ath0 MLME-AUTH.indication» на «убике» при подключении девайса, чаще всего такое из-за двух причин:

• * не выключен Airmax
• * наврали в пароле (pre-shared key)

С приходом Let’s Encrypt сертификаты стали бесплатными, а https массово шагнул в эти ваши интернеты. Выпустить сертификат для домена, почты и сервисов стало просто, но срок действия сертификата в 90 дней не слишком велик, что ведет нас к тому, что периодически его нужно перевыпускать. В свою очередь приходится заниматься и тем, чтобы проверять, не истек ли сертификат, продлился ли он корректно.

Много раз сталкивался с тем, что сертификат не продлялся. Причин этому достаточно — ошибки при проверке, ошибки при конфигурировании сервера, изменения в DNS. Банальнейшая история, когда А запись для домена и WWW прописана на разные адреса и что-то в записях меняется, например при переезде. Бывают также превышения лимита запросов к Let’s Encrypt, на какое время сертификат перевыпустить не получится.

Именно для этого требуется хоть какой-нибудь мониторинг хозяйства из ssl сертификатов. Саму проверку мы по сути можем выполнить одной командой:

openssl s_client -servername <NAME> -connect <HOST:PORT> 2>/dev/null | openssl x509 -noout -dates

И смотреть, что у нас получилось в выходе notAfter. Решение для посмотреть по-быстрому, но пользоваться не слишком удобно. Что приводит нас к необходимости усложнить...

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

nginx -T | sed -r -e 's/[ \t]*$//' -e 's/^[ \t]*//' -e 's/^#.*$//' -e 's/[ \t]*#.*$//' -e '/^$/d' | \
sed -e ':a;N;$!ba;s/\([^;\{\}]\)\n/\1 /g' | \
grep -P 'server_name[ \t]' | grep -v '\$' | grep '\.' | \
sed -r -e 's/(\S)[ \t]+(\S)/\1\n\2/g' -e 's/[\t ]//g' -e 's/;//' -e 's/server_name//' | \
sort | uniq | xargs -L1 > /path/to/sitelist

Для тех, кто использует панели управления, вроде ISPManager — плохая новость, изящно список не получить — нужно пользоваться nginx и выборкой оттуда. А вот у VestaCP / HestiaCP / MyVesta есть аккуратная выборка:

v-list-users | tail -n +3 | awk '{print "v-list-web-domains "$1" | tail -n +3"}' | bash | awk '{ print ($1)":443" | "sort -d" }' > /path/to/sitelist

Далее можно попробовать что-то свое, а можно взять готовое решение от Джулио @elarraydejota из Мадрида — https://github.com/juliojsb/jota-cert-checker. Из многих скриптов этот понравился больше всего. Стабильная работа, понятный код и приятный выбор между отчетами. Остается только добавить в начало скрипта выборку по доменам или подключать ее в скрипте с помощью source, далее сможем получать отчеты в терминале или по почте.

В терминале это выглядит вот так:

На почте вот так:

Но не все же так хорошо? Да, не все. Удалось подружить скрипт с телеграмом, но вывод как для слаки при большом количестве доменов в виде картинки — очень неудачный вариант, для 1-5 еще ничего. Пока пришлось отказаться от этой затеи.. Также к минусам можно отнести и сложности с кириллическими доменами, даже в punnycode. Проверка их с помощью openssl s_client клиента проходит не всегда.

Понадобилось на несколько разных серверов на Debian/Ubuntu поставить агент Zabbix, чтобы подключить их к мониторингу. Вместо того, чтобы ставить совсем все руками, немного автоматизировал процесс и добавил интерактива и в конце немного покажет адреса, чтобы удобно добавить в inventory. Скрипт спрашивает ровно три вещи:

1. хостнейм сервера — можно прощелкать, укажет автоматически
2. адрес Zabbix сервера — указывать обязательно
3. порт — можно прощелка, укажет стандартный 10050

Для запуска скрипта:

bash <(wget -O - https://raw.githubusercontent.com/skurudo/usefulbash/main/zabbix-add-agent-on-debian.sh)

Код приведен ниже и также доступен на Github:

#!/bin/bash
# YASZAIT
# Yet Another Simple Zabbix Agent Installer Tool
##############################################################
# enter some data to start
echo -n "Enter this server name: "
read SRV_HOSTNAME
# if SRV_HOSTNAME is empty, use server hostname
if [ -z "$SRV_HOSTNAME" ]; then
        SRV_HOSTNAME=($(hostname -f))
fi
echo -n "Enter Zabbix Server (FQDN or IP): "
read ZABBIX_SERVER
# if ZABBIX_SERVER is empty, try again
if [ -z "$ZABBIX_SERVER" ]; then
    echo -n "=> Please enter address of your Zabbix server... [example.org or IP]: "
        read -r ZABBIX_SERVER
fi
echo -n "Listening port (10050): "
read LISTEN_PORT
# if LISTEN_PORT is empty, set it to 10050
if [ -z "$LISTEN_PORT" ]; then
    LISTEN_PORT=10050
fi

# Zabbix agent simple installation
apt-get install zabbix-agent
# change configuration file
cat > /etc/zabbix/zabbix_agentd.conf << EOF
# simple core config file
#
# address of the server
Server=$ZABBIX_SERVER
ServerActive=$ZABBIX_SERVER
# port for Zabbix
ListenPort=$LISTEN_PORT
# hostname 
Hostname=$SRV_HOSTNAME
#Hostname=$(hostname -f)
# pid and logs
PidFile=/var/run/zabbix/zabbix_agentd.pid
LogFile=/var/log/zabbix-agent/zabbix_agentd.log
LogFileSize=0
EOF
# restart the zabbix agent
service zabbix-agent restart 
# check agent status
service zabbix-agent status
# show a little ip4 addresses for Zabbix server
echo "######################################"
echo "# Information about IP addresses #####"
echo "######################################"
echo "Server ipv4 addresses:"
ip addr show | grep "inet "

Сейчас пока задач по доработкам нет — свои задачи скрипт выполнил, но некоторые мысли есть...

• * сейчас скрипт не проверяет OS и отработает только под Debian-подобной системой (поскольку CentOS и других под рукой уже нет — дописывать и проверять сложно, пока отложено);
• * скрипт не проверяет установлен ли сейчас какой-то агент, он просто перезапишет конфиг (не очень ясно, насколько это востребованная история);
• * скрипт не проверяет занятость порта (отсылка к предыдущему пункту по сути);
• * скрипт не использует сертификаты или PKI (при наличии задачи возможно стоило бы использовать);
• * при однородности серверов мониторинга можно было бы наверное использовать фиксированные значения или давать выбор (здесь опущено для универсальности, серверы были разные);
• * возможно стоило бы подумать и усложнить конфигурационный файл агента (стоит обдумать опции на досуге);

Третьего дня привезли чудесные агрегаты — 27-дюймов, 2к экран, колонки, камера, процессор Core i7-10700T, 16Гб памяти на борту, SSD 512Gb, а также nVidia GTX1650 4GB. Ждали мы эту пару довольно долго, оказалось, довольно таки не частые экземпляры. Но вот беда, комплектовались они Windows 10 Home...

Но беда — не беда, т. к. сменить версию почти всегда (на самом деле нет, не всегда, но часто) можно штатными методами и без переустановки.

Шаг 1 — Нажимаем WIN + R.
Шаг 2 — Вызываем slui.exe
Шаг 3 — Запускаем
Шаг 4 — Вводим ключ для Windows 10 Pro (обычно не прокатывает, что удивительно!), если это так, то используем стандартный ключ — VK7JG-NPHTM-C97JM-9MPGT-3V66T.
Шаг 5 — Нюанс, если есть ругать на ключ, а у меня так было — отключаемся от интернетов и вводим ключ повторно, после чего перезагружаемся.

Возникла задача добавить несколько десятков пользователей в Яндекс.Коннект и сразу же начались поиски пути решения, чтобы избавиться от ручного труда и в дальнейшем облегчить жизнь. Решил попробовать вариант от Energys — статья на habr’e. Почему попробовать? За пару лет что-то могло перестать работать, как говорится — «За время пути собака могла подрасти!»

С первого взгляда не понравилось то, что пароли у сотрудников будущих одинаковые — это обязательно нужно было поменять, плюс не указана должность — потребовалось добавить. Однако для общего понимания статья подходит как нельзя лучше. К тому же изменения сравнительно не сложные — готовимся и применяем.

Самое не простое в этой истории — возня с токеном от Яндекса. В статье она описана, пройдем по шагам для истории и чтобы ничего не забыть:

• * зайти в аккаунт яндекса под администратором домена;
• * в Я.OAuth первым делом нужно создать приложение;
• * приложению даем права, в нашем случае — Яндекс.Коннект Directory API;
• * выбираем платформу «веб-сервисы» и нажимаем «подставить url для разработки»;
• * сохраняемся и получим ID приложения — именно оно понадобится для получения токене;
• * вставляем ID приложения и получаем токен:

https://oauth.yandex.ru/authorize?response_type=token&client_id=<ID приложения>

• * именно этот токен и будет использоваться в скрипте;

Идея сравнительно не сложная:

1. готовим файл определенного образца;
2. добавляем переменных;
3. читаем список из файла;
4. в запросе в цикле добавляем переменные;
5. в каждой итерации ждем пару секунд.

Сам скрипт выглядит следующим образом — он же на GitHub:

#!/bin/bash
# path to users list - путь к списку пользователей
employees='./usrlist'
# line example from users list - пример строки файла 
# usrlist: email_lastname_firstname_middlename_password_position
# for example: petrova_Петрова_Авдотья_Федоровна_eeKrutoiparol23_Менеджер

# OAuth_Token
# link to material about token - ссылка на формирование отладочного токена
# https://tech.yandex.ru/oauth/doc/dg/tasks/get-oauth-token-docpage/
# link about our apps - список ваших приложений
# https://oauth.yandex.ru/
# get token from apps id - получить токен из ID приложения
# https://oauth.yandex.ru/verification_code#access_token=435843755894374389
TOKEN="token-here-and-there"

# read and trim user file - читаем и перебираем файл со списком пользователей
for i in $( cat $employees ); do
value=($(echo $i | tr "_" " "))

# make variables for api request from file - заводим переменные для запроса из файла
email="${value[0]}"
lastname="${value[1]}"
firstname="${value[2]}"
middlename="${value[3]}"
password="${value[4]}"
position="${value[5]}"

# Make user for good - создаем сотрудника ради добра
# department = 1 for default - департамент 1 умолчанию
#only http answers, not full - только http ответы, не полный лог
curl -i -X POST -H 'Content-type: application/json' -d '{"department_id": 1, "position": "'$position'", "password": "'$password'", "nickname": "'$email'", "name": {"first": "'$firstname'", "last": "'$lastname'", "middle": "'$middlename'"}}' -H "Authorization: OAuth $TOKEN" 'https://api.directory.yandex.net/v6/users/' | grep HTTP
#full answers - полные ответы
#curl -i -X POST -H 'Content-type: application/json' -d '{"department_id": 1, "position": "'$position'", "password": "'$password'", "nickname": "'$email'", "name": {"first": "'$firstname'", "last": "'$lastname'", "middle": "'$middlename'"}}' -H "Authorization: OAuth $TOKEN" 'https://api.directory.yandex.net/v6/users/' 
# wait for 2 sec - ждем пару секунд
wait 2
done

C чем удалось столкнуться при отладке и работе скрипта? Буквально несколько моментов:

• * если посылать запросы слишком часто, часть может не сработать — нужно подбирать тайминги между запросами.. пауза в 1-2 секунды работает;
• * обязательно нужно смотреть на входные данные — аккуратность с символами в названиях важна;
• * моя частая ошибка — 422 Unprocessable Entity — при разборе оказалось, что пароль был слишком простой;

Не так давно мне удалось попасть на официальный курс MTCSWE (MikroTik Certified Switching Engineer) к Дмитрию Скоромнову. На сколько понимаю первый или один из первых в этой стране. Курс был интересен мне тем, что там ожидалось раскрытие темы VLAN целиком и полностью, плюс работа с коммутаторами от «рижских парней», которых из новых у меня в хозяйстве пока нет.

Обучение проходило в районе Красных Ворот, недалеко от Басманного суда, в центре PM Expert. К помещению никаких претензий нет. Все сравнительно удобно — как столы, так и внутренность. Перекур тоже можно провести недалеко. Столы бы только побольше, чтобы можно было капитально разложиться, но здесь, как говорится, чем богаты.

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

Материалы традиционно были авторские, традиционно цветные и сшитые на пружине. Не кислый такой томик на 138 страниц плюс лабораторные работы на 98 страниц. Большая подборка по курсу MTCSWE с глубоким погружением в материал. Без преувеличения — информации дается много: как и теоретической, так и практической. Теории по L2 довольно таки много, как по мне. MTU например весьма глубоко рассматривается. Также подробно идет (R/M) STP, ARP, VLAN.

Не очень понравилось, как мы попали с таймингом по времени про VLAN — начали мы их во второй половине дня в субботу и продолжили в воскресенье.. их бы все-таки на более свежую голову разбирать. Особенно когда речь идет уже о практике. В лабораторных работах были задания на анализ ситуации, с которыми видимо особо не сталкивались и получалось — ну мы посмотрели, так не заводится или заводится с нагрузкой. Немного сбивало с толку :)

Сразу скажу, что сам экзамен я не сдал. Мне удалось набрать только 53%. Не смотря на качественный подход, практических умений не хватило все-таки. Сложности обещали сразу, видел комментарии, что экзамен не простой. Сам только не представлял насколько. Традиционно на экзамен дается час времени и 24 вопроса (хотя почему-то пишут про 25). Вопросы снова по традиции с закавыками на один выбор или множественный выбор. Самая большая засада для меня была с нехваткой времени — на перепроверку ответов его тоже не хватило, разбором типовых конфигураций с VLAN’ами и расчетами по RSTP. Без практического опыта, полученного и переваренного предварительно — сложно. Теперь, когда стали понятны слабые стороны, можно будет подготовиться лучше и попробовать сдать повторно. Надеюсь, что во второй раз результат получится более приятный. Менее болезненным для меня, как слушателя — повторное обучение в случае неудачной сдачи экзамена у Дмитрия проходит полностью бесплатно. Такие риски он на себя берет — дает возможность укрепить знания и полноценно сдать экзамен.

PS: Большое спасибо Дмитрию, что решился читать реально непростой курс. А также было здорово увидеться с коллегами, с которыми были знакомы исключительно заочно :-)

Второго дня в версии 6.47 ветки stable завезли поддержку DoH (DNS over HTTPS). До этого оно было только в ветке с beta и использовать ее не очень хотелось в виду отсутствия стабильности. Почему это так важно? Дело в том, что DNS без каких-либо дополнений дает возможность вышестоящему провайдеру смотреть и подменять dns-запросы. Не видно причин, зачем ему давать такое делать. А также есть некая простота в том, что теперь свои dns-запросы не нужно заворачивать в тот же VPN.

DNS поверх HTTPS (DoH) — протокол для выполнения разрешения DNS по протоколу HTTPS. Целью этого метода >является повышение конфиденциальности и безопасности пользователей путём предотвращения перехвата и >манипулирования данными DNS с помощью атак типа «Атака посредника».

Первым делом нужно обновиться до 6.47 в ветке stable (или воспользовать beta). В случае с long-term стоит либо потерпеть и подождать или переключиться на stable.

Далее идем в IP -> DNS. Сразу же стоит обратить внимание, что вы можете получать DNS динамически (вышестоящий провайдер или настройки APN) и надо бы убрать автоматику. Чаще всего выглядит это как-то так:

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

/tool fetch url=https://erza.ru/cert/cacert.pem
/certificate import file-name=cacert.pem passphrase=""

Также список корневых сертификатов можно взять на сайте haxx.se или же с DigiCert

После чего удалим лишние dns-серверы и впишем свои. В итоге у нас все выглядит вот так:

Провести проверку можно с помощью torch или в connection tracker:

Список DoH серверов — смотреть тут, но самые популярные скорее всего будут Google ( https://8.8.8.8/dns-query ) и Cloudflare ( https://1.1.1.1/dns-query ).

Тестируем и проверяем на сайте Cloudflare

На всякий случай привожу листинг команд:

/tool fetch url=https://erza.ru/cert/cacert.pem
/certificate import file-name=cacert.pem passphrase=""
/ip dns set use-doh-server=https://1.1.1.1/dns-query
/ip dns set verify-doh-cert=yes
/ip dns set servers=""

UPDATE: Никита Тарикин набросал еще более интересную штуку со скриптом и поворотами — MikroTik DNS-over-HTTPS CloudFlare :)

С выходом Winbox 3.22 появился в этой чудесной программе Legacy Mode, который позволяет, не смотря на усилия инженеров, подключаться менее защищенными методами к роутерам с RouterOS младше версии 6.43. Довольно полезная фишка для тех, кто не может или не хочет обновляться. Стоит заметить, что она выключена по умолчанию, включается впрочем просто:

Так что если вдруг видите ошибку — router does not support secure connection please enable legacy mode — знаете, что нужно включить.