Внешний вид
Кейс №3 (тренировка): «Сайты не открываются» — неверный вышестоящий DNS на CHR
Дата: 2026-09-29 Сценарий: заявка №2 игры «сломал — почини». Поломка: на CHR вышестоящий DNS сменён на «чёрную дыру» (192.0.2.1). Статус: ✅ локализовано и исправлено обучающимся
Симптом
«Ни один сайт не открывается, на всех устройствах; роутер перезагружали — не помогло».
Диагностика
| Шаг | Результат | Вывод |
|---|---|---|
ping 192.168.100.1 (alpine1) | ок | LAN и шлюз живы |
ping 1.1.1.1 | ок | интернет есть: маршрутизация и NAT работают |
ping ya.ru | bad address | имена не резолвятся → проблема в DNS |
Локализация однозначна: обрыв ровно на этаже DNS, при живом «транспорте». На CHR (ssh chr):
/ip dns print→servers: 1.1.1.1,allow-remote-requests: yes.
Интересное место кейса
Попытка исправить сервером 1.1.1.1 не сработала — и это не ошибка диагностики, а ограничение среды: UDP/53 от CHR внешним адресам умирает в цепочке libvirt-NAT (доказано в кейсе №1, UFW) — при живом ICMP/TCP. В реальном выезде аналог: «метод верный, фикк не оживает → упираемся в проблему выше по стеку (у провайдера)».
Правильное значение в лаборатории — DNS хоста (прямой L2, без NAT-цепочек):
routeros
/ip dns set servers=192.168.122.1Проверка: ping ya.ru с CHR и с alpine1 — ок.
Уроки
- Различать «нет интернета» и «нет DNS»: пинг по IP + пинг по имени — обязательная пара проверок. Разница между ними — всегда DNS.
- DNS-клиент → DNS роутера (allow-remote-requests) → вышестоящие серверы: ломаться может на каждом шаге, смотреть надо оба.
- Диагноз может быть верным, а стандартный фикс — неприменимым из-за особенностей среды; признак — нужно подняться на уровень выше (провайдер/аплинк).
Замечания
- Первичный вывод «хня с серверами» — сленг, но по сути точный: проблема локализована в конфигурации DNS-серверов CHR. Для отчётов учимся формулировать нормативно: «некорректный вышестоящий DNS-сервер на маршрутизаторе абонента».