Нижче наведено набір сніппетів для налаштування 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

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

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

Перезберемо Nginx з патчем CVE-2026-9256 відповідно до Debian-way.

Критична вразливість у 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.