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

Скажу своими словами, как мне видится эта ситуация. С одной стороны вроде ничего особенного не случилось, потому что код ядра всё равно открыт. Бери и пользуйся. Копируй ядро и вноси туда свои изменения.

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

Ядро Linux по факту является основой нашего импортозамещения на уровне операционных систем. Практически все они сделаны на нём. Теперь вырастет стоимость развития и поддержки.

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

С ядром Linux в России вряд ли наберётся ресурсов на самостоятельное развитие. Вот если бы с Китаем объединиться, думаю, результат бы был. Может и будет. Поживём - увидим. Всё идёт к тому, что интернет, как и весь мир, сегментируется. Уже и Linux скоро у каждого свой будет.

Причём видно, что кто-то специально создаёт условия, чтобы процессы по разделению развивались и множились. Выполняются необоснованные действия, которые вредят обеим сторонам. Кому выгода от того, что русских исключили из мэйнтейнеров? Ядру? Нет. У нас много хороших программистов, которые развивали это ядро в том числе. Самим русским? Тоже нет.

⇨ 'It's really hard to find maintainers...' Linus Torvalds

#разное

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

Я попытался немного разобраться с этой темой и сделал ряд тестов в виртуальных машинах. Основные сложности тут следующие:

1️⃣ Если просто писать данные на диск с уровня операционной системы Linux, то она будет их кэшировать, пока у неё достаточно оперативной памяти для этого. Если не учитывать этот момент, то результаты будут разными в зависимости от объёма оперативной памяти и размера записываемых данных.

2️⃣ Если речь идёт о виртуальных машинах, то там есть слой кэширования гипервизора.

3️⃣ Если используется аппаратный рейд контроллер, то там есть свой слой кэширования, плюс запись в несколько потоков может идти быстрее, чем в один.

На практике это выглядит так. Берём виртуальную машину на Proxmox с 1G оперативной памяти и виртуальным диском без кэширования. Пробуем тесты на запись с помощью dd и разных флагов:

# dd if=/dev/zero of=/tempfile bs=1M count=512
259 MB/s

# dd if=/dev/zero of=/tempfile bs=1M count=2000
247 MB/s

# dd if=/dev/zero of=/tempfile bs=1M count=2000 oflag=direct
240 MB/s

# dd if=/dev/zero of=/tempfile bs=1M count=2000 oflag=dsync
123 MB/s

# dd if=/dev/zero of=/tempfile bs=1M count=2000 oflag=sync
123 MB/s

Используются флаги:

▪️direct - прямая запись в обход файлового кэша и синхронизации
▪️dsync - запись данных с синхронизацией каждого блока, то есть ждём подтверждение диска об успешной записи
▪️sync - запись данных и метаданных с синхронизацией

Результаты меня удивили. Я всегда был уверен, что запись dd по умолчанию будет вестись в кэш ОС, если хватает оперативной памяти. Я провёл много тестов на разных виртуалках, в разных гипервизорах, с разным количеством памяти в VM. И везде запись нулей из /dev/zero на диск в кэш не попадала. Из-за большого количества тестов глаз замылился, и я не мог понять, в чём причина. Подумал уже, что по дефолту dd работает с флагом direct, но это не так.

Причина вот в чём. Если файл /tempfile уже существует, то запись ведётся напрямую, а если отсутствует и оперативы достаточно, то в кэш. Проверяем:

# dd if=/dev/zero of=/tempfile bs=1M count=200
231 MB/s
# rm /tempfile
# dd if=/dev/zero of=/tempfile bs=1M count=200
635 MB/s

Если взять ещё меньше файл, то скорость будет ещё больше:

# rm /tempfile
# dd if=/dev/zero of=/tempfile bs=1M count=100
1.6 GB/s

Если вы будете писать с помощью dd обычный файл, который полностью помещается в оперативную память, то тоже при первичной записи файл попадёт в кэш:

# dd if=/tempfile of=/tempfile2 bs=1M count=128
910 MB/s

Всё было записано в кэш. Скорость диска мы вообще не увидели. Для тестирования линейной скорости записи на диск обязательно используйте флаг direct или sync. Значения вы получите разные в зависимости от флага, но они точно будут без использования кэша ОС.

А теперь я включу кэширование диска (Write back) на уровне гипервизора и выполню тесты с direct:

# dd if=/dev/zero of=/tempfile bs=1M count=2000 oflag=direct
1.0 GB/s

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

Интересная тема. Пару часов проковырялся с тестами, документацией, статьями. Забыл упомянуть, что погонял тесты с помощью sysbench, используя те же размеры блока и их количества. Результаты полностью совпадают с dd.

❗️Если при тестах диска вы видите очень большой разброс в значениях, у вас 100% где-то что-то залетает в кэш. Я не раз слышал от знакомых и читателей замечания по этому поводу. Люди получают сильно разные результаты тестов и не понимают, как их интерпретировать. Могут из-за этого ошибочно посчитать одно хранилище или формат диска быстрее другого.

#linux #disk

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

Взял тестовый сервер Proxmox, в котором есть железный RAID контроллер без кэша и собранный RAID10 из 4-х HDD. Воткнул туда дополнительно обычный SSD AMD Radeon R5 R5SL480G 480ГБ. RAID10 подключил как обычный LVM storage, а SSD как LVM-Thin.

Нарезал там LV для хоста:

# lvcreate -V 10G -n test_ssd --thinpool SSD-RADEON/SSD-RADEON
# lvcreate -L 10G -n test_raid10 raid10

Сделал фс ext4 и смонтировал:

# mkfs.ext4 /dev/SSD-RADEON/test_ssd
# mkfs.ext4 /dev/raid10/test_raid10
# mount /dev/SSD-RADEON/test_ssd /mnt/SSD-RADEON
# mount /dev/raid10/test_raid10 /mnt/raid10

Прогнал серию из 10-ти тестов для каждого хранилища с помощью dd:

# dd if=/dev/zero of=/mnt/raid10/tempfile bs=1M count=2000 oflag=direct
# dd if=/dev/zero of=/mnt/SSD-RADEON/tempfile bs=1M count=2000 oflag=direct

Далее взял fio и прогнал тесты с его помощью:

Линейное чтение: 
# fio -ioengine=libaio -direct=1 -invalidate=1 -name=test -bs=1M -iodepth=32 -rw=read -runtime=30 -filename=/dev/raid10/test_raid10

Линейная запись: 
# fio -ioengine=libaio -direct=1 -invalidate=1 -name=test -bs=1M -iodepth=32 -rw=write -runtime=30 -filename=/dev/raid10/test_raid10

Пиковые IOPS случайной записи: 
# fio -ioengine=libaio -direct=1 -invalidate=1 -name=test -bs=4k -iodepth=128 -rw=randwrite -runtime=30 -filename=/dev/raid10/test_raid10

Так для обоих дисков. С dd сделал по 10 тестов, с fio по 5. Потом создал VM на Debian 12, создал для неё такие же диски, выбрав параметры:

▪️Device: SCSI
▪️Cache: Default (No cache)
▪️IO thread: yes
▪️Async IO: Default (io_uring)

Настройки все по умолчанию. И там выполнил точно такие же тесты. Свёл всё в одну таблицу. Я тут приводить точные цифры тестов не буду, так как они не имеют принципиального значения. Цифры можете сами посмотреть. Перейду сразу к выводам.

Разброс в производительности не более 9%. А если точно, то разница между хостом и VM только в одном тесте на запись была 9%, в остальных случаях 2-6%. Немного удивило то, что в паре тестов в VM результаты были выше на 2%, чем на хосте. Я несколько раз перепроверял, но ситуация воспроизводилась снова. Не знаю, с чем это может быть связано.

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

#proxmox #disk #perfomance

Завершу тему с тестированием дисков информацией про кэширование в Proxmox VE. У него стандартный набор режимов, которые будут плюс-минус такие же и у рейд контроллеров. Сделаю в формате небольшой шпаргалки, а подробности с картинками есть в документации.

▪️None - режим по умолчанию. Если не хочется разбираться в этой теме, то можете оставлять этот режим и не заморачиваться. Он универсален для сервера общего назначения. Гипервизор никак не вмешивается в операции ввода-вывода. VM работает как-будто напрямую с хранилищем. Может отправлять данные в очередь хранилища на запись, либо дожидаться реальной записи.

▪️Writethrough - операции записи VM идут напрямую в хранилище, как и в режиме none. В этом режиме добавляется кэш гипервизора, который используется только для чтения. То есть мы получаем такую же надёжность записи, как и в none, но добавляется кэш на операции чтения. Если у вас сервер отдаёт много статики, то можете включить этот режим.

Железный рейд контроллер без батарейки обычно работает в таком же режиме.

▪️Directsync - кэширование гипервизора не используется вообще, как в none. Отличие этого режима в том, что мы заставляем VM работать с хранилищем только в режиме реальной записи с подтверждением. То есть виртуалка не использует очередь хранилища. Затрудняюсь придумать пример, где это реально надо. Никогда не использовал этот режим.

▪️Writeback - операции записи и чтения кэшируются гипервизором. VM будет получать подтверждения о записи, когда данные попадут в кэш гипервизора, а не хранилища. Это существенно увеличивает быстродействие дисков VM. Особенно если у гипервизора много свободной оперативной памяти для кэша. Если будет сбой сервера и данные из кэша хоста не успеют записаться, то мы получим потерю информации с разными последствиями для системы. Она скорее всего выживет, но если там работала СУБД, то база может оказаться битой.

Если у вас настроен UPS, сервер корректно завершает работу в случае пропадания питания, и в целом стабильно работает, без проблем и аварийных завершений, то можно использовать этот режим для всех виртуальных машин. Железный рейд контроллер с батарейкой обычно работает в этом же режиме.

▪️Writeback (unsafe) - то же самое, что Writeback, но с одним отличием. В режиме Writeback гостевая VM может отправить команду на запись данных в реальное хранилище, а не кэш гипервизора. У неё есть возможность принудительно поддерживать консистентность данных. В режиме unsafe команда на запись в хранилище всё равно перехватывается кэшем хоста. Это обеспечивает максимальное быстродействие VM и максимальную ненадёжность сохранности данных. Я этот режим использую на тестовых гипервизорах.

❗️Все эти режимы имеют смысл при использовании типа диска RAW. Например, при использовании LVM Storage или обычных raw файлов с хранением в директории хоста. Во всех остальных случаях (qcow2, zfs) кэширование лучше не трогать и оставлять его в режиме none. Также следует аккуратно менять режимы при использовании raid контроллера с батарейкой, встроенной памятью и включенным кэшированием. Будет неочевидно, какой режим выбрать - тот или иной кэш гипервизора или самого контроллера, либо их обоих. Надо тестировать на своей нагрузке. Я в таких случаях оставляю кэш контроллера и не использую кэш гипервизора. Просто интуитивно так делаю. Как лучше, я не знаю.

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

#proxmox #disk

За что больше всего люблю дистрибутив Debian, так это за его консерватизм. Много лет назад я написал статью на сайте:

⇨ Как настроить сетевые параметры в Debian

Последние 5 лет вообще её не трогал. А она не потеряла актуальность и популярность. Последние 2 года это самая посещаемая статья сайта. Каждый день по 200-300 посетителей приходят её прочитать. А за всё время её посмотрели сотни тысяч раз. Если прикинуть, то это большой масштаб. И таких статей много. То, что я написал, прочитали уже миллионы людей. Вроде сидишь себе, что-то пишешь. А тебя читает столько народа. В уникальное время живём. Надо это ценить.

Собрался с силами и переработал статью, актуализировал. Перенёс все настройки на ip, замерив ifconfig и route. Давно серьёзно не занимался сайтом и контентом нём. Это забирает очень много времени. Нет возможности его выделять. Одна переработка заняла целый день. А если писать с нуля, то нужно ещё больше времени. Для того, чтобы подобная статья вышла в топ поисковиков, приходится работать с SEO, надо это знать. Из-за этого текст выглядит немного косоязычно. Но если этого не сделать, то текст заберут другие сайты, добавят SEO и статья от них уйдёт в ТОП. Так что лучше самому сразу сделать так, как надо.

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

Статью можно использовать новичкам как шпаргалку. Там есть вся база:

◽️статические и динамические настройки ip адресов
◽️dns и hostname
◽️статические маршруты
◽️vlan
◽️отключение ipv6
◽️несколько адресов на одном интерфейсе

Узнал для себя некоторые новые вещи, на которые раньше не обращал внимание. Например, 2 типа активации сетевого интерфейса в /etc/network/interfaces:

▪️auto - интерфейс активируется при загрузке системы. Это подходящая настройка для статичного сетевого адаптера.
▪️allow-hotplug - интерфейс поднимается, когда подсистема udev обнаружит его. Это произойдёт и при загрузке системы, как в случае с auto, если сетевая карта будет подключена, и в случае подключения, отключения устройства. Например, если это usb сетевая карта или VPN туннель. Настройка больше подходит для динамических сетевых интерфейсов.

Ещё интересный момент. Если сбросить dhcp lease через консоль соответствующей командой:

# dhclient -r

То вы не только потеряете все полученные по dhcp настройки, но и статические адреса. Соответственно, вас отключает по ssh. Для меня это было сюрпризом. Такие вещи надо делать осторожно, имея доступ к консоли сервера напрямую.

#debian #network

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

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

Я всегда так делаю. Мысленно представляю, что завтра у меня недоступны некоторые или все сервера. Какой план на этот счёт? Чтобы не было всех серверов, сразу отсекаем по максимуму доступ к бэкапам. Я уже много раз писал и рассказывал:

❗️Бэкап-сервера должны сами ходить за данными. У серверов с данными не должно быть полного доступа к бэкапам.

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

Подробно про бэкапы я не так давно рассказывал в отдельных заметках:

⇨ Два принципиально разных подхода к созданию бэкапов
⇨ Проверка бэкапов

По моему мнению надёжные бэкапы - основа спокойной жизни админа. Дальше уже реализуем другие организационные меры:

🔴 Закрываем доступ из интернета к внутренним сервисам. По минимуму выставляем их наружу. Не надо без крайней нужды пробрасывать, к примеру, rdp порт. Меня разок через него шифровали. И хотя чаще всего от этого не будет проблем, но раз в 10 лет обязательно найдётся какая-нибудь уязвимость, которая в обход аутентификации позволит выполнить вредоносный код на сервере.

🔴 Используем антивирусы на пользовательских компах. Если у вас бюджетка или прям совсем бедный бизнес, который не может себе позволить купить антивирус, поставьте бесплатный от Касперского. Базово он защитит от вирусов.

🔴 Не давайте пользователям полные права. Вкупе с антивирусом, это закроет большую часть проблем с их стороны. Хоть и не все.

🔴 Не оставляйте свои рабочие места включенными 24/7. Я сам такое практиковал раньше. Удобно, когда рабочий комп всегда включен и к нему можно удалённо подключиться. Сейчас даже дома не оставляю свой рабочий ноут включённым, когда ухожу из дома или надолго отхожу от рабочего места. Выключаю ноут, когда надо - включаю. RDP тоже на нём отключен.

🔴 Не подключайте к своему рабочему компу бэкапы, не настраивайте беспарольные доступы куда-либо, не назначайте лишние права своей учётке в инфраструктуре. Нередко на компы админов злоумышленники заходят руками и смотрят, к чему есть доступ. Если у вас пароли в KeePass, а файл закрыт надёжным паролем, уже с вашего компа ничего не сделать. Пароли в Winbox и Xshell у меня зашифрованы мастер-паролем, на ключе для ssh тоже пароль.

Если сами страдали от шифровальщиков, расскажите, как они заходили к вам и к каким последствиям это приводило. Ко мне один раз заходили через rdp, один раз через письмо у пользователя. У него, кстати, антивирус не помог. Не распознал шифровальщика. Всё, к чему у пользователя был доступ, зашифровали.

#security

🔝 ТОП постов за прошедший месяц. Все самые популярные публикации по месяцам можно почитать со соответствующему хэштэгу #топ. Отдельно можно посмотреть ТОП за прошлый год.

Пользуясь случаем, хочу попросить проголосовать за мой канал, так как это открывает некоторые дополнительные возможности по настройке: https://t.me/boost/srv_admin.

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

📌 Больше всего пересылок:
◽️Топ-10 артефактов Linux для расследования инцидентов (980)
◽️Терминальный сервер на базе Windows 10,11 (806)
◽️Система управления инфраструктурой OpenRPort (686)

📌 Больше всего комментариев:
◽️Как найти работу в ИТ после 45 лет? (288)
◽️Тайная жизнь современных ОС (231)
◽️Новость с исключением русских мэйнтейнеров (208)

📌 Больше всего реакций:
◽️Шпаргалка по tcpdump (351)
◽️Терминальный сервер на базе Windows 10,11 (318)
◽️Настройка default_server в Nginx (279)

📌 Больше всего просмотров:
◽️Топ-10 артефактов Linux для расследования инцидентов (11612)
◽️Бесплатные курсы Yandex Cloud (11265)
◽️Настройка VM в Proxmox с помощью Terraform (10449)

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

#топ

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

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

Сейчас есть Xshell 8 без каких либо ограничений for Home and School use only. Скачать бесплатную версию можно на отдельной странице. Причём Xshell идёт в связке с бесплатной же Xftp для sftp соединений. Получается очень удобно. Достаточно в Xshell подключиться к серверу и из этой сессии вызвать Xftp для доступа к файлам.

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

🟢 Внешний вид, а именно - возможность убрать всё лишнее. Пошло это со времён ноутбуков с небольшим экраном и удалённой работы. В Xshell можно оставить только окно с терминалом и заголовок (Alt+S). Всё остальное я открываю горячими клавишами. Когда всё настроишь, открывать нужно только список настроенных соединений. В итоге рабочее окно это только терминал.

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

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

🟢 SSH + RDP соединения в одном клиенте. В 5-й версии RDP не было, теперь есть. Для меня это хорошая новость. Теперь можно исключить mRemoteNG, а использовать только Xshell.

🟢 Возможность ручной и автоматической записи сессий ssh в лог файлы. Для каких-то серверов у меня пишутся логи, для каких-то нет. Есть встроенный просмотрщик логов, который откроет весь лог и покажет его в консоли, как-будто вы просто отключились от сервера, но сохранили вывод консоли.

🟢 Возможность гибко управлять расположением вкладок с соединениями в окне программы. Из-за этого я не пользуюсь возможностями мультиплексоров, типа screen или tmux для открытия нескольких окон в рамках одного соединения. Мне удобнее управлять этим в Xshell.

Это основное, что вспомнил во время написания. В Xshell есть всё, что только можно ожидать от подобной программы. Я даже не придумаю, чего там не хватает. Из того, что есть ещё:

🟡 Возможность распознавать текст в консоли и что-то подсвечивать/подчёркивать в зависимости от содержимого. Можно открыть текстовый файл или вывести лог в консоль и подсветить слова или фразы средствами Xhell.

🟡 Можно сохранять свои быстрые команды или скрипты для запуска. Также есть поддержка сценариев, который можно записать на основе своих действий в консоли.

🟡 Умеет работать через proxy (для каждого соединения может быть свой), запускать X11 Forwarding или обычное перенаправление портов по ssh.

🟡 Огромное количество настроек и режимов терминала. Начиная от шрифтов и их размера, заканчивая VT modes и кодировками. Кто-то спрашивал, какой я использую шрифт в консоли. Обычно Cascadia Mono. Подсмотрел его в Windows Terminal. У меня он там стоял по умолчанию. Сразу понравился.

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

Подводя итог скажу, что программа, на мой взгляд, одна из лучших. Я её называю бесплатной, но, конечно же, это не так. Бесплатна она только для домашнего пользования, хотя никакой проверки нет. Если захотите её купить, то стоит она 100$. На сайте есть список продавцов в РФ.

#менеджеры_подключений

Занимался на днях в очередной раз перенастройкой своих VPN каналов. Честно говоря уже надоело этим заниматься, но внешние обстоятельства постоянно меняются. Хочу рассказать об одной особенности OpenVPN, которую я постоянно использую, и которая видится мне весьма полезной и функциональной.

OpenVPN сервер умеет управлять маршрутами внутри своих VPN сетей. Это получается второй контур маршрутизации поверх системного. Расскажу кратко, как это работает.

Допустим, у вас есть OpenVPN сервер, к которому подключаются разные клиенты. Будь то динамические подключения от удалённых сотрудников, либо другие одиночные сервера, маршрутизаторы своих внутренних подсетей. На сервере у вас указано, что все запросы к подсетям:

10.1.3.0/24
10.1.4.0/24
10.1.5.0/24

Отправляются в VPN сеть, конкретно в tun0 интерфейс. Настроить это можно сразу в конфиге openvpn для туннеля tun0:

route 10.1.3.0 255.255.255.0
route 10.1.4.0 255.255.255.0
route 10.1.5.0 255.255.255.0

OpenVPN сервер при запуске добавляет указанные маршруты в систему. Это можно сделать и вручную. Сервер при старте просто использует /sbin/ip route add для добавления маршрутов.

За каждую указанную выше подсеть у нас отвечают разные клиенты VPN. Это может быть указано в его конфигурационном файле. Делается это так:

iroute 10.1.3.0 255.255.255.0

При подключении клиента с этой настройкой OpenVPN сервер понимает, что весь трафик в эту подсеть стоит адресовать этому клиенту. Если клиент поменяется, то эта настройка может переехать к другому.

Глобально настройки сервера и других VPN клиентов не меняются. Они просто подключаются и получают общую маршрутизацию. А по каким маршрутам внутри VPN побегут пакеты определяют настройки отдельных клиентов, которые выполняют роль маршрутизаторов. И этих клиентов можно легко заменить без необходимости менять какие-либо ещё настройки.

Подробнее об этом можно прочитать в документации. Искать по параметру --iroute для внутренней маршрутизации и --client-config-dir для персональных настроек клиентов.

Мне пришлось заменить одного клиента на другого, через которого ходил трафик в youtube. Настройки остальных пользователей трогать не пришлось. У меня используется схема с единым OpenVPN сервером в РФ, к которому подключаются все клиенты. А он уже раскидывает трафик в зависимости от потребностей.

Набросал ниже схему, чтобы было понятно, о чём идёт речь.

#openvpn

Я постоянно использую Grafana как в связке с Zabbix Server, так и с Prometheus. У неё довольно часто выходят новые версии, но я обычно не спешу с обновлением, так как нет большой нужды. Смотрю через неё простые дашборды, так что обновления обычно не приносят конкретно мне каких-то необходимых нововведений.

Очень долго использовал 7-ю версию, не обновлялся. Потом собрался с силами и обновился до 10-й. Пришлось повозиться и сделать сначала экспорт всего через API, а потом импортировать уже в новую 10-ю версию. Из-за большой разницы в версиях просто обновиться поверх старой не получилось.

Не так давно вышла очередная версия уже 11-й ветки. Там много изменений. Конкретно меня привлеки улучшения в плане оповещений (alerts), экспорт в pdf, некие действия (actions) в визуализациях. Полный список обновлений 11-й версии и недавней 11.3 смотрите по ссылкам:

⇨ What’s new in Grafana v11.0
⇨ Grafana 11.3 release

Обновление с 10-й версии прошло вообще без проблем. Конкретно у меня это выглядело так:

# docker stop grafana
# docker rm grafana
# docker pull grafana/grafana:latest
# docker run -d -p 3000:3000 --name=grafana \
-v grafana_data:/var/lib/grafana \
-e "GF_INSTALL_PLUGINS=grafana-clock-panel,grafana-simple-json-datasource,alexanderzobnin-zabbix-app" \
grafana/grafana:latest

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

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

Если кому интересно, то я использую следующие дашборды в Grafana:

◽️Сводный дашборд активных триггеров со всех серверов Zabbix. Удобно все их открыть на одной странице. Разработчики Zabbix обещают реализовать это в рамках своего сервера, но пока такого нет. Объединить несколько серверов в дашборде Zabbix пока невозможно. Как это выглядит, можно посмотреть в моей статье на сайте. Внешний вид дашборда с триггерами с тех пор вообще не изменился.
◽️Дашборд Node Exporter Full от Prometheus для некоторых серверов
◽️Родной дашборд Angie от разработчиков.
◽️Дашборд от моего шаблона Zabbix для Linux Server.
◽️Мой сводный дашборд с личными метриками - сайты, каналы, статус компов в доме, на даче, электрокотёл, камеры и т.д.

Grafana - удобный универсальный инструмент, который позволил объединить две разнородные системы мониторинга в едином веб интерфейсе. Не приходится идти на компромиссы в выборе системы мониторинга. Какая лучше подходит, ту и используешь. А потом всё это объединяешь.

Изначально заметку планировал по нововведениям Grafana сделать, но там не так просто всё это попробовать. Сходу не нашёл, всё, что хотел. Соответственно и не потестировал ещё. Надо больше времени на это. Если наберётся материала на заметку, сделаю её отдельно. Отмечу только одно важное для меня изменение, которое сразу заметил. Если вкладку с Grafana открыть в фоне, то эта падлюка не подгружает метрики, пока не сделаешь её активной. А некоторые метрики долго подгружаются. Хочется её открыть в фоне, а потом к ней вернуться, когда она уже точно метрики подгрузит. Но не тут то было. Теперь она в таких вкладках из фона быстрее показывает метрики. Видно, что она всё равно что-то подгружает, но делает это быстрее, чем раньше.

#grafana #мониторинг