Отказы из прошлых уроков трека складываются в одну таблицу. По виду ошибки понятно, где искать и на какой машине.
| Что видно у клиента | Где искать |
|---|---|
Could not resolve host |
имя: резолвер клиента |
ошибка сразу, и ip route get на клиенте — тоже ошибка |
маршрут клиента |
| ожидание и тайм-аут | фильтр или обратный путь: пакет или ответ пропадает |
ошибка сразу, nc -zv — Connection refused |
сервер: на этом адресе и порту никто не слушает |
| ответ пришёл, но не тот | сайт: не та страница, не тот сервер |
curl печатает Couldn't connect to server через 0 мс в двух случаях: пакет не ушёл с клиента или сервер отказал. Различают их ip route get на клиенте и nc -zv.
Причин бывает несколько сразу. Исправил одну — запрос дойдёт до следующей, и вид отказа сменится. Это продвижение: после каждой правки прочитай новый отказ и ищи по таблице дальше.
Меняй по одной вещи за раз. Если поменять несколько сразу и заработает, не узнаешь, что помогло; если не заработает — что сломалось.
curl с lab-node1 к 192.0.2.12:8080 сразу печатает Couldn't connect to server, а sudo ip -n lab-node1 route get 192.0.2.12 — RTNETLINK answers: Invalid argument. Где искать причину?
-
Запрос шёл по адресу, имя не участвовало. Ошибка имени выглядит как
Could not resolve host. -
Фильтр с
dropдаёт ожидание до тайм-аута, а ошибка пришла через 0 мс. -
При закрытом порте сервера
ip route getна клиенте напечатал бы путь. Ошибка здесь — у клиента, ещё до отправки пакета.
ip route get спрашивает ядро клиента, куда отправить пакет, и ошибка значит, что пути нет или он запрещён — например, записью blackhole. До сервера пакет не дошёл, поэтому смотрят sudo ip -n lab-node1 route.
Главное в шаге
- Тайм-аут, отказ и ошибка имени указывают на разные этапы и разные машины.
- Исправленная причина меняет вид отказа: значит, запрос продвинулся дальше.