fa
Feedback
NetworkAdmin.ru

NetworkAdmin.ru

رفتن به کانال در Telegram

Авторский блог про сетевое и системное администрирование. Сайт: networkadmin.ru Реклама: @dad_admin Биржа: https://telega.in/c/networkadminru

نمایش بیشتر
4 725
مشترکین
اطلاعاتی وجود ندارد24 ساعت
-47 روز
+230 روز
آرشیو پست ها
💚 Практика настройки SSHD: что имеет смысл проверить Служба SSH есть почти на каждом сервере: виртуальном или железном. Доступ по SSH - это основа администрирования. В идеале его стоит закрывать от публичной сети, но на практике это не всегда возможно. Основные параметры настраиваются в /etc/ssh/sshd_config. Ниже указаны моменты, на которые стоит обратить внимание. 1️⃣ Парольная аутентификация. Каждый решает сам:

PasswordAuthentication yes
Можно оставить ее включенной как резервный вариант. Если пароль сложный и несловарный - реального риска перебора нет. Но если отключить парольную аутентификацию, почти весь бот-скан исчезает из логов. 2️⃣ Аутентификация по ключам. По умолчанию включена:

PubkeyAuthentication yes
Лучше использовать ключи ed25519 - они короче, быстрее и безопаснее RSA в большинстве практических сценариев. 3️⃣ Доступ root. Разрешать или нет - зависит от модели работы:

PermitRootLogin no
Если вы администрируете сервер один - работа напрямую под root упрощает жизнь. Если команда, то лучше отдельные пользователи + sudo + аудит действий. Если сомневаетесь, лучше временно отключите вход root и работайте через sudo. 4️⃣ Ограничение пользователей и групп. Можно явно задать, кто имеет право подключаться:

AllowGroups sshgroup
AllowUsers user01 user02
Я чаще применяю это для SFTP-доступа, создавая отдельную группу под файловый обмен. 5️⃣ Порт. Стандарт - 22:

Port 22
Смена порта - это не защита, а лишь снижение шума. Боты все равно найдут сервис, особенно если порт открыт публично и индексируется сканерами. Но хуже от смены обычно не становится. 6️⃣ Количество попыток входа. Ограничиваем перебор в рамках одной сессии:

MaxAuthTries 3
Три неверных ввода - соединение рвется. 7️⃣ Количество сессий внутри подключения. Не путать с числом параллельных подключений:

MaxSessions 1
Для обычного администрирования одной сессии достаточно. 8️⃣ Принудительная команда и SFTP-изоляция. Можно запускать не shell, а конкретную команду, например, логирующую обертку или SFTP. Пример для группы sftpusers с chroot:

Subsystem sftp internal-sftp -u 002
Match User sftpusers
ChrootDirectory /var/www
ForceCommand internal-sftp -u 002
Пользователи группы будут ограничены SFTP-доступом к /var/www с umask 002. Главное - это осознанная настройка, а не конфиг по умолчанию. #linux #ssh 🧑‍💻 NetworkAdmin

Высокие технологии, они среди нас #юмор 🧑‍💻 NetworkAdmin
Высокие технологии, они среди нас #юмор 🧑‍💻 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

⌛️ Как посмотреть прогресс 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

Уходи, здесь все под контролем моих лап #юмор 🧑‍💻 NetworkAdmin
Уходи, здесь все под контролем моих лап #юмор 🧑‍💻 NetworkAdmin

🤩 Почему изнутри сети не открывается ваш же сервис Довольно классическая ситуация: снаружи сайт работает, а из локальной сети по публичному IP или домену не открывается. Пингуется, но HTTPS не отвечает. Или вообще таймаут. Виновник часто один - Hairpin NAT (он же NAT loopback). ▪️ В чем проблема Допустим: • Сервер внутри сети: 192.168.1.10 • Публичный IP роутера: 203.x.x.x • На роутере настроен проброс 443192.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

📘 На Stepik вышел курс — «DevOps-инженер: От основ до продакшена» Хотите автоматизировать деплой и выстраивать надёжные CI/C
📘 На Stepik вышел курс — «DevOps-инженер: От основ до продакшена» Хотите автоматизировать деплой и выстраивать надёжные CI/CD процессы? Этот курс — полный путь DevOps-инженера: от первого сервера до продакшена. • CI/CD: Jenkins, GitLab CI/CD, GitHub Actions, Blue-Green, Canary, rollback • Контейнеризация: Docker (образы, Compose, networking), безопасность контейнеров • Kubernetes: Pods, Services, Deployments, Helm • Infrastructure as Code: Terraform, Ansible, ArgoCD и Flux для GitOps • Мониторинг: Prometheus, Grafana, ELK Stack, OpenTelemetry, SLI/SLO/SLA • Продакшен практики: High Availability, Disaster Recovery, Chaos Engineering • В стоимость включено: поддержка на протяжении курса, разбор задач и вопросов, рецензирование итогового проекта и помощь в составлении резюме 🎓 Сертификат — добавьте в резюме или LinkedIn 🔥 Цена со скидкой: 9 990 ₽ → 5 990 ₽, действует ограниченное время 👉 Пройти курс на Stepik

📁 Централизованный сбор логов в 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

✈️ Паразитное чтение диска в 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

⬛️ Подозрение на взлом 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

Современные требования к DevOps #юмор 🧑‍💻 NetworkAdmin
Современные требования к DevOps #юмор 🧑‍💻 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

👆 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

Как скрыть проблемное обновление 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

🐳 Dockerfile для Python: как не получить мусор на 1.2 ГБ Типичная история: копируешь с Stack Overflow, образ раздут, непонят
🐳 Dockerfile для Python: как не получить мусор на 1.2 ГБ Типичная история: копируешь с Stack Overflow, образ раздут, непонятно почему работает. Правильный промпт для AI:
Создай production-ready Dockerfile для Flask. Multi-stage build, непривилегированный пользователь, alpine base, healthcheck. Python 3.11.
30 секунд — и получаешь готовый файл с объяснением каждой строки. Не просто работает, а работает правильно. Команда GigaDevOps проводит онлайн практикум: разбираем реальные DevOps-задачи с AI прямо в эфире. 19 марта в 19:00 МСК 👉 РЕГИСТРАЦИЯ

😨 Как восстановить случайно удаленный скрипт Настраивал как-то 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

🌐 Сети для всех — сообщество для тех, кто хочет разобраться в компьютерных сетях и системном администрировании. 👉 Наш Telegram-канал: https://t.me/Networks_anyone 👉 Наш VK-канал: https://vk.ru/club236314394 Внутри сообщества вас ждет: - практические задания и разборы - понятная теория без воды - видеолекции и примеры конфигураций - обсуждение реальных и нестандартных сетевых задач - помощь и живое общение с единомышленниками 🎓 Курсы команды «Сети для всех»: 1️⃣ Компьютерные сети (Cisco — введение) https://stepik.org/a/227855 2️⃣ Компьютерные сети (Cisco — продвинутый уровень) https://stepik.org/a/230932 3️⃣ Компьютерные сети (MikroTik — практическое администрирование) https://stepik.org/a/260615 👥 Более 500 студентов уже с нами — присоединяйтесь к сообществу и прокачивайте сети вместе с нами. Сети для всех — понятно, практично, по делу. #СетиДляВсех #NetworksForAll

Когда сказали, что отправят ключ почтой и через неделю приходит конверт с этим.. #юмор 🧑‍💻 NetworkAdmin
Когда сказали, что отправят ключ почтой и через неделю приходит конверт с этим.. #юмор 🧑‍💻 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

🔑 Как сменить пароль в 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