Кейс №1: CHR не получает IP на WAN (DHCP)

Дата: 2026-09-28 Среда: NetLab (KVM/libvirt, MikroTik CHR 7.23.7, сеть default 192.168.122.0/24 NAT) Статус: ✅ решён (обход + восстановление L2)

---

Симптом

CHR запущен, RouterOS загружена, но IP на WAN-интерфейсе (ether1) отсутствует: /ip address print пусто, DHCP-клиент в статусе searching.

Проверки (снизу вверх)

#	Проверка	Результат	Вывод
1	CHR видит оба интерфейса, MAC есть, link есть	✅	клиент жив
2	DHCP-клиент на ether1 активен, status=searching	✅ без адреса	клиент шлёт запросы
3	/log print where topics~"dhcp"	пусто	ошибок DHCP-клиента нет
4	ip link show master virbr0	vnet0 в мосте, UP	L2-доставка до сегмента сервера есть
5	ip -4 addr show virbr0	192.168.122.1/24	серверный адрес на месте
6	ss -ulpn | grep 67	dnsmasq слушает 0.0.0.0%virbr0:67	DHCP-сервер поднят
7	nftables/iptables	отключены	фаервол не мешает
8	tcpdump -i virbr0 -n -v port 67 or 68	только DHCP-Message: Discover от CHR (каждые ~3 с), Offer отсутствует	запрос доходит до сегмента сервера, сервер молчит
9	journalctl -b | grep dnsmasq	пул 192.168.122.2–254, bind на virbr0, ошибок нет	конфиг сервера корректен
10	Перезапуск сети (net-destroy/net-start)	не помогло	причина не «зависший процесс»

Причина

Две связанные проблемы инфраструктуры лаборатории:

1. dnsmasq сети default не отвечает на исправные DHCP Discover при внешне здоровом конфиге (корень не установлен — вероятен конфликт на уровне хоста; требует отдельного расследования).
2. При перезапуске сети default tap-интерфейс работающей VM отцепился от моста и не прицепился обратно (virbr0 NO-CARRIER, портов нет) — после этого обрыв стал полным: потерян L2.

Исправление (обход, клиентская сторона)

1. DHCP-клиент на CHR отключён, задан статический адрес из подсети WAN:

   /ip dhcp-client disable [find]
   /ip address add address=192.168.122.10/24 interface=ether1
   /ip route add dst-address=0.0.0.0/0 gateway=192.168.122.1
   /ip dns set servers=1.1.1.1

2. Восстановлен L2: virsh destroy chr + virsh start chr (tap заново прицеплен к мосту).

Результат

• ping 192.168.122.10 с хоста: 0% loss.
• WebFig: HTTP 200 (http://192.168.122.10).
• Конфигурация CHR сохранилась на диске и пережила перезагрузку.

Уроки (выносить на собеседование)

• «Searching» = клиент шлёт, сервер молчит. Половина пути — проверить трафик tcpdump'ом: запрос ушёл? ответ пришёл? Это сразу делит проблему на «сторона клиента / транспорт / сторона сервера».
• Discover не содержит IP — «неправильный пул» не может быть причиной молчания на Discover; пул важен только на этапе Request (опция 50).
• DHCP-сервер одной сети недоступен из другой — разные broadcast-домены (клиентский D-Link 192.168.1.0/24 и лабораторный virbr0 192.168.122.0/24 никак не связаны).
• «В логах пусто» ≠ «сервер не видит»: у libvirt'ового dnsmasq подробное логирование DHCP выключено — логи смотреть вместе с захватом трафика.
• После перезапуска виртуальной сети проверять привязку tap к мосту (ip link show master <bridge>) — работающие VM связь сами не восстанавливают.
• Обход симптома (статический адрес) — легитимная тактика, чтобы быстро восстановить сервис клиенту, пока причина расследуется.

Корень проблемы (добавлено после углублённого расследования)

Виновник всех «мистических» сбоев лабы — фаервол UFW на хосте. Правила iptables (policy DROP на INPUT/FORWARD, цепочки ufw-*) остались активными в ядре, хотя сервис при этом числился неактивным. UFW дропал весь UDP-трафик от VM к хосту: DHCP (UDP/67) — отсюда кейс №1, DNS (UDP/53) — отсюда «bad address» на Alpine. ICMP (ping) UFW пропускал — поэтому картина была сюрреалистичной: «пинги есть, всё остальное мертво».

Лечение:

sudo ufw allow in on virbr0
sudo ufw allow in on virbr-lab
sudo ufw route allow in on virbr0 out on virbr-lab
sudo ufw route allow in on virbr-lab out on virbr0

После этого DNS/DHCP из VM заработали мгновенно.

Урок: «сервис фаервола неактивен» ≠ «правил нет» — правила живут в ядре независимо. Проверка: iptables -L -n -v (счётчики дропов на ufw-after-input). Типовая диагностика «ICMP ходит, UDP нет» = фильтр по протоколу, не L2/L3.

Открытые вопросы

Почему dnsmasq сети default не отвечает на DHCP — закрыто: отвечал-то он нормально, ответы (и запросы) дропались UFW на входе в хост.