⚡ Как оптимизировать сетевой стек Linux для высоких нагрузок

В условиях высоких сетевых нагрузок стандартных настроек ядра и драйверов NIC часто недостаточно: возникают «пропуска» пакетов, увеличивается задержка и теряется пропускная способность. Ниже — практическое руководство по тонкой настройке с помощью ethtool и sysctl на Debian/Ubuntu (или производных).


1. Аудит текущих параметров

Проверяем значения кольцевых буферов (RX/TX):

  sudo ethtool -g eth0
  

Показывает текущие размеры ring-буферов: rx, tx, rx-mini, rx-jumbo и т.д.
Смотрим текущие sysctl-параметры сетевого стека:

  sysctl net.core.rmem_max net.core.wmem_max \
         net.ipv4.tcp_rmem net.ipv4.tcp_wmem net.ipv4.tcp_congestion_control
  

2. Увеличиваем буферы NIC

1. Подбираем оптимальные значения.
Обычно в нагрузочных дата-центрах достаточно:

   sudo ethtool -G eth0 rx 4096 tx 4096
   

* rx 4096 — кольцевой буфер для приёма пакетов.
* tx 4096 — кольцевой буфер для передачи.

> Когда применять: На серверах с большой пропускной способностью (>1 Gbps) и высокой маллатентностью сети.

2. Проверяем после изменения:

   ethtool -g eth0
   

Убедитесь, что значения приняты драйвером.


3. Настройка параметров ядра (sysctl)

Добавьте в /etc/sysctl.d/99-network-tuning.conf:

# Увеличиваем максимальные размеры буферов ядра
net.core.rmem_max = 16777216
net.core.wmem_max = 16777216

# Стандартизованные границы TCP-буферов (min/default/max)
net.ipv4.tcp_rmem = 4096 87380 16777216
net.ipv4.tcp_wmem = 4096 65536 16777216

# Увеличиваем очередь для входящих соединений
net.core.netdev_max_backlog = 5000

# Активация TCP-Congestion Control: BBR (если ядро поддерживает)
net.ipv4.tcp_congestion_control = bbr
net.ipv4.tcp_mtu_probing = 1

* rmem_max/wmem_max задают максимальный объём памяти, выделяемой ядром под сетевые буферы.
* tcp_rmem/tcp_wmem определяют минимум/дефолт/максимум для динамического буфера TCP-соединения.
* netdev_max_backlog увеличивает очередь пакетов, ожидающих обработки kernel-space до userspace.
* BBR снижает задержки и повышает пропускную способность в условиях загруженных сетей.

Применяем:

sudo sysctl --system

4. Проверка и валидация

Мониторим показатели через ss или netstat:

  ss -s
  

Смотрим на количество ошибок, состояние TCP-сокетов, очереди.

* Измеряем пропускную способность:

  iperf3 -c <сервер> -P 4 -t 60
  

Сравниваем до и после настроек.


5. Зачем и когда применять

* Виртуальные машины/контейнеры с «тонкой» сетью: при «подёргиваниях» в трафике (bursty traffic).
* Серверы игр/стриминга/СХД: где важна низкая задержка и высокая стабильность.
* Сервисы с пиковыми нагрузками (backup, CDN-ноды): помогут снизить потерю пакетов при пиках.


6. Полезный трюк и предостережение

* Трюк:
Чтобы изменения NIC-буферов применялись автоматически при перезагрузке, создайте udev-правило /etc/udev/rules.d/70-ethtool.rules:

  ACTION=="add", SUBSYSTEM=="net", NAME=="eth0", RUN+="/usr/sbin/ethtool -G eth0 rx 4096 tx 4096"
  

* Предупреждение:
На VDS с ограниченной памятью чрезмерное увеличение буферов может привести к OOM-ситуациям. Всегда мониторьте нагрузку на RAM и swap.


Вывод
С помощью правильной комбинации ethtool + sysctl можно значительно улучшить сетевые метрики: снизить пинг, уменьшить потерю пакетов и увеличить throughput.

👉 Сохрани, пригодится!

#Linux@linux_odmin #LinuxTips@linux_odmin #Команды@linux_odmin

👉 @linux_odmin

Ускоряем TCP-стек: тонкий тюнинг offload и sysctl

В самом пиковом трафике TCP-серверы часто не вытягивают заявленную пропускную способность. Причина — неэффективные offload-фичи NIC и «жесткие» дефолтные параметры ядра.

1. Проверяем возможности сети (offloads):

ethtool -k eth0

Вы увидите, какие фичи задействованы (GRO, GSO, TSO, LRO и т.п.).

2. Тонкая настройка offload-фичей:

▫️Чтобы отключить оффлоад (например, при отладке или если оборудование плохо работает):

  ethtool -K eth0 gro off gso off tso off lro off
  

▫️Чтобы вернуть на продакшн-уровень (во многих случаях лучше оставить включённым):

  ethtool -K eth0 gro on gso on tso on lro on
  

Зачем: отключение может помочь выявить причину артефактов или падений производительности. В бою же правильная комбинация offload снижает CPU-нагрузку.

3. Настройка sysctl для TCP-стека:
Создаём файл /etc/sysctl.d/99-network-tuning.conf с ключевыми параметрами:

# Увеличиваем буферы приёмника/передачи
net.core.rmem_max = 268435456
net.core.wmem_max = 268435456

# Автоматически масштабируем буферы TCP
net.ipv4.tcp_rmem = 4096 87380 268435456
net.ipv4.tcp_wmem = 4096 87380 268435456

# Увеличиваем размер очереди соединений
net.core.somaxconn = 1024

# Включаем TCP Fast Open (по возможности)
net.ipv4.tcp_fastopen = 3

# Тюнинг для низкой задержки (если нужно)
net.ipv4.tcp_low_latency = 1

Сохраняем и применяем:

sysctl --system

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

4. Полезный трюк (systemd-интеграция offload):
Вместо скриптов можно зафиксировать нужные offload-параметры в профиле systemd-networkd.
Создаём /etc/systemd/network/20-eth0.network:

[Match]
Name=eth0

[Link]
# Примеры: включить TSO и GSO, отключить GRO
TCPGenericReceiveOffload=no
TCPGenericSendOffload=yes

Дальше:

systemctl restart systemd-networkd

Такой подход гарантирует, что при рестарте сети offload-настройки сохранятся.

5. Предупреждение об ошибке:
Не стоит «глушить» все offload-фичи на продакшене без причин — может вырасти CPU-загрузка и снизиться общая пропускная способность.

Заключение:
Правильный монтаж offload и sysctl-тюнинг — залог стабильной и быстрой сети.

#Linux@linux_odmin #LinuxTips@linux_odmin #Команды@linux_odmin

👉 @linux_odmin

🚀 Bash скрипт мониторинга заполнения диска с оповещением на email 📩

Отслеживаем заполнение дисковых разделов и получаем предупреждения, когда они переполняются.

#!/usr/bin/env bash

# ⚙️ Настройки
THRESHOLD=80           # порог заполнения в %
EMAIL="admin@example.com"
SUBJECT="⚠️ Disk Usage Alert on $(hostname)"
TMPFILE=$(mktemp)

# 📊 Сбор данных о дисках
df -H | grep -vE '^Filesystem|tmpfs|cdrom' > "$TMPFILE"

# 📣 Проверка и оповещение
while read -r filesystem size used available percent mount; do
    used_value=${percent%\%}
    if [ "$used_value" -ge "$THRESHOLD" ]; then
        echo -e "Раздел: $filesystem\nТочка монтирования: $mount\nЗаполнено: $percent" | \
        mail -s "$SUBJECT" "$EMAIL"
    fi
done < "$TMPFILE"

# 🧹 Убираем временный файл
rm "$TMPFILE"

1. THRESHOLD – задаёт порог в процентах, при котором срабатывает оповещение.
2. df -H – получает информацию о дисках в «читаемом» формате (GB).
3. Цикл while перебирает строки, игнорируя заголовки и tmpfs.
4. Если заполнение раздела ≥ $THRESHOLD %, отправляем письмо через mail -s.


✨Запланируйте выполнение скрипта через cron:

  # Каждые 30 минут
  */30 * * * * /path/to/disk_alert.sh
  

Вместо email можно отправлять уведомления в Slack или Telegram через их API.
Для логирования добавьте запись в syslog через logger.

#Linux@linux_odmin #LinuxTips@linux_odmin #Команды@linux_odmin

👉 @linux_odmin

🔍 Быстрая диагностика задержек и потерь пакетов с tcpdump + tshark

Устали искать «почему тормозит сеть» вслепую? Давайте соберём данные и быстро выявим узкое место.

1️⃣ Сниффинг трафика

tcpdump -i eth0 port 80 -w /tmp/capture.pcap \
  -C 50 -W 4

• -C 50 & -W 4 — кольцевой буфер: четыре файла по 50 МБ, без остановки
• port 80 — фильтрация по порту (замените на нужный)

2️⃣ Подсчёт средних RTT и пакетов

tshark -r /tmp/capture.pcap \
  -q -z io,stat,0,AVG(tcp.analysis.ack_rtt)

Выдаст статистику задержек TCP-ACK во времени.

3️⃣ Анализ потерь и повторов

tshark -r /tmp/capture.pcap \
  -Y "tcp.analysis.retransmission or tcp.analysis.loss" \
  -T fields -e frame.number -e tcp.analysis.retransmission

Список фреймов с повторными передачами или потерями.

4️⃣ Состояние сокетов в реальном времени

ss -s          # общая статистика
ss -ti dst :80 # детально по портам

❓ Зачем и когда

Выявить задержки: RTT и пики задержек.
Найти потери: точно знать, на каком сегменте уходит трафик.
Без GUI: всё в консоли, подходит для серверов.

💡 Трюк
Для live-анализа пропускайте вывод tcpdump напрямую:

tcpdump -i eth0 -l port 443 | tshark -l -T fields -e frame.time_relative -e tcp.analysis.ack_rtt

Таким образом вы сразу видите задержки без файлов.

#Linux@linux_odmin #LinuxTips@linux_odmin #Команды@linux_odmin

👉 @linux_odmin

🔒 iptables: блокируем скан nmap

Многие забывают: nmap умеет скрываться. Обычные правила iptables не всегда помогут. Но есть трюк.

📌 Цель: заблокировать NULL, FIN, XMAS сканы — любимые техники скрытного обнаружения.



👣 Пошагово:

# Блокируем NULL-скан (без флагов)
iptables -A INPUT -p tcp --tcp-flags ALL NONE -j DROP

# Блокируем FIN-скан (только FIN-флаг)
iptables -A INPUT -p tcp --tcp-flags ALL FIN -j DROP

# Блокируем XMAS-скан (FIN, PSH, URG)
iptables -A INPUT -p tcp --tcp-flags ALL FIN,PSH,URG -j DROP

💡 Эти сканы эксплуатируют особенности TCP — они не характерны для нормального трафика. Если ты не хостишь экзотику, можно смело дропать.



⚠️ Важно: Не перебарщивай — агрессивные правила могут мешать нестандартным приложениям (например, BitTorrent). Проверяй логи!


🔥 Добавь логирование в отдельную цепочку для отладки:

iptables -N SCAN_DROP
iptables -A SCAN_DROP -j LOG --log-prefix "PortScan Blocked: " --log-level 7
iptables -A SCAN_DROP -j DROP

# Пример с логом:
iptables -A INPUT -p tcp --tcp-flags ALL FIN,PSH,URG -j SCAN_DROP

🧠 Защита от портсканирования — это must-have на фронте. Идеально в связке с fail2ban.

Сохрани, пригодится 💥

#Linux@linux_odmin #LinuxTips@linux_odmin #Команды@linux_odmin

👉 @linux_odmin

🔥 Как быстро сбросить iptables, не потеряв доступ по SSH

Иногда после кривой настройки iptables можно отрезать себя от сервера. Но если SSH-сессия ещё активна — есть шанс всё вернуть.

🔧 Пошагово:
1. Сохраняем текущие правила в файл — на всякий случай:

iptables-save > /root/iptables.bak

2. Создаём “спасательный” скрипт для сброса:

cat <<EOF > /tmp/flush.sh
#!/bin/bash
iptables -P INPUT ACCEPT
iptables -P FORWARD ACCEPT
iptables -P OUTPUT ACCEPT
iptables -F
EOF

chmod +x /tmp/flush.sh

3. Запускаем с отложенным выполнением (через 1 минуту):

at now + 1 minute -f /tmp/flush.sh

4. ⚠️ За это время проверь правила и поправь ошибки.
Если всё заработает — отмени задание, чтобы не сбросить то, что уже исправлено:

atq # узнать ID задания
atrm <ID>

🧠 Зачем?
Этот приём спасает при ошибках в firewall’е, когда нельзя подключиться заново, но активная сессия ещё жива.

💡Добавляй в iptables-скрипты проверку подключения (например, через ping/curl), прежде чем применять DROP-политики.

Сохрани, пригодится. А ты так страхуешься?

#Linux@linux_odmin #LinuxTips@linux_odmin #Команды@linux_odmin

👉 @linux_odmin

🔥 Сетевой интерфейс завис после ifdown? Как поднять без ребута

Иногда после ifdown eth0 интерфейс "залипает": ip link показывает DOWN, ifup eth0 — молчит или пишет, что интерфейс уже внизу. Особенно частая беда при ручных правках /etc/network/interfaces.

📌 Решение:

# Убедимся, что интерфейс точно down
ip link show eth0

# Принудительно поднимем
ip link set eth0 up

# Применим конфиг из /etc/network/interfaces
ifup --force eth0

💡 Или ещё жёстче — снять все адреса и применить заново:

ip addr flush dev eth0
ifdown --force eth0 && ifup eth0

📍Когда применять:
– после кривого ifdown;
– при ошибках конфигурации сетевого интерфейса без желания ребутать;
– если systemctl restart networking не помогает.

🛑 Важно: на проде делай это только с консоли или IPMI, иначе останешься без доступа.

Сохрани — пригодится, когда SSH срежет сук под тобой 😅

#Linux@linux_odmin #LinuxTips@linux_odmin #Команды@linux_odmin

👉 @linux_odmin

Сколько раз бывало: "Где лежит этот конфиг? А в каком файле та самая строка?" — и понеслась лихорадочная проверка /etc, find, grep...

🔍 Поиск файлов по имени:

find /etc -name "sshd_config"

А если не знаешь точное имя — используй маску:

find /var/log -iname "*auth*"

📂 Поиск только файлов или только директорий:

find /opt -type f       # только файлы
find /srv -type d       # только каталоги

🧵 Поиск по содержимому файла — мой любимый grep:

grep -Ri "PermitRootLogin" /etc/ssh

Здесь:

* -R — рекурсивно,
* -i — игнор регистра.

🎯 Хочешь только имена файлов, а не строки? Используй:

grep -Rl "Listen 80" /etc

🔥 Ищу файлы, изменённые за последние сутки:

find /etc -mtime -1

Это спасает, если надо понять, кто и когда трогал конфиги. Отличный приём при разборе инцидентов.

#Linux@linux_odmin #LinuxTips@linux_odmin #Команды@linux_odmin

👉 @linux_odmin

🛠 Мини-гайд: Как читать htop, если ты не просто кликаешь мышкой

htop — любимая команда всех линуксоидов. Но многие юзают её по принципу “вижу, что что-то горит — и ладно”. А ведь она даёт кучу полезной инфы, если читать внимательно.

Вот что стоит смотреть:


🔹 CPU bars (вверху)
– Разноцветные полоски = разные типы загрузки

* 🔴 красное — system (ядро)
* 💚 зелёное — user (твои процессы)
* 🔵 синее — nice (низкий приоритет)
* ⚫ серое — idle (простой)

Если всё в красном — значит, ядро чем-то занято. Чаще всего — IO или проблемы с драйверами.


🔹 Memory / Swap
– Если swap активно используется — беда. RAM не хватает.
– Если swap постоянно растёт — ищи прожорливый процесс.


🔹 Сортировка по колонкам
Нажми F6, чтобы выбрать, по чему сортировать:
– CPU
– MEM
– TIME+ (время работы)
– PRI (приоритет)

Часто забывают про TIME+ — а он показывает, кто реально долго жрёт ресурсы.


🔹 Управление процессами прямо из htop
– F9 — убить процесс
– F7/F8 — изменить приоритет (nice)
– F3 — поиск по названию
– F2 — кастомизация интерфейса (рекомендую)


htop — не просто анимация для терминала. Это инструмент диагностики.

Запусти у себя, поиграй с колонками и цветами, и начни действительно понимать, что происходит в системе.

#Linux@linux_odmin #LinuxTips@linux_odmin #Команды@linux_odmin

👉 @linux_odmin

🧠Ловим «призрачный» трафик: tcpdump

Сервер «висит» — подозрительная активность, но ss, netstat и iftop ничего не показывают? Используй tcpdump, чтобы увидеть весь трафик в обход сокетов.


📌 1. Базовый сниффинг по интерфейсу:

tcpdump -i eth0 -n

📌 2. Только входящие подключения (например, к порту 22):

tcpdump -i eth0 'tcp dst port 22'

📌 3. Вывести IP-адреса и порты в читаемом виде:

tcpdump -ni eth0

📌 4. Сохраняем трафик в файл для анализа:

tcpdump -i eth0 -w /tmp/capture.pcap

📌 5. Проверка на скан SYN-пакетов (часто — злоумышленники):

tcpdump 'tcp[tcpflags] & tcp-syn != 0 and tcp[tcpflags] & tcp-ack == 0'

🔍 Когда использовать:
– Видишь нагрузку, а не можешь найти, кто её создаёт
– Подозрение на сканирование, ботнет или майнер
– Анализ нестандартного поведения сети

💡tcpdump может показать даже raw-трафик от контейнеров, tun-интерфейсов, снифферов, которые не видны через ss/netstat.

#Linux@linux_odmin #LinuxTips@linux_odmin #Команды@linux_odmin

👉 @linux_odmin

💡 Как ускорить резолв DNS в Linux (и не словить таймаут)

Иногда curl, apt, ping и др. тормозят из-за медленного DNS. Особенно при неверной конфигурации /etc/resolv.conf. Вот как это проверить и поправить:


🔧 1. Проверяем текущий DNS:

systemd-resolve --status | grep 'DNS Servers' -A2

или:

resolvectl status

Убедись, что указан локальный (127.0.0.53) резолвер, если используется systemd-resolved, или явные DNS (например, 8.8.8.8) — если нет.


⚙️ 2. Проверяем /etc/resolv.conf:

cat /etc/resolv.conf

Если там:

nameserver 127.0.0.53

— ок для systemd-resolved.

Если там:

nameserver 127.0.0.1

— опасно! Убедись, что локальный DNS работает (dnsmasq, unbound и пр.). Иначе — будут фризы.


🚑 3. Подключи быстрые DNS напрямую (если нужно):

sudo nano /etc/systemd/resolved.conf

Добавь:

[Resolve]
DNS=1.1.1.1 8.8.8.8
FallbackDNS=9.9.9.9

Применить:

sudo systemctl restart systemd-resolved

📌 Совет:

Проверь производительность DNS:

systemd-resolve google.com --statistics

Или используй dig, drill и resolvectl query.


#Linux@linux_odmin #LinuxTips@linux_odmin #Команды@linux_odmin

👉 @linux_odmin

🔗 goto: Навигация в консоли на новом уровне! 🚀

🔥 goto — это удобный инструмент для быстрого перемещения по директориям в командной строке. Если вы устали от постоянного набора длинных путей к папкам, этот инструмент станет вашим спасением!

🎯 Что делает goto?
- Позволяет сохранять короткие алиасы для директорий.
- Упрощает переход к важным папкам одной командой.
- Работает быстро, удобно и просто!

📌 Ключевые функции:
1. Добавление алиасов:

   goto add <alias> <path>
   

Пример:

   goto add projects ~/Documents/Projects
   

2. Навигация по алиасу:

   goto <alias>
   

Пример:

   goto projects
   

3. Список всех алиасов:

   goto list
   

4. Удаление алиасов:

   goto remove <alias>
   

💻 Установка
Просто клонируйте репозиторий и следуйте инструкциям:

git clone https://github.com/grafviktor/goto.git
cd goto
make install

🛠 Для кого?
- Разработчиков, которые работают с множеством проектов.
- Системных администраторов, часто переключающихся между директориями.
- Всех, кто хочет оптимизировать свою работу в терминале.


📥 Репозиторий: https://github.com/grafviktor/goto

#Linux@linux_odmin #Github@linux_odmin

👉 @linux_odmin

🚨 tcpdump + iptables: ищем странный трафик с минимальными усилиями

Бывает сервер грузится входящими соединениями, но откуда — непонятно. Ловим сразу по факту, не копаясь в логах.

🎯 Цель: отловить соединения к нестандартному порту, которых быть не должно.

🔧 Шаги:

1. Выясни, куда идет трафик:

   ss -tnlp
   

Смотри, какие порты слушаются. Допустим, нашли неожиданный порт 4444.

2. Добавь временное правило в iptables, чтобы логировать:

   iptables -I INPUT -p tcp --dport 4444 -j LOG --log-prefix "INCOMING 4444: " --log-level 4
   

3. Лови трафик через tcpdump, если логов нет или нужно больше деталей:

   tcpdump -i any port 4444 -n
   

Или в файл:

   tcpdump -i any port 4444 -n -w suspicious.pcap
   

4. Проверка логов:

   dmesg | grep 'INCOMING 4444'
   

Или в journald:

   journalctl -k | grep 'INCOMING 4444'
   

5. Удаление правила после анализа:

   iptables -D INPUT -p tcp --dport 4444 -j LOG --log-prefix "INCOMING 4444: " --log-level 4
   

⚠️ Зачем и когда применять:

– Быстрое выявление подозрительной активности
– Минимальное вмешательство в работу сервиса
– Отличный способ понять, «кто ломится» на редкие или ошибочно открытые порты

💡 tcpdump + iptables LOG — мощный дуэт для экспресс-анализа трафика без сложных тулов.

Сохрани, пригодится при разборе аномалий ⚙️

#Linux@linux_odmin #Github@linux_odmin

👉 @linux_odmin

🔒 Быстрый способ ограничить доступ к SSH по стране с помощью ipset + iptables

Если нужно быстро отрезать SSH от всего мира, кроме, скажем, России (или наоборот — закрыть доступ для определённой страны), вот практический способ.


1. Установи нужные пакеты:

apt install ipset xtables-addons-common -y

2. Скачай GeoIP базы:

/usr/lib/xtables-addons/xt_geoip_dl
/usr/lib/xtables-addons/xt_geoip_build -D /usr/share/xt_geoip /usr/share/xt_geoip/*

3. Создай ipset с нужной страной:

ipset create geo-ru hash:net

4. Загрузи IP-диапазоны страны (например, Russia):

wget -O - https://ipdeny.com/ipblocks/data/countries/ru.zone | while read ip; do ipset add geo-ru $ip; done

5. Применение iptables-правила:

iptables -A INPUT -p tcp --dport 22 -m set ! --match-set geo-ru src -j DROP

📌 Быстрый и действенный способ снизить количество bruteforce-попыток к SSH, особенно если сервер рассчитан на работу только из одной страны.

⚠️ Geo-блокировка не панацея — используйте вместе с fail2ban, ключами и сменой порта.

💡Можно применить тот же принцип для любого сервиса — не только SSH. Просто поменяй порт и ipset.

#Linux@linux_odmin #Github@linux_odmin

👉 @linux_odmin

🔥 Диагностика внезапных потерь связи через ip route get

Сеть вроде «живая», ping до шлюза идёт, но пакеты не доходят до нужного хоста? Быстрая проверка маршрута решит многое.

📌 Что делать:

ip route get 8.8.8.8

🔍 Что покажет:

- интерфейс, через который идёт маршрут
- IP-адрес источника (важно при policy routing)
- реальный шлюз
- отметку mtu, cache, unreachable и др.

🛠 Пример:

ip route get 8.8.8.8
8.8.8.8 via 192.168.1.1 dev eth0 src 192.168.1.100 uid 1000

Если вместо via ... → unreachable, значит маршрут битый или его нет.

👀 Когда использовать:

- подозрение на policy routing
- неочевидные проблемы при SNAT/DNAT
- быстро понять, почему не ходит трафик

💡 Трюк:
Добавь -o к ip — получишь вывод в JSON, удобно парсить в скриптах:

ip -j route get 8.8.8.8 | jq .

Сохрани, пригодится в проде, когда всё внезапно «перестаёт работать».

#Linux@linux_odmin #Github@linux_odmin

👉 @linux_odmin

🔥 Неожиданный source IP у входящих соединений? Проверяем Reverse Path Filtering (rp_filter)

📌 Столкнулись с асимметричной маршрутизацией, при которой ss или tcpdump показывают странный source IP? Или iptables дропает "легитимные" соединения? — проблема может быть в rp_filter.


1. Нужно проверить текущие настройки:

   sysctl net.ipv4.conf.all.rp_filter
   sysctl net.ipv4.conf.default.rp_filter
   

1 — strict mode (по умолчанию);
0 — отключено;
2 — loose mode (рекомендуется при асимметрии или сложной маршрутизации).

2. Временно изменить поведение:

   sysctl -w net.ipv4.conf.all.rp_filter=2
   sysctl -w net.ipv4.conf.default.rp_filter=2
   

3. Постоянно через /etc/sysctl.conf:

   net.ipv4.conf.all.rp_filter=2
   net.ipv4.conf.default.rp_filter=2
   

❗️ Когда применять:
Если используется policy-based routing, мульти-хоминг или VPN с отдельными маршрутами — strict режим (1) может ломать соединения.

💡Используйте 2 для loose проверки, если трафик приходит по одному интерфейсу, а уходит через другой.

#Linux@linux_odmin #Github@linux_odmin

👉 @linux_odmin

🎉Коллеги, всех причастных с праздником!!!

Желаю, чтобы начальство думало о тебе не только тогда, когда “ничего не работает”.

👉 @linux_odmin

🔥 Bash-скрипт: Поиск больших файлов в системе

Когда место на сервере внезапно заканчивается, найти "пожирателей" места бывает непросто. Вот простой скрипт, который покажет топ-20 самых больших файлов:

#!/bin/bash

# Где искать (по умолчанию — весь /)
SEARCH_DIR="/"

# Сколько файлов показывать
TOP=20

echo "=== Топ-$TOP самых больших файлов в $SEARCH_DIR ==="
find "$SEARCH_DIR" -type f -printf '%s %p\n' 2>/dev/null | sort -nr | head -n $TOP | awk '{printf "%10d MB  %s\n", $1/1024/1024, $2}'

Как использовать:

1. Сохраните в /usr/local/bin/bigfiles.sh.
2. Сделайте исполняемым:

   chmod +x /usr/local/bin/bigfiles.sh
   

3. Запускайте, например:

   /usr/local/bin/bigfiles.sh
   

#Linux@linux_odmin #Github@linux_odmin

👉 @linux_odmin

💡 Как я ускоряю поиск по логам в Linux

Сегодня покажу вам приём, который не раз спасал мне нервы при анализе логов.

Представим, что нужно найти ошибки в большом лог-файле, например /var/log/nginx/access.log. Обычно все начинают с:

cat access.log | grep "500"

Но это медленно. Лучше так:

grep "500" access.log

Ещё лучше — использовать less и внутри него grep-подобный поиск:

less +F access.log

А затем нажать /500 — и перейти по найденным совпадениям. Работает быстро, особенно на больших логах.

А если хочется реального профита, то вот мой любимый трюк:

grep -E "500|502|503" access.log | awk '{print $1}' | sort | uniq -c | sort -nr | head

Что делает эта команда:
- Ищет ошибки 500/502/503
- Извлекает IP-адреса (предположим, это первое поле)
- Считает, сколько раз каждый IP дал ошибку
- Показывает топ атакующих/плохих клиентов

Эта команда — мини-аналитика в одну строку. Часто помогает сразу понять, где проблема.


#Linux@linux_odmin #LinuxTips@linux_odmin #Команды@linux_odmin

👉 @linux_odmin