🤩 DHCP Relay: как раздавать IP через маршрутизаторы

В простых сетях DHCP-сервер и клиенты обычно находятся в одном сегменте. Клиент шлет broadcast-запрос, сервер отвечает и все работает. Но как только появляется маршрутизатор, broadcast дальше не идет, и DHCP внезапно ломается.

Именно для таких случаев и нужен DHCP relay.

Идея простая: маршрутизатор принимает DHCP-broadcast от клиента и пересылает его unicast’ом на DHCP-сервер в другой сети. Ответ сервера он так же передает обратно клиенту.

▪️ Как это выглядит логически

Клиент: DHCPDISCOVER (broadcast)
Маршрутизатор (relay): ловит запрос и отправляет его на DHCP-сервер
DHCP-сервер: выдает адрес с учетом подсети клиента
Relay: возвращает ответ клиенту

Ключевой момент - relay добавляет в пакет поле giaddr, по которому сервер понимает, из какой сети пришел запрос.

▪️ Пример на Linux (isc-dhcp-relay)

1️⃣ Устанавливаем relay:

apt install isc-dhcp-relay

2️⃣ Указываем IP DHCP-сервера, например 10.50.0.10, и интерфейсы, где сидят клиенты:

INTERFACES="eth1 eth2"
SERVERS="10.50.0.10"

3️⃣ Перезапускаем:

systemctl restart isc-dhcp-relay

Готово. Клиенты из разных VLAN/подсетей будут получать IP от одного центрального DHCP-сервера.

▪️ Где это реально используется

Несколько VLAN, один DHCP-сервер
Офисы с централизованной сетевой инфраструктурой
Wi-Fi контроллеры и L3-коммутаторы
MikroTik / Cisco / Juniper - relay там настраивается аналогично

▪️ Важно помнить

На DHCP-сервере должны быть описаны все подсети
UDP порты 67/68 должны быть разрешены
Без relay DHCP через маршрутизатор не работает по определению

#networking #dhcp

🧑‍💻 NetworkAdmin

Что-то пошло не по плану 😕

#юмор

🧑‍💻 NetworkAdmin

🕓 Автоматизация работы с дисками и устройствами

В linux все железо - это события. Вставили диск, появился интерфейс, подключили USB - ядро сгенерировало событие, а udev решил, что с ним делать. Если нужно не просто чтобы работало, а чтобы работало как надо, в дело идут udev rules.

▶️ Что такое udev rules

udev rules - это правила, которые:

переименовывают устройства
задают права и владельцев
создают симлинки
запускают команды при подключении/отключении

Работают на уровне событий, без cron, демонов и костылей.

👁 Где живут правила

Свои правила кладут сюда:

/etc/udev/rules.d/

Файлы читаются в порядке номеров, например:

10-local.rules
99-usb.rules

▪️ Простой пример: стабильное имя для диска. Допустим, USB-диск каждый раз появляется как sdb, sdc, sdd. Это неудобно.

Смотрим атрибуты:

udevadm info --query=all --name=/dev/sdb

Пишем правило:

SUBSYSTEM=="block", ENV{ID_SERIAL}=="WD_Elements_25A1", SYMLINK+="backup_disk"

Теперь диск всегда доступен как:

/dev/backup_disk

▪️ Права и владелец для устройств. Например, для USB-UART адаптера:

SUBSYSTEM=="tty", ATTRS{idVendor}=="1a86", ATTRS{idProduct}=="7523", MODE="0660", GROUP="dialout"

Больше не нужно chmod после каждой перезагрузки.

▪️ Автоматический запуск команды. Можно выполнить действие при подключении:

ACTION=="add", SUBSYSTEM=="block", ENV{ID_FS_LABEL}=="DATA", RUN+="/usr/local/bin/mount-data.sh"

▪️ После правок:

udevadm control --reload
udevadm trigger

Или просто переподключить устройство.

#linux #udev

🧑‍💻 NetworkAdmin

📊 Как уменьшить файловую систему ext4

Файловая система ext4 умеет уменьшаться штатно, при условии, что на разделе достаточно свободного места. В этом ее большое отличие от xfs, которая сжиматься не умеет вообще. Но есть важное ограничение: уменьшение ext4 возможно только в размонтированном виде. На живой системе это не работает.

Если нужно уменьшить корневой раздел, без перезагрузки не обойтись.

▪️ Классический способ. В идеальном мире вы загружаетесь с LiveCD, монтируете нужный раздел и выполняете:

/sbin/resize2fs /dev/sda1 40G

Файловая система на /dev/sda1 будет уменьшена до 40 ГБ, при условии, что данных там меньше этого объема. Перед и после операции настоятельно рекомендуется проверить файловую систему:

/sbin/e2fsck -yf /dev/sda1

Если раздел смонтирован, ничего не получится:

resize2fs: On-line shrinking not supported
e2fsck: Cannot continue, aborting.

▪️ А если LiveCD недоступен? Вот тут начинается самое интересное. resize2fs можно выполнить из initramfs, то есть еще до загрузки основной системы. По сути, мы превращаем initramfs в мини-LiveCD.

1️⃣ Добавляем утилиты в initramfs. Создаем исполняемый файл /etc/initramfs-tools/hooks/resizefs:

#!/bin/sh
set -e
. /usr/share/initramfs-tools/hook-functions

copy_exec /sbin/e2fsck
copy_exec /sbin/resize2fs

2️⃣ Добавляем скрипт выполнения. Создаем исполняемый файл /etc/initramfs-tools/scripts/local-premount/resizefs:

#!/bin/sh
set -e

/sbin/e2fsck -yf /dev/sda1
/sbin/resize2fs /dev/sda1 40G
/sbin/e2fsck -yf /dev/sda1

3️⃣ Пересобираем initramfs. Смотрим доступные ядра:

ls /boot | grep config

И пересобираем образ, например для последнего ядра:

update-initramfs -u -k 6.1.0-22-amd64

После этого перезагружаемся. Процесс будет выполнен до монтирования root, а значит безопасно с точки зрения блокировок. Если что-то пойдет не так, всегда можно загрузиться с другого ядра, где initramfs не трогали.

#ext4 #filesystems

🧑‍💻 NetworkAdmin

⚙️ Ограничение памяти процессов через systemd

Если нужно аккуратно ограничить потребление памяти процессом, systemd делает это буквально из коробки. Причем не грубо, а с понятной логикой: можно замедлять процесс, забирать у него память или в крайнем случае прибивать. Все параметры описаны в документации, но на практике используются лишь несколько ключевых. Разберу их на примере.

▪️ Основные параметры

▪️ MemoryAccounting=yes
Включает учет потребления памяти для юнита. Без этого остальные лимиты просто не работают.

▪️ MemoryHigh=2G
Мягкий лимит. Процесс может его превышать, но systemd начнет активно забирать память и тормозить выполнение. Основной и самый безопасный механизм.

▪️ MemoryMax=3G
Жёсткий предел. При достижении процесс будет убит OOM Killer’ом. Использовать стоит осторожно, скорее как страховку.

▪️ MemorySwapMax=512M
Ограничение на использование swap. Полезно, если не хотите, чтобы сервис утонул в свопе.

▪️ Restart=on-failure
Позволяет автоматически перезапустить сервис, если его убили по памяти.

▪️ OOMPolicy=kill
Определяет поведение при OOM: либо корректная остановка (stop), либо жесткое убийство (kill).

▪️ Пример systemd unit

[Unit]
Description=Node.js Worker
After=network.target

[Service]
ExecStart=/usr/bin/node /opt/app/worker.js
Restart=on-failure

MemoryAccounting=yes
MemoryHigh=2G
MemoryMax=3G
MemorySwapMax=512M
OOMPolicy=kill

[Install]
WantedBy=multi-user.target

▪️ Быстрое тестирование из консоли. Создадим процесс, который пытается съесть 1 ГБ памяти:

node -e 'let a = "x".repeat(1024*1024*1024); setTimeout(()=>{}, 600000)'

Теперь запустим его с лимитами через systemd:

systemd-run --scope \
  -p MemoryHigh=300M \
  -p MemoryMax=400M \
  node -e 'let a = "x".repeat(1024*1024*1024); setTimeout(()=>{}, 600000)'

Процесс запросит гигабайт, но реально получит лишь разрешенный объем.

Проверяем:

ps -o pid,rss,cmd -C node

RSS будет в пределах лимита, даже если виртуальная память (VSZ) гораздо больше.

#linux #systemd

🧑‍💻 NetworkAdmin

🔑 Как сменить пароль в RDP/RDS сессии

Пользователи, которые работают с корпоративными ресурсами через RDP/RDS, часто упираются в странную проблему: нужно сменить пароль, а привычный Ctrl + Alt + Del ведет себя неправильно.

⚠️ Причина простая - в RDP-сессии это сочетание перехватывается локальным компьютером, а не удалённым сервером. В итоге открывается окно безопасности вашей рабочей машины, а не терминального сервера.

Но варианты есть.

▪️ Ctrl + Alt + End

Это полный аналог Ctrl + Alt + Del, но именно для RDP.
Работает, если вы подключены напрямую к серверу.

▪️ Если RDP внутри RDP

Когда есть цепочка из нескольких RDP-сессий, Ctrl + Alt + End срабатывает только в первом окне и дальше не проходит.

В этом случае помогает экранная клавиатура:

Запустите osk.exe
Зажмите Ctrl + Alt на физической клавиатуре
Нажмите Del на экранной клавиатуре

В итоге появится окно Windows Security уже на нужном сервере.

▪️ Удобный вариант для терминальных пользователей. Чтобы не объяснять это каждый раз, можно положить на Public Desktop ярлык для смены пароля.

Через команду оболочки:

explorer.exe shell:::{2559a1f2-21d7-11d4-bdaf-00c04f60b9f0}

Через VBS-скрипт:

Set objShell = CreateObject("Shell.Application")
objShell.WindowsSecurity

Через PowerShell:

powershell.exe -noprofile -noninteractive -command "(New-Object -ComObject shell.application).WindowsSecurity()"

Пользователь кликает по ярлыку и сразу попадает в нужное окно смены пароля, без плясок с клавишами.

Мелочь, но сильно упрощает жизнь в RDS-среде, особенно для не самых технических пользователей.

#windows #rdp #rds

🧑‍💻 NetworkAdmin

✨ LACP (802.3ad): агрегация каналов на практике

Когда одного сетевого линка уже не хватает по пропускной способности или хочется повысить отказоустойчивость, на помощь приходит LACP - Link Aggregation Control Protocol (IEEE 802.3ad). Он позволяет объединить несколько физических интерфейсов в один логический канал.

Важно сразу понять: LACP - это не удвоение скорости для одного соединения, а распределение потоков между линками.

▪️ Зачем используют LACP

увеличение суммарной пропускной способности
отказоустойчивость (один линк упал - трафик идет по другим)
прозрачность для приложений и сервисов

Частые кейсы: сервера виртуализации, NAS, storage, аплинки между коммутаторами.

▪️ Как это работает

LACP объединяет интерфейсы в bond / lag.
Трафик распределяется по хешу: MAC, IP, порт назначения (зависит от настроек).
Один TCP-поток всегда идёт по одному физическому каналу, чтобы не было reorder пакетов.

▪️ Пример на Linux (bonding). Создаём bond-интерфейс в режиме 802.3ad: modprobe bonding

Пример /etc/network/interfaces:

auto bond0
iface bond0 inet static
  address 10.10.0.10/24
  bond-mode 802.3ad
  bond-miimon 100
  bond-slaves eno1 eno2
  bond-xmit-hash-policy layer3+4

После поднятия можно проверить:

cat /proc/net/bonding/bond0

▪️ Коммутатор - обязателен

LACP должен быть настроен с двух сторон.
Если на сервере включен 802.3ad, а на свитче обычный access/trunk, линк либо не поднимется, либо будет флапать.

На большинстве управляемых коммутаторов это выглядит как LAG / Port-Channel с режимом LACP active.

▪️ Частые ошибки

ожидание, что один iperf покажет x2 скорость
разные настройки LACP на сервере и коммутаторе
объединение портов с разной скоростью (1G + 10G - это плохая идея)

#networking #lacp

🧑‍💻 NetworkAdmin

Когда сказали, что отправят ключ почтой и через неделю приходит конверт с этим..

#юмор

🧑‍💻 NetworkAdmin

😨 Как восстановить случайно удаленный скрипт

Настраивал как-то bash-скрипт бэкапа с ротацией старых копий. Для удобства и сам скрипт, и тестовые бэкапы лежали в одной директории. В итоге перепутал условие удаления и после выполнения скрипт аккуратно удалил… сам себя. А это была единственная версия.

Переписывать всё с нуля совсем не хотелось, поэтому решил попробовать восстановление. Если файл небольшой и действовать сразу - шансы на успех вполне хорошие.

Есть утилита scalpel, для файлового карвинга. Ставим:

apt install scalpel

Scalpel ищет файлы по сигнатурам. Для бинарников они обычно известны, а вот bash-скрипт - это обычный текст. Поэтому я добавил свою сигнатуру в /etc/scalpel/scalpel.conf:

NONE y 2000 #!/usr/bin/env bash

#!/usr/bin/env bash - шебанг, с которого обычно начинаются скрипты. Этого достаточно, чтобы scalpel начал их искать.

Создаем каталог для результата и запускаем сканирование:

mkdir /tmp/recover
scalpel /dev/mapper/vg0-root -o /tmp/recover

Указываем именно блочное устройство с файловой системой. Через несколько минут сканирования раздела ~60G в каталоге появилось множество восстановленных текстовых файлов.

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

Вывод простой: если что-то удалили случайно - ничего не пишите на диск и сразу пробуйте восстановление.

#linux #recovery

🧑‍💻 NetworkAdmin

❓ Как скрыть проблемное обновление Windows и не ловить ошибки

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

Есть два рабочих подхода: поставить обновления на паузу (до 35 дней) или скрыть конкретное обновление, чтобы Windows Update его игнорировал.

▪️ Способ 1. Утилита wushowhide

Раньше Microsoft официально распространяла графическую утилиту wushowhide.diagcab, которая позволяет скрывать и возвращать отдельные обновления. Сейчас страница KB3073930 удалена, но сам файл все еще можно найти и использовать.

После запуска утилита показывает список доступных обновлений, достаточно выбрать проблемное и скрыть его. Windows Update перестанет его предлагать.

▪️ Способ 2. PowerShell и PSWindowsUpdate. Более гибкий и удобный вариант для администраторов - PowerShell-модуль PSWindowsUpdate.

Посмотреть список доступных обновлений:

Get-WindowsUpdate

Скрыть конкретное обновление по номеру KB:

Hide-WindowsUpdate -KBArticleID KB5029244

С драйверами чуть сложнее: у них часто нет привычного KB-номера. Сначала получаем их идентификаторы:

$updates = Get-WindowsUpdate -WindowsUpdate -UpdateType Driver
$updates | Select Title, Description -Expand Identity

После этого скрываем нужный драйвер по его ID:

Hide-WindowsUpdate -UpdateID "a1c4d2f8-7e91-4f0b-9e3a-8c2b7e9d1234"

В итоге система продолжит получать остальные обновления, но проблемное больше не всплывет. Удобный способ переждать баги без полного отключения Windows Update.

#windows #update

🧑‍💻 NetworkAdmin

👆 ZRAM и ZSWAP: ускоряем систему без апгрейда RAM

Когда оперативной памяти начинает не хватать, система либо активно уходит в swap и тормозит, либо ловит OOM. Увеличивать RAM не всегда возможно, особенно на VPS, ноутбуках или старых серверах. Тут на помощь приходят zram и zswap - два механизма сжатия памяти в linux.

▪️ Что такое ZRAM

ZRAM - это сжатый swap прямо в оперативной памяти. Ядро создает блочное устройство (/dev/zram0), данные в нем хранятся в сжатом виде, обычно с коэффициентом 2–3x.

➕ Плюсы:

swap без диска (очень быстро);
отлично работает на SSD-less системах;
спасает от резких OOM.

➖ Минусы:

съедает часть CPU на сжатие;
занимает RAM (но эффективнее обычного swap).

Быстрая настройка:

apt install zram-tools

Или вручную:

modprobe zram
echo lz4 > /sys/block/zram0/comp_algorithm
echo 4G > /sys/block/zram0/disksize
mkswap /dev/zram0
swapon /dev/zram0

▪️ Что такое ZSWAP

ZSWAP - это не отдельный swap, а кэш перед обычным swap. Сначала страницы памяти сжимаются и держатся в RAM, и только потом (если нужно) пишутся на диск.

➕ Плюсы:

прозрачный для системы;
не требует отдельного устройства;
снижает нагрузку на диск.

➖ Минусы:

нужен обычный swap;
меньше контроля, чем у zram.

Включается через параметры ядра:

zswap.enabled=1 zswap.compressor=lz4 zswap.max_pool_percent=20

Проверка:

cat /sys/module/zswap/parameters/enabled

▪️ Что выбрать

Ноутбук, VPS, бездисковая система - zram
Сервер с SSD и swap - zswap

Можно и вместе (zram как swap + zswap для дискового swap)

#linux #memory

🧑‍💻 NetworkAdmin

💚 Защищаем nginx, postfix и API

Fail2Ban часто вспоминают только в контексте защиты SSH от брутфорса. Но на практике его польза гораздо шире: он отлично подходит для защиты веб-сервисов, почты и API, где логов много, а автоматических атак еще больше.

▪️ Nginx: защита от перебора и сканеров. Самый частый кейс - массовые запросы к несуществующим страницам, /wp-login.php, /admin, /phpmyadmin.

Пример jail:

[nginx-404]
enabled  = true
filter   = nginx-404
logpath  = /var/log/nginx/access.log
maxretry = 20
findtime = 60
bantime  = 1h

Фильтр (/etc/fail2ban/filter.d/nginx-404.conf):

failregex = ^<HOST> .* "GET .* HTTP/.*" 404

В результате IP, который активно сканирует сайт, улетает в бан автоматически.

▪️ Postfix: защита почтового сервера. Почтовые серверы постоянно атакуют: перебор паролей, relay-попытки, фейковые отправки.

Готовые jail уже есть:

postfix
postfix-sasl
dovecot

Пример включения:

[postfix-sasl]
enabled = true
port    = smtp,submission,imap,imaps
logpath = /var/log/mail.log
maxretry = 5

Это резко снижает шум и нагрузку на почтовый сервер.

▪️ API и приложения. Fail2Ban отлично работает и для REST API, особенно если: нет rate limit, нет WAF, логируются ошибки авторизации.

Пример: баним за 10 ошибок 401 за минуту:

[api-auth]
enabled  = true
filter   = api-auth
logpath  = /var/log/app/api.log
findtime = 60
maxretry = 10
bantime  = 30m

Фильтр:

failregex = ^.* <HOST> .* 401 Unauthorized

▪️ Куда банить. Fail2Ban умеет:

iptables / nftables;
firewalld;
cloud-firewalls (через actions);
отправлять алерты в телегу.

#linux #fail2ban

🧑‍💻 NetworkAdmin

Современные требования к DevOps

#юмор

🧑‍💻 NetworkAdmin

⬛️ Подозрение на взлом linux-сервера

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

1️⃣ Анализ логов (особенно для веб-сервера). Начинать стоит с логов веб-сервера и приложения. Если известно о незакрытой уязвимости - ищем:

её эксплуатацию,
загрузку или запуск web-shell,
подозрительные запросы к конкретным файлам.

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

2️⃣ Поиск недавно измененных файлов. Не серебряная пуля (mtime легко подменить), но иногда сильно помогает:

find /var/www/site -type f -mtime -30 ! -mtime -1 -printf '%TY-%Tm-%Td %TT %p\n' | sort -r

Команда выводит файлы, измененные за последние 30 дней (кроме сегодняшнего), и сортирует их от новых к старым.
Если вывод большой, то сохраняйте в файл и анализируйте отдельно. В таком виде команда реально полезна.

3️⃣ Системные журналы и планировщики. Проверяем:

системные логи,
логи аутентификации SSH,
cron, at, systemd timers.

Отдельный плюс - если логи отправляются на внешний log-server: злоумышленнику сложнее их подчистить.
Где именно искать запланированные задачи - это тема отдельного разбора, но пропускать ее нельзя.

4️⃣ История команд. Иногда всплывает что-то интересное:

cat ~/.bash_history
cat ~/.mysql_history
sudo -u postgres psql
\s

Да, историю могут чистить, но если этого не сделали, то есть шанс увидеть и ручную активность атакующего.

5️⃣ Проверка целостности пакетов. Сравниваем системные файлы с эталонными хешами из пакетов:

dpkg --verify
rpm -Va

Любые неожиданные изменения в системных бинарниках - серьезный красный флаг.

6️⃣ Пользователи, SSH и домашние каталоги. Проверяем:

системных пользователей и их shell,
authorized_keys,
домашние каталоги пользователей, от которых работают сервисы (web, app, db),
временные директории (/tmp, /var/tmp).

Часто зловреды прячутся именно там.

7️⃣ Сетевые соединения. Смотрим, какие порты слушаются и куда сервер ходит сам:

ss -tulnp | column -t
ss -ntu

Неожиданные исходящие соединения - это один из самых надежных индикаторов компрометации.

8️⃣ Список процессов. Иногда достаточно просто посмотреть глазами:

ps axf

Майнеры, странные бинарники и процессы без имени часто палятся именно здесь.

#linux #security

✈️ Паразитное чтение диска в linux

Бывает неприятная ситуация: диск постоянно нагружен чтением, latency растет, сервисы подтормаживают, а по iotop, pidstat и lsof - тишина. Никакой очевидный процесс диск не ест, но I/O живет своей жизнью. В таких случаях на помощь приходит blktrace.

blktrace работает на уровне блочного устройства, а не процессов. Он показывает реальные операции чтения и записи, которые уходят в диск: кто, куда и с какими смещениями обращается. Это особенно полезно, когда:

чтение идет из page cache/readahead,
нагрузка создается kernel-потоками,
виноват не процесс, а ФС, LVM, RAID, snapshot или backup-агент.

▪️ Устанавливается просто:

apt install blktrace

▪️ Запускаем трассировку, например, для диска sda:

blktrace -d /dev/sda -o /tmp/trace

Даем системе поработать 10–30 секунд и останавливаем. Далее анализируем:

blkparse /tmp/trace.* | less

В выводе видно:

тип операции (Read/Write),
сектор и размер,
PID и имя процесса (если применимо),
временные метки.

Если нужен быстрый срез, кто больше всего читает:

blkparse /tmp/trace.* | grep " R " | awk '{print $6}' | sort | uniq -c | sort -nr | head

▪️ Для наглядности можно использовать btt (Block Tracing Tool):

btt -i /tmp/trace.*

Он строит статистику задержек и нагрузки по времени, удобно, когда ищете периодическую активность.

⚠️ Важно: blktrace - тяжелый инструмент. Не держите его включенным долго, особенно на проде. Но как инструмент расследования - это один из самых точных.

#linux #storage

🧑‍💻 NetworkAdmin

📁 Централизованный сбор логов в Windows без стороннего ПО

Если в инфраструктуре десятки или сотни Windows-машин, смотреть логи на каждой вручную - тупиковый путь. Для централизованного сбора событий microsoft давно встроила в систему механизм Windows Event Forwarding (WEF) и он работает без агентов и сторонних SIEM.

WEF позволяет автоматически отправлять события с клиентов на сервер-коллектор через WinRM (HTTP/HTTPS).

▪️ Архитектура

▪️Source Computers - клиенты, которые отправляют события;
▪️Collector - сервер, принимающий события;
▪️Используется служба Windows Remote Management (WinRM);
▪️События попадают в журнал Forwarded Events.

Поддерживаются два режима:

▪️Collector-initiated - сервер сам подписывается на машины (удобно в домене)
▪️Source-initiated - клиенты сами знают, куда отправлять логи (через GPO)

▪️ Быстрая настройка коллектора. На сервере:

wecutil qc

Это включает службу Windows Event Collector и создает журнал Forwarded Events.

Проверяем WinRM:

winrm quickconfig

▪️ Создание подписки

Открываем Event Viewer → Subscriptions → Create Subscription.

Выбираем:

▪️Тип (Collector или Source initiated)
▪️Какие события собирать (через XPath или GUI)
▪️Частоту доставки (Normal / Minimize latency)

Пример фильтра:
собирать события входа (Event ID 4624) и неудачных попыток (4625) из Security.

▪️ Настройка через GPO. Для Source-initiated режима:

Computer Configuration → Administrative Templates → Windows Components → Event Forwarding → Configure target Subscription Manager

Указываем:

Server=http://wef-server:5985/wsman/SubscriptionManager/WEC

После применения политики клиенты начнут отправлять события автоматически.

#windows #wef

🧑‍💻 NetworkAdmin

🤩 Почему изнутри сети не открывается ваш же сервис

Довольно классическая ситуация: снаружи сайт работает, а из локальной сети по публичному IP или домену не открывается. Пингуется, но HTTPS не отвечает. Или вообще таймаут. Виновник часто один - Hairpin NAT (он же NAT loopback).

▪️ В чем проблема

Допустим:

• Сервер внутри сети: 192.168.1.10
• Публичный IP роутера: 203.x.x.x
• На роутере настроен проброс 443 → 192.168.1.10

Снаружи все ок. Но когда клиент внутри сети обращается к 203.x.x.x, пакет:

1. Уходит на роутер
2. Роутер должен отправить его обратно внутрь
3. Сервер отвечает напрямую клиенту

И тут соединение ломается, потому что NAT не переписывает обратный трафик корректно. В итоге асимметрия маршрута и разрыв сессии.

▪️ Что такое Hairpin NAT

Это механизм, при котором роутер позволяет внутренним клиентам обращаться к внутренним сервисам через внешний IP, корректно делая двойной NAT.

Если функция отключена, то доступ изнутри по внешнему адресу работать не будет.

▪️ Где это встречается

• Домашние роутеры
• MikroTik
• Kubernetes NodePort
• Docker с опубликованными портами
• Облачные VPC

▪️ Как чинить

1️⃣ Включить NAT loopback

Во многих роутерах есть отдельная опция: NAT Loopback / Hairpin NAT / Reflection

2️⃣ Добавить правило SNAT (пример для iptables)

iptables -t nat -A POSTROUTING -s 192.168.1.0/24 -d 192.168.1.10 -j MASQUERADE

Это заставляет сервер отвечать обратно через роутер.

3️⃣ Split DNS (самый правильный способ). Во внутреннем DNS сделать:

site.networkadmin.ru → 192.168.1.10

А наружу оставить публичный IP. Это избавляет от NAT-костылей и работает стабильнее.

#network #nat

🧑‍💻 NetworkAdmin

Уходи, здесь все под контролем моих лап

#юмор

🧑‍💻 NetworkAdmin

⌛️ Как посмотреть прогресс cp, dd, gzip и других утилит

В репозиториях большинства linux-дистрибутивов есть небольшая, но очень полезная утилита - progress. Она показывает процент выполнения для операций coreutils: cp, mv, dd, tar, gzip/gunzip, cat и других.

По смыслу ее часто сравнивают с pv, но принцип работы разный. pv получает данные из pipe - значит, поток нужно заранее направить через него.
progress работает иначе: он сканирует /proc, находит поддерживаемые процессы, затем через fd и fdinfo отслеживает изменения открытых файлов и вычисляет прогресс.

Главный плюс - подключиться можно в любой момент, даже если процесс уже запущен. Например, вы распаковываете огромный SQL-дамп и хотите понять, сколько еще ждать.

▪️ Пример. Создадим тестовый файл:

dd if=/dev/urandom of=testfile bs=1M count=2048

(Для dd процент может не отображаться, если конечный размер неизвестен, будет показываться только скорость.)

Сжимаем файл:

gzip testfile

В другой консоли смотрим прогресс:

watch -n 1 progress -q

Вывод будет примерно такой:

[34209] gzip /tmp/testfile
    6.5% (132.2 MiB / 2 GiB)

Без watch утилита покажет текущее состояние и завершится, а для живого мониторинга лучше обновлять раз в секунду.

Аналогично при распаковке:

gunzip testfile.gz

Во второй консоли:

watch -n 1 progress -q

[35685] gzip /tmp/testfile.gz
    76.1% (1.5 GiB / 2.0 GiB)

progress - крошечная утилита (~31 КБ), написанная на C, с единственной зависимостью - ncurses. Устанавливается просто:

apt install progress
dnf install progress

Минимум веса и максимум пользы.

#linux #progress

🧑‍💻 NetworkAdmin

📱 Ansible Pull: когда сервер сам себя настраивает

Обычно с Ansible работают в режиме push: управляющая машина подключается по SSH и применяет playbook к целевым хостам. Но есть и обратная модель - ansible-pull, когда сервер сам забирает конфигурацию и применяет ее локально.

Это удобно там, где:

хосты находятся за NAT или в изолированной сети;
нет постоянного доступа с управляющего узла;
инфраструктура динамическая (VPS, авто-масштабирование).

Как это работает

Сервер:

Клонирует репозиторий (обычно Git)
Запускает playbook локально
Повторяет процесс по cron/systemd timer

▪️ Пример запуска:

ansible-pull -U https://git.networkadminru/infra.git site.yml

Где:

-U - URL репозитория
site.yml - основной playbook

По сути, это self-configuring node.

▪️ Автоматизация по расписанию. Чаще всего делают так:

*/15 * * * * ansible-pull -U https://git.networkadminru/infra.git site.yml

И сервер каждые 15 минут сам проверяет обновления конфигурации.

▪️ Когда это особенно полезно

Edge-серверы и филиалы;
Облака с автоскейлингом;
Zero-trust сети;
Immutable-подход с периодическим re-apply.

🤩 Плюсы

Нет необходимости держать открытый SSH;
Хорошо масштабируется;
Минимальная точка отказа;
Можно использовать Git как single source of truth.

🤩 Минусы

Сложнее централизованный контроль;
Нужно аккуратно работать с секретами;
Логи выполнения нужно куда-то отправлять.

▪️ Push vs Pull - что выбрать?

Классический Ansible: удобен для администрирования и ad-hoc задач
Ansible Pull: хорош для распределенных и автономных систем

Иногда разумно комбинировать оба подхода.

#ansible #devops

🧑‍💻 NetworkAdmin

Высокие технологии, они среди нас

#юмор

🧑‍💻 NetworkAdmin