Отладка вместо угадывания

Отладка сети не в том, чтобы знать больше команд. Она в том, чтобы заменить догадки последовательностью вопросов, ответы на которые нельзя оспорить. В методе три правила. Начинайте с проверки, самой дешёвой по времени и отсекающей больше всего. Меняйте ровно одну вещь за раз. И после каждой проверки спрашивайте, что её результат доказывает, а что нет: проверка, которая могла пройти по двум разным причинам, не сказала вам ничего.

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

Лесенка вопросов снизу вверх: есть ли у машины вообще адрес и маршрут по умолчанию? Превращается ли имя в адрес? Отвечает ли адрес на уровне IP? Открыт ли порт и отвечает ли на нём служба? Возвращает ли приложение правильный ответ? На каждый вопрос отвечает свой инструмент, и каждый ответ сужает круг подозреваемых, пока не останется один слой. Смысл лесенки в том, что она заканчивается: хорошая отладка уменьшает множество возможных причин, а не увеличивает его.

Каждый инструмент доказывает что-то узкое, и использовать его для большего — верный способ прийти к неверному выводу. ping доказывает, что хост отвечает на ICMP и что путь существует в обе стороны; он не доказывает, что веб-сервер запущен. dig доказывает, что ответил резолвер и насколько ответ закэширован; он не доказывает, что адрес достижим. curl доказывает, что весь стек делает для одного конкретного запроса; он не доказывает, что другие клиенты получат тот же ответ. ss доказывает, что именно слушает на этой машине и на каком адресе; он не доказывает, что межсетевой экран кого-то впускает.

$ dig api.example.org +short
198.51.100.20

$ dig api.example.org +short
198.51.100.20

$ dig api.example.org @1.1.1.1 +short
203.0.113.7

$ dig api.example.org @8.8.8.8 +short
203.0.113.7Два резолвера, два разных ответа: это кэш и устаревшая запись, а не сломанная сеть.

$ curl -v https://api.example.org/health
*   Trying 198.51.100.20:443...
* connect to 198.51.100.20 port 443 failed: Connection timed out
* Failed to connect to api.example.org port 443: Connection timed out

$ curl -sv https://api.example.org/health -o /dev/null
*   Trying 93.184.216.34:443...
* Connected to api.example.org (93.184.216.34) port 443
* Server certificate: CN=*.example.org
< HTTP/2 200
< content-type: application/jsonОдна и та же команда с таймаутом на порт и с адресом, который действительно работает.

На ss стоит посмотреть отдельно: он разделяет два отказа, которые снаружи выглядят одинаково — никто не слушает порт, или кто-то слушает, но только на петлевом адресе. Сервер, привязанный к 127.0.0.1, принимает соединения с той же машины и отказывает всем снаружи, что бы ни говорил межсетевой экран. Это одно различие объясняет большую долю случаев, когда служба работает локально и недоступна отовсюду ещё.

$ ss -tlnp
State   Local Address:Port   Process
LISTEN  127.0.0.1:8080       users:(("node",pid=4127,fd=21))
LISTEN  0.0.0.0:22           users:(("sshd",pid=880,fd=3))

$ curl -s -o /dev/null -w "%{http_code}\n" http://127.0.0.1:8080/
200Одна служба доступна из сети, вторая только с этой машины.