B7. Налагодження зламаної мережі

просунутийспирається на модуль 5, модуль 6, модуль 7, модуль 13, модуль 16

Мета

До цього ви будували мережі: все, що ви налаштували, працювало за задумом, а якщо ні, то помилка була вашою й свіжою. На роботі буває навпаки: мережу збудував хтось інший, раніше, і вона «колись працювала». Скарга звучить як «сайт гальмує» чи «щось з інтернетом», а причина лежить на іншому рівні, ніж здається. Ця робота тренує саме таке налагодження.

Після цієї роботи ви зможете:

йти від скарги користувача до причини послідовно, рівень за рівнем, а не вгадуванням;
відрізнити несправність маршрутизації від несправності ARP, файрвола, DNS і MTU за тим, що показують ping, ip neigh, ip route get, nft list ruleset, dig, tracepath;
знайти причину, яку видно лише за побічними ознаками (зависає лише велика відповідь, а маленька проходить);
виправляти по одній несправності й перевіряти результат після кожної;
описати кожну проблему так, щоб інший інженер її зрозумів і повторив виправлення: симптом, як знайдено, причина, виправлення.

Завдання

Результат: мережа, в якій усі користувачі отримують усе, що мусило працювати, і звіт report.md про шість несправностей.

Як отримати зламану мережу. Скрипт break.sh із каталогу роботи будує топологію й вносить несправності:

sudo ./break.sh            # будує й ламає
sudo ./break.sh --teardown # прибирає все

Якщо простори імен h1, h2, r1, r2, dns, web у вас уже є (наприклад, з B2), задайте префікс для break.sh і для check.sh однаково: sudo B7_PREFIX=b7- ./break.sh, sudo B7_PREFIX=b7- ./check.sh. Усі простори тоді матимуть цей префікс (b7-h1 тощо), решта роботи не змінюється.

Не читайте break.sh. Це те саме, що дивитися в конспект відповідей: в реальному житті скрипта, який зламав мережу, у вас не буде. Якщо потрібна підказка, читайте «Часті помилки» нижче.

Топологія. Назви просторів імен і адреси фіксовані.

h1 10.7.1.10 ─┐
              ├─ LAN1 10.7.1.0/24 ─ r1 ──(10.7.0.0/30)── r2 ─ LAN серверів 10.7.2.0/24 ─┬─ dns 10.7.2.53
h2 10.7.1.11 ─┘                                                                        └─ web 10.7.2.80

Шлюз LAN1 — 10.7.1.1 (r1), шлюз серверів — 10.7.2.1 (r2). На web працюють сайт (порт 80, файл big.bin розміром 300 кБ) і API (порт 8080). На dns працює dnsmasq, що відповідає за домен lab: web.lab має вказувати на 10.7.2.80, dns.lab на 10.7.2.53. Клієнти h1 і h2 користуються цим сервером: їхній resolv.conf лежить у /etc/netns/<простір>/resolv.conf.

Політика мережі, яку чіпати не можна. Між LAN1 і серверами заборонено telnet (TCP, порт 23). Правило стоїть на r1. Ваше завдання полагодити мережу, а не розібрати захист: чекер перевіряє, що політика лишилась.

Що скаржаться користувачі. Симптоми з їхнього погляду, причини шукаєте ви:

№	Скарга
1	«Сторінка сайту відкривається, але великі файли з нього не завантажуються: зависають і закінчуються таймаутом.»
2	«З LAN1 не вдається зв’язатися з сервером web, а з сервером dns усе гаразд.»
3	«На ноутбуку одного з нас нічого не працює за межами нашої підмережі, а в сусіда працює.»
4	«Сайт відкривається, а API на порту 8080 не відповідає.»
5	«За адресою `http://web.lab/` сайт не відкривається, хоча за IP-адресою сервера відкривається.»
6	«На одному з ноутбуків імена не резолвляться, на іншому резолвляться.»

Скарги можуть накладатися одна на одну: поки не виправлено одну, інша може бути не видна. Це навмисно.

Що зробити.

Запустити break.sh і переконатися, що скарги відтворюються.
Знайти причину кожної несправності й виправити її мінімальною зміною.
Після кожного виправлення повторювати відтворення й запускати check.sh.
Написати report.md.

Формат звіту. Шість розділів, по одному на несправність. Заголовок другого рівня з короткою назвою, далі чотири поля:

## Несправність 1. Короткий заголовок

**Симптом.** Що бачив користувач і що показала ваша перша перевірка.

**Як знайшов.** Які команди, що в їхньому виводі вказало на причину.

**Причина.** Чому саме так сталося, механізмом, а не словами «не працювало».

**Виправлення.** Що зроблено, яку команду виконано; яке ще виправлення було б можливе.

Звіт має бути вашою роботою: причину пояснюйте власними словами й цитуйте реальний вивід своїх команд.

Чого робити не треба. Не перебудовуйте мережу з нуля, не вимикайте файрвол цілком, не міняйте адреси чи топологію, не пишіть у /etc/hosts замість лагодження DNS, не перезапускайте break.sh заради «чистого» стану перед перевіркою (він поверне всі несправності).

Готово, коли sudo ./check.sh проходить усі перевірки, а звіт містить шість повних розділів.

Перед початком

Прочитайте в модулі 5 розділи про ARP і таблицю сусідів, у модулі 6 розділ «Фрагментація і Path MTU Discovery», у модулі 7 про вибір маршруту за довшим префіксом, у модулі 13 про резолвер і запис A, у модулі 16 про ланцюжки nftables і хуки.
Потрібні права root і пакети iproute2, nftables, dnsmasq, nginx, bind9-dnsutils (dig), curl, tcpdump, python3. Їх ставить setup/provision.sh; вручну: sudo apt-get install nftables dnsmasq nginx bind9-dnsutils curl tcpdump python3.
Перед break.sh варто повторити, як зайти в простір імен: sudo ip netns exec h1 bash дає оболонку, де команди бачать лише мережу h1. Усі команди нижче виконуються так чи через ip netns exec <простір> команда.

Етапи

Спосіб, а не перелік команд, і є змістом роботи. Поки ви не виправили одну несправність і не переконалися в результаті, до наступної не переходьте: накладені проблеми тоді плутають.

Зафіксуйте, що працює й що ні.

Для кожного клієнта (h1, h2) зробіть однаковий набір перевірок і запишіть результат у таблицю: ping шлюзу, ping dns і web за IP, dig web.lab, curl сторінки, curl великого файлу, curl порту 8080. З цієї таблиці вже видно, скільки різних проблем у вас є й на яких клієнтах.
Йдіть знизу вгору.

Від канального рівня до прикладного: спершу чи бачить хост шлюз (ping, ip neigh), потім чи є маршрут (ip route get <адреса>), далі чи дістається пакет до сервера (ping, tracepath -n, tcpdump на проміжному вузлі), потім чи відповідає служба (ss -ltn на сервері, curl), і лише тоді імена.

Питайте себе: «де саме пакет зникає?». tcpdump на кількох вузлах показує це точніше за здогади: якщо SYN є на r1, а на r2 його немає, проблема між ними.
Порівнюйте робоче з неробочим.

Коли h1 працює, а h2 ні (чи навпаки), різниця між ними й є причина: ip neigh, ip route, cat /etc/resolv.conf у кожного. Якщо працює порт 80, а 8080 ні, порівняйте, що їх розрізняє на шляху.
Дивіться на лічильники.

nft list ruleset показує правила разом із лічильниками packets. Правило, лічильник якого росте в момент вашої невдалої спроби, і є той, що діє. Якщо лічильник стоїть на нулі, воно не має стосунку.
Виправляйте по одній і перевіряйте.

Після кожної зміни повторіть відтворення з першого етапу й запустіть check.sh. У виводі чекера лише симптоми, причини він не називає. Фіксуйте в нотатках, що саме змінили: із цього складеться звіт.
Напишіть звіт.

Для кожної несправності чотири поля з формату вище. Пишіть, поки пам’ятаєте: «Як знайшов» забувається першим.

Перевірка

sudo ./check.sh            # звіт у ./report.md
sudo ./check.sh ~/b7/report.md

Чекер нічого не ламає й не лагодить. Він перевіряє для кожного з клієнтів h1 і h2: шлюз, dns і web відповідають; web.lab і dns.lab розв’язуються у правильні адреси; сторінка відкривається; великий файл завантажується повністю й без пошкоджень (порівнюється хеш); API на порту 8080 відповідає; telnet до web, як і належить політиці, заборонений. Окремо він переконується, що web слухає 80 і 8080, а dns слухає UDP 53. Звіт: шість розділів із чотирма полями в кожному, а також згадка кожної з шести категорій причин (MTU й ICMP, маршрут, ARP, nftables, запис DNS, резолвер) за ключовими словами.

У повідомленнях про невдачу чекер називає лише те, що не працює з боку користувача. Перед перевіркою він очищає кеш маршрутів, бо той зберігає виявлений MTU шляху до десяти хвилин і може приховати проблему.

Що треба вміти підтвердити

Твердження	Чим доводиться
Ви знаєте, де пакет зникає	`tcpdump` на двох сусідніх вузлах
Ви відрізняєте відсутність маршруту від відсутності відповіді	`ip route get` і `ping` з різними відповідями
Ви знаходите причину за побічною ознакою	велика відповідь зависає, мала проходить
Ви показуєте, що правило діє	лічильник `nft list ruleset` росте
Ви порівнюєте робоче з неробочим	`ip neigh`, `ip route`, `resolv.conf` у двох клієнтів
Кожне виправлення перевірено	`check.sh` після кожної зміни

Часті помилки

Гадати замість вимірювати. Перезапускати служби й міняти налаштування наосліп. Це не лише повільно, але й змінює стан так, що початкова причина зникає без пояснення.

Вважати, що ping проходить, отже мережа здорова. Маленький ICMP не перевіряє ні MTU, ні порти, ні DNS. Для кожного класу скарги потрібна відповідна перевірка: великий пакет (ping -M do -s 1472 <адреса>), порт (curl чи nc), ім’я (dig).

Перевірка ping -M do приховала проблему. Вона змушує ОС запам’ятати MTU шляху на десять хвилин. Завантаження, яке щойно зависало, раптом працює, хоча ви нічого не виправили. ip route flush cache скидає запам’ятане значення. Перевіряйте виправлення після скидання кешу.

Знайти одне виправлення й вважати, що все готово. У роботі шість причин, а скарг теж шість; кожна виправлена причина відкриває наступну.

Виправити симптом, а не причину. Додати маршрут до 10.7.2.80/32, замість того щоб виправити маску; вписати адресу в /etc/hosts, замість того щоб виправити DNS. Чекер помітить не кожен обхід (маршрут на /32 він пропустить), але головне тут не чекер: у реальній мережі обхід лишає дефект для наступного користувача, а у звіті ви маєте назвати справжню причину.

Зняти файрвол цілком. Працюватиме порт 8080 і зникне захист від telnet. Правило, що заважає, знаходять за лічильником і видаляють за handle.

Перезапустити break.sh «для чистоти». Він знову внесе всі несправності. Для початку з нуля спершу --teardown.

Далі, якщо цікаво

Поставте tcpdump на r2 і з’ясуйте, скільки разів web повторює той самий великий сегмент, перш ніж TCP здасться. Виправте несправність 1 трьома різними способами (ICMP, обмеження MSS на маршрутизаторі, вирівнювання MTU) і порівняйте їхню поведінку для нових з’єднань. Запустіть break.sh B: ті самі класи проблем, але інші значення, й перевірте, наскільки ваш порядок дій не залежить від конкретних чисел. Напишіть власний «чек-лист налагодження» на одну сторінку з того, що виявилося корисним.