Linux Ready | DevOps

Прокидываем 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 | #практика

Подключаемся к закрытым серверам через SSH ProxyJump!

В инфраструктуре серверы часто не имеют публичного IP-адреса и доступны только из внутренней сети. При этом отдельный сервер может быть доступен извне и использоваться как промежуточный SSH-узел — bastion или jump host.

Например, bastion доступен по адресу 203.0.113.10, а внутренний сервер имеет адрес 10.0.0.20. Напрямую подключиться к внутреннему серверу из внешней сети нельзя:
ssh admin@10.0.0.20

Если bastion имеет доступ к 10.0.0.20:22, используем ProxyJump:
ssh -J user@203.0.113.10 admin@10.0.0.20

(адреса в примерах документационные — при повторении замените их на свои)

SSH сначала подключится к 203.0.113.10, а соединение с SSH-сервером на 10.0.0.20 будет установлено через этот промежуточный узел.

Если SSH на bastion работает на нестандартном порту, его можно указать прямо в параметре -J:
ssh -J user@203.0.113.10:2222 admin@10.0.0.20

Для постоянной работы удобнее описать оба сервера в ~/.ssh/config:
Host bastion
HostName 203.0.113.10
User user

Host internal
HostName 10.0.0.20
User admin
ProxyJump bastion

После этого подключение к внутреннему серверу выполняется обычной командой:
ssh internal

Через тот же маршрут можно использовать scp:
scp backup.tar.gz internal:/tmp/

Или sftp:
sftp internal

Если до целевого сервера нужно пройти через несколько промежуточных узлов, их можно перечислить через запятую:
ssh -J user@gateway1,user@gateway2 admin@internal

То же самое можно записать в конфигурации:
Host internal
HostName 10.0.0.20
User admin
ProxyJump gateway1,gateway2

Для bastion и внутреннего сервера можно использовать разные SSH-ключи:
Host bastion
HostName 203.0.113.10
User jump
IdentityFile ~/.ssh/bastion_ed25519

Host internal
HostName 10.0.0.20
User admin
IdentityFile ~/.ssh/internal_ed25519
ProxyJump bastion

Приватный ключ от внутреннего сервера при этом не требуется копировать на bastion. Аутентификацию на конечном сервере выполняет локальный SSH-клиент.

Посмотреть итоговую конфигурацию, которую SSH применит для подключения, можно через:
ssh -G internal

Например, отдельно вывести основные параметры:
ssh -G internal | grep -Ei 'hostname|user|proxyjump|identityfile'

Если соединение не устанавливается, запускаем SSH с диагностическим выводом:
ssh -v internal

Для более подробной диагностики:
ssh -vvv internal

Так можно увидеть установление соединения через промежуточный узел, выбор ключей, проверку host key и этапы аутентификации.

ProxyJump можно использовать вместе с обычным port forwarding. Например, PostgreSQL работает на внутреннем сервере и слушает только локальный порт 5432:
ssh -N -J user@203.0.113.10 \
-L 5433:127.0.0.1:5432 \
admin@10.0.0.20

После этого локально подключаемся к базе через порт 5433:
psql -h 127.0.0.1 -p 5433 database

SSH-соединение пройдёт через bastion до внутреннего сервера, а перенаправление на 127.0.0.1:5432 будет выполнено уже со стороны конечного SSH-сервера.

🔥 ProxyJump позволяет подключаться к серверам во внутренних сетях через bastion без ручного создания промежуточных SSH-сессий. Настройку можно вынести в ~/.ssh/config и использовать тот же маршрут для ssh, scp, sftp и SSH-туннелей.

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

Проверяем состояние соединений через conntrack!

Linux firewall работает не только с отдельными пакетами. Подсистема Netfilter connection tracking ведёт таблицу отслеживаемых соединений, в которой хранится состояние TCP, UDP и других потоков. Это полезно при диагностике NAT, firewall и асимметричной маршрутизации.

Установим утилиту для работы с таблицей conntrack:
sudo apt update && sudo apt install conntrack -y

Текущие соединения можно вывести через -L и сразу отфильтровать по протоколу и адресу назначения:
sudo conntrack -L -p tcp --dst 203.0.113.10

(адреса в примерах документационные — при повторении замените их на свои)

Для TCP-запись содержит состояние соединения, а также параметры исходного и обратного направлений. На узле, выполняющем NAT, по различиям между ними можно определить преобразование адресов и портов:
tcp 6 431999 ESTABLISHED
src=10.0.0.20 dst=203.0.113.10 sport=52144 dport=443
src=203.0.113.10 dst=198.51.100.5 sport=443 dport=52144

При диагностике удобнее наблюдать события в реальном времени. conntrack может выводить создание, обновление и удаление записей по мере прохождения трафика:
sudo conntrack -E -p tcp

Фильтр можно ограничить адресом и портом назначения:
sudo conntrack -E -p tcp \
--dst 203.0.113.10 \
--dport 443

Состояние таблицы важно контролировать на загруженных шлюзах:
sysctl net.netfilter.nf_conntrack_count
sysctl net.netfilter.nf_conntrack_max

Если nf_conntrack_count приближается к nf_conntrack_max, таблица близка к заполнению. При переполнении новые соединения могут перестать нормально отслеживаться, а в журнале ядра обычно появляются сообщения conntrack:
journalctl -k -g 'nf_conntrack'

Время хранения записи для установленного TCP-соединения можно проверить отдельно:
sysctl net.netfilter.nf_conntrack_tcp_timeout_established

Удалять записи вручную следует только при понимании последствий. Для удаления конкретного TCP-потока укажем параметры его исходного направления:
sudo conntrack -D -p tcp \
--src 10.0.0.20 \
--dst 203.0.113.10 \
--sport 52144 \
--dport 443

🔥 conntrack позволяет увидеть состояние соединения с точки зрения Netfilter, включая оба направления потока и результат NAT. Это полезный уровень диагностики между tcpdump и анализом правил nftables.

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

Восстанавливаем удалённый файл через /proc, пока процесс держит его открытым!

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

Предположим, работающий сервис пишет в лог, который случайно удалили:
rm /var/log/app.log

Найти открытые файлы с нулевым количеством жёстких ссылок можно через lsof. Опция +L1 выбирает открытые файлы, у которых link count меньше 1:
sudo lsof +L1

Для удалённого лога вывод может выглядеть так:
app 4217 root 5w REG ... /var/log/app.log (deleted)

Здесь 4217 — PID процесса, 5 — номер файлового дескриптора, а w означает, что он открыт на запись.

Соответствующий FD доступен через procfs:
sudo ls -l /proc/4217/fd/5

Символическая ссылка будет указывать на уже удалённый pathname:
/proc/4217/fd/5 -> /var/log/app.log (deleted)

Хотя имени файла в каталоге уже нет, открытый файловый дескриптор всё ещё связан с файловым объектом. Пока последний такой FD не закрыт, содержимое можно скопировать через /proc:
sudo cp /proc/4217/fd/5 /tmp/app.log.recovered

Проверяем восстановленную копию:
ls -lh /tmp/app.log.recovered

При необходимости сравниваем размеры:
sudo stat /proc/4217/fd/5
stat /tmp/app.log.recovered

Это не классический undelete — cp создаёт новый файл с новым inode и копирует доступное содержимое. Если процесс продолжает запись, копия не гарантирует консистентный snapshot. Доступ через /proc//fd/ также может быть ограничен правами и настройками системы. Восстановить данные нужно до закрытия последнего FD: после этого при нулевом link count ядро сможет освободить inode и блоки файла.

🔥 Поэтому после случайного rm активного файла не спешите перезапускать процесс — сначала проверьте: sudo lsof +L1. Пока FD открыт, данные ещё могут быть доступны через /proc//fd/.

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