NetworkAdmin.ru

❓ Что происходит на перегруженном TCP-сервере Когда TCP-сервер начинает захлебываться под нагрузкой, проблема не всегда в CPU, памяти или плохом приложении. Иногда упирается сам механизм приема новых соединений. Чтобы понять, что происходит, полезно знать три вещи: SYN flood, backlog и somaxconn ▪️ Как выглядит обычное TCP-подключение: клиент отправляет SYN сервер отвечает SYN-ACK клиент присылает ACK соединение считается установленным Но между "клиент постучался" и "приложение приняло соединение" есть очереди ядра. ▪️ Что может пойти не так: SYN flood. Сервер получает огромное количество SYN, но рукопожатие не завершается. Это может быть атака, кривой балансировщик, сетевые потери или просто всплеск нагрузки. В итоге очередь полуоткрытых соединений заполняется, и новые клиенты начинают теряться. backlog. Когда приложение вызывает listen(), оно указывает размер очереди ожидающих подключений. Если приложение не успевает быстро принимать новые соединения через accept(), очередь переполняется. Тогда часть клиентов начинает видеть: таймауты, connection refused, повторные SYN, странные задержки на подключении. somaxconn. Это системный лимит ядра на максимальный backlog. Даже если приложение просит большую очередь, ядро все равно ограничит ее значением net.core.somaxconn. Посмотреть можно так: sysctl net.core.somaxconn А заодно часто смотрят: sysctl net.ipv4.tcp_max_syn_backlog Первый параметр влияет на очередь установленных, но еще не принятых приложением соединений. Второй на очередь полуоткрытых SYN. ▪️ Что происходит на перегруженном сервере на практике: приложение медленно вызывает accept() очередь backlog заполняется новые подключения начинают отваливаться если сверху еще идет SYN flood, ситуация усугубляется снаружи кажется, что сервер то работает, то нет ▪️ Как смотреть симптомы: ss -lnt netstat -s | grep -i listen dmesg | grep -i syn ▪️ Что обычно помогает: увеличить somaxconn; проверить backlog самого приложения; поднять tcp_max_syn_backlog; включить или проверить SYN cookies; разбираться, почему приложение медленно принимает соединения; выносить защиту от flood на firewall/LB; Например: sysctl -w net.core.somaxconn=4096 sysctl -w net.ipv4.tcp_max_syn_backlog=4096 Но увеличение очередей не лечит корень проблемы. Если приложение не успевает обрабатывать подключения, вы просто делаете буфер больше. Это даст время, но не бесконечную защиту. Хорошая диагностика здесь начинается с простого вопроса: сервер не справляется с валидной нагрузкой или его забивают незавершенными SYN? Потому что снаружи это выглядит одинаково: TCP-порт открыт, а подключиться нормально уже нельзя. #tcp #network 🧑‍💻 NetworkAdmin

⚙️ Windows предпочитает IPv6: почему старые сервисы могут ломаться Если для удаленного хоста доступны и IPv4, и IPv6, Windows по умолчанию может выбрать IPv6. То есть если DNS или mDNS в локальной сети вернул сразу две записи: A -> IPv4-адрес AAAA -> IPv6-адрес то подключение с windows-клиента часто пойдет именно по IPv6-адресу из AAAA. В обычной современной сети это нормально. IPv6 - не лишний протокол, а полноценная часть сетевого стека Windows. Но иногда из-за этого начинаются странные проблемы. Например: • имя хоста резолвится нормально; • ping может работать; • по IPv4 сервис доступен; • но приложение пытается подключиться по IPv6; • а сам сервис IPv6 не слушает или работает с ним криво. Особенно часто это всплывает со старыми приложениями, самописными сервисами, легаси-софтом, SMB-сценариями в рабочих группах и внутренними утилитами, которые всегда жили на IPv4. Симптомы могут выглядеть так: по IP 192.168.x.x все открывается по имени хоста - ошибка соседний компьютер виден, но сервис не отвечает приложение пишет timeout в логах видно попытку подключения к IPv6 Первый импульс - полностью отключить IPv6. Но это плохая идея. Microsoft не рекомендует полностью отключать IPv6 в Windows, потому что часть компонентов системы рассчитывает на его наличие. Более аккуратный обходной путь - поднять приоритет IPv4 над IPv6 в prefix policy. Посмотреть текущую таблицу префиксов: netsh interface ipv6 show prefixpolicies Увеличить приоритет IPv4-mapped адресов можно так: netsh interface ipv6 set prefix ::ffff:0:0/96 55 4 В некоторых инструкциях также встречается настройка для ::/96: netsh interface ipv6 set prefix ::/96 60 3 После изменения стоит проверить таблицу еще раз: netsh interface ipv6 show prefixpolicies Смысл этих настроек в том, что винда меняет предпочтения при выборе адреса назначения. IPv6 остается включенным, но при наличии IPv4 и IPv6 система может начать чаще выбирать IPv4. Проверить резолвинг можно так: nslookup hostname А доступность порта: Test-NetConnection hostname -Port 445 #windows #network 🧑‍💻 NetworkAdmin

❓ SSHFS-Win: подключаем Linux-каталог как диск в Windows В Windows можно подключать каталоги с удаленного linux/unix-сервера как обычный сетевой диск. Не через SMB, не через FTP и не через WebDAV, а по защищенному SSH-соединению. Для этого есть SSHFS-Win - порт SSHFS-клиента для Windows. Он позволяет монтировать удаленную файловую систему по SSH так, будто это обычный диск в Проводнике. После установки SSHFS-Win каталог можно подключить прямо из Проводника Windows. Например, UNC-путь: \\sshfs.r\administrator@192.168.158.100\remote_folder sshfs.r - тип подключения administrator - пользователь на удаленном сервере 192.168.158.100 - адрес сервера remote_folder - удаленный каталог Можно смонтировать диск и из командной строки: net use M: \\sshfs.r\administrator@192.168.158.100\ps /user:administrator После этого в системе появится диск M:, с которым можно работать как с обычным сетевым диском. Если нужна SSH-аутентификация по ключу, можно использовать другой префикс: \\sshfs.k\administrator@192.168.158.100\remote_folder Префикс sshfs.k говорит SSHFS-Win использовать ключевую аутентификацию. Это удобнее и безопаснее, чем постоянно вводить пароль, особенно если доступ нужен регулярно. Пример подключения по ключу: net use M: \\sshfs.k\administrator@192.168.158.100\remote_folder Отключить диск можно стандартно: net use M: /delete ▪️ Где SSHFS-Win особенно полезен: • админ работает на Windows, а серверы linux; • нужно быстро открыть /var/log или /etc; • нет желания поднимать samba; • нужен доступ к файлам через уже разрешенный SSH; • удобно подключать dev/test каталоги; • нужно временно смонтировать удаленную папку без лишней инфраструктуры. SSHFS-Win - это не замена нормальному файловому серверу для большой команды. Для постоянной совместной работы, офисных файлов и тяжелой нагрузки чаще лучше использовать SMB/NFS/специализированное хранилище. Но для админских задач SSHFS-Win очень удобен: есть SSH-доступ - есть и сетевой диск в windows. Главное - использовать ключи, ограничивать права пользователя на сервере и не монтировать под root то, что можно открыть обычной учеткой. #windows #sshfs 🧑‍💻 NetworkAdmin

🛡 Как защитить скрипт от повторного запуска Одна из классических проблем в автоматизации: скрипт еще не успел завершиться, а cron, systemd timer или админ руками запускает его снова. В итоге получаем неприятные эффекты: два бэкапа пишут в один каталог, две задачи одновременно чистят одни и те же файлы, несколько копий скрипта дергают API, повторный запуск ломает промежуточное состояние, база получает дубли или конфликтующие операции и т.д. Чтобы этого избежать, удобно использовать flock. flock - это утилита для работы с файловыми блокировками. Идея простая: перед запуском скрипт пытается взять lock-файл. Если блокировка уже занята, значит другая копия скрипта еще работает. ▪️ Самый простой вариант: flock -n /tmp/myjob.lock /opt/scripts/myjob.sh /tmp/myjob.lock - файл блокировки -n - не ждать освобождения lock, а сразу завершиться /opt/scripts/myjob.sh - команда, которую нужно выполнить Если первый запуск еще работает, второй просто не стартует. ▪️ Для cron это выглядит так: */5 * * * * flock -n /tmp/backup.lock /opt/scripts/backup.sh ` Теперь даже если бэкап длится дольше 5 минут, новая копия не запустится поверх старой. ▪️ Можно добавить логирование: flock -n /tmp/backup.lock /opt/scripts/backup.sh || echo "backup already running" ▪️ Но часто удобнее встроить flock прямо в сам скрипт: #!/usr/bin/env bash set -euo pipefail LOCK_FILE="/tmp/myjob.lock" exec 200>"$LOCK_FILE" flock -n 200 || { echo "script already running" exit 1 } echo "start job" # основная логика скрипта sleep 30 echo "done" exec 200>"$LOCK_FILE" открывает lock-файл на файловом дескрипторе 200 flock -n 200 пытается взять блокировку если блокировка занята - скрипт завершается пока скрипт работает, дескриптор открыт и lock удерживается После завершения процесса блокировка освобождается автоматически. ▪️ Где хранить lock-файл? Для временных задач часто используют: /tmp/myjob.lock Для системных сервисов лучше: /run/myjob.lock /run обычно живет в tmpfs и очищается после перезагрузки. Это удобно для runtime-блокировок. ▪️ Есть и режим ожидания: flock /tmp/myjob.lock /opt/scripts/myjob.sh В этом случае второй запуск будет ждать, пока первый освободит lock. Можно задать таймаут ожидания: flock -w 60 /tmp/myjob.lock /opt/scripts/myjob.sh Так команда подождет до 60 секунд и завершится, если блокировка не освободится. #bash #flock 🧑‍💻 NetworkAdmin

Этот мир уже не будет прежним #юмор 🧑‍💻 NetworkAdmin

С днём системного администратора! 🏆 Пусть серверы не падают, бэкапы восстанавливаются, мониторинг молчит, а пользователи хотя бы иногда пробуют перезагрузить компьютер до обращения в поддержку. Желаю стабильного аптайма, спокойных дежурств, крепких нервов и достойной зарплаты. За localhost! 🍻🍷 🧑‍💻 NetworkAdmin

без подписи

без подписи

без подписи

без подписи

Стикерпак вместо тысячи слов в чате Сегодня День сисадмина, и Яндекс 360 отметил его по-своему — собрал набор «esc от стресса». «Работает? Не трогай» и «F» отвечают на большинство рабочих вопросов быстрее, чем развёрнутое сообщение. Со стрессом Яндекс 360 помогает справляться и вне чатов: сотрудники, права и сервисы управляются из одной админки — снять доступы уходящему одно действие, а не обход всех панелей. Поставить стикерпак себе тут. Реклама ООО «Яндекс», ИНН 7736207543, erid: 2W5zFJDFTSZ

За пачку вискаса все настрою 😮 #юмор 🧑‍💻 NetworkAdmin

Лапшу заказывали? #юмор 🧑‍💻 NetworkAdmin

✅ Безопасная работа с удалением и chmod find - одна из самых полезных и часто используемых утилит в linux. Но именно с ней часто происходят самые неприятные аварии. Хотели удалить старые логи - удалили не тот каталог. Хотели поправить права - сломали половину /var/www. Хотели найти временные файлы - случайно зацепили mount point. И проблема не в find, а в том, что он очень послушный. Что написали - то и сделал. Поэтому главное правило: сначала показать, потом делать. 🤩 Плохой подход: find /var/log -name "*.gz" -delete 🤩 Лучше сначала так: find /var/log -name "*.gz" -print Посмотрели список, убедились, что там нет ничего лишнего и только потом добавили действие: find /var/log -name "*.gz" -delete Для удаления по возрасту тоже сначала проверяем: find /backup -type f -mtime +30 -print И только после проверки: find /backup -type f -mtime +30 -delete ▪️ Очень важный флаг - -type. Если удаляем файлы, явно пишем: find /backup -type f -name "*.tar.gz" -mtime +14 -delete Если меняем права каталогов: find /var/www -type d -exec chmod 755 {} \; Если меняем права файлов: find /var/www -type f -exec chmod 644 {} \; Это защищает от классической ошибки, когда одинаковые права случайно применяют и к файлам, и к директориям. ▪️ Для chmod часто удобнее использовать + вместо \;: find /var/www -type f -exec chmod 644 {} + Так команда запускается не для каждого файла отдельно, а пачками. На больших каталогах это заметно быстрее. Если в путях могут быть пробелы, переводы строк или странные символы, используйте безопасную связку: find /data -type f -name "*.log" -print0 | xargs -0 rm -f Но если можно обойтись встроенным -delete, часто лучше использовать его: find /data -type f -name "*.log" -mtime +7 -delete ▪️ Еще один полезный предохранитель - ограничение глубины: find /var/log -maxdepth 1 -type f -name "*.gz" -print Так find не уйдет рекурсивно во все вложенные каталоги. И наоборот, если нужно пропустить верхний уровень: find /data -mindepth 1 -type d -empty -delete Это помогает не удалить сам корневой каталог поиска, если он вдруг окажется пустым. #bash #find 🧑‍💻 NetworkAdmin

📱 Nginx map: отдельные логи для 404 и 5xx без костылей Иногда нужно не просто писать общий access log, а отдельно сохранять конкретные типы запросов. Например: все 404, все 5xx, запросы от конкретных ботов, отдельные URI, нестандартные методы, трафик из определенных стран. Можно потом парсить общий лог через grep, awk или SIEM. Но в Nginx часто есть более аккуратный способ - использовать map. map позволяет создать переменную на основе другой переменной Nginx. А потом использовать эту переменную в логах, блокировках, редиректах и другой логике. ▪️ Пример: пишем 404 и 5xx в отдельные файлы. В секции http добавляем: map $status $to404log { 404 1; default 0; } map $status $to5xxlog { ~^5 1; default 0; } Теперь в нужном виртуальном хосте: access_log /var/log/nginx/404.log combined if=$to404log; access_log /var/log/nginx/5xx.log combined if=$to5xxlog; ▪️ Что получится: • запросы со статусом 404 попадут в /var/log/nginx/404.log • ответы 500, 502, 503, 504 и другие 5xx попадут в /var/log/nginx/5xx.log • при этом общий access log можно оставить как есть Например: access_log /var/log/nginx/access.log combined; ▪️ Как это работает: • Nginx смотрит на встроенную переменную $status • если статус 404, переменная $to404log получает значение 1 • если статус начинается с 5, переменная $to5xxlog получает значение 1 • директива access_log ... if= пишет запись только если переменная не равна 0 Так можно быстро отделить интересные события без внешней обработки логов. ▪️ map полезен не только для логов. Например, можно помечать нежелательные User-Agent: map $http_user_agent $block_useragent { default 0; ~*semrushbot 1; ~*ahrefs 1; ~*rss2tg 1; ~*seznambot 1; ~*AspiegelBot 1; ~*BLEXBot 1; ~*MASHIAH 1; } А в виртуальном хосте вернуть 403: if ($block_useragent) { return 403; } Да, if в Nginx часто ругают, но для простого return внутри server это нормальный и распространенный сценарий. По такой же логике можно делать условия по другим переменным: $request_method $request_uri $remote_addr $host $geoip_country_code $http_referer Например: • отдельно логировать POST-запросы • блокировать конкретные URI для некоторых User-Agent • писать подозрительные запросы в отдельный лог • ограничивать доступ по стране через GeoIP • включать разные upstream’ы по признакам запроса #nginx #linux 🧑‍💻 NetworkAdmin

без подписи

👍 Sysinternals без скачивания: подключаем как сетевой диск Короткая, но полезная штука для админов Windows. У Sysinternals есть live-каталог, который можно подключить как сетевой диск и запускать утилиты напрямую, без ручного скачивания архива. Команда простая: net use S: http://live.sysinternals.com/tools Если все прошло нормально, Windows ответит: Команда выполнена успешно. После этого у вас появляется диск S:, где лежат утилиты Sysinternals. Переходим на него: S: И запускаем нужный инструмент: procexp64.exe Для тех, кто не пользовался Sysinternals: это старый и очень известный набор утилит microsoft для диагностики и администрирования windows. ▪️ Что там особенно полезно: • Process Explorer. Расширенный менеджер процессов. Показывает дерево процессов, потоки, DLL, handles, параметры запуска, цифровые подписи, сетевую активность и много другой информации. procexp64.exe • TCPView. Показывает сетевые соединения: какой процесс, куда подключился, какой порт использует и в каком состоянии соединение. tcpview.exe • Autoruns. Один из лучших инструментов для разбора автозагрузки. Показывает Run-ключи, службы, драйверы, scheduled tasks, shell extensions и многое другое. Autoruns.exe • PsExec. Утилита для удаленного запуска процессов на Windows-хостах. PsExec.exe • Handle. Помогает понять, какой процесс держит файл или каталог. handle.exe Такой способ особенно удобен, когда нужно быстро что-то проверить на сервере или рабочей станции, а заранее набор утилит не скачан. Закончили работу - отключаем диск: net use S: /delete ❗️ Запускать инструменты напрямую из интернета удобно, но не всегда уместно. В корпоративной среде могут быть ограничения: прокси, firewall, AppLocker / WDAC, запрет WebDAV, требования к контролю версий утилит и т.д. #windows #sysinternals 🧑‍💻 NetworkAdmin

⚙️ MBR2GPT: как перевести Windows с Legacy BIOS на UEFI без переустановки Иногда windows на современном железе оказывается установленной в режиме Legacy BIOS / CSM. Работает и ладно. Но есть нюанс: для нормальной UEFI-загрузки нужен диск с таблицей разделов GPT, а не старый MBR. Почему вообще стоит переходить на UEFI + GPT: • поддержка дисков больше 2 ТБ; • больше 4 основных разделов без костылей; • современный механизм загрузки; • поддержка Secure Boot; • меньше зависимости от режима совместимости CSM. Secure Boot особенно важен: он помогает защититься от подмены загрузчика и запуска вредоносного кода до старта ОС. Если Windows уже установлена в legacy-режиме, не всегда нужно переустанавливать систему. Начиная с Windows 10 1703, есть встроенная утилита: mbr2gpt Она умеет конвертировать системный диск из MBR в GPT без удаления данных. Сначала проверяем, в каком режиме загружена Windows: $env:firmware_type Если видим: Legacy, значит система загружена в режиме совместимости. ▪️ Проверяем разметку диска и разделы: Get-Disk | Get-Partition Важно: на системном MBR-диске обычно должно быть не больше 3 первичных разделов, потому что mbr2gpt нужно место для создания EFI System Partition. ▪️ Проверяем возможность конвертации: mbr2gpt /validate /allowFullOS ▪️ Если проверка прошла успешно, запускаем конвертацию: mbr2gpt /convert /allowFullOS После этого утилита: • проверит структуру диска • создаст EFI-раздел • сконвертирует MBR в GPT • добавит UEFI-загрузчик Windows • обновит загрузочные данные Дальше нужно перезагрузить компьютер или сервер и зайти в настройки прошивки. Там меняем режим загрузки: Legacy / CSM -> UEFI Если есть опция boot order, выбираем Windows Boot Manager для нужного диска. После успешной загрузки можно снова проверить режим: $env:firmware_type Теперь должно быть: UEFI #windows #uefi #gpt 🧑‍💻 NetworkAdmin

🖥 trap в bash: как правильно ловить ошибки и чистить временные файлы В скриптах часто есть временные файлы, lock-файлы, промежуточные каталоги и другие следы работы. Проблема начинается, когда скрипт падает посередине. Например: временный файл остался в /tmp; lock-файл не удалился; mount point не размонтировался; сервис был остановлен, но обратно не запущен; промежуточные данные остались в неконсистентном состоянии. Для таких случаев в bash есть trap. Он позволяет выполнить команду или функцию при наступлении события: выход из скрипта, ошибка, Ctrl+C, kill и так далее. ▪️ Самый частый сценарий - чистка временных файлов при завершении скрипта. #!/usr/bin/env bash set -euo pipefail TMP_DIR="$(mktemp -d)" cleanup() { rm -rf "$TMP_DIR" } trap cleanup EXIT echo "working in $TMP_DIR" # основная логика скрипта mktemp -d создает временный каталог cleanup() описывает, что нужно убрать trap cleanup EXIT гарантирует запуск cleanup при выходе из скрипта. Даже если скрипт завершится с ошибкой, временный каталог будет удален. Можно ловить не только обычный выход, но и прерывание с клавиатуры: trap cleanup EXIT INT TERM EXIT - любой выход из скрипта INT - прерывание через Ctrl+C TERM - сигнал завершения процесса ▪️ Полезный пример с lock-файлом: #!/usr/bin/env bash set -euo pipefail LOCK_FILE="/tmp/myjob.lock" cleanup() { rm -f "$LOCK_FILE" } trap cleanup EXIT if [[ -e "$LOCK_FILE" ]]; then echo "script already running" exit 1 fi touch "$LOCK_FILE" # основная логика sleep 30 Но тут важный момент: для защиты от повторного запуска лучше использовать flock, а не просто проверку файла. Зато trap отлично подходит, чтобы гарантированно убрать временные следы после работы. ▪️ Еще полезный прием - выводить сообщение при ошибке: error_handler() { echo "error on line $LINENO" } trap error_handler ERR Так можно быстрее понять, где именно скрипт упал. ▪️ На практике часто объединяют оба подхода: cleanup() { rm -rf "$TMP_DIR" } on_error() { echo "script failed on line $LINENO" } trap cleanup EXIT trap on_error ERR trap не делает скрипт надежным сам по себе. Он только помогает корректно завершиться и прибрать за собой. #bash #scripting 🧑‍💻 NetworkAdmin

без подписи