Про Linux-клиент OpenVPN 3 и подводные камни дружбы с ним сегодняшний ночной пост, дамы и господа!

В Linux OpenVPN имеет имена пакетов openvpn и openvpn3. Второй - новая и более крутая итерация, в которой появились менеджеры конфигураций и сессий, поддержка D-Bus, а значит, теперь, чтобы поднять коннект, права root не нужны (наконец-то!), да и в целом управление стало гибче (если хотите копнуть глубже, велком: readme).

openvpn3 несомненно лучше, но(!) по-прежнему не завезли GUI. И тут речь даже не про сам клиент, а про плагин для NetworkManager, который удобно встраивается в интерфейс, умеет кушать конфиги ovpn или wg и удобно структурировать всё это дело в меню быстрого доступа.

Т.е. мне не нужно скачивать, устанавливать, а потом каждый раз перед подключением запускать клиент, будь то вышеперечисленные wg и ovpn или какой-нибудь OpenConnect (Cisco AnyConnect). Это всё уже вшито в оболочку, подключение к приватной сети происходит так же просто, как подключение к Wi-Fi (см. скрин).

#openvpn3 #linux

И раз плагин OpenVPN 3 для NetworkManager ещё не дописали, будем юзать CLI:

# Импортируем конфиг
openvpn3 config-import --config </path/to/config.ovpn> to /profile .ovpn --name <Profile's_Name> --persistent

# Подключаемся
openvpn3 session-start --config <Profile's_Name>

# Смотрим список активных коннектов
openvpn3 sessions-list

# Отключаемся
openvpn3 session-manage --disconnect --config <Profile's_Name>

Но если бы всё было так просто, этого поста бы не было🤓

Первое с чем пришлось столкнуться - после дисконнекта пропал Интернет. Точнее, как позже выяснилось, перестали резолвиться DNS-имена и ситуацию спас рестарт сервиса systemd-resolved. Оказалось, пока клиент ovpn активен, он перезатирает файл /etc/resolv.conf, чего при нормальной работе происходить не должно.

/etc/resolv.conf — конфигурационный файл, который определяет параметры DNS‑резолвера (системы преобразования доменных имён в IP‑адреса). Когда приложение запрашивает IP‑адрес для домена (например, google.com), система сначала проверяет локальный кеш, а затем обращается к DNS‑серверам из этого файла.
Если в системе есть systemd-resolved (как в моём случае), /etc/resolv.conf становится симлинком на /run/systemd/resolve/stub-resolv.conf. Если кто-то подменит этот файл, последствия могут быть самые разные.

В общем, openvpn3 нужно явно ткнуть, что в системе используется systemd-resolved и самовольно менять /etc/resolv.conf - нехорошо:

# Смотрим текущий конфиг
sudo openvpn3-admin netcfg-service --config-show
# У меня в выводе было "resolv-conf file: /etc/resolv.conf", из-за этого рушилась работа systemd-resolved.

# Объясняем openvpn3, что у нас systemd-resolved и не нужно напрямую перезатирать resolv.conf
sudo openvpn3-admin netcfg-service --config-unset resolv-conf
sudo openvpn3-admin netcfg-service --config-set systemd-resolved true

# Киляем openvpn3-netcfg
sudo kill $(pgrep -f openvpn3-service-netcfg)

Теперь при коннекте resolv.conf остаётся нетронутым, а после дисконнекта имена резолвятся штатно. Казалось бы всё, но... Теперь все запросы шли на сервера DNS за ВПНом, что не всегда секьюрно (особенно, если VPN корпоративный 🤫).

Чтобы через VPN DNS шли только запросы к доменам, пушнутым сервером (например, example.com), нужно установить dns-scope tunnel:

openvpn3 config-manage --config ИМЯ_ПРОФИЛЯ --dns-scope tunnel

# Проверка. В выводе должно быть "DNS Resolver Scope: tunnel"
openvpn3 config-manage --config ИМЯ_ПРОФИЛЯ --show

# Киляем openvpn3-netcfg
sudo kill $(pgrep -f openvpn3-service-netcfg)

После подключения к VPN резолвинг example.com и google.com должны происходить через разные DNS:

resolvectl query example.com    # должен резолвиться через интерфейс VPN
resolvectl query google.com     # должен резолвиться через основной интерфейс

Немного справки:
- Конфиг netcfg хранится в /var/lib/openvpn3/netcfg.json и переживает рестарт
- --dns-scope tunnel тоже переживает рестарт
- Если изменения не применяются, убедитесь, что старые процессы openvpn3 были завершены перед проверкой.

Кому-то эта информация сэкономит часы дебага в будущем.

#openvpn3 #splitdns #linux #cli #quickstart

При назначении пользователю оболочки по умолчанию важно убедиться, что она присутствует в списке разрешённых оболочек. Этот список хранится в файле /etc/shells. Каждая строка содержит полный путь к допустимой командной оболочке, например:

#cat /etc/shells
/bin/bash
/usr/bin/zsh

В нём не должно быть /usr/sbin/nologin и /bin/false, т.к. эти пути используются для служебных учётных записей, не требующих интерактивного входа.

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

#linux #cli #shell

Начало 2010-х годов, стремительное развитие информационных технологий. Чем больше разрасталась инфраструктура, тем в большей рутине тонули инженеры и системные администраторы.

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

В 2012 году программист с опытом работы в крупных компаниях (одной из которых была Red Hat) представляет миру совершенно новый подход в автоматизации управления серверами: очень низкий порог входа, идемпотентность (это когда повторный запуск одной и той же задачи не приводит к нежелательным изменениям), безагентность, и, что не менее важно - доступность и открытый исходный код.

Через 3 года компанию, занимающуюся развитием и поддержкой покупает Red Hat. Это даёт ресурсы для дальнейшего развития, но часть новых решений разрабатывается для Enterprise сегмента.

На сегодняшний день у проекта более 68 тысяч звёзд на GitHub, его используют почти 85 000 компаний по всему миру. Де-факто он стал стандартом для автоматизации ИТ‑инфраструктуры.

Создал его Михаэль Дехан (Michael DeHaan). Имя проекта: Ansible.

#soft #ansible

GitHub: Быстрый старт

1. Регистрируемся.

2. Создаём репозиторий, заполнив имя и описание, остальные настройки оставляем по умолчанию.

3. Устанавливаем git

# Linux (debian-based)
sudo apt update && sudo apt install git

# Windows (PowerShell)
winget install --id Git.Git -e --source winget

4. Указываем свои данные в конфигурации:

git config --global user.name "Ваше Имя"
git config --global user.email "your.email@example.com"

5. Генерируем SSH‑ключ, чтобы не вводить каждый раз логин/пароль:

ssh-keygen -t ed25519 -C "your.email@example.com"

6. Со страницы репозитория GitHub копируем URL SSH (доступен в зелёной кнопке "Code") и клонируем репозиторий:

git clone git@github.com:<username>/<repo-name>.git

7. Для удобства и повышения производительности лучше работать в редакторе/IDE, которая "дружит" с git, например, VS Code. Открываем репозиторий, выполнив в каталоге с проектом команду `code .` или в интерфейсе: File → Open Folder…

Теперь в Source Control (Ctrl + Shift + G) можно видеть изменения, коммитить, пушить и т.д.

----- Упрощённая справка -----

Коммит (commit) - создание локального "снимка" изменений и добавление комментария. Позволяет узнать кто, когда и зачем (если указано в комментарии) вносил правки, добавляет возможность отката на момент создания любого коммита.

Пуш (push) - отправка локальных коммитов на удалённый репозиторий, например, на GitHub.

Если нужно получить последние изменения из удалённого репозитория, используется пул (pull).

#git #github #quickstart

Шпаргалка по сборке ядра Linux из исходников

1. Проверка текущей версии ядра:

# uname -r
6.8.0-107-generic

2. Установка утилит для сборки:

sudo apt install build-essential libncurses-dev bc flex bison libssl-dev libelf-dev dwarves git fakeroot zstd libtool automake autoconf pkg-config flex bison

3. Скачивание и распаковка исходных кодов ядра:

wget https://cdn.kernel.org/pub/linux/kernel/v6.x/linux-6.19.11.tar.xz
tar -xJf linux-6.19.11.tar.xz

4. Конфигурация ядра

cd linux-6.19.11

# за основу берём конфигурацию текущего ядра
cp /boot/config-$(uname -r) .config
make localmodconfig

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

Перед началом сборки нужно либо отключить параметр CONFIG_SYSTEM_REVOCATION_LIST в .config, либо добавить валидный список отозванных сертификатов в debian/canonical-revoked-certs.pem.
Чтобы отключить REVOCATION_LIST: выполнить make menuconfig → "Cryptographic API" → "Certificates for signature checking" → отключить REVOCATION → Save → Exit.

5. Сборка ядра, используя все потоки CPU

make -j$(nproc)

6. Установка ядра и модулей

make modules_install
make install

В случае успешной установки будет сгенерирован initramfs, созданы ссылки, а также обновлена конфигурация grub.

7. Перезапуск системы

reboot

8. Проверка версии загруженного ядра

# uname -r
6.19.11

#linux #cli #linux_kernel

Шпаргалка по просмотру списка задач cron

• Список задач текущего пользователя:

crontab -l

• Задачи конкретного пользователя:

crontab -u username -l

• Задачи всех пользователей:

while IFS=: read -r username password uid gid info home shell; do

    # Пропускаем системные аккаунты с UID < 1000
    if [ "$uid" -ge 1000 ] 2>/dev/null; then
        crontab_output=$(sudo crontab -u "$username" -l 2>/dev/null)

        if [ -n "$crontab_output" ]; then
            echo -e "\n👨‍💻 $username (UID: $uid)"
            echo "────────────────────────────────────────────"
            echo "$crontab_output"
            echo
        fi
    fi
done < /etc/passwd

• Периодические задачи:

for file in /etc/cron.{hourly,daily,weekly,monthly}/*; do
    if [ -f "$file" ]; then
        echo -e "\n📋  $file"
        echo "────────────────────────────────────────────"
        cat "$file"
        echo
    fi
done

• Сложные сценарии:

for file in /etc/cron.d/*; do
    if [ -f "$file" ]; then
        echo -e "\n📋  $file"
        echo "────────────────────────────────────────────"
        cat "$file"
        echo
    fi
done

#linux #cli #cron

Исправляем проблему с локалями "Please check that your locale settings are supported and installed on your system"

# Проверяем установленные локали
locale -a

# Недостающие локали раскомментируем в /etc/locale.gen
sudo nano /etc/locale.gen

# Запускаем генерацию и применяем
sudo locale-gen
sudo update-locale

#linux #cli #perl #locale

Шпаргалка по генерации ssh-ключей в Windows

1. Задаём переменные

$EnvName      = "test"                    # Окружение: prod, test и т.д.
$UserName     = "ivanov"                  # Ваш логин
$SshFolder    = "$env:USERPROFILE\.ssh"   # Путь к файлам ssh-client
$Date         = Get-Date -Format yyyyMMdd # Дата генерации ключа
$KeyName      = "id_ed25519_$EnvName"     # Имя ключей
$PrivateKey   = "$SshFolder\$KeyName"     # Путь к приватному ключу
$PublicKey    = "$PrivateKey.pub"         # Путь к публичному ключу

2. Создаём папку .ssh и назначаем корректные права

New-Item -ItemType Directory -Path "C:\Users\$env:USERNAME\.ssh" -Force
takeown /F "$env:USERPROFILE\.ssh" /R /D Y
icacls "$env:USERPROFILE\.ssh" /grant ""$env:USERDOMAIN\$env:USERNAME":(OI)(CI)F" /T /C /Q
icacls "$env:USERPROFILE\.ssh" /grant "SYSTEM:(OI)(CI)F" /T /C /Q

3. Генерируем ключ

ssh-keygen -t ed25519 -C "${UserName}@${EnvName}-${Date}" -f $PrivateKey

4. Добавляем в ssh-агент (опционально)

Set-Service ssh-agent -StartupType Automatic
Start-Service ssh-agent
ssh-add $PrivateKey

5. Заполняем $env:USERPROFILE\.ssh\config (опционально)

Host test01
    HostName test01.domain.example
    IdentityFile C:\Users\Ivanov\.ssh\id_ed25519_test
    User ivanov

Host test01b
    HostName 10.110.0.10
    IdentityFile C:\Users\Ivanov\.ssh\id_ed25519_test
    ProxyJump test01
    User ivanov

6. Подключаемся

ssh test01b

Более подробно как всегда в Дзене:
https://dzen.ru/a/apnVaTkWs2OwozoI?share_to=link