Лабораторная: диагностика TCP/IP¶

В паре со статьёй: Сеть TCP/IP и набор команд ip

Окружение: две одноразовые VM в одной виртуальной сети (например, host-only сеть VirtualBox/libvirt), чтобы иметь контролируемое, изолированное соединение между ними.

Начальные условия¶

1. Две VM, host-a и host-b, в одной подсети, подтверждена доступность друг от друга через ping до внесения какой-либо неисправности.
2. Доступ root/sudo на обеих.

Инструкции¶

Часть 1 — Сломайте намеренно¶

На host-b внесите одну из следующих неисправностей:

• Неверный маршрут: sudo ip route del default (полностью удаляет маршрут по умолчанию — host-b всё ещё может достучаться до host-a напрямую в той же подсети, но ничего за её пределами).
• Неверный адрес: смените собственный IP host-b на адрес из другой подсети, отличной от подсети host-a, без соответствующего обновления маршрута: sudo ip addr add 192.0.2.99/24 dev eth0 (пока оставьте оригинальный адрес на месте, не удаляйте его).

Часть 2 — Диагностируйте с host-a¶

Используя только послойный подход из статьи (ip link, ip addr, ip route get, ping), определите с host-a, доступен ли host-b вообще, и если нет — на каком уровне происходит сбой.

Ожидаемые результаты¶

• Неисправность отсутствующего маршрута по умолчанию: пинг с host-a напрямую на host-b в общей подсети всё ещё успешен (маршрут по умолчанию не нужен для трафика в пределах одной подсети) — неисправность проявится только если host-b понадобится достучаться до чего-то за пределами локальной подсети, что вообще не покажет тест пингом в той же подсети. Это сама по себе и есть урок: убедитесь, что вы тестируете реальное условие сбоя, а не просто «хост на связи».
• Неисправность адреса в другой подсети: зависит от того, на какой адрес целится host-a. Если host-a целится в оригинальный (всё ещё присутствующий) адрес, всё работает — снова демонстрируя, что добавление неверного адреса не удаляет правильный. Если целиться в новый адрес 192.0.2.99, и у host-a нет маршрута в эту подсеть, пинг провалится с «Network is unreachable», сообщённым локально на host-a ещё до отправки какого-либо пакета — отдельный тип сбоя, отличный от таймаута (таймаут означает, что пакеты были отправлены, но ответа не пришло; «Network is unreachable» означает, что локальное ядро вообще не пыталось отправить, поскольку у него нет маршрута).

Чек-лист диагностики¶

• [ ] Различили ли вы «Network is unreachable» (нет локального маршрута) и тихий таймаут (пакеты отправлены, ответа нет)? Это указывает на разные проблемы — одна локальная, другая может быть где угодно на маршруте или на самом адресате.
• [ ] Использовали ли вы ip route get <target-ip> на host-a перед пингом, чтобы спрогнозировать, считает ли ядро, что у него вообще есть путь?
• [ ] Для неисправности отсутствующего маршрута по умолчанию: правильно ли вы определили, что связность в пределах одной подсети не затронута, и объяснили почему (маршрут по умолчанию не нужен в пределах одной подсети)?

Критерии успеха¶

Вы можете, находясь только на host-a (без входа на host-b для проверки его конфигурации напрямую), определить, является ли описанный сбой связности проблемой маршрутизации на удалённой стороне, несовпадением адресации, или чем-то иным — используя только ip route get, ping и рассуждение о сообщениях об ошибках, которые каждый из них выдаёт.

Очистка / откат¶

# На host-b восстановите маршрут по умолчанию (подставьте реальный IP шлюза вашей лабораторной сети):
sudo ip route add default via <gateway-ip> dev eth0

# Удалите дополнительный адрес, если добавляли:
sudo ip addr del 192.0.2.99/24 dev eth0

Убедитесь, что ping с host-b до чего-то за пределами локальной подсети (например, шлюза лаборатории, или интернета, если лабораторная сеть имеет доступ) снова проходит, прежде чем считать окружение восстановленным.