Нижче наведено набір сніппетів для налаштування WireGuard для трьох різних дистрибутивів Linux та FreeBSD.
Припускається, що сервер працюватиме на Debian, а мережа буде 10.9.21.0/24.

Сервер, Debian

apt install wireguard-tools
nano /etc/network/interfaces.d/wg0

auto wg0
iface wg0 inet static
    address 10.9.21.1/32
    pre-up ip link add wg0 type wireguard
    pre-up wg setconf wg0 /etc/wireguard/wg0.conf
    up ip -4 route add 10.9.21.0/24 dev wg0
    # up /bin/systemctl restart sshd.service
    post-down ip link del wg0

umask 077
cd /etc/wireguard/
wg genkey > server-private.key
wg pubkey < server-private.key > server-public.key

nano /etc/wireguard/wg0.conf

[Interface]
ListenPort = 1234
PrivateKey = <server-private.key>

[Peer]
# Debian client
PublicKey = <public.key>
AllowedIPs = 10.9.21.3/32

[Peer]
# CentOS client
PublicKey = <public.key>
AllowedIPs = 10.9.21.4/32

[Peer]
# Ubuntu client
PublicKey = <public.key>
AllowedIPs = 10.9.21.5/32

[Peer]
# FreeBSD client
PublicKey = <public.key>
AllowedIPs = 10.9.21.6/32

Оригінальні капи Keychron з OSA-профілем виглядають непогано, але я не прихильник стилю друкарських машинок.
Враховуючи, що я звик до ноутбучних клавіатур у деяких комбінаціях натискати CTRL/SUPER/ALT/SHIFT одним пальцем, постало питання знайти низькопрофільні кейкапи однієї висоти.
Натискання двох клавіш одним пальцем може бути не зовсім зрозумілим тим, хто просто друкує текст, але це буде зрозуміло користувачам тайлових WM, де все керування запуском програм та вікнами базується на комбінаціях клавіш.
Одразу ж були куплені цілком нормальні низькопрофільні кейкапи Womier.
Так, їхній низ може мати сліди лиття, але якщо їх доопрацювати, вони дуже пристойні.
Також для тесту були куплені свитчі OUTEMU Half-height Switch.
Так, вони низькопрофільні, але на цьому все.
Тактильні відчуття у них просто ніякі.
Забігаючи наперед: оригінальні Keychron Silk POM Tactile Banana — дуже хороші, але фактично їх не порівняти з Gazzew Boba Black U4T.

Маємо сонар Deeper DP4H13S10, завдання збільшити дальність дії сигналу.
Оригінальний Deeper Range Extender коштує приблизно €195.
Як це можна вирішити, використовуючи те, що є? І навіть зробити це краще?
Дуже легко.

Добре поповнення колекції.
Новинам треба дати настоятися, після чого смакувати деталі.

• Red Hat, RED HAT, КАРЛ!
• GitHub Actions, як завжди.
• NPM, до цього вже звикли.
• Arch User Repository, вже цікавіше.

Що ж тут може бути не так?

Критична вразливість у nginx, що дозволяє віддалено досягти виконання коду з правами робочого процесу nginx через відправлення спеціально оформленого HTTP-запиту.
Але не у цьому річ.
А річ у тому, що мейнтейнери Debian не квапляться викочувати новий пакет із патчами.

• Security Bug Tracker CVE-2026-9256
• NGINX ngx_http_rewrite_module vulnerability CVE-2026-9256

apt --no-install-recommends \
    --no-install-suggests install \
    build-essential \
    fakeroot \
    devscripts

nano /etc/apt/sources.list

# trixie sources
deb-src https://deb.debian.org/debian/ trixie main contrib non-free non-free-firmware
deb-src http://security.debian.org/debian-security/ trixie-security main contrib non-free non-free-firmware
deb-src https://deb.debian.org/debian/ trixie-updates main contrib non-free non-free-firmware

Минуло лише пів року, але стрічка новин не переставала приносити нові кумедні вразливості.
Як завжди, я не акцентую увагу на системних вразливостях snapd / Rust Coreutils / Flatpak, ядрі (Copy Fail, Dirty Frag, Fragnesia, pidfd, PinTheft, GRO Frag) або AppArmor.

Якими б небезпечними вони не були - вони “умовно” пасивні, тобто за їх наявності потрібна низка факторів і активних дій зсередини чи ззовні для успішної експлуатації.

Мені набагато цікавіше стежити за поширеннями шкідливого коду в системах розповсюдження пакетів, бібліотеках та інших репозиторіях.

Тому що це стосується “активних” і безпосередніх атак, їм майже не потрібно поєднання певних факторів, після завантаження вони відразу ж вразять репозиторій розробника, далі зберуть його персональну / фінансову / авторизаційну інформацію, а після цього продовжать діяти по ланцюжку на всіх серверах, до яких у нього був доступ.

Продовжуючи попередні нудні опуси на тему ізоляції оточень, саме час пригадати про wayland.
Звичайно, це не заклик до дії, а лише приклади та роздуми.
Сам я дотримуюся філософії, де центр системи це користувач, і він має право налаштовувати все так, як він вважає за потрібне, а не так як це нав’язується загальними тенденціями, або як це реалізовано в конкретному дистрибутиві, разом з цим розуміючи і приймаючи всі ризики та наслідки цих дій.
Як то кажуть, “If you know what you are doing”.

І перш ніж розпочати, знову варто написати, що:

• Так, я розумію, що це дуже поверхово.
• Так, ніякі підключення до локальної графічної оболонки не припустимі для чогось небезпечного, і потрібно використовувати vnc або virt-viewer/spice.
• Непривілейований LXC слід замінити на Xen / KVM
• І так, я знаю, що з KVM ізоляції також можна вийти.
• І про Flatpak я теж знаю.
• І, нарешті, так, я знаю про Qubes OS та її архітектуру, можна сказати, з моменту її появи, а це 2010 рік.

І, дещо спрощуючи та адаптуючи ідеї QubesOS під свої повсякденні завдання, я віддаю перевагу в основному використати або інших локальних юзерів, або досить легковажні оточення LXC.

І так, у них я запускаю не щось потенційно небезпечне, а те, що багато хто з вас використовують безпосередньо під своїм акаунтом у системі, наприклад:

• Firefox для повсякденного використання та перегляду “чого завгодно”.
• Декілька проектів, які використовують пакети з PyPI, RubyGems.
• Окремо те, що я збираю з сорців з того ж GitHub.
• Сторонні програми element-desktop, Telegram, Zoom.

Вступ здалеку

Нещодавно знову ностальгував у FreeBSD, все чудово, все звично, все зручно.
Лише один момент повністю виключає її з використання, принаймні в мене.
Майже на всіх моїх ноутбуках FreeBSD не підтримує ні режим сну, ні режим очікування (s2ram/s2disk).
І зробити я з цим нічого не зміг, а перепробував багато чого.

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

З багатьох приємних дрібниць, які є у Фряхі, і які відсутні в Debian це ZFS Boot Environments, що зручніше, ніж, скажімо, снапшоти LVM.
А друге це GEOM_ELI, який підтримує не лише, як LUKS, режим АБО пароль, АБО ключ, але також підтримує режим І пароль, І ключ.

Подумав, подумав, та й вирішив розгорнути Debian з нуля з урахуванням усіх інструментів, які використовую, досвіду, і, що важливо, звичок.

Debian поки що залишається основною моєю системою, тому єдиний спосіб отримання хардварного (фізичного) ключа шифрування на додаток до паролю - це зробити його з хедера і розмістити на USB-флешці.

Попередній огляд ноутбука

Стандартна ситуація, у вас є основний робочий комп’ютер, на якому у вас є три різних проекта.
Один проект на nodejs, другий продакшн на python, а третій ваш власний “pet project”, теж на python.
А ще у вас у цій же системі особиста та робоча пошта, та й, скажімо, браузер і клієнт-банк.
І це все під вашим юзером.
Звичайно ж, головне, щоб не під рутом!
Решта не має значення. ¯\_(ツ)_/¯
Все цілком звичайне.

У багатьох технічно грамотних розробників таких проектів можуть бути десятки і десятки ключів для ssh або git серверів.

Приклад із популярним фреймворком PyTorch

Цілком повсякденно Ви пишете свій код, іноді комітіте, і тут у ваш затишний pet-project з AI прилітає оновлення torchtriton.
А після цього з вашої системи відлітають наступні набори даних, відповідно до основної функції бінарника, яка робить наступне:

• Збір системної інформації:
  • nameservers з /etc/resolv.conf
  • hostname з gethostname()
  • поточний логін з getlogin()
  • поточна робоча директорія з getcwd()
  • змінні оточення
• Читання наступних файлів:
  • /etc/hosts
  • /etc/passwd
  • Перші 1,000 файлів з $HOME/*
  • $HOME/.gitconfig
  • $HOME/.ssh/*

Оновлення прилетіло, конфедиційні дані – відлетіли.
Скомпрометовано не тільки все під вашим юзером (і, можливо, системою), але й по ланцюжку все, чим ви керували, куди комітили, куди підключалися.

Дуже, дуже часто доводиться стикатися з необхідністю використання певної версії Пітона, наприклад, для torch, або чогось специфічного.
Використовувати conda або Docker у зв’язці з nvidia-container-toolkit і потім налаштовувати образи наприклад nvidia/cuda:13.0.1-runtime-ubuntu22.04 мені відчувається протиприродно, хоча часто так робив.
Та й у контейнері доводиться встановлювати додаткові пакети.

Простіше і зручніше зібрати все на хостовій системі, але при цьому не допустити контамінації всієї системи сторонніми бібліотеками та файлами.

Далі наводиться приклад компіляції кількох версій Python тільки для групи verpy, що дещо зручніше, ніж встановлення лише для одного користувача.

• ai - довільний користувач, від якого здійснюється компіляція.
• verpy - група, якою буде дозволено використання.

apt install \
    build-essential libssl-dev zlib1g-dev libbz2-dev libreadline-dev libsqlite3-dev \
    wget curl llvm libncurses5-dev libncursesw5-dev xz-utils tk-dev libffi-dev \
    liblzma-dev libgdbm-dev libnsl-dev libgdbm-compat-dev

mkdir /opt/openssl
mkdir /opt/python
groupadd --gid 42398 verpy
usermod -aG verpy ai

Не вдаючись до подробиць, як саме і чому все організовано, доступ здійснюється по наступному ланцюжку:

Nginx stream ingress <> Main Nginx Frontend <> Nginx Backend inside GitLab instance.

Основний фронтенд управляє піддоменом gitlab, який закритий для зовнішнього доступу за допомогою авторизації auth_basic.

У цьому прикладі показана установка поверх LXC, тоді як для будь-якого більш-менш серйозного застосування це абсолютно неприйнятно і вимагає використання KVM з додатковими заходами безпеки.
І, крім того, встановлення на KVM буде набагато, набагато простіше.
LXC не забезпечує адекватної безпеки, оскільки для правильної роботи потрібне монтування розділів /sys та /proc з хоста, які доступні всім примірникам LXC.
Крім того, цей приклад потребує використання привілейованого контейнера LXC.
Однак LXC дозволяє легко налаштувати тестову інфраструктуру без накладних витрат, пов’язаних з KVM.
Тому деякі аспекти в цьому прикладі будуть пов’язані виключно з налаштуванням в LXC.

Хост

Спочатку давайте підготуємо хост-систему.

nano /etc/modules

overlay
nf_nat
br_netfilter
xt_conntrack
rbd
fuse
ip_vs
ip_vs_rr
ip_vs_wrr
ip_vs_sh
iptable_nat

nano /etc/sysctl.d/35-lxc-kubernetes.conf

kernel.dmesg_restrict = 0
net.ipv4.ip_forward = 1
net.ipv6.conf.all.forwarding = 1
net.bridge.bridge-nf-call-iptables = 1
# --conntrack-max-per-core Default: 32768 * N
net.netfilter.nf_conntrack_max=131072
# net.bridge.bridge-nf-call-arptables
# kernel.pid_max=100000
# user.max_user_namespaces=15000
vm.compact_memory = 1
vm.overcommit_memory = 1

Початковий огляд ноутбука

Прикладка товщини термопрокладок для чіпів SSD.

Щось мій щоденний “завжди із собою” робочий інструмент почав грітися.

Ремонт плеєра Hi-Fi Walker H2 з проблемою - гріється та не включається.
При трясці чути шуми деталей усередині.

Час модифікації файла

Кожна сторінка має щонайменше три точки відображення позначки часу в різних файлах, елементах сторінки або відповіді сервера, і всі вони повинні бути однаковими.

• ld+json "dateModified": "2025-03-07T15:43:42+00:00"
• sitemap <lastmod>2025-03-07T15:43:42+00:00</lastmod>
• headres last-modified: Fri, 07 Mar 2025 15:43:42 GMT

Блок голівок жорсткого диска з чотирма пластинами - всього 8 магнітних голівок, для двостороннього читання/запису інформації з пластин.