* Плюсы: Огромное количество настроек, поддержка аппаратного ускорения в большинстве роутеров, работа на сетевом уровне (Layer 3).
* Минусы: Чудовищно сложная настройка (IKEv2, Phase 1, Phase 2, политики шифрования). Код IPsec в ядре Linux — это десятки тысяч строк, в которых до сих пор находят дыры.
* Кейс: Соединить два офиса на оборудовании Cisco/Mikrotik/Juniper.

* Плюсы: Скорость (быстрее IPsec и OpenVPN в разы), простота (всего ~4000 строк кода — легко проверить на баги), мгновенное соединение.
* Минусы: Работает только по UDP (может блокироваться суровыми провайдерами), по умолчанию не имеет динамического управления IP (но это решается обертками типа Tailscale или Netmaker).
* Кейс: Удаленный доступ для сотрудников, связь микросервисов, личный VPN.

# Посмотреть статус пиров и объем переданного трафика
sudo wg show

# Проверить наличие интерфейса и его параметры
ip address show wg0

# Статус соединений
sudo swanctl --list-sas
# ИЛИ (для старых версий)
sudo ipsec statusall

# Проверить политики безопасности в ядре
ip xfrm policy

* Философия: Индексируем абсолютно каждое слово в каждой строке лога.
* Плюсы: Мгновенный полнотекстовый поиск. Мощнейшая аналитика и визуализация. Ты можешь найти ошибку в конкретном запросе среди миллиарда записей за доли секунды.
* Минусы: Прожорливость. Elasticsearch обожает оперативную память (RAM) и «кушает» её гигабайтами. Индексы занимают много места на диске.

input {
  beats { port => 5044 }
}
filter {
  grok { match => { "message" => "%{COMBINEDAPACHELOG}" } }
}
output {
  elasticsearch { hosts => ["localhost:9200"] }
}

* Философия: Мы не индексируем текст. Мы индексируем только метаданные (метки: имя сервера, имя контейнера, уровень лога). Сами логи сжимаются и лежат в дешевом объектном хранилище (S3).
* Плюсы: Потребляет в 10 раз меньше ресурсов, чем Elasticsearch. Идеально интегрируется в Grafana рядом с метриками. Хранение стоит копейки.
* Минусы: Поиск по самому тексту лога (grep) медленнее, чем в ELK, так как системе приходится «на лету» распаковывать чанки данных.

scrape_configs:
- job_name: system
  static_configs:
  - targets: [localhost]
    labels:
      job: varlogs
      __path__: /var/log/*.log

Модель OSI — это карта для поиска неисправностей.
L1 (Физический): Горит ли линк на сетевухе? Не перебит ли кабель?
L2 (Канальный): Видим ли мы MAC-адрес соседа? Работают ли VLAN-ы? (Инструмент: `arp -a`).
L3 (Сетевой): Здесь живут IP и **Ping (ICMP)**. Маршрутизация пакетов между сетями.
L4 (Транспортный): Порты! TCP (с гарантией доставки) и UDP (быстро, но без гарантии).
L7 (Прикладной): Здесь живет HTTPS, DNS, SSH.
Суть: Если не работает сайт (L7), сначала проверь пинг (L3) и линк (L1). Идем снизу вверх.

Это процесс установления надежного соединения. Состоит из трех шагов:
1. SYN: Клиент шлет запрос «Привет, давай свяжемся, мой номер (Sequence Number) — X».
2. SYN-ACK: Сервер отвечает «Привет! Я согласен. Твой номер X подтверждаю, мой номер — Y».
3. ACK: Клиент говорит «Ок, твой Y подтверждаю, погнали данные!».
Зачем: Это гарантирует, что обе стороны готовы к передаче, и позволяет синхронизировать номера пакетов, чтобы данные пришли в правильном порядке.

* BGP (Border Gateway Protocol) — это протокол обмена маршрутами между Автономными Системами (AS). Весь интернет — это лоскутное одеяло из AS.
* Суть проблемы: В BGP нет встроенной проверки доверия. Если крупный провайдер (или злоумышленник) случайно анонсирует, что «самый короткий путь к серверам Google лежит через меня» (BGP Hijacking), весь мировой трафик пойдет туда и «умрет».
* Пример: Именно из-за ошибок в BGP-конфигурациях случались глобальные сбои у Facebook и WhatsApp, когда они буквально «исчезали» из глобальной таблицы маршрутизации.

Техническая суть:
Утилита позволяет не только смотреть SMART, но и управлять очередями, форматировать блоки под разный размер (LBA) и проверять реальный износ ячеек памяти (NAND Endurance).

# Установка (если еще нет)
sudo apt install nvme-cli

# Вывести список всех NVMe дисков и их базовую инфу
sudo nvme list

# Показать детальный лог здоровья (критические предупреждения, температуру, износ)
sudo nvme smart-log /dev/nvme0n1

Техническая суть:
Podman не требует запущенного демона (daemonless) и позволяет запускать контейнеры в изолированных User Namespaces. Если хакер «сломает» контейнер, он окажется внутри системы с правами обычного бесправного пользователя.

# Запуск контейнера от обычного пользователя (без sudo!)
podman run -d --name my-app -p 8080:80 nginx

# Генерируем systemd-юнит, чтобы контейнер сам стартовал после ребута
podman generate systemd --name my-app --files --new

Техническая суть:
Ты создаешь фейковый файл (например, id_rsa, kubeconfig или AWS Access Key) и кладешь его в «соблазнительное» место. Как только кто-то попытается им воспользоваться, сервер-приемник зафиксирует IP и время обращения.

# Создаем уникальный домен-приманку через сервис (например, canarytokens.org)
# Если кто-то выполнит резолв этого имени:
host secret-token-unique-id.canarytokens.com
# Тебе тут же упадет письмо/алерт с IP того, кто это сделал.

Репликация — это механизм синхронизации данных между Master (Writer) и Replica (Reader).
* Асинхронная: Мастер записывает данные и тут же подтверждает успех клиенту, не дожидаясь реплики.
* *Плюс:* Максимальная скорость.
* *Минус:* Риск потери данных при падении Мастера (те миллисекунды данных, что не успели улететь на реплику).

* Синхронная: Мастер ждет, пока реплика подтвердит получение данных, и только потом отвечает клиенту.
* *Плюс:* Гарантия сохранности данных.
* *Минус:* Если реплика «залагает» или упадет сеть — встанет и запись на Мастере.

Индекс — это отдельная структура (обычно B-Tree), которая позволяет не сканировать всю таблицу целиком.
* Проблема: Каждый индекс занимает место на диске. Но главное — любой индекс замедляет запись (INSERT/UPDATE). При каждом изменении данных базе приходится обновлять и все связанные с этой колонкой индексы.
* Вывод: Индексы нужно создавать только на те колонки, по которым реально идет частая фильтрация (WHERE) или сортировка (ORDER BY).

Логический бэкап (dump) на терабайтной базе — это плохая идея. Он будет делаться вечно и создаст огромную нагрузку.
* Правильный путь: 1. Снапшоты на уровне ФС/LVM: Замораживаем ФС на секунду, делаем снапшот, размораживаем и спокойно копируем данные.
2. Физический бэкап: Инструменты вроде `pg_backrest` для PostgreSQL или `Percona XtraBackup` для MySQL. Они копируют сами файлы данных «на лету», не блокируя чтение и запись.
3. Бэкап с реплики: Самый надежный способ. Снимаем бэкап с репликационного сервера, чтобы вообще не нагружать основной Master-сервер.

Техническая суть:
zRAM создает сжатое блочное устройство прямо в оперативной памяти. Когда RAM начинает заканчиваться, ядро сжимает неиспользуемые страницы и складывает их в этот «быстрый swap», не обращаясь к медленному диску. Степень сжатия часто достигает 1:3.

# Устанавливаем утилиту
sudo apt install zram-tools

# Настройка в /etc/default/zramswap:
# ALGO=zstd (самый эффективный алгоритм сжатия в 2026-м)
# PERCENT=50 (выделяем до 50% RAM под сжатый пул)

# Перезапуск сервиса
sudo systemctl restart zramswap

# Проверка статуса
zramctl

Техническая суть:
Параметр `-Parallel` в командлете `ForEach-Object` позволяет запускать скрипт-блоки одновременно в разных потоках. Лимит потоков можно задать через `-ThrottleLimit`.

$servers = Get-ADComputer -Filter 'OperatingSystem -like "*Server*"' | Select-Object -ExpandProperty Name

# Опрашиваем по 20 серверов одновременно
$servers | ForEach-Object -Parallel {
    Get-Service -Name "Spooler" -ComputerName $_ | Select-Object Machinename, Status
} -ThrottleLimit 20

Техническая суть:

1. Версионность: Ты всегда видишь, кто и когда изменил инструкцию по восстановлению бэкапа.
2. Peer Review: Ты можешь создать Pull Request с описанием новой схемы сети, а коллеги проверят его на ошибки.
3. Автоматизация: При пуше в Git документация может сама собираться в красивый статический сайт (через MkDocs или Hugo).

Золотые правила Read-Only Friday:

* Никаких обновлений прошивок на центральных свитчах.
* Никаких массовых изменений GPO в Active Directory.
* Никаких «да я только одну строчку в конфиге nginx поправлю».
* Никаких миграций баз данных.

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

[Unit]
Description=GOST-enabled Nginx Web Server
After=network-online.target

[Container]
Image=registry.corp.local/nginx-gost:latest
PublishPort=8080:80
Environment=TLS_MODE=strict
Volume=/srv/web:/usr/share/nginx/html:ro

[Install]
WantedBy=multi-user.target

systemctl daemon-reload
systemctl start nginx-gost.service

# 1. Удаляем публичные мусорные репозитории Microsoft
winget source remove msstore
winget source remove winget

# 2. Добавляем корпоративный источник с авторизацией по сертификату
winget source add --name CorpRepo --arg https://repo.internal.local/api --type Microsoft.Rest --accept-source-agreements

# 3. Ставим нужный пакет тихо и без лишних вопросов
winget install Corp.ZabbixAgent --source CorpRepo --exact --silent --accept-package-agreements

# Логинимся через корпоративный OIDC
vault login -method=oidc

# Запрашиваем динамический доступ к роли read-only
vault read database/creds/pg-prod-readonly

# Вывод:
# Key                Value
# ---                -----
# lease_id           database/creds/pg-prod-readonly/gK9...
# lease_duration     15m
# password           A1b2C3d4_dynamic_hash_8f92
# username           v-oidc-adm_ivanov-pg-prod-read-1a2b3c

* Unix Sockets: Обмен данными идет напрямую через ядро Linux без участия сетевого стека (TCP/IP).
* Плюс: Меньше задержки (latency) и нагрузки на CPU.
* Минус: Работает только в рамках одной ОС. Если бэкенд переедет на соседний контейнер/сервер, придется переписывать конфиг.

* TCP (IP:Port): Данные проходят через весь сетевой стек, даже если бэкенд на том же хосте (loopback).
* Плюс: Легко масштабировать — просто меняем `127.0.0.1` на IP другого сервера.
* Вывод: В 2026-м для высоконагруженных локальных связок (Nginx + PHP-FPM/Python) используем сокеты, для микросервисов — TCP.

По умолчанию бэкенд видит IP того, кто к нему обратился — т.е. вашего Nginx. Чтобы передать адрес клиента, мы используем заголовок X-Forwarded-For или X-Real-IP.

* На стороне Nginx: прокидываем заголовок.
* На стороне бэкенда: используем модуль (например, `ngx_http_realip_module`), чтобы подменить адрес источника в логах и логике приложения.
* Важно:* В 2026-м обязательно настраиваем `set_real_ip_from`, чтобы доверять заголовкам только от своих балансировщиков, иначе любой школьник подменит свой IP в HTTP-заголовке.

Буферизация позволяет Nginx «впитать» ответ от бэкенда максимально быстро и отпустить воркер бэкенда заниматься следующими задачами.

* Если включено: Nginx забирает ответ в память (или на диск) и сам медленно отдает его клиенту с плохим 5G-интернетом. Бэкенд свободен.
* Если выключено (off): Бэкенд будет «висеть» открытым, пока клиент не скачает последний байт. При 1000 медленных клиентах ваш бэкенд захлебнется в процессах.
* Исключение: SSE (Server-Sent Events) или стриминг, где данные должны уходить клиенту мгновенно.

upstream backend_cluster {
    server unix:/run/php-fpm.sock weight=5; # Быстрый локальный сокет
    server 192.168.10.50:8080 backup;       # Резерв на случай падения
}

server {
    listen 443 ssl http2;
    server_name service.local;

    # Работа с реальными IP (только от доверенного шлюза)
    set_real_ip_from  10.0.0.1;
    real_ip_header    X-Forwarded-For;

    location / {
        proxy_pass http_backend_cluster;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        
        # Защита от "залипания" бэкенда
        proxy_connect_timeout 5s;
        proxy_send_timeout 60s;
        proxy_read_timeout 60s;
        
        proxy_buffering on;
        proxy_buffer_size 8k;
    }
}

Техническая суть:
Мы переходим на Btrfs с использованием алгоритма ZSTD. В отличие от старого доброго Gzip, ZSTD нативно поддерживается ядром и умеет в «умное» сжатие: если данные не сжимаются (например, уже зашифрованные бинарники), драйвер просто перестает тратить циклы CPU.

Под капотом: Используем механизм Copy-on-Write (CoW). При записи блок данных сначала сжимается в памяти, а затем атомарно пишется на диск. Это не только экономит до 40-60% места на типичных текстовых логах и конфигах, но и продлевает жизнь SSD, так как физических операций записи становится меньше.

# 1. Добавляем опции сжатия в fstab (уровень 3 — золотая середина для ARM)
# UUID=...  /var/log  btrfs  defaults,compress-force=zstd:3,noatime  0  0

# 2. Если раздел уже смонтирован, применяем на лету к существующим данным
btrfs filesystem defragment -r -czstd /var/log

# 3. Смотрим реальное потребление (df тут бессилен)
# Утилита compsize показывает магию чисел
compsize /var/log

# Вывод будет примерно такой:
# Processed 12405 files, 204856 blocks.
# Raw size: 12.4G
# Compressed size: 4.1G (33.06%)

Экономия дискового пространства в 3 раза без потери производительности (а на медленных дисках — даже с приростом, так как узкое место — шина данных, а не CPU). Плюс, мгновенные снапшоты позволяют откатить неудачное обновление системы за секунды.

Мы используем Windows LAPS (Local Administrator Password Solution), который теперь нативно интегрирован в ОС и Active Directory. Больше никаких сторонних костылей.

Как это работает: Каждая машина в домене генерирует уникальный, сложный пароль для своей учетки локального администратора. Этот пароль шифруется и сохраняется в защищенном атрибуте объекта компьютера в AD. Доступ к чтению этого атрибута жестко ограничен через ACL только для группы «Trusted Admins». Каждые 30 дней (или по вашему триггеру) пароль ротируется автоматически.

# 1. Проверяем состояние LAPS на конкретном сервере
Get-LapsDiagnostics -ComputerName "SRV-DB-01"

# 2. Получаем текущий пароль (требуются права доступа к зашифрованному атрибуту)
Get-LapsADPassword -Identity "SRV-DB-01" -AsClearText

# Вывод:
# ComputerName  Password            Expiration
# ------------  --------            ----------
# SRV-DB-01     $tr0ng_P@ss_2026!   10.04.2026 14:00:00

# 3. Принудительно заставляем сервер сменить пароль прямо сейчас
Set-LapsADPasswordExpiration -Identity "SRV-DB-01" -In 0

Полное исключение атаки типа Pass-the-Hash. Даже если злоумышленник вытащит хеш с одного сервера, он не сможет зайти под ним на другой. Админ больше не знает паролей — он получает их по требованию под присмотром аудита.

Техническая суть:
Используем eBPF (Extended Berkeley Packet Filter). Это технология, которая позволяет запускать микропрограммы прямо внутри ядра Linux без его пересборки или загрузки модулей.

Под капотом: Мы вешаем «хуки» на системные вызовы (kprobes) или функции в пользовательском пространстве (uprobes). eBPF-программа собирает статистику в реальном времени с нулевым влиянием на производительность. Вы видите всё: от задержек записи на диск конкретным процессом до того, какой именно микросервис рвет TCP-сессию.

# Запускаем однострочник, который строит гистограмму задержек I/O
bpftrace -e 'kprobe:vfs_read { @start[tid] = nsecs; } 
             kretprobe:vfs_read /@start[tid]/ { 
                 $lat = (nsecs - @start[tid]) / 1000000; 
                 if ($lat > 10) { @[comm] = lhist($lat, 0, 100, 10); }
                 delete(@start[tid]); 
             }'

# На выходе получаем четкую картину:
# @[postgres]:
# [10, 20)      |@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@| 152
# [20, 30)      |@@@@                                | 18
# [50, 60)      |@                                   | 2

Обнаруживаем «невидимые» проблемы: блокировки в ядре, микро-всплески трафика или утечки дескрипторов. В эпоху Cloud-Native и сложных распределенных систем это единственный способ не сойти с ума при поиске иголки в стоге сена.

Это классическая проблема MTU (Maximum Transmission Unit) и MSS (Maximum Segment Size). Когда мы упаковываем трафик в туннель (WireGuard, IPsec, GRE), добавляются дополнительные заголовки. Пакет становится больше стандартных 1500 байт и либо дропается, либо фрагментируется (что убивает производительность).
Если на промежуточном узле (или на DPI провайдера в 2026-м) запрещена фрагментация (флаг DF), пакет просто исчезнет в черной дыре. Решение: Нужно уменьшать MSS на интерфейсе туннеля (обычно до 1300-1400 байт), чтобы TCP-сессия сразу договаривалась о меньшем размере полезной нагрузки.

Load Average — это не только про CPU. Это очередь процессов в состоянии Running (R) и Uninterruptible Sleep (D). Если CPU свободен, значит, процессы «стоят в очереди» к дисковой подсистеме или ждут ответа от сети (состояние I/O Wait).
Разберем состояния подробнее:
High CPU Usage: Процессы в состоянии R. Решается оптимизацией кода или добавлением ядер.
High I/O Wait: Процессы в состоянии D. Причина: «умирающий» диск, перегруженная NFS-шара или проблемы с контроллером на ARM-сервере. Процессы отправили запрос на запись и замерли.
Zombie Processes: Состояние Z. Код не закрывает дочерние процессы. На LA влияют косвенно, но забивают таблицу процессов.

Для NVMe-накопителей в 2026 году классические атрибуты SMART не всегда информативны. Нужно использовать nvme-cli и смотреть на два критических параметра:
Percentage Used: Это прямой показатель износа ячеек. Если там 95%+, диск пора менять превентивно, даже если он работает идеально.
Available Spare: Это резервные блоки. Если этот показатель начал падать ниже 10% — значит, резервные ячейки кончаются, и контроллер скоро переведет диск в режим Read-only (защита данных при смерти).
Media and Data Integrity Errors: Любое число выше нуля — это повод для немедленной миграции данных.

# 1. Пытаемся пропихнуть стандартный пакет через туннель
# -M do запрещает фрагментацию, -s задает размер (1472 + 28 байт заголовка = 1500)
ping -M do -s 1472 10.10.1.1

# 2. Если получаем "Frag needed and DF set", ищем рабочее значение опытным путем:
ping -M do -s 1300 10.10.1.1

# 3. Нашли рабочее число? Правим MSS для проходящего трафика через nftables
# Актуально для 2026 года в Linux-роутерах:
nft add rule inet fw mangle forward oifname "wg0" tcp flags syn tcp option maxseg size set 1360

# 4. Или проверяем износ диска на ARM-сервере:
nvme smart-log /dev/nvme0n1 | grep percentage_used