К этому месту курса вы знаете, как устроены Ethernet, адресация, VLAN, STP, маршрутизация, NAT и ACL. Этого достаточно, чтобы настроить сеть, и недостаточно, чтобы чинить чужую.

Разница в том, что при аварии вопрос стоит иначе: не «как это работает», а «где именно перестало». Знание протоколов даёт список возможных причин — обычно длинный. Метод сокращает этот список быстрее, чем перебор.

Плохая диагностика выглядит как череда правдоподобных догадок: переподключить, перезагрузить, поменять кабель, «а давайте отключим фаервол». Иногда помогает. Понимания не оставляет, воспроизвести успех нельзя.

Жалоба почти никогда не описывает проблему. «Интернет не работает» может означать что угодно — от выключенного Wi-Fi до упавшего почтового сервера.

Три вопроса, которые сужают область быстрее всего:
1. У кого именно? У одного человека, у отдела, у всех? Один — смотрим на его устройство и порт. Отдел — на его VLAN и коммутатор. Все — на общую точку: шлюз, канал, DNS.
2. Что именно? Всё вообще или один сервис? Не открывается сайт, но работает мессенджер — это не «сеть упала».
3. Когда началось и что менялось? Самый результативный вопрос за всю диагностику.

Полезно сразу спросить: «а раньше это работало?» Ответ «нет, мы только настроили» переводит задачу из поиска поломки в проверку конфигурации — а это совсем другая работа.

Модель OSI полезна не как схема для запоминания, а как порядок проверки. Работает в обе стороны, и выбор направления зависит от симптома.

Снизу вверх — когда не работает совсем ничего. Есть линк? Есть адрес? Пингуется шлюз? Пингуется адрес за пределами сети? Разрешается имя? Открывается сервис? Первый шаг, на котором ответ «нет», и есть граница проблемы.

Сверху вниз — когда не работает один сервис, а остальное живо. Начинать снизу бессмысленно: физика и адресация заведомо в порядке, раз работает всё остальное.

Ключевая мысль: каждая проверка должна отсекать половину вариантов, а не подтверждать одну догадку. Проверка, которая при любом исходе не сокращает список, — потраченное время.

Тот же приём применяется не только к слоям, но и к пути. Трафик идёт от хоста через коммутатор доступа, ядро, маршрутизатор, межсетевой экран, канал провайдера — и проверять их по очереди долго.

Быстрее ткнуть в середину: пингуется ли шлюз? Если да — вся левая половина пути исправна, и смотреть надо правее. Если нет — правая половина не имеет значения. Одна проверка убирает половину сети.

На этом же приёме строятся traceroute и mtr: они показывают, до какого узла путь жив. С одной оговоркой — промежуточные узлы часто не отвечают на трассировку намеренно, и звёздочки в середине сами по себе не означают поломку. Значение имеет то, докуда трафик доходит, а не то, кто молчит.

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

Поэтому вопрос «что менялось за последние сутки» экономит часы перебора. Ответ «ничего» стоит принимать с осторожностью: люди искренне не считают изменением то, что делали не они или считают мелочью.

Отсюда практический вывод, который стоит вводить в привычку до первой аварии: журнал изменений и резервные копии конфигураций. Диагностика с ответом «вот дифф последнего изменения» и без него — это две разные задачи по трудоёмкости.

tcpdump — сильный инструмент и плохое начало. Он отвечает на вопрос «что реально в проводе», но чтобы вопрос был осмысленным, надо уже понимать, что вы ожидаете там увидеть.

Дамп оправдан, когда:
• настройки выглядят верными, а поведение не совпадает с ожиданием;
• надо понять направление потери — запросы уходят, но ответов нет (проблема на той стороне) или не уходят вовсе (проблема у нас);
• подозрение на то, что кто-то отвечает вместо ожидаемого хоста.

Именно на этом построена лаба eth-frame-anatomy: там видно, как ARP-запрос уходит широковещательно, а ответа нет — и это сразу отвечает, на чьей стороне искать.

Менять несколько вещей сразу. Заработало — неизвестно от чего. Не заработало — неизвестно, что откатывать.

Верить, что «ничего не меняли». Смотрите на время начала проблемы и сопоставляйте с журналами.

Останавливаться на симптоме. Перезагрузка помогла — это не диагноз. Через неделю повторится.

Считать, что ping — это проверка сети. ICMP могут фильтровать отдельно: хост живой, сервис работает, а ping запрещён.

Игнорировать «мелочь». Работает, но медленно; работает, но через раз — это тоже неисправность, обычно на первом уровне, и она никуда не денется.

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

Полезно проходить их не перебором, а методом. Например:
• «адреса верные, а связи нет» — проверка на канальном уровне выше сетевого: смотрим ARP-таблицу, а не маршруты;
• «хост пропал, а на нём всё настроено» — сначала физика: NO-CARRIER на хосте против состояния порта на коммутаторе;
• «отделы перемешались» — сравниваем фактическую раскладку портов по VLAN с задуманной, а не ищем поломку;
• «филиал отвалился целиком, а внутри всё работает» — граница проблемы прямо в симптоме: смотреть надо транк между площадками.

Каждый раз работает одно и то же: сначала сузить область, потом искать причину внутри неё.