🧰 Проверка сетевых подключений с помощью ss
Заменим устаревший netstat!

Сегодня хочу показать вам, как удобно и эффективно использовать команду ss для анализа сетевых подключений. Это современная альтернатива netstat, которая работает быстрее и дает больше деталей.

🔍 Примеры, которые стоит запомнить:

ss -tuln

Показывает все слушающие TCP/UDP порты без разрешения имён. Часто использую при проверке, какие службы открыты наружу.

ss -tp

Показывает активные TCP-соединения с указанием PID/имени процесса. Очень выручает при отладке приложений, которые что-то "держат".

ss -s

Краткая сводка по соединениям — как netstat -s, но быстрее. Отлично, чтобы быстро глянуть на состояние TCP-стека.

💡 Совет: если у вас в системе много соединений, используйте ss с фильтрами, например:

ss -t state established '( dport = :ssh or sport = :ssh )'

Покажет только установленные SSH-соединения — очень удобно, если сервер используется как bastion.



👨‍💻 А вы уже полностью перешли на ss или ещё пользуетесь netstat по привычке? Делитесь в комментариях своим опытом!

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

👉 @linux_odmin

🛠 Как узнать, кто перезагрузил сервер?

Сегодня покажу вам простой способ выяснить, кто именно инициировал перезагрузку сервера. Иногда бывает так: сервер внезапно ушёл в ребут, и ты не уверен — это был плановый рестарт, баг или кто-то нажал reboot не подумав. Давайте разбираться!

🔍 Шаг 1: Проверяем журнал перезагрузки

last -x | grep reboot

Эта команда покажет дату и время перезагрузки. Но кто?

🔍 Шаг 2: Ищем инициатора в журнале auditd (если он включён)

ausearch -k reboot

или

ausearch -x /sbin/reboot

Это поможет, если у вас включён auditd. Если нет — смотри следующий шаг.

🔍 Шаг 3: Проверка journalctl

journalctl -b -1 | grep -i 'reboot\|shutdown\|poweroff'

Здесь могут быть строки вроде:

systemd-logind[...]: Power key pressed.
systemd-logind[...]: Rebooting system.

или

systemd[1]: Received request to reboot from UID=1000

UID поможет понять, какой пользователь инициировал ребут.

🔍 Шаг 4: Кто был в системе до ребута?

last -F | head

Посмотри, кто был залогинен незадолго до перезагрузки. Возможно, это и есть "виновник".



🧠 Мой совет: Настрой логирование и аудит таких событий заранее — особенно на продакшене. А ещё можешь повесить алерт на неожиданные ребуты через Prometheus + Alertmanager.

Полезно? Делитесь в комментах своими кейсами, когда сервер ушёл в ребут «сам по себе» 😅

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

👉 @linux_odmin

🧠 Что делает команда exec в bash — и зачем она нужна?

Многие слышали о exec, но используют редко. А зря! Это мощный инструмент, особенно в скриптах и системном администрировании.

🔹 Что делает exec?
Она заменяет текущий процесс новым, без создания дочернего. То есть, вместо запуска новой программы — текущий процесс «перевоплощается» в неё.

Простой пример:

exec top

В этом случае оболочка bash будет заменена на top, и когда вы закроете top, сессия завершится.



🛠 Где это может пригодиться:

1. В systemd-юнитах — при запуске сервиса через скрипт:

   #!/bin/bash
   exec /usr/bin/myapp
   

Это позволит системе правильно отслеживать основной процесс.

2. В контейнерах (например, Docker) — если вы запускаете скрипт в качестве ENTRYPOINT, используйте exec, чтобы сигналы (например, SIGTERM) корректно передавались вашему приложению.

3. Для перенаправления ввода/вывода:

   exec >> /var/log/myscript.log 2>&1
   

Всё, что будет выведено в stdout и stderr после этой строки — пойдёт в лог.


⚡ exec не делает магии, но помогает делать вещи правильно. Особенно там, где важна замена PID и корректная работа сигналов.

А вы используете exec в своих скриптах? Поделитесь опытом 👇

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

👉 @linux_odmin

📌 Команда : xargs — что это, как использовать с find, реальные примеры


Если ты всё ещё пишешь

bash  
find . -name "*.log" -exec rm {} \;  

— пора познакомиться с xargs.


🔹 Что делает xargs
Простыми словами: берёт вывод одной команды и передаёт его как аргументы другой.
Часто используется в связке с find, grep, ls, cat и т.д.


🔧 Пример 1: удаление файлов

bash  
find . -name "*.log" | xargs rm  

Быстрее и читаемее, чем -exec.
А если в путях есть пробелы — добавь -print0 и -0:

bash  
find . -name "*.log" -print0 | xargs -0 rm  

🔧 Пример 2: архивация большого списка файлов

bash  
cat filelist.txt | xargs tar -czf archive.tar.gz  

Но лучше писать так:

bash  
xargs -a filelist.txt tar -czf archive.tar.gz  

⚠️ Полезные флаги
- -n N — запускать по N аргументов
- -P N — параллельное выполнение (например, -P 4 для 4 потоков)
- -I {} — подстановка аргументов вручную:

bash  
cat urls.txt | xargs -I {} curl -O {}

🧠 Где применять
- Удаление, копирование, перемещение файлов
- Обработка списков (имён, URL, путей)
- Массовый запуск скриптов
- Комбинация с parallel — огонь 🔥


✍️ Итог
xargs — это must-have в наборе админа.
Один раз освоил — и половина баш-магии стала проще.

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

👉 @linux_odmin

🎯 Как быстро очистить лог-файлы, не перезапуская сервис

Привет, коллеги! Сегодня хочу показать простой, но очень полезный приём для работы с логами. Иногда лог-файлы разрастаются до гигантских размеров, и хочется их обнулить — но без остановки сервиса, который пишет в этот файл.

🔧 Вот как это сделать:

: > /var/log/your-log.log

Или, альтернативно:

truncate -s 0 /var/log/your-log.log

📌 Что здесь происходит:

- : > — это no-op команда (:) с перенаправлением вывода в файл, по сути затирает его.
- truncate -s 0 — устанавливает размер файла в 0 байт.

💡 Главное: не удаляйте лог-файл напрямую!
Если вы сделаете rm /var/log/your-log.log, то большинство демонов продолжат писать в уже открытый файловый дескриптор — и вы потеряете лог, не освободив место.

Если лог-файл всё-таки нужно удалить — сделайте это аккуратно:

> /var/log/your-log.log && systemctl reload your-service

Или используйте logrotate — но об этом в одном из следующих постов 😉

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

👉 @linux_odmin

⚙️ Автоматизация рутинных задач с systemd timers

Привет, друзья! Сегодня расскажу, как я заменил cron на более гибкое решение — systemd timers.

Почему это круто?
👉 Логирование, зависимость от сервисов, простая отладка и интеграция в systemctl.

🔧 Пример: бэкап каталога каждый день

1. Создаем сервис-файл:

/etc/systemd/system/backup-home.service

[Unit]
Description=Backup /home to /backup

[Service]
Type=oneshot
ExecStart=/usr/local/bin/backup-home.sh

2. Создаем таймер:

/etc/systemd/system/backup-home.timer

[Unit]
Description=Daily backup of /home

[Timer]
OnCalendar=*-*-* 03:00:00
Persistent=true

[Install]
WantedBy=timers.target

3. Активируем:

sudo systemctl daemon-reexec
sudo systemctl enable --now backup-home.timer

📌 Скрипт backup-home.sh можно писать как угодно: rsync, tar, borg, хоть scp.

✅ Плюс: systemd сам выполнит задание при следующей загрузке, если сервер был выключен в 3 ночи (благодаря Persistent=true).

🔥 Используете systemd timers или предпочитаете cron? Расскажите, что автоматизируете!

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

👉 @linux_odmin

🔐 Сегодня покажу вам, как быстро проверить, какие пользователи могут входить по SSH

Когда нужно быстро провести аудит, кто действительно может зайти на сервер по SSH, поможет вот такой однострочник:

getent passwd | awk -F: '$3 >= 1000 && $7 ~ /bash/ {print $1}' | while read user; do
  if [ -f /home/$user/.ssh/authorized_keys ]; then
    echo "$user — доступ по ключу"
  elif grep -q "^$user:" /etc/shadow && [ "$(awk -F: -v u="$user" '$1 == u {print $2}' /etc/shadow)" != "*" ]; then
    echo "$user — может входить с паролем"
  fi
done

💡 Что делает скрипт?
- Ищет всех "нормальных" пользователей (UID ≥ 1000 и оболочка bash)
- Проверяет, есть ли у них authorized_keys — значит, ключи
- Если нет — сверяет в /etc/shadow, заблокирован ли пароль

📌 На заметку:
- Подходит для систем с классической схемой пользователей (не LDAP и не sssd)
- UID порог можно подправить под свою среду
- Можно дополнить логированием, например в syslog или файл


А ты проверяешь регулярно, кто может входить на твои сервера? Пиши в комментариях — автоматизировал ли ты аудит SSH-доступа у себя? 👇

#Linux@linux_odmin #LinuxTips@linux_odmin #Команды@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

👋 Привет, коллеги!

Сегодня хочу поделиться тем, что стоит автоматизировать на сервере в первую очередь. Это база, которая поможет вам сэкономить кучу времени и спать спокойно 😴


🔧 Что обязательно автоматизировать:

1. Резервное копирование (бэкапы)
> Без бэкапов нет продакшена. Это аксиома.

- Автоматизируйте регулярные бэкапы баз данных, конфигов, важных каталогов.
- Используйте rsnapshot, borg, restic, duplicity.
- Настройте оповещения об ошибках и ротацию архивов.


2. Установка и обновление пакетов
> Старое ПО = потенциальная уязвимость.

- unattended-upgrades (Debian/Ubuntu), dnf-automatic (RHEL/AlmaLinux).
- Обновляйте хотя бы критические патчи безопасности.


3. Мониторинг и алерты
> Узнать о проблеме до пользователей — 🔥

- Prometheus + Alertmanager, Zabbix, Netdata, Uptime Kuma.
- Telegram, Email, Slack — что угодно, лишь бы вы не прозевали тревогу.


4. Ротация и очистка логов
> Логи не должны съедать диск.

- logrotate с автоочисткой по размеру или сроку.
- Логи от багов нужны, но не навсегда 😉


5. Автоматический рестарт сервисов
> Упал — поднялся.

- systemd с Restart=on-failure, watchdog-скрипты.
- Плюс мониторинг: жив ли Nginx, работает ли БД.


6. Создание пользователей и SSH-ключей
> Добавлять вручную — долго и скучно.

- Скрипты, шаблоны, Ansible, cloud-init — на выбор.


7. Конфигурации и деплой
> Один конфиг — много серверов.

- Используйте Ansible, SaltStack, Chef, bash-скрипты с шаблонами.

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

👉 @linux_odmin

🔧 Сегодня покажу вам простой способ ограничить ресурсы для процессов с помощью cgroups v2

Иногда на сервере какой-нибудь процесс начинает «жрать» всё подряд — CPU, память, I/O. Чтобы таких ситуаций избежать, можно использовать cgroups v2.

📦 Пример: ограничим использование CPU и памяти для скрипта

# Создаём директорию cgroup
CGROUP=/sys/fs/cgroup/mylimit
mkdir $CGROUP

# Ограничим память до 200M
echo $((200*1024*1024)) > $CGROUP/memory.max

# Ограничим CPU до 20% от одного ядра
echo 20000 > $CGROUP/cpu.max  # 20000 микросекунд из 100000

# Запускаем процесс с этими ограничениями
echo $$ > $CGROUP/cgroup.procs
./your_script.sh

🔍 Проверить потребление можно так:

cat $CGROUP/memory.current
cat $CGROUP/cpu.stat

💡 Советы:
- Работает только если у вас включён cgroup v2 (можно проверить mount | grep cgroup)
- Удобно использовать вместе с systemd, если вы хотите применить это к сервисам (systemctl set-property)

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

👉 @linux_odmin

🛡 Сегодня расскажу, как быстро проверить безопасность конфигурации SSH-сервера

Открытый SSH — это ворота на сервер. И если конфигурация слабая, то защита — как дверь из картона. Проверим, насколько хорошо у вас настроен sshd.

✅ Вот простой чеклист, что стоит сделать:

# 1. Отключить root-доступ
PermitRootLogin no

# 2. Включить только ключевую авторизацию
PasswordAuthentication no

# 3. Установить ограничение по IP (если возможно)
# Можно использовать firewall или AllowUsers с указанием IP

# 4. Ограничить количество подключений:
MaxAuthTries 3
LoginGraceTime 30
MaxSessions 2

# 5. Изменить порт (не security, но уменьшает шум)
Port 2222

🔍 Проверка: используем ssh-audit

pip install ssh-audit
ssh-audit your.server.com

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

🛠 А ещё можно включить Fail2Ban или iptables для защиты от перебора паролей, если всё-таки оставляете PasswordAuthentication yes.

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

👉 @linux_odmin

🛠 strace: незаменимый инструмент для отладки зависших процессов

Привет, друзья! Сегодня расскажу про одну из моих любимых утилит — strace. Она помогает понять, что именно делает (или не делает) ваш процесс.

Представьте: процесс висит. Никаких логов. CPU не грузит. Что делать?

✅ Запускаем strace:

sudo strace -p <PID>

Где <PID> — идентификатор зависшего процесса.

📌 Вы сразу увидите системные вызовы, которые делает процесс: может, он ждёт файл, завис на сокете или лочит какой-то ресурс.

Если хотите записать всё в лог:

sudo strace -ff -o debug_log -p <PID>

- -ff — создаёт отдельный файл для каждого потока.
- -o — префикс имени лог-файла (например, debug_log.1234).

💡 А чтобы отследить запуск с нуля (например, подозрительный скрипт):

sudo strace -f -o trace.log ./script.sh

Очень удобно для анализа поведения сторонних бинарников или скриптов.


Пользуйтесь и делитесь с коллегами — strace может сэкономить часы диагностики! А вы часто его используете? Напишите в комментах, как он вас выручал 😎

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

👉 @linux_odmin

⏰ Systemd вместо cron: как настроить таймеры правильно

Привет, друзья! Сегодня покажу, как можно элегантно заменить cron с помощью systemd-таймеров. Это удобно, прозрачно и гибко — особенно в серверной среде, где важен контроль над логами, зависимостями и запуском задач.



💡 Почему лучше, чем cron?

- логи идут через journalctl
- удобная отладка: systemctl status, list-timers
- можно задать зависимости и условия запуска



🛠 Пример: скрипт бэкапа раз в день

Допустим, у нас есть скрипт /usr/local/bin/backup.sh. Создадим два юнит-файла:

🔹 backup.service

[Unit]
Description=Daily backup job

[Service]
Type=oneshot
ExecStart=/usr/local/bin/backup.sh

🔹 backup.timer

[Unit]
Description=Run daily backup

[Timer]
OnCalendar=*-*-* 03:00
Persistent=true

[Install]
WantedBy=timers.target

📌 OnCalendar=*-*-* 03:00 — запуск каждый день в 03:00
📌 Persistent=true — если сервер был выключен в это время, задача выполнится при следующем старте



🚀 Активация:

sudo systemctl daemon-reload
sudo systemctl enable --now backup.timer

Проверить активные таймеры:

systemctl list-timers

Посмотреть логи:

journalctl -u backup.service

С systemd всё под контролем! А ты уже пробовал такие таймеры вместо cron?

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

👉 @linux_odmin

🔒 Как быстро заблокировать IP через nftables без перезапуска правил

Иногда нужно срочно отрубить наглого сканера или атакующего IP, но без пересборки всего firewall-правила. Вот как это делается динамически, через nftables.



🔹 Шаг 1: создаём таблицу и цепочку (если ещё нет)

nft add table inet filter
nft add chain inet filter input { type filter hook input priority 0 \; }

🔹 Шаг 2: создаём сет blocked_ips

nft add set inet filter blocked_ips { type ipv4_addr \; flags timeout \; }

> timeout позволяет задавать TTL для блокировок.

🔹 Шаг 3: добавляем правило на блокировку из сета

nft add rule inet filter input ip saddr @blocked_ips drop

🔹 Шаг 4: баним IP с TTL 1 час

nft add element inet filter blocked_ips { 192.0.2.123 timeout 1h }

💡 Зачем это?
— Блокировка IP на лету, без перезагрузки firewall.
— Удобно использовать в связке со скриптами, fail2ban и даже вручную.
— Работает быстро и безболезненно для остальных правил.

🛑 Best practice: не делай flush ruleset, если используешь stateful блокировку — можно потерять connection tracking и нарушить трафик.


Сохрани, пригодится для быстрой обороны 🔥
А ты так блочишь IP?

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

👉 @linux_odmin

💥 WireGuard: Быстрая настройка через systemd без ifupdown и Netplan

Хочешь минимализм без танцев с бубном? Вот как быстро поднять WireGuard-туннель чисто через systemd — особенно удобно на серверах без NetworkManager.


📌 1. Создай конфиг /etc/wireguard/wg0.conf:

[Interface]
Address = 10.0.0.1/24
PrivateKey = <your_private_key>
ListenPort = 51820

[Peer]
PublicKey = <peer_pub_key>
AllowedIPs = 10.0.0.2/32

⚠️ Убедись, что chmod 600 wg0.conf — приватный ключ должен быть защищён.


📌 2. Активируй через systemd:

systemctl enable wg-quick@wg0
systemctl start wg-quick@wg0

👉 Это создаст интерфейс wg0 и применит всё из конфига.


📌 3. Проверка статуса:

wg show

Покажет активные пиры, handshake, трафик и т.д.


💡 Трюк:
Если используешь systemd-networkd, можешь вместо wg-quick собрать туннель через .netdev и .network — это даёт больше контроля и не требует wg-quick.


🧠 Когда использовать:
– Минималистичные серверы без NM и Netplan
– Контейнеры и чёткие systemd-based системы
– Желание поднять VPN при boot без сторонних скриптов

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

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

👉 @linux_odmin

💡 Как быстро сбросить зависший SSH-сеанс без ожидания таймаута

Иногда SSH-соединение замирает (например, при потере сети), и попытка закрыть его обычным Ctrl+C не работает. Не жди таймаута — есть правильный способ разорвать зависший сеанс.

🔧 Решение: спец-последовательность OpenSSH

Нажми Enter, затем ~. (тильда + точка) — и SSH сразу завершится:

<Enter>~.

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

~. — escape-последовательность, встроенная в OpenSSH-клиент. Работает только в начале новой строки.

👉 Другие полезные комбинации:
- ~? — список доступных escape-команд
- ~# — переслать локальный порт (вручную)
- ~& — фоновый режим

⚠️ Работает только в интерактивных SSH-сессиях, не в скриптах.

🧠 Зачем знать:
- Мгновенное закрытие зависших сессий
- Удобно при обрывах VPN/моб. сети
- Не нужен kill -9 на терминале

Сохрани, пригодится в дороге или на выезде 🚀

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

👉 @linux_odmin

⚠️ systemd-networkd и маршруты: частая ошибка с static routes

Если ты настраиваешь сеть через systemd-networkd и вручную прописываешь маршруты, будь внимателен: непрописанный gateway может сломать всё подключение.

📄 Пример .network файла с правильным static route:

[Match]
Name=eth0

[Network]
Address=192.168.1.10/24
Gateway=192.168.1.1

[Route]
Destination=10.10.0.0/16
Gateway=192.168.1.1

🔍 Типичная ошибка:

[Route]
Destination=10.10.0.0/16

❌ Без Gateway или PreferredSource маршрут будет нерабочим или странно себя вести.

📌 Зачем и когда это нужно:
— Когда нужно направить часть трафика (например, к VPN или другим подсетям) в обход основного маршрута.
— systemd сам не всегда умеет «додумать», как доставить пакет, если маршрут не полный.

🧪 Проверь после старта:

networkctl status eth0
ip route show dev eth0

💡Проверяй journalctl -u systemd-networkd — там видно, почему не применились маршруты.

Сохрани, чтобы не отлаживать сеть часами 😬
А ты правильно пишешь [Route]?

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

👉 @linux_odmin

🛡️ Быстрая проверка iptables-правил с логированием трафика

Нужно быстро понять, почему пакет не доходит? Добавь временное логирование в iptables — это упростит отладку.

💡 Шаги:

1. Вставь логирующее правило перед DROP:

iptables -I INPUT -s 192.168.0.100 -j LOG --log-prefix "DROP DEBUG: " --log-level 4

👉 Меняй -s и -j под нужное направление/адрес.

2. Проверь логи (обычно dmesg или syslog):

dmesg | grep "DROP DEBUG"
# или
grep "DROP DEBUG" /var/log/syslog

3. Удалить правило после отладки:

iptables -D INPUT -s 192.168.0.100 -j LOG --log-prefix "DROP DEBUG: " --log-level 4

📌 Зачем и когда:
— Удобно при отладке фаервола, особенно при сложных правилах.
— Можно логировать и FORWARD/OUTPUT.
— Не забудь убрать, чтобы не заспамить логи!

💥 Лайфхак: добавь -m limit чтобы не заливать логи:

-m limit --limit 5/min

🧠 Сохрани, пригодится при разборе сетевых траблов.

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

👉 @linux_odmin

🔥 WireGuard через systemd: автоподключение при старте + автоматический рестарт

WireGuard крут, но не всегда подключается сам при перезагрузке. Особенно, если интерфейс поднимается раньше, чем сеть. Решение — systemd-сервис с зависимостями.

📌 Настраиваем правильный автозапуск

1. Создай кастомный systemd unit:

sudo systemctl edit wg-quick@wg0

2. Вставь следующее:

[Unit]
Description=WireGuard via wg-quick for %i
After=network-online.target
Wants=network-online.target

[Service]
Restart=on-failure
RestartSec=5

[Install]
WantedBy=multi-user.target

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

sudo systemctl daemon-reexec

4. Включи автозапуск:

sudo systemctl enable wg-quick@wg0

5. Проверь статус:

systemctl status wg-quick@wg0

🧠 Зачем это нужно?

- After=network-online.target гарантирует, что интерфейс поднимется после появления сети.
- Restart=on-failure полезен, если туннель может не подняться с первого раза (например, из-за временного недоступного пира).

⚠️ Без этого юнита туннель часто не поднимается после ребута на headless-серверах.

💡 Совет: проверь DNS внутри туннеля — в wg0.conf можно указать DNS=..., если используешь resolvconf или systemd-resolved.

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

#Linux@linux_odmin #VPN@linux_odmin #Systemd@linux_odmin

👉 @linux_odmin

💡 WireGuard через IPv6-only VPS с доступом к IPv4-сайтам

Если у тебя есть VPS только с IPv6 (например, Hetzner), но нужно обеспечить выход в IPv4-интернет — этот пост для тебя.

🔧 Настраиваем NAT64 + DNS64 через WireGuard

1. Устанавливаем и настраиваем WireGuard на сервере (IPv6-only VPS):

apt install wireguard

/etc/wireguard/wg0.conf:

[Interface]
Address = fd00::1/64
ListenPort = 51820
PrivateKey = <серверный_приватный_ключ>
PostUp = sysctl -w net.ipv6.conf.all.forwarding=1
PostUp = iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
PostDown = iptables -t nat -D POSTROUTING -o eth0 -j MASQUERADE

[Peer]
PublicKey = <клиентский_публичный_ключ>
AllowedIPs = fd00::2/128

2. Добавляем NAT64 с Tayga:

apt install tayga

/etc/tayga.conf:

tun-device nat64
ipv4-addr 192.0.2.1
prefix 64:ff9b::/96

mkdir -p /var/spool/tayga
tayga --mktun
ip link set nat64 up
ip addr add 192.0.2.1 dev nat64
ip addr add 64:ff9b::1 dev nat64
ip route add 64:ff9b::/96 dev nat64

3. Настраиваем DNS64 (через bind9 или unbound):
Пример настройки unbound:

apt install unbound

В unbound.conf:

module-config: "dns64 validator iterator"
dns64-prefix: 64:ff9b::/96

4. WireGuard на клиенте:

[Interface]
PrivateKey = <клиентский_ключ>
Address = fd00::2/128

[Peer]
PublicKey = <серверный_ключ>
Endpoint = [IPv6-адрес]:51820
AllowedIPs = ::/0

⚙️ Зачем это?
Так можно использовать дешевый IPv6-only VPS как NAT64-шлюз и обойтись без дорогого IPv4-адреса. Подходит для роутера или ноутбука за CGNAT.

💡 Фишка:
Можно комбинировать с systemd-resolved или dnsmasq для более гибкого DNS64.

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

#Linux@linux_odmin #WireGuard@linux_odmin #Сеть@linux_odmin

👉 @linux_odmin