Модуль 6.4: Відлагодження мереж

Вирішення проблем | Складність: [COMPLEX] | Час: 30–35 хв

Передумови

Перед початком цього модуля:

Обов’язково: Модуль 3.1: Основи TCP/IP
Обов’язково: Модуль 3.4: iptables та netfilter
Бажано: Модуль 6.1: Системне вирішення проблем

Що ви зможете робити після цього модуля

Після завершення цього модуля ви зможете:

Діагностувати мережеві збої, використовуючи систематичний пошаровий підхід (фізичний -> канальний -> IP -> транспортний -> прикладний)
Захоплювати та аналізувати пакети за допомогою tcpdump для відлагодження проблем зі з’єднанням
Відстежити потік пакетів через правила iptables, мости та мережеві простори імен
Дебажити проблеми з мережею Kubernetes (Service недоступний, збій DNS, проблеми CNI) на рівні Linux

Чому цей модуль важливий

«Мережа лежить» — це найпопулярніше виправдання для будь-яких проблем із додатками. Навички відлагодження мереж дозволяють вам перевірити, чи дійсно проблема в мережі, і точно вказати, де саме вона виникла.

Розуміння відлагодження мереж допоможе вам:

Доводити наявність проблем у мережі — або спростовувати їх.
Вирішувати проблеми зі зв’язком — DNS, файрволи, маршрутизація.
Аналізувати трафік — бачити, що насправді відбувається «в дротах».
Діагностувати Kubernetes — Service Discovery, мережі подів.

Більшість «мережевих проблем» насправді виявляються помилками конфігурації або додатків.

Методологія: Рівень за рівнем

┌─────────────────────────────────────────────────────────────┐
│                    ВІДЛАГОДЖЕННЯ МЕРЕЖІ                     │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│  Починайте з рівня 1 і йдіть вгору:                         │
│                                                             │
│  ┌──────────────────────────────────────────────────────┐   │
│  │ Рівень 7: Додатки      curl, wget, логіка додатку    │   │
│  ├──────────────────────────────────────────────────────┤   │
│  │ Рівень 4: Транспортний ss, tcpdump (порти)           │   │
│  ├──────────────────────────────────────────────────────┤   │
│  │ Рівень 3: Мережевий    ping, traceroute, ip route    │   │
│  ├──────────────────────────────────────────────────────┤   │
│  │ Рівень 2: Канальний    ip link, arp                  │   │
│  ├──────────────────────────────────────────────────────┤   │
│  │ Рівень 1: Фізичний     кабель, комутатор, ethtool    │   │
│  └──────────────────────────────────────────────────────┘   │
│                                                             │
│  Кожен рівень залежить від тих, що нижче.                   │
│  Якщо рівень 3 впав, рівень 7 не запрацює.                  │
│                                                             │
└─────────────────────────────────────────────────────────────┘

Основні інструменти діагностики

ss: Стан сокетів

Найкращий інструмент для перевірки того, чи “слухає” програма порт.

# Показати всі порти, що слухають (TCP), з назвами процесів
sudo ss -tlnp

# Перевірити конкретний порт
ss -tlnp | grep :80

dig: Детектив DNS

Якщо ви можете пінгнути IP, але не можете зайти на домен — проблема в DNS.

# Швидка перевірка домену
dig google.com +short

# Перевірити, чи відповідає конкретний DNS-сервер
dig @8.8.8.8 google.com

tcpdump: Рентген мережі

Коли ви хочете бачити самі пакети даних.

# Перехопити весь трафік на інтерфейсі eth0
sudo tcpdump -i eth0

# Тільки трафік на порту 80
sudo tcpdump -i eth0 port 80

# Тільки трафік між вашим сервером та базою даних
sudo tcpdump -i eth0 host 10.0.0.50

”Connection Refused” проти “Timed Out”

Розуміння цієї різниці економить години часу:

Помилка	Що це означає	Ймовірна причина
Connection Refused	Сервер відповів “ні”	Програма не запущена або слухає не той порт/IP
Connection Timed Out	Сервер взагалі не відповів	Файрвол (iptables) тихо скидає пакети або сервер вимкнений

Тест

Як за допомогою ss перевірити, чи запущений вебсервер на порту 443?

Відповідь
`ss -tlnp | grep :443`.
Яка команда в Linux показує шлях пакета через роутери до цілі?

Відповідь
`traceroute` (або `tracepath`).
Ви отримуєте “Connection Timed Out”. Куди дивитися в першу чергу?

Відповідь
У правила файрвола (iptables/nftables) або на мережеву доступність хоста (ping). Пакет десь блокується або не доходить.
Як перехопити тільки HTTP-трафік за допомогою tcpdump?

Відповідь
`sudo tcpdump -i any port 80`.

Практична вправа

Завдання: Провести повну діагностику зв’язку.

Перевірте, чи є у вашої машини IP-адреса:
Terminal window
```
ip addr
```
Перевірте зв’язок зі своїм шлюзом (gateway):
Terminal window
```
ping -c 3 $(ip route | grep default | awk '{print $3}')
```
Перевірте, чи працює DNS:
Terminal window
```
dig +short google.com
```
Перевірте, чи відкритий порт SSH (22) на вашій машині:
Terminal window
```
ss -tln | grep :22
```

Критерії успіху: Ви вмієте крок за кроком перевіряти кожен рівень мережевого зв’язку.

Підсумок

Дійте пошарово: від заліза до додатка.
DNS — перша підозра при повільній роботі.
Connection Refused = Проблема в програмі.
Timed Out = Проблема в мережі або файрволі.
tcpdump — останній аргумент у суперечці з мережевими інженерами.

Розділ «Вирішення проблем» завершено! Тепер ви маєте повний арсенал для порятунку систем: від аналізу логів та процесів до глибокої діагностики мереж.

Далі: Розділ 7: Скрипти на Bash — навчіться автоматизувати всі ці перевірки та операції.