Когда приложение не может подключиться к внешнему сервису, первое, что обычно проверяют — firewall, маршруты или настройки приложения.
Но на практике проблема часто находится глубже. Бывает, что приложение работает нормально, конфигурация выглядит правильно, маршрут есть, firewall не показывает явных проблем, а соединения всё равно нет.
В такой ситуации важно посмотреть, что реально происходит с пакетами. Например:
curl https://api.example.com
Получаем:
Connection timed out
Проверяем, что firewall не является причиной:
systemctl status firewalld
Всё выглядит нормально, но соединения всё равно нет. Здесь помогает
tcpdump. Это один из главных инструментов Linux для сетевой диагностики. Он показывает реальные пакеты: что ушло с сервера, что вернулось обратно и на каком этапе возникла проблема.В такие моменты
tcpdump часто экономит часы поиска. Смотрим TCP-трафик к HTTPS-порту:sudo tcpdump -nn -i any port 443
Параметры:
-nn — не выполнять DNS-resolve и не заменять номера портов именами; -i — выбрать интерфейс; any — слушать все интерфейсы.Например:
IP 10.0.0.15.42310 > 142.250.184.14.443: Flags [S]
Видим SYN-пакеты, но не видим SYN-ACK в ответ. Это означает, что клиент пытается установить TCP-соединение, но ответ обратно не приходит.
Дальше стоит искать проблему в: фильтрации трафика; security group; ACL; маршрутизации; удалённом сервисе. Если видим:
IP 142.250.184.14.443 > 10.0.0.15.42310: Flags [S.]
значит TCP handshake проходит.
Сеть, скорее всего, работает, и проблему уже стоит искать выше сетевого уровня: TLS ;сертификаты; настройки приложения; протокол взаимодействия. Для конкретного хоста лучше ограничивать фильтр:
sudo tcpdump -nn -i any host 10.0.0.5
Например, проверяем соединение приложения с PostgreSQL:
sudo tcpdump -nn -i eth0 host 10.0.0.5 and port 5432
На production это намного удобнее, когда через сервер проходят тысячи соединений. Иногда нужно посмотреть содержимое HTTP-запросов:
sudo tcpdump -A -s0 -i eth0 host 10.0.0.5 and port 80
Можно увидеть:
GET /health HTTP/1.1
Host: backend.local
Для обычного HTTP это работает. Для HTTPS посмотреть содержимое запросов не получится — данные будут зашифрованы TLS. Можно увидеть сам факт соединения и TLS handshake, но не содержимое HTTP-запроса. Если нужно сохранить трафик:
sudo tcpdump -nn -i any port 443 -w capture.pcap
Открыть файл можно в Wireshark или повторно через:
tcpdump -r capture.pcap
На нагруженных серверах удобно ограничивать количество пакетов:
sudo tcpdump -nn -i any port 443 -c 100
Ещё полезный фильтр — только новые TCP-соединения:
sudo tcpdump -nn -i any 'tcp[tcpflags] & tcp-syn != 0 and tcp[tcpflags] & tcp-ack == 0'
Важно помнить:
tcpdump показывает только сетевой трафик, но не знает, какой процесс его создал. Для связи соединения с процессом используйте:ss -tnp
🔥 Главная сила
tcpdump в том, что он помогает быстро определить, где именно проблема: пакет не вышел с сервера; пакет ушёл, но ответ не пришёл; TCP установился, а ошибка уже внутри приложения.🚪 Linux Ready | #практика