Какими инструментами проверить сетевую связанность между клиентом и сервером Linux и как определить маршрут запроса

Что проверяют

Есть ли у вас порядок диагностики, а не набор команд наугад. Интервьюер хочет услышать, как вы отделяете проблему DNS от маршрутизации, фаервола и самого приложения, и следом обычно спрашивает, чем «connection refused» отличается от таймаута.

Как отвечать

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

• имя: dig +short api.example.com или getent hosts api.example.com. Второй учитывает /etc/hosts и nsswitch.conf, то есть видит имя так же, как приложение;
• маршрут на своей машине: ip route get 10.20.0.5 показывает, через какой интерфейс и шлюз ядро отправит пакет, ip addr и ip route дают общую картину;
• путь по сети: traceroute (на Linux по умолчанию UDP, -I для ICMP, -T для TCP, для обоих обычно нужен root), tracepath без root, mtr -rwc 100 host совмещает трассировку и статистику потерь по каждому хопу;
• доступность: ping проверяет только ICMP, который часто закрыт. Порт проверяют nc -zv host 443 или curl -v, TLS через openssl s_client -connect host:443;
• сервер: ss -tlnp показывает, слушает ли процесс порт и на каком адресе, правила фаервола видны в nft list ruleset или iptables -L -n -v;
• пакеты: tcpdump -i any host 10.20.0.5 and port 443 на обеих сторонах показывает, доходит ли SYN и уходит ли ответ.

Refused означает, что хост доступен, но порт никто не слушает или фаервол отклонил соединение правилом REJECT. Таймаут чаще говорит о том, что пакет где-то молча отброшен: security group, фаервол или нет обратного маршрута.

Где спотыкаются

Делают вывод по ping. Отсутствие ответа на ICMP ещё не значит, что сервис недоступен, а ответ на ping ничего не говорит о порте приложения.

Паникуют из-за звёздочек в traceroute. Многие маршрутизаторы просто не отвечают на истёкший TTL, важно, доходит ли трассировка до цели.

Не проверяют адрес привязки. В ss сервис висит на 127.0.0.1:8080, то есть слушает только локальный интерфейс, и снаружи к нему не подключиться.