Сервис работает, а снаружи не отвечает. В чем причина?

Комментов под утренним постом набралось не мало, давайте разберем.

Но сначала хочу подсветить такой момент: собеседующему важно именно как вы рассуждаете и накидываете вариантов, пусть даже неправильных.

В целом есть три способа строить ответ, которые кстати применимы и к другим абстрактным вопросам.

1. Самый простой вариант — просто перечислять гипотезы. Фаервол, порты, DNS, балансер, сертификат, NAT и прочее.
Плюс: быстро видно кругозор.
Минус: интервьюер не понимает, умеете ли вы это сужать.

2. Идти по слоям. Взять путь пакета от процесса до клиента и двигаться по нему.
Плюс: самый безопасный формат, в котором сразу видно структуру.
Минус: если на каком-то слое пусто, то это тоже сразу видно.

3. Задавать встречные вопросы. «А что значит не отвечает?», «доступ на сервер есть?», «это железка, докер или кубер?».
Плюс: ближе всего к реальной работе. Вы превращаете ответ в реальное расследование, а собеседующий сам подкидывает вводные и сужает область.
Минус: вас могут намеренно завести в ситуацию, где вы поплывёте.

Лучше всего отвечать гибридно. Два-три вопроса, которые сразу сильно сужают область поиска, потом озвучить метод, потом идти по слоям, называя конкретные команды.

Конкретно тут сузить проще всего так:
— Как именно «не отвечает»? Таймаут / connection refused / connection reset / отвечает, но 502-504. Дальше по ответу: refused и reset означают, что пакет дошёл до хоста и кто-то ответил. Таймаут — где-то DROP, NAT или маршрут.
— Доступ на сервер есть или чиним вслепую?
— Где крутится сервис: bare metal, VM, docker, k8s? Есть ли перед ним прокси, балансер, облачный фаервол?
— Когда сломалось и что перед этим делали?

Минимальный хороший ответ:
ss -tulpn — слушает ли сервис вообще и на каком адресе. Классика 127.0.0.1 вместо 0.0.0.0
curl -v localhost:PORT — жив ли он локально. Если нет, journalctl -u service -e и дальше это уже не про сеть
Фаервол на хосте: iptables -nvL / nft list ruleset / ufw status. И отдельно — облачные security groups и периметровый фаервол.
tcpdump -ni any port PORT — пакеты вообще долетают до сервера?
С клиента: nc -vz IP PORT строго по IP. Работает по IP, если хотим проверить домен идём в dig
ip r, traceroute / mtr — маршруты и где обрывается путь

Этого в целом хватит, остальное даст глубину и может вас выделить среди других.

Полный чеклист:
— Сервис: процесс жив, bind-адрес, слушает ли IPv6 и IPv4, конфиг и unit-файл, логи, dmesg на предмет OOM-killer.
— Контейнер: проброс портов (docker port), тип сети. В k8s: селектор сервиса, kubectl get endpoints (пустой endpoints — очень частая причина), targetPort, ingress, NetworkPolicy, readiness probe.
— Хост: ip a — интерфейс поднят, адрес и маска верные. ip r — дефолтный шлюз и маршруты. SELinux/AppArmor. Переполненная таблица conntrack. rp_filter и асимметричный роутинг.
— Фаерволы: локальный, облачный, периметровый NGFW/WAF. Отдельно: правила могли не сохраниться и слететь после ребута.
— NAT: DNAT настроен и указывает куда надо, hairpin, проброшен TCP, но забыт UDP.
— Путь: traceroute/mtr, провайдер, блокировки, проверка из другой геолокации или через VPN.
— Балансер и прокси: health check мог выкинуть живой бэкенд, протух сертификат, не тот server_name или SNI и nginx отдаёт default server.
— DNS: A-запись, TTL и кэш, split-horizon.
— Клиент: его собственный фаервол, корпоративный прокси.

Если хотите совсем упороться:
— MTU и PMTU blackhole. Когда пинг проходит, TCP-хендшейк проходит, а TLS или крупные ответы виснут намертво.
— Переполненный conntrack. conntrack -S, дропы в dmesg.
— Рассинхрон IPv4/IPv6.

И не забывайте называть конкретные команды для проверки.

Те, кто не попал на скрины — не расстраивайтесь, скорее всего просто кто-то до вас ответил почти так же.