Я на днях писал про программу для построения съемы локальной сети Scanopy. И так совпало, а может и не совпало, а авторы читают мой канал, что мне написали авторы программы 10-Strike LANState. У них вышла бесплатная Pro версия на 25 хостов, которой раньше не существовало. Были только платные.

Это старая и известная компания в кругах офисных системных администраторов. Про один из их продуктов я когда-то давно писал - 10-Страйк Мониторинг Сети. Этим программам очень много лет, они выглядят старомодно и передают привет из двухтысячных. Но тем не менее до сих пор поддерживаются и работают на современных системах, стоят недорого, есть в реестре отечественного ПО.

Я установил себе 10-Strike LANState и настроил схему домашней сети. В этот раз не поленился и аккуратно всё добавил, изучил, попробовал.

У меня впечатления двойственные. С одной стороны всё работает, возможностей много, 25 хостов добавить можно. Программа просканировала сеть и добавила все узлы. Дальше я уже вручную доделывал. С другой стороны выглядит она так себе, интерфейс неотзывчивый, иконки очень старые, их мало. Их можно и самому загрузить, возможность есть, но кому захочется этим заниматься?

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

➕ Программа легко и быстро настраивается. Windows like стиль установщика и настройки мышкой в менюшках.
➕ Есть индикация хостов в режиме реального времени. По сути эта программа очень похожа на Friendly Pinger. У меня кто-то недавно спрашивал, есть ли какой-то современный аналог этой программы. Вот это он и есть.
➕ В LANState можно включить встроенный веб сервер и смотреть интерактивную карту через браузер.
➕ Через LANState можно быстро выключать виндовые компьютеры. Мне лично это удобно, так как перед сном обычно проверяю, чтобы всё выключено было.

Теперь минусы:
➖ Бесплатная версия работает как обычная программа под Windows, даже не служба. Сглаживает это тот факт, что разработчики поддерживают работу через Wine. То есть на Linux её запустить тоже можно.
➖ Интерфейс, как я уже сказал, на любителя. Настойка иконок, подписей и связей немного неинтуитивна. Я привыкал какое-то время, пока настраивал.
➖ Для завершения работы постоянно приходится вводить учётную запись на компьютере. Нет возможности сохранить.
➖ Не знаю, на чём написана программа, но интерфейс подтормаживает, неотзывчивый.

А вообще, эта программа очень функциональная. Там много всего реализовано:
◽️Базовый мониторинг стандартных метрик, плюс расширение своими скриптами. Через программу можно ходить по WMI или SSH, выполнять запросы. Для каждого узла можно свой дашборд собирать с метриками.
◽️Метрики можно выносить в интерактивном режиме на схему.
◽️LANState может выступать в виде Syslog сервера и принимать логи. Я так понимаю, это для сетевых устройств сделано. Для них же поддерживаются запросы по SNMP, чтобы собирать метрики. Помимо метрик, можно забирать конфигурации и некоторые другие вещи. Есть встроенная поддержка популярных вендоров, в том числе Mikrotik.
◽️Можно выполнять задачи по расписанию. Например, выключать все компьютеры в какое-то время.
◽️Можно настроить действие при двойном клике по узлу. Например, открыть веб страницу, RDP соединение или что-то ещё.
◽️Можно добавить сетевые диски, мониторить их доступность.

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

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

❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.

———
ServerAdmin: 📱 Telegram | 🌐 Сайт | 📲 MAX

#мониторинг #отечественное

Для тех, кто работал с OpenVPN, привычен метод аутентификации на основе клиентских сертификатов, который используется там по умолчанию. В веб сервере Angie ровно эти же сертификаты можно использовать для аутентификации клиентов при доступе к закрытым сервисам.

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

Для реализации подобного метода понадобится свой CA для выпуска сертификатов, сертификат сервера, сертификаты клиентов. Подойдёт любая инструкция для OpenVPN, где делается всё то же самое. В качестве программы для работы с сертификатами можно использовать:

◽️Easy-RSA - популярный набор скриптов на базе openssl.
◽️Step-CA - своя локальная служба для управления CA с простой автоматизацией перевыпуска.
◽️CFSSL - современная одиночная утилита от CloudFlare с конфигами в формате json.
◽️XCA - кроссплатформенное приложение с GUI, в отличие от предыдущих вариантов консольных команд.

Для простоты и краткости команд я возьму Easy-RSA. Но если вы хотите в графическом интерфейсе всё делать, то берите XCA. Принцип там такой же.

Ставим Easy-RSA:

# apt install easy-rsa

Создаём свой CA:

# make-cadir /etc/angie/easy-rsa
# cd /etc/angie/easy-rsa
# ./easyrsa init-pki
# ./easyrsa build-ca

По умолчанию сертификат для CA выпускается на 10 лет, остальные - на 825 дней. Сделаем остальные тоже 10-ти летними. Добавляем в файл vars параметр:

set_var EASYRSA_CERT_EXPIRE 3650

Заодно увеличим время жизни списка отозванных сертификатов до года. Я не знаю, как ведёт себя Angie, но OpenVPN перестаёт принимать новые аутентификации, когда файл отзывов протухает.

set_var EASYRSA_CRL_DAYS 365

Остальные параметры меняйте по своему усмотрению. Они некритичны. Выпускаем сертификаты и ключи для сервера и первого клиента:

# ./easyrsa build-server-full server nopass
# cp /etc/angie/easy-rsa/pki/issued/server.crt /etc/angie
# cp /etc/angie/easy-rsa/pki/private/server.key /etc/angie
# ./easyrsa build-client-full client01 nopass

Для передачи клиенту сертификат и ключ от него надо упаковать в один контейнер формата PKCS12:

# openssl pkcs12 -export -in /etc/angie/easy-rsa/pki/issued/client01.crt -inkey /etc/angie/easy-rsa/pki/private/client01.key -out client01.p12

Передаём client01.p12 клиенту. Готовим конфигурацию виртуального сервера Angie. Показываю на примере конфигурации default.conf с доступом по IP:

server {
  listen    443 ssl;
  server_name localhost;

  access_log /var/log/angie/host.access.log main;

  ssl_certificate   /etc/angie/server.crt;
  ssl_certificate_key /etc/angie/server.key;
  ssl_client_certificate /etc/angie/easy-rsa/pki/ca.crt;
  ssl_crl /etc/angie/easy-rsa/pki/crl.pem;
  ssl_verify_client on;

  location / {
    root  /usr/share/angie/html;
    index index.html index.htm;
  }
}

Перезапускаю веб сервер:

# angie -t
# angie -s reload

Захожу на веб сервер по IP - получаю ошибку: "400 Bad Request
No required SSL certificate was sent".

Надо добавить сертификат в браузер. В Яндекс.Браузере это делается в разделе Настройки ⇨ Системные ⇨ Сеть ⇨ Управление сертификатами ⇨ Импорт ⇨ Выбираем скопированный файл client01.p12.

Теперь мы попадаем на стандартную страницу веб сервера. Если нужно запретить доступ пользователю - отзываем его сертификат:

# ./easyrsa --batch revoke client01
# ./easyrsa gen-crl
# angie -s reload

Эти команды обновят файл отзывов crl.pem, который проверяет веб сервер. Последний надо обязательно заставить перечитать конфигурацию, иначе он не примет изменения. Теперь client01 получит ошибку доступа: "The SSL certificate error".

Простая и удобная аутентификация. Берите на вооружение.

❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.

———
ServerAdmin: 📱 Telegram | 🌐 Сайт | 📲 MAX

#angie

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

Называется Tower Networking Inc. - симулятор интернет провайдера, где нужно управлять сетевой инфраструктурой в жилом комплексе. Вам предстоит прокладывать кабели (👹🙈), настраивать свитчи и роутеры, устранять неисправности и многое другое, что сопровождает подобную деятельность.

Игра выглядит аутентично и атмосферно. Вот некоторые отзывы о ней:

Шедевральная игра. Она просто обязана быть у всех ценителей. Парадоксально, что её абсолютно не хочется пройти до конца. Ты просто не хочешь, чтобы она заканчивалась. Один единственный минус-как только ты сел играть-ты попал в ловушку времени.

Подойдет любому инженеру, который не умеет отдыхать после реальной галеры.

За 12 часов игры узнал больше чем за пять лет университета.

Слава Омниссии, теперь я могу админить пользователей и поддерживать вечно отказывающую сетку не только на работе, но и дома! Нет, не так, я же на удалёнке, я и так из дома её админю... Я могу ОДНОВРЕМЕННО админить сетку и там, и там! Дурка, ♥️♥️♥️♥️♥️! Будучи системным администратором, я одобряю! Лучшее наглядное, пусть и крайне упрощённое, пособие о работе сисадмина.

Хоть где-то в жизни пригодились знания о настройке циски, которые я получил ещё лет 10 назад.

Думаю, по комментариям идею вы поняли 😄. Вот ещё по этой теме, кому мало работы и хочется добрать сисадминства дома:

⇨ ServiceIT: You can do IT
⇨ SysAdmin Odyssey - Back to the office
⇨ IT Specialist Simulator

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

🎮 Steam / ▶️ Игровой процесс

———
ServerAdmin: 📱 Telegram | 🌐 Сайт | 📲 MAX

#игра

На днях проскочила новость о том, что Let's Encrypt запускает выпуск сертификатов на IP адреса. Меня это сразу заинтересовало, так как давно думал, почему этого нельзя сделать. Мне нередко хотелось выпустить сертификат на IP адрес, чтобы нормально работал запущенный на нём сервис, для которого нет необходимости делать доменное имя.

Сейчас многий софт без TLS и доверенного сертификата не хочет подключаться в принципе. Если выпускаешь самоподписанный сертификат, то надо настраивать доверие через передачу сертификата CA на целевую машину. Всё это создаёт неудобства, особенно в тестовой среде.

И вот теперь эта проблема решена. Можно взять виртуалку с внешним IP адресом и выпустить для него подтверждённый сертификат. Я сразу же решил проверить, как это работает.

Мне больше всего нравится certbot как клиент для взаимодействия с Let's Encrypt, хотя я пробовал и использовал все известные клиенты. К сожалению, у него пока не вышла стабильная версия с поддержкой этой новой функциональности. Проверял версию 4.0.0 из пакетов Debian 13, и самую свежую 5.2.2 из docker hub. Нет поддержки новых сертификатов. При запросе ошибка:

The Let's Encrypt certificate authority will not issue certificates for a bare IP address.

Сразу показываю рабочий вариант с использованием acme.sh. От установки, до выпуска сертификата:

# git clone https://github.com/acmesh-official/acme.sh.git
# cd ./acme.sh
# ./acme.sh --install -m zeroxzed@gmail.com
# ./acme.sh --issue -d 85.143.175.116 --standalone --server letsencrypt --certificate-profile shortlived

Получаем набор файлов для использования по назначению:

◽️ ~/.acme.sh/85.143.175.116_ecc/85.143.175.116.cer
◽️ ~/.acme.sh/85.143.175.116_ecc/85.143.175.116.key
◽️ ~/.acme.sh/85.143.175.116_ecc/fullchain.cer

Устанавливаем веб сервер, прописываем там в виде доменного имени IP адрес, подключаем этот сертификат. Пример для Angie/Nginx:

# mkdir -p /etc/nginx/tls
# ./acme.sh --install-cert -d 85.143.175.116 --key-file /etc/nginx/tls/85.143.175.116.key --fullchain-file /etc/nginx/tls/85.143.175.116.cer --reloadcmd "systemctl reload nginx"

Рисуем примерно такую конфигурацию для доступа по IP адресу:

server {
  listen 80 default_server;
  listen 443 ssl default_server;

  ssl_certificate /etc/nginx/tls/85.143.175.116.cer;
  ssl_certificate_key /etc/nginx/tls/85.143.175.116.key;

  root /var/www/html;
  index index.html index.htm index.nginx-debian.html;

  server_name _;

  location / {
    try_files $uri $uri/ =404;
  }
}

Заходим по HTTPS на IP адрес сервера и видим действительный сертификат. Никаких предупреждений.

Сертификат выдаётся менее чем на 7 дней, так что нужно внимательно следить за автоматическим обновлением. Описанных в заметке настроек достаточно для этого. Acme.sh добавил задание в cron пользователя, будет запускаться раз в сутки.

Удобная и функциональная возможность. Берите на вооружение. Не знаю, поддерживает ли получение таких сертификатов Angie напрямую, через свой встроенный клиент. Я не проверял. Если у кого-то есть информация, поделитесь.

❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.

———
ServerAdmin: 📱 Telegram | 🌐 Сайт | 📲 MAX

#webserver #angie #nginx

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

Мне один раз досталась в наследство компания, где периодически падал локальный DNS сервер. Когда это случилось первый раз, было стрёмно. Я ещё только изучал инфраструктуру. Там и кластер виртуализации был, и DRBD диски, и домен на Samba. Разом всё сломалось, мониторинг спамит, пользователи жалуются техподдержке, она теребит меня. Быстро догадался зайти по IP на сервер и перезапустить тогда ещё использовавшийся Bind, если не ошибаюсь. Потом уже всё перенастроил, но Bind успел упасть ещё пару раз. На серваке, где он работал, как потом выяснилось, банально кончалась память.

Сам я потом тоже использовал какое-то время Bind, потом перешёл на DNSmasq, если в инфре была винда, то использовал её DNS сервер, если есть железный роутер, то DNS сервер обычно на нём. На базе DNSmasq собран небезызвестный Pi-hole. Я немного пользовался им, даже запускал его в контейнере на Mikrotik. В итоге отказался, так как всё это ненадёжно работало на моём железе.

Длинная подводка получилась. Рассказать хотел о новом для меня DNS сервере - Technitium DNS. Впервые увидел его в недавнем обзоре. По описанию понравилось, поэтому решил попробовать. Особенно привлекла простая возможность собрать полноценный (но однонаправленный) кластер. Я всё это развернул у себя, в том числе и кластер, и протестировал. DNS сервер понравился. Думаю, что при необходимости буду использовать именно его, если нужен будет сервер с веб панелью управления, статистикой, разграничением доступа, блокировками по готовым спискам и т.д.

Technitium DNS - современный сервер, который поддерживает всевозможные технологии и настройки:

▪️DNS-over-TLS, DNS-over-HTTPS, and DNS-over-QUIC, DNSSEC.
▪️Блокировки по готовым спискам доменов.
▪️Быстрый запуск через готовый Docker контейнер (есть и другие способы).
▪️Расширение функциональности через встроенный магазин приложений (может, к примеру, логи запросов писать в MySQL).
▪️Встроенный DHCP сервер.
▪️Управление доступом на основе ролей (RBAC).
▪️API с доступом по токенам.
▪️Поддержка работы через HTTP и SOCKS5 прокси.

В этом сервере есть всё, что можно только придумать и желать от современного программного продукта. Я пробежался по огромному списку возможностей и не придумал, чего там не хватает.

При этом, всё это настраивается очень просто, особенно в базовой функциональности. Я развернул на двух нодах и собрал сервер в кластер. Использовал следующий docker-compose.yml, изменив только имя хостов:

services:
 dns-server:
  container_name: technitium-01
  hostname: technitium-01
  image: technitium/dns-server:latest
  ports:
   - "5380:5380/tcp" # Web console (HTTP)
   - "53:53/udp"   # DNS service
   - "53:53/tcp"   # DNS service
   - "53443:53443/tcp" # Web console (HTTPS)
   # - "853:853/udp"   # DNS-over-QUIC
   # - "853:853/tcp"   # DNS-over-TLS
   # - "443:443/udp"   # DNS-over-HTTPS (HTTP/3)
   # - "443:443/tcp"   # DNS-over-HTTPS (HTTP/1.1, HTTP/2)
   # - "67:67/udp"    # DHCP service
  environment:
   - DNS_SERVER_DOMAIN=home.local
   - DNS_SERVER_ADMIN_PASSWORD=your_password
   - DNS_SERVER_PREFER_IPV6=false
   - DNS_SERVER_RECURSION=AllowOnlyForPrivateNetworks
   - DNS_SERVER_FORWARDERS=62.76.76.62,77.88.8.1,62.76.62.76,77.88.8.8
  volumes:
   - ./config:/etc/dns
  restart: unless-stopped
  sysctls:
   - net.ipv4.ip_local_port_range=1024 65000

Запустил, зашёл на веб интерфейс http://server-ip:5380/, собрал в кластер, настроил списки блокировки и другие настройки. Подключил нескольким пользователям. Проверил - отлично работает, никаких проблем не возникло. Выключил одну ноду, кластер продолжил работать на второй, запросы резолвил.

Продукт однозначно хорош. Я не знаю, что сейчас есть лучше для рекурсивного кэширующего DNS сервера. Если знаете - подскажите.

❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.

———
ServerAdmin: 📱 Telegram | 🌐 Сайт | 📲 MAX

#dns