В последнее время Proxmox практически безальтернативно занял нишу одиночных хостов и небольших кластеров виртуализации на базе QEMU+KVM. Но не Проксмоксом единым живо это направление. Я застал времена, когда Proxmox только начал развиваться и не был распространён.

В то время знакомство c KVM я начинал с управления через консоль с помощью libvirt. А подключение к консоли непосредственно виртуалок осуществлялось по VNC. Потом перешёл на Virt-Manager и какое-то время пользовался им. Позже уже перешёл на Proxmox.

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

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

📌 Основные возможности Incus:

▪️Запуск LXC, Docker контейнеров, виртуальных машин на базе QEMU+KVM.
▪️Использование образов контейнеров и виртуальных машин на базе проекта linuxcontainers.org.
▪️Создание кластера из десятков хостов. Сразу скажу, что кластер не тестировал, хотя хочется. Но на это надо много времени.
▪️Управление через веб-интерфейс как одиночными хостами, так и кластером.
▪️Поддержка всевозможных хранилищ: директория на хосте, zfs, lvm, btrfs, ceph, cephfs, linstor, truenas.
▪️Поддержка сетевых технологий: Linux Bridge, OVN, Macvlan, SR-IOV.
▪️Incus может сам управлять IP адресами (IPAM) на базе dnsmasq, сам реализует NAT для выхода виртуалок и контейнеров во внешнюю сеть.
▪️Устанавливается поверх любой Linux системы, может запускаться в Docker.

Я установил Incus на одиночный хост с Debian 13. Установка максимально простая:

# apt install incus incus-base qemu-system

Если нужны только контейнеры, то пакет qemu-system можно не ставить. Это я установил только консольную службу. Без веб интерфейса. Его ставить необязательно. Для простых конфигураций можно очень легко обойтись без него.

➕ Отсюда сразу вытекает первый плюс по сравнению с Proxmox. Вы можете как угодно подготовить хост в плане дисковой подсистемы и окружения. Это помимо того, что Incus более легковесный.

После установки нужно выполнить инициализацию. Для управления Incus можно создать отдельного пользователя и запуcкать всё от него, но я всё сделал от root:

# incus admin init

Вам зададут несколько вопросов на тему сети и хранилища. Я выбрал настройки по умолчанию: обычный bridge с именем incusbr0 и хранилище в локальной директории, по умолчанию это /var/lib/incus/storage-pools.

Теперь можно посмотреть, какие готовые образы мы можем использовать:

# incus image list images:

Образов много. Более конкретно можно посмотреть так:

# incus image list images:debian
# incus image list images:alt
# incus image list images:ubuntu

и т.д.

Запустим контейнер:

# incus launch images:debian/13 debian-ct --storage default

Он будет автоматически подключен к incusbr0, ему будет выдан IP адрес из диапазона внутренней сети, он будет иметь доступ к интернету. Зайти в контейнер можно так:

# incus exec debian-ct -- bash

То же самое для виртуальной машины Ubuntu или Alt:

# incus launch images:ubuntu/noble ubuntu-vm --vm --storage default
# incus launch images:alt/Sisyphus alt-vm --vm --storage default

Заходим в виртуалки так же:

# incus exec ubuntu-vm -- bash

Другие полезные команды:

# incus ls
# incus info ubuntu-vm
# incus profile show default
# incus storage list
# incus network list

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

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

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

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

#incus #виртуализация

Продолжаю тему с Incus. В первой заметке я разобрал запуск и управление через CLI. Теперь разберу веб интерфейс.

Изначально я пошёл по сложному пути и запустил веб интерфейс через найденный контейнер Docker. Использовал простой Docker-Compose:

services:
  lxconsole:
   image: 'penninglabs/lxconsole:latest'
   restart: unless-stopped
   ports:
   - '80:5000'
   volumes:
   - ./backups:/opt/lxconsole/backups
   - ./certs:/opt/lxconsole/certs
   - ./server:/opt/lxconsole/instance

Всё в целом завелось, зашёл на 80-й порт, зарегистрировал учётку и начал настраивать. Этот веб интерфейс рассчитан в том числе на управление кластером или набором нод. Можно их по отдельности добавлять и переключаться. Но так как я использовал в тестовом окружении самоподписанные сертификаты, у меня не работало подключение к консоли виртуальных машин и контейнеров. И некоторые другие вещи, связанные с WebSocket. То есть этот способ рабочий, но нужно настраивать нормальное соединение по HTTPS.

Я какое-то время помучался и нашёл более удобный и простой вариант для одиночного сервера. Есть репозиторий Zabbly со всеми пакетами для incus:

⇨ https://pkgs.zabbly.com/incus/stable/pool/main/i/incus/

Можно скачать одиночный пакет с веб интерфейсом и установить. Примерно так:

# wget https://pkgs.zabbly.com/incus/stable/pool/main/i/incus/incus-ui-canonical_6.17-debian11-202510101456_amd64.deb
# dpkg -i incus-ui-canonical_6.17-debian11-202510101456_amd64.deb

Либо подключить репозиторий и установить оттуда:

# curl -fsSL https://pkgs.zabbly.com/key.asc -o /etc/apt/keyrings/zabbly.asc
# sh -c 'cat <<EOF > /etc/apt/sources.list.d/zabbly-incus-lts-6.0.sources
Enabled: yes
Types: deb
URIs: https://pkgs.zabbly.com/incus/lts-6.0
Suites: $(. /etc/os-release && echo ${VERSION_CODENAME})
Components: main
Architectures: $(dpkg --print-architecture)
Signed-By: /etc/apt/keyrings/zabbly.asc

EOF'
# apt install incus-ui-canonical

После установки добавляем в юнит systemd настройку веб интерфейса:

# systemctl edit incus.service

[Service]
Environment = INCUS_UI=/opt/incus/ui/

Сохраняем, перечитываем конфиг и перезапускаем:

# systemctl daemon-reload
# systemctl restart incus

Разрешаем подключаться к incus извне:

# incus config set core.https_address :8443

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

Покажу пример, как настроить проброс порта внутрь виртуалки. Для примера возьму VM ubuntu24 c IP 10.253.116.184. Проброшу в неё порт 80 с внешнего IP адреса ноды 192.168.137.14.

Иду в раздел Networks, выбираю бридж incusbr0, перехожу на вкладку Forwards. Добавляю Forward:

◽️Listen address: 192.168.137.14
◽️Listen port: 80, Protocol: TCP
◽️Target address: 10.253.116.184
◽️Target port: 80

То же самое через консоль:

# incus network forward port add incusbr0 192.168.137.14 TCP 80 10.253.116.184 80

Сравните с тем, как это выглядит в Proxmox.

Проект в целом мне понравился. Причём без каких-то компромиссов. Для одиночного хоста он удобнее Proxmox. Тут более простой и наглядный IPAM, с которым не надо разбираться. Раздача IP адресов и NAT работают сразу. Проброс портов внутрь виртуалок тоже делается очень просто через веб интерфейс. В Proxmox всё это настраивается сложнее. Причём заметно сложнее. Для проброса портов придётся писать правила для iptables.

Если у вас есть жирная виртуалка с включённой вложенной виртуализацией, а она у некоторых хостеров включена, то вы можете на ней развернуть Incus и запускать виртуалки с контейнерами.

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

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

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

#incus #виртуализация

Расскажу про одну простую настройку в Nginx/Angie, которую использую постоянно, но с некоторыми нюансами, про которые возможно кто-то не знает. По крайней мере я не сразу об этом узнал. Речь пойдёт про basic_auth.

Я уже много раз упоминал про эту настройку, которая позволяет очень просто и быстро скрыть от посторонних глаз какой-то сервис с помощью простой аутентификации с использованием имени пользователя и пароля. Делается это примерно так:

# sh -c "echo -n 'user01:' >> /etc/nginx/.htpasswd"
# sh -c "openssl passwd -apr1 >> /etc/nginx/.htpasswd"

Создали файл .htpasswd, куда добавили пользователя user01 и задали ему интерактивно пароль. Теперь настраиваем Nginx/Angie, добавляя в секцию server или отдельной location настройку:

location / {
auth_basic "Access Denied";
auth_basic_user_file /etc/nginx/.htpasswd;
try_files $uri $uri/ =404;
}

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

Таким способом очень удобно скрывать различные непубличные сервисы или технические панели. Например, я всегда так закрываю публикацию баз 1C, доступ в Phpmyadmin, Zabbix, Grafana, Apache Guacamole, какую-нибудь веб панель для управления, если используется и т.д. В общем, всё, что не для широкой публики лучше скрыть от посторонних глаз.

Иногда хочется, чтобы кого-то пускало напрямую без аутентификации. Первое, что приходит в голову, добавить директивы allow и deny, потому что они тоже часто используются. По крайней мере я постоянно использую. Но они напрямую не работают с basic_auth, либо одно, либо другое. Нужен ещё один параметр - satisfy.

location / {
satisfy any;
allow 192.168.137.0/24;
deny all;
auth_basic "Access Denied";
auth_basic_user_file /etc/nginx/.htpasswd;
try_files $uri $uri/ =404;
}

В этом примере пользователи из подсети 192.168.137.0/24 зайдут на ресурс напрямую без аутентификации, а всем остальным нужно будет ввести пароль. Это удобно для той же публикации 1С, когда люди из офиса ходят напрямую в локальную базу, а снаружи с аутентификацией. В случае публикации на внешнем сервере удобно разрешить доступ с внешнего IP адреса офиса прямой доступ, а всем остальным с паролем.

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

Если нужно указать несколько подсетей и отдельных IP адресов, то их можно добавлять новыми строками, примерно так:

allow 192.168.0.0/24;
allow 10.20.5.0/24;
allow 185.25.48.189;

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

Basic_auth простая и надёжная технология. Не припоминаю, чтобы хоть раз была какая-то уязвимость в обход неё. Пароль можно только перехватить, если не используется HTTPS, либо сбрутить, но это трудно, так как во-первых, стоит настраивать ограничение в веб-сервере на количество одновременных запросов. Я всегда это делаю по умолчанию. Плюс, производительности веб сервера будет недостаточно, чтобы подбирать сложный пароль с хорошей скоростью. Это не локально брутить. По интернету несловарный сложный пароль не подобрать.

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

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

#nginx #angie

На днях в комментариях посоветовали отечественный open source продукт платформы виртуализации Open vAIR. Впервые о нём услышал, поэтому решил попробовать. Чтобы сразу было понятно, что это такое, назову его условным аналогом Proxmox и других подобных продуктов. Это полностью бесплатная платформа для запуска виртуальных машин от компании Aerodisk.

Сразу перечислю особенности Open vAIR:

◽️Это не дистрибутив, а софт, который ставится поверх системы. Разработчики рекомендуют Ubuntu. Я попробовал поставить на Debian, не получилось, не все зависимости установились автоматически. В планах поддержка отечественных дистрибутивов.
◽️Система построена на базе open source: FastAPI, PostgreSQL, RabbitMQ, QEMU, KVM, libvirt, Vue, OpenVSwitch, Restic.
◽️Умеет запускать только виртуальные машины, контейнеров нет.
◽️Поддерживает в качестве хранилищ: локальные диски, NFS, iSCSI и Fibre Channel.
◽️Сетевые возможности: Bridge, VLAN, порт-группы.
◽️Резервное копирование реализовано через Restic.
◽️Развитый REST API для управления.

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

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

Я развернул систему у себя. Процесс описывать не буду, так как всё делал строго по инструкции в репозитории. Там готовый скрипт, который всё делает автоматически. Отмечу, что продукт ставится с локальной документацией, которая построена на базе MkDocs. Ещё обратил внимание, что установку автоматически запускают в Tmux, что удобно и разумно. Первый раз вижу, чтобы кто-то об этом позаботился в установщике.

Запуск виртуалки выглядит следующим образом:

1️⃣ Добавляем хранилище. Им может выступать диск по NFS, локальный диск, или его раздел. Директория на уже используемом диске не поддерживается (почему? 🤷🏼‍♂️).
2️⃣ Создаём виртуальный диск. Поддерживаются форматы raw или qcow2. Диск можно создать заранее или в процессе создания виртуалки.
3️⃣ Загружаем ISO образ.
4️⃣ Создаём виртуальную машину. Для сети выбираем бридж, который создан автоматически в момент установки Open vAIR.

Функциональность пока очень простая - создание и запуск виртуалок. Больше ничего.

Теперь о проблемах, с которыми столкнулся. У меня не заработал VNC клиент для подключения к консоли виртуалки. Сначала думал, что браузер блокирует всплывающие окна. Отключил блокировку - не помогло. Потом подумал, что проблема в самоподписанном сертификате. Добавил в исключения, тоже не помогло. Пробовал в разных браузерах, везде одно и то же.

Открыл консоль браузера, там видно, что сервер возвращает 500-ю ошибку на нажатие на кнопку с VNC. Отловил запрос и запустил отдельно. Увидел в тексте ошибки упоминание о том, что нет lsof. Установил lsof на хост и VNC консоль заработала. Неочевидная ошибка. Не каждый догадается о решении.

Попробовал бэкапы. Сначала вообще не запускались, получал ошибку. Потом прочитал документацию и понял, что надо добавить в конфиг параметры репозитория для Restic. Добавил их, репозиторием сделал локальную директорию.

Сами бэкапы представляют из себя бэкап всех дисков виртуалок и дамп системной sql базы средствами Restic. Без каких-то изысков. Просто всё летит в репозиторий Restic. Мне не видится в таком виде это надёжным решением для запущенных VM. Не увидел создание снепшотов дисков во время бэкапа.

Впечатления от Open vAIR - продукт сырой и по функциональности очень куцый. В таком виде я не вижу ему применения, так как тот же Incus намного функциональнее, не говоря уже о Proxmox. Могу только пожелать разработчикам удачи в разработке, поддержке и добавлении функциональности.

Из плюсов отмечу приятный интерфейс и русский язык. Ну и то, что это в принципе open source продукт.

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

#виртуализация #отечественное

Сейчас появилось очень много программ для построения mesh-сетей. Это локальные сети поверх других сетей, где хосты могут соединяться друг с другом напрямую, если есть возможность. А каждый из членов сети может выступать маршрутизатором для доступа к другим ресурсами.

Известными представителями подобных продуктов являются Nebula, Tailscale, Netmaker, Netbird и ZeroTier. На последнем я бы хотел остановиться поподробнее. Он выделяется из этого списка своим протоколом передачи данных, в то время как остальные в основном используют WireGuard. Плюс, Mikrotik в RouterOS7 имеет реализацию, как клиента, так и своего контроллера на базе ZeroTier.

Я раньше только слышал про него, сам не пробовал. Решил исправить это, развернул и протестировал. Сразу скажу, что это не инструмент для обхода блокировок. Он не для этого придуман и в данной роли работает плохо. Не стоит эту тему развивать.

ZeroTier - платный SaaS сервис. Регистрируетесь, платите деньги и получаете личный кабинет для управления всеми своими сетями. Но при этом серверная часть выложена в open source. Каждый может развернуть свой локальный сервер и управлять им через CLI. Я немного изучил команды, там на самом деле всё относительно просто.

В связи с этим появилось очень много реализаций бесплатного веб интерфейса для управления сервером. Я недавно читал статью про настройку Self-Hosted ZeroTier с помощью интерфейса ZTNET, поэтому не стал смотреть другие интерфейсы, а их много, взял сразу этот. В целом, там всё необходимое для управления есть.

Запускаем так:

# wget -O docker-compose.yml https://raw.githubusercontent.com/sinamics/ztnet/main/docker-compose.yml
# sed -i "s|http://localhost:3000|http://$(hostname -I | cut -d' ' -f1):3000|" docker-compose.yml
# docker compose up -d

Можно и вручную всё это сделать. В репозитории есть описание. Теперь можно идти на 3000 порт сервера и регистрировать учётку админа.

Принцип объединения устройств в единую сеть следующий:

1️⃣ Скачиваете клиента под свою систему (есть под все, в том числе мобильные)
2️⃣ В клиенте указываете Network ID или сканируете QR код, который видно в веб интерфейсе. В этом ID, как я понял, закодирован IP контроллера.
3️⃣ Клиент подключается к серверу, на сервере вы подтверждаете его подключение.
4️⃣ Клиент получает IP адрес внутренней сети.

Я объединил Windows, Linux и Mikrotik. Получилось всё без проблем. Узлы сети сразу же напрямую увидели себя по внутренним адресам сети ZeroTier. Заработали RDP, SSH, Winbox.

Вы можете назначить Mikrotik шлюзом для какой-то подсети, которая находится за ним. Клиенты, которые подключатся к общей mesh-сети, могут ходить в ту сеть через него. А какой-нибудь Linux сервер назначить шлюзом для доступа в другую инфраструктуру. То есть каждый узел может выступать в роли и клиента, и шлюза для других. Настраивается это очень просто, буквально в несколько кликов в веб интерфейсе.

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

В ZTNET это отключается в разделе настроек ZT Controller, где вы можете создать так называемый Custom Planet, который будет работать только локально и никуда подключаться не будет. Вам нужно будет обеспечить к нему прямой доступ всех клиентов, либо опубликовав контроллер напрямую в интернете, либо пробросив к нему порт 9993/udp.

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

Продукт простой, функциональный, бесплатный и известный. Много кем поддерживается. Так что если нужно что-то подобное, то можете смело использовать. Единственное, я бы поискал какой-то другой GUI. Этот показался немного кривоват, хотя вся необходимая функциональность присутствует.

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

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

#vpn #network