🔥 Чеклист: почему не работает iptables NAT на Debian/Ubuntu

Столкнулся с тем, что DNAT/SNAT в iptables не пашет, хотя правила прописаны? Вот быстрый разбор:

1. Включи IP Forwarding:

sysctl net.ipv4.ip_forward
sudo sysctl -w net.ipv4.ip_forward=1

(или пропиши в /etc/sysctl.conf:
net.ipv4.ip_forward=1)

2. Проверь таблицу NAT:

sudo iptables -t nat -L -n -v

3. Не забывай о правилах FORWARD:

sudo iptables -L FORWARD -n -v

— Должны быть разрешающие правила для трафика между нужными интерфейсами.

4. Проверяй, не конфликтует ли firewalld или nftables:
На новых системах могут быть активны другие firewall-менеджеры.

sudo systemctl status firewalld
sudo systemctl status nftables

5. Обнови iptables-persistent после изменений:

sudo netfilter-persistent save

⚠️ После всех правок — всегда тестируй NAT с помощью tcpdump на обоих интерфейсах, чтобы видеть, проходит ли трафик!

Сохрани, чтобы не искать в следующий раз!

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

👉 @linux_odmin

NetworkManager иногда игнорирует ручные изменения в /etc/resolv.conf

На современных дистрибутивах (Ubuntu, CentOS, Fedora) за DNS часто отвечает NetworkManager, который может перезаписывать /etc/resolv.conf при каждом подключении. Ручные правки слетают, DNS-серверы меняются сами собой — раздражает?

✅ Решение:
Закрепи нужный DNS через NetworkManager, чтобы изменения были постоянными.

Пошагово:

1. Найди имя интерфейса:

   nmcli device status
   

2. Пропиши DNS для интерфейса:

   nmcli con mod <имя_подключения> ipv4.dns "8.8.8.8 1.1.1.1"
   nmcli con mod <имя_подключения> ipv4.ignore-auto-dns yes
   

3. Перезапусти соединение:

   nmcli con down <имя_подключения> && nmcli con up <имя_подключения>
   

4. Проверь результат:

   resolvectl status
   

💡 Трюк:
Чтобы глобально задать DNS для всех новых соединений:

nmcli networking off
nmcli general hostname myhost
nmcli con mod "System eth0" ipv4.dns "8.8.8.8"
nmcli con mod "System eth0" ipv4.ignore-auto-dns yes
nmcli networking on

⚠️ Избегай ручного редактирования /etc/resolv.conf при использовании NetworkManager — иначе гарантированы "сюрпризы" после ребута или reconnection.

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

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

👉 @linux_odmin

🔐 Быстрый способ защитить SSH от брутфорса с помощью nftables

SSH-серверы в публичной сети постоянно испытывают волну брутфорс-атак. Вместо дополнительного уровня с fail2ban можно использовать встроенные возможности nftables для динамической блокировки злонамеренных IP.


1. Создаём таблицу и базовый цепочки

   sudo nft add table inet filter
   sudo nft 'add chain inet filter input { type filter hook input priority 0 \; }'
   sudo nft 'add set inet filter blacklist { type ipv4_addr\; flags dynamic\; }'
   

* table inet filter: единая таблица для IPv4/IPv6.
* chain input: обрабатывает входящий трафик до локального стека.
* set blacklist: обрабатывает динамические списки IP (добавляем IP при превышении лимита).

2. Добавляем правило учёта попыток подключения

   sudo nft add rule inet filter input tcp dport 22 ct state new limit rate 10/minute accept comment "Разрешаем до 10 новых зачключений SSH в минуту"
   sudo nft add rule inet filter input tcp dport 22 ct state new add @blacklist { ip saddr } expire 1h comment "Если превысили скорость — вносим в чёрный список на 1 час"
   

* ct state new + limit: разрешаем первые 10 новых соединений в минуту.
* add @blacklist { ip saddr }: при каждом новом подключении вне лимита IP добавляется в blacklist.

3. Блокируем пакеты из чёрного списка

   sudo nft insert rule inet filter input ip saddr @blacklist drop comment "Блокируем SSH для чёрного списка"
   

* insert: ставим правило выше остальных, чтобы сразу сбрасывать пакеты.
* @blacklist: любой IP из сета моментально сбрасывается.

4. Сохраняем конфигурацию

   sudo nft list ruleset > /etc/nftables.conf
   sudo systemctl enable nftables --now
   

* list ruleset сохраняет текущее состояние, после перезагрузки правила восстанавливаются.


Зачем и когда использовать:

* Почему: минимизируем зависимость от внешних скриптов, снимаем нагрузку при атаке (нет лишних fork/grep/iptables).
* Когда: если сервер доступен из интернета, и надо быстро выставить «самоблок» без дополнительных демонов.


🌟 Вместо фиксированного времени (expire 1h) можно использовать «скоростной» подход с limit rate напрямую:

nft add rule inet filter input tcp dport 22 ct state new counter limit rate over 15/minute drop comment "Быстрая блокировка при 15 попытках в минуту"

- так не потребуется динамический set, а «автоблок» сработает мгновенно.


Сохрани, пригодится!
А ты так защищаешь SSH?

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

👉 @linux_odmin

⚡ Как оптимизировать сетевой стек 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="[email protected]"
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