Прокидываем TCP-порты через socat!

Бывает требуется опубликовать локальный TCP-сервис на другом порту или адресе, не изменяя конфигурацию приложения и не разворачивая отдельный reverse proxy. Для этого в линукс удобно использовать socat — универсальный инструмент для двунаправленной передачи данных между сокетами.

Установим socat в Debian или Ubuntu:

sudo apt update && sudo apt install socat -y

Предположим, приложение принимает соединения только на loopback-адресе:

127.0.0.1:8080

Проверим listener через ss:

ss -tlnp | grep ':8080'

Для сервиса, привязанного к IPv4 loopback, вывод может выглядеть так:

LISTEN 0 128 127.0.0.1:8080 0.0.0.0:*

Чтобы временно опубликовать сервис через порт 9000, запускаем дополнительный listener:

socat TCP-LISTEN:9000,reuseaddr,fork \
  TCP:127.0.0.1:8080

socat принимает соединения на 9000/tcp и для каждого из них устанавливает TCP-соединение с 127.0.0.1:8080. Без bind IPv4-listener обычно привязывается к 0.0.0.0, поэтому порт становится доступен на IPv4-адресах хоста с учётом firewall и других сетевых ограничений.

Проверим новый listener:

ss -tlnp | grep ':9000'

Если входящие соединения на 9000/tcp разрешены, сервис можно проверить через адрес сервера:

curl http://203.0.113.10:9000

Адреса из документационных диапазонов в примерах необходимо заменить реальными адресами своей инфраструктуры. Параметр fork создаёт дочерний процесс для каждого принятого соединения, а reuseaddr включает SO_REUSEADDR и упрощает повторную привязку адреса после перезапуска.

Если публиковать порт на всех локальных IPv4-адресах не требуется, listener можно привязать к конкретному адресу:

socat TCP-LISTEN:9000,bind=192.0.2.10,reuseaddr,fork \
  TCP:127.0.0.1:8080

В этом случае соединения принимаются только на 192.0.2.10. Параметр bind выполняет привязку к IP-адресу, а не непосредственно к сетевому интерфейсу.

socat также может проксировать TCP-соединения на другой сервер. Например, локальный 5433/tcp можно направить на PostgreSQL внутри другой сети:

socat TCP-LISTEN:5433,bind=127.0.0.1,reuseaddr,fork \
  TCP:10.0.0.20:5432

Для локального клиента это обычное соединение с 127.0.0.1:5433, тогда как socat передаёт байтовый поток на 10.0.0.20:5432:

psql -h 127.0.0.1 -p 5433 database

Ещё один полезный сценарий — публикация Unix domain socket через локальный TCP-порт. Предположим, приложение использует следующий сокет:

/run/myapp/app.sock

Свяжем его с 127.0.0.1:8080:

socat TCP-LISTEN:8080,bind=127.0.0.1,reuseaddr,fork \
  UNIX-CONNECT:/run/myapp/app.sock

Если приложение обслуживает HTTP, проверить соединение можно через curl:

curl http://127.0.0.1:8080

Работает и обратное направление: Unix-сокет может передавать соединения в TCP:

socat UNIX-LISTEN:/tmp/backend.sock,fork \
  TCP:127.0.0.1:8080

Для диагностики достаточно добавить -d -d, чтобы socat выводил информацию о создаваемых соединениях:

socat -d -d \
  TCP-LISTEN:9000,reuseaddr,fork \
  TCP:127.0.0.1:8080

Для постоянного проксирования предпочтительнее использовать штатную конфигурацию сервиса, reverse proxy, NAT или отдельный systemd-unit. socat полезен для диагностики, временной публикации сервисов и связывания TCP с Unix domain sockets без изменения конфигурации приложений.

🔥 socat позволяет одной командой организовать простой транспортный прокси между TCP-портами, удалёнными адресами и Unix-сокетами — хороший инструмент для диагностики и тестирования сетевого взаимодействия.

🚪 Linux Ready | #практика

📂 Напоминалка по расширению параметров Bash!

Например, ${VAR:-default} использует значение по умолчанию, если переменная не задана, а ${VAR##pattern} и ${VAR%%pattern} позволяют удалять части строк прямо средствами Bash без дополнительных команд.

На картинке — основные возможности Bash Parameter Expansion: установка значений по умолчанию, удаление префиксов и суффиксов, поиск и замена строк, извлечение подстрок, получение длины переменной и др.

Сохрани, чтобы не потерять!

🚪 Linux Ready | #ресурс

❤️ Oh My BackEnd — дорожная карта для backend-разработчиков!

В репозитории собраны ключевые навыки, необходимые для разработки веб-приложений: от Linux, Docker, сетей и баз данных до HTTP, безопасности, мониторинга и проектирования систем. Удобно, что темы расположены в рекомендуемом порядке изучения, разделены по уровням сложности и дополнены пояснениями о том, где и зачем эти знания применяются.

Оставляю ссылочку: GitHub 📱

🚪 Linux Ready | #репозиторий

🔴В 2025 году Россияне заработали 5,3 млрд рублей на арбитраже криптовалют

По данным Минфин 32% граждан покинули своё место работы поскольку уже в первый месяц смогли заработать 250 000 рублей, а через 2-3 месяца с легкостью вышли на семизначные числа.

Самое смешное, что лишь 8% россиян что-то слышали об этой профессии хотя все инструкции бесплатно лежат на канале Арбитраж Криптовалют

Там объясняют, как имея телефон и доступ в интернет заработать свои первые $3000. Причём разжёвывают так доступно, что поймёт даже ребенок. Кстати, на канале сегодня вышла новая рабочая связка!

Ссылка для входа — https://t.me/+gL6CZ_b93PBhZGM6

В util-linux есть инструмент lsfd, который позволяет фильтровать открытые файловые дескрипторы по их свойствам!

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

Вместо ручного поиска по /proc можно использовать lsfd:

sudo lsfd -Q 'DELETED'

Фильтр -Q позволяет выбирать дескрипторы по выражению, а DELETED — находить открытые файлы, которые уже удалены из файловой системы.

Можно сразу вывести только интересующие поля:

sudo lsfd -Q 'DELETED' \
  -o PID,COMMAND,NAME

Так становится видно, какой процесс удерживает файл и к какому пути тот относился.

А самое интересное — lsfd умеет не просто показывать список, а выполнять выборки по свойствам дескрипторов:

# Дескрипторы конкретного процесса
sudo lsfd -Q 'PID == 1234'

Это удобно при разборе утечек дескрипторов, проблем с освобождением места и неожиданного поведения долгоживущих сервисов.

🔥 lsfd превращает диагностику файловых дескрипторов в обычную фильтруемую выборку. Полезно, когда нужно быстро найти конкретный класс открытых файлов, а не просматривать огромный список вручную.

🚪 Linux Ready | #совет

👨‍💻 На Хабре лежит годная статья: «Всё, что вы настроили в Linux, можно было не настраивать»!

В этой статье:
• Узнаете, почему автор после 15 лет использования Linux отказался от сложных конфигураций в пользу Fedora с GNOME;
• Разберёте, когда i3, кастомные панели, dotfiles и скрипты действительно полезны, а когда лишь усложняют работу;
• Задумаетесь, почему постоянная настройка окружения часто создаёт иллюзию продуктивности, не ускоряя решение реальных задач.

🔊 Продолжай читать на Habr!

🚪 Linux Ready | #статья

Как принудительно ограничить аппетит прожорливого процесса, чтобы он не использовал весь процессор и не вешал сервер?

Когда тяжелый скрипт, бэкап или процесс компиляции внезапно забивает CPU под 100%, сервер перестает отвечать, а соседние сервисы начинают падать. Вместо радикального убийства процесса через kill можно использовать утилиту cpulimit, которая динамически контролирует его работу, отправляя сигналы остановки и возобновления, удерживая нагрузку в жестких рамках.

Ограничение уже запущенного процесса по его идентификатору (PID) до заданного процента мощности:

$ cpulimit -p 1234 -l 40

Утилита перехватит управление процессом 1234 и не позволит ему занять более 40% от одного ядра CPU.

Запуск новой тяжелой задачи с автоматическим и мгновенным лимитированием ресурсов:

$ cpulimit -l 25 -- tar -czf backup.tar.gz /var/www

Архивация начнется в фоне, но процесс гарантированно будет использовать не более четверти процессорного времени.

Важно: cpulimit высчитывает проценты от общего числа ядер (на 4-ядерном процессоре лимит 200% означает полную загрузку двух ядер), и для работы с чужими процессами понадобятся права sudo.

🔥 Помогает на лету усмирить любой фоновый скрипт или парсер, сохраняя стабильность и отзывчивость всей ОС.

🚪 Linux Ready | #совет