Ubuntu 24.04 «Network is unreachable»: сироватка правди таблиці маршрутизації (і виправлення)

Що насправді означає «Мережа недоступна» (з погляду kernel)

Коли ви бачите:

cr0x@server:~$ ping -c 1 1.1.1.1
ping: connect: Network is unreachable

Ця помилка зазвичай — ENETUNREACH, що піднялося з kernel. Переклад: kernel намагався знайти маршрут до призначення і зазнав невдачі на етапі пошуку маршруту — ще до того, як він спробував ARP/NDP або торкнувся кабелю.

Ця різниця важлива. Якщо ARP не вдається, ви часто отримуєте «Destination Host Unreachable» (від локального хоста) або тайм-аути. Якщо DNS не працює — «Name or service not known». Якщо невдала операція пошуку маршруту — «Network is unreachable». Linux не красномовний; він дає конкретний режим помилки.

Є кілька варіантів, які варто знати:

• Немає відповідного маршруту у жодній із таблиць, що переглядалися для цього призначення.
• Маршрут існує, але він позначений як unreachable, prohibit або blackhole (так, це реальні типи маршрутів).
• Політика маршрутизації (ip rules) перенаправила пошук у таблицю, в якій немає маршруту.
• Вибрано IPv6, але IPv6-маршрутизація відсутня (або RA вимкнено), тож v6 виглядає недоступним, хоча v4 працює.

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

Жарт №1: таблиця маршрутів — як оргструктури корпорації: всі стверджують, що вона точна, і всі помиляються, поки щось не ламається.

Сироватка правди таблиці маршрутизації: як Linux приймає рішення

Якщо ви запам’ятаєте одну команду з усього цього матеріалу — нехай це буде ця:

cr0x@server:~$ ip route get 1.1.1.1
1.1.1.1 via 192.0.2.1 dev ens18 src 192.0.2.10 uid 1000
    cache

ip route get — це ваша сироватка правди. Вона змушує kernel виконати той самий пошук маршруту, який він зробить для реального трафіку, і виводить обраний наступний хоп, вихідний інтерфейс і вибір джерела адреси.

Три ключові моменти, які регулярно дивують розумних людей:

1. Kernel обирає вихідний IP. Якщо цей src невірний (не з підмережі, застарілий або з іншого VRF/таблиці), відповіді не повернуться. Іноді симптом — «недоступно», іноді — таймаут. У будь-якому випадку, читайте src.
2. Правила можуть перевизначати маршрути. Маршрут, який ви бачите в main, не обов’язково той, що використовується. ip rule може відправити трафік у іншу таблицю за джерелом, fwmark, UID або іншими селекторами.
3. Метрики вирішують конфлікти. Декілька маршрутів за замовчуванням часто зустрічаються на ноутбуках (Wi‑Fi + VPN + Docker + «корисні» інструменти). Kernel вибере маршрут з найменшою метрикою, а не той, який ви планували.

Стек рішення маршрутизації (приблизно)

Для більшості хостів Ubuntu 24.04 шлях виглядає так:

• Додаток просить з’єднання; kernel формує tuple потоку (dst, src якщо прив’язано, mark тощо).
• Оглядається список ip rule зверху вниз. Кожне правило обирає таблицю маршрутів для пошуку (або каже «prohibit»).
• Знаходиться відповідний маршрут: спочатку хостовий, потім більш специфічний префікс, потім default.
• Визначається наступний хоп: прямий підключений маршрут використовує ARP/NDP для L2-сусіда; через gateway — ARP/NDP для gateway.
• Потім ми, нарешті, доходимо до «чи інтерфейс UP», «чи є carrier», «чи вирішився сусід».

Отже: якщо ви бачите «Network is unreachable», це відбувається до етапу вирішення сусідів. Ваше завдання — знайти, який пошук не дав придатного маршруту — і чому.

Є перефразована ідея від Werner Vogels, яка підходить для експлуатації: Все ламається, постійно; ваше завдання — проектувати під це (парафраз). Маршрутизація — один із тих шарів, що «тихо ламається», поки не ламається.

Швидкий план діагностики (перший/другий/третій)

Коли у вас pager, вам не потрібний мережевий семінар. Потрібен швидкий шлях до вузького місця. Ось порядок, який на практиці економить найбільше часу.

Перший: спитайте kernel, що б він зробив

1. ip route get <dst> для конкретної IP-адреси призначення. Якщо помилка — маршрутизація відсутня. Якщо обрано несподіваний інтерфейс або src — маршрутизація є, але неправильна.
2. ip rule щоб побачити, чи політика маршрутизації відправляє трафік у таблицю, про яку ви забули.

Другий: перевірте базові речі, що створюють маршрути

1. ip addr на обраному інтерфейсі: правильна адреса? правильна довжина префіксу? не tentative?
2. ip route та ip -6 route: чи є default маршрут? чи в тій таблиці, яку ви справді використовуєте?
3. Netplan/NetworkManager/systemd-networkd стан: чи джерело конфігурації справді застосовує те, що ви думаєте?

Третій: лише потім ганяйте L2 та зовнішні проблеми

1. ip neigh / ip -6 neigh: чи можете ви вирішити MAC шлюзу?
2. ping шлюз і хост у тому ж сегменті.
3. tcpdump тільки коли потрібні докази, а не терапія.

План зроблено навмисно з пріоритетом маршрутизації. «Network is unreachable» зазвичай означає, що kernel навіть не спробував відправити пакет.

Практичні завдання: команди, виводи, рішення (12+)

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

Завдання 1: Відтворіть помилку з IP, не з іменем

cr0x@server:~$ ping -c 1 1.1.1.1
ping: connect: Network is unreachable

Що це означає: Не DNS. Не брандмауер. Kernel не знайшов маршрут (або існує маршрут типу unreachable/prohibit).

Рішення: Йдіть прямо до ip route get і ip rule. Не витрачайте час на resolv.conf.

Завдання 2: Запитайте kernel про рішення маршруту

cr0x@server:~$ ip route get 1.1.1.1
RTNETLINK answers: Network is unreachable

Що це означає: Таблиці маршрутів, які переглядалися (згідно з поточними політиками), не дали придатного маршруту.

Рішення: Спочатку перевірте політичну маршрутизацію (ip rule), потім таблиці маршрутів (ip route show table ...).

Завдання 3: Перевірте правила політики маршрутизації (звичайний винуватець «працювало вчора»)

cr0x@server:~$ ip rule
0:      from all lookup local
100:    from 10.10.0.0/16 lookup 100
32766:  from all lookup main
32767:  from all lookup default

Що це означає: Трафік з 10.10.0.0/16 використовує таблицю 100. Якщо ваш застосунок прив’язав джерело або kernel його обрав, ви можете опинитись у іншому всесвіті маршрутів.

Рішення: Перевірте маршрути таблиці 100. Якщо вона пуста або не має default, ви знайшли ваш «unreachable».

Завдання 4: Показати маршрути в main таблиці (IPv4)

cr0x@server:~$ ip route
192.0.2.0/24 dev ens18 proto kernel scope link src 192.0.2.10

Що це означає: У вас тільки підключений маршрут. Немає default маршруту. Хост може говорити зі своєю підмережею — і лише з нею.

Рішення: Додайте/виправте default gateway через Netplan/NetworkManager, а не вручну (якщо тільки ви не триажите).

Завдання 5: Показати маршрути в конкретній таблиці (policy таблиця 100)

cr0x@server:~$ ip route show table 100
10.10.0.0/16 dev wg0 proto kernel scope link src 10.10.0.5

Що це означає: Таблиця 100 досяжна тільки для VPN-підмережі. Якщо таблиця 100 використовується для трафіку в інтернет, ви отримаєте «unreachable».

Рішення: Додайте default до таблиці 100 (якщо це задумано) або виправте правило, що відправляє трафік туди.

Завдання 6: Підтвердити наявність default (і що він не конкурує)

cr0x@server:~$ ip route show default
default via 192.0.2.1 dev ens18 proto dhcp src 192.0.2.10 metric 100
default via 198.51.100.1 dev ens19 proto dhcp src 198.51.100.10 metric 50

Що це означає: Два default маршрути. Kernel віддасть перевагу метриці 50 (ens19). Це може бути відключена мережа, management VLAN або мертва uplink.

Рішення: Вирішіть, який інтерфейс має бути власником default. Виправте метрики або видаліть небажаний default на рівні конфігурації.

Завдання 7: Подивитись адреси й префікси (неправильна маска = тихий хаос)

cr0x@server:~$ ip -br addr
lo               UNKNOWN        127.0.0.1/8 ::1/128
ens18            UP             192.0.2.10/32 fe80::a00:27ff:fe4e:66a1/64

Що це означає: /32 на LAN-інтерфейсі майже ніколи не є правильним, якщо тільки ви не робите point-to-point з явними on-link маршрутами. З /32 kernel не вважатиме gateway on-link, якщо це не вказано явно.

Рішення: Виправте довжину префіксу в Netplan/DHCP конфігурації. Тимчасово можна додати on-link маршрут до шлюзу (але ви маєте відчути певне соромління).

Завдання 8: Перевірити, чи gateway вважається on-link

cr0x@server:~$ ip route get 192.0.2.1
RTNETLINK answers: Network is unreachable

Що це означає: Навіть адреса шлюзу недосяжна. Класичний випадок — неправильна довжина префіксу або відсутній підключений маршрут.

Рішення: Виправте адресацію спочатку; маршрутизація залежить від неї.

Завдання 9: Якщо маршрути нормальні — перевірте стан L2-сусіда для шлюзу

cr0x@server:~$ ip neigh show dev ens18
192.0.2.1 lladdr 00:11:22:33:44:55 REACHABLE

Що це означає: ARP працює. Якщо ви досі не можете дістатися зовні підмережі, проблема — upstream (маршрутизація шлюзу/NAT/фаєрвол) або політика маршрутизації.

Рішення: Пропінгуйте шлюз, потім трасуйте рішення маршрутизації далі. Якщо neighbor має статус FAILED, фокусуйтеся на VLAN, bridge-конфігурації, кабелю або політиках безпеки.

Завдання 10: Швидка перевірка стану лінку та лічильників драйвера

cr0x@server:~$ ip -s link show dev ens18
2: ens18: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP mode DEFAULT group default qlen 1000
    link/ether 08:00:27:4e:66:a1 brd ff:ff:ff:ff:ff:ff
    RX:  bytes packets errors dropped  missed   mcast
    1249389   15234      0       0       0     123
    TX:  bytes packets errors dropped carrier collsns
     893221   10112      0       0       0       0       0

Що це означає: LOWER_UP вказує на carrier. Помилки/колізії/дропи дають швидку перевірку фізичної або віртуальної проблеми комутатора.

Рішення: Якщо carrier down — припиніть аналіз маршрутизації та виправте лінк. Якщо carrier up і лічильники чисті — повертайтеся до аналізу маршрутів/політик.

Завдання 11: Переглянути згенеровану конфігурацію Netplan (виловити невідповідності наміру й реальності)

cr0x@server:~$ sudo netplan get
network:
  version: 2
  ethernets:
    ens18:
      dhcp4: true

Що це означає: Система очікує DHCP для IPv4. Якщо немає default маршруту, DHCP-сервер може не надсилати опцію router, або клієнт не застосовує її.

Рішення: Підтвердіть renderer та логи (NetworkManager vs systemd-networkd), потім перевірте деталі DHCP-лізу.

Завдання 12: Визначити renderer і активний стек мереж

cr0x@server:~$ networkctl status -n0
WARNING: systemd-networkd is not running, output will be incomplete.

Що це означає: systemd-networkd, ймовірно, не є активним renderer. NetworkManager, ймовірно, активний (поширено на десктопах; іноді на серверах теж).

Рішення: Не редагуйте неправильний шар. Далі перевірте стан NetworkManager.

Завдання 13: Перевірити стан пристрою та з’єднання в NetworkManager

cr0x@server:~$ nmcli -f GENERAL.STATE,GENERAL.CONNECTION,IP4.GATEWAY,IP4.ROUTE dev show ens18
GENERAL.STATE:                         100 (connected)
GENERAL.CONNECTION:                    Wired connection 1
IP4.GATEWAY:                           --
IP4.ROUTE[1]:                          dst = 192.0.2.0/24, nh = 0.0.0.0, mt = 100

Що це означає: Підключено, але немає gateway. Саме так ви отримуєте «Network is unreachable» для трафіку поза підмережею.

Рішення: Виправте профіль з’єднання (gateway, DHCP опції або прапори «never-default»). Перезапуск інтерфейсу не створить gateway з повітря.

Завдання 14: Переглянути інфо DHCP-ліза щодо опції router

cr0x@server:~$ journalctl -u NetworkManager -b | tail -n 8
Dec 30 10:14:22 server NetworkManager[1023]: <info>  [1735553662.1234] dhcp4 (ens18): option routers: (none)
Dec 30 10:14:22 server NetworkManager[1023]: <info>  [1735553662.1236] dhcp4 (ens18): option subnet_mask: 255.255.255.0
Dec 30 10:14:22 server NetworkManager[1023]: <info>  [1735553662.1238] dhcp4 (ens18): state changed bound -> bound

Що це означає: DHCP-сервер не надав router (default gateway). Ваш хост поводиться правильно; мережа — ні.

Рішення: Ескалюйте до власників мережі/DHCP, або налаштуйте статичний gateway, якщо цей сегмент цього вимагає.

Завдання 15: Тимчасовий триаж — додати default маршрут (не плутайте триаж із виправленням)

cr0x@server:~$ sudo ip route add default via 192.0.2.1 dev ens18 metric 100

cr0x@server:~$ ip route get 1.1.1.1
1.1.1.1 via 192.0.2.1 dev ens18 src 192.0.2.10 uid 0
    cache

Що це означає: Ви тимчасово відновили маршрутизацію.

Рішення: Негайно внесіть постійну зміну в Netplan/NM. Ручні маршрути зникають після перезавантаження або під час перезапуску мережі — це приємний сюрприз о 02:00.

Завдання 16: Доведіть, чи політика маршрутизації вибирає іншу таблицю за джерелом

cr0x@server:~$ ip route get 1.1.1.1 from 10.10.0.5
RTNETLINK answers: Network is unreachable

Що це означає: З джерелом 10.10.0.5 (ймовірно VPN) пошук не знаходить маршрут. Це проблема політики маршрутизації, а не «інтернет упав».

Рішення: Виправте ip rule і маршрути таблиць. Багато VPN-клієнтів встановлюють правила, що мають сенс для ноутбуків, але не для серверів.

Завдання 17: Перевірити, чи reverse path filtering не маскує помилку маршрутизації

cr0x@server:~$ sysctl net.ipv4.conf.all.rp_filter net.ipv4.conf.ens18.rp_filter
net.ipv4.conf.all.rp_filter = 1
net.ipv4.conf.ens18.rp_filter = 1

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

Рішення: Якщо у вас multi-homing, політика маршрутизації або VRF, розгляньте значення 2 (loose) для відповідних інтерфейсів, але робіть це свідомо і документуйте причину.

Поширені помилки: симптом → корінна причина → виправлення

1) «ping: connect: Network is unreachable» до будь-якої зовнішньої IP

Симптом: Можна пропінгувати власну IP і, можливо, шлюз, але не можна пропінгувати публічні IP.

Корінна причина: Відсутній default маршрут (DHCP не надав router option, статична конфігурація неповна або renderer не той).

Виправлення: Додайте правильний default gateway у реальній системі конфігурації (Netplan/NM/systemd-networkd). Перевірте за ip route show default та ip route get.

2) «Network is unreachable» тільки для деяких джерел / тільки в контейнерах

Симптом: Хост може досягти призначення, але трафік з певного джерела (VPN, контейнер, вторинна NIC) недосяжний.

Корінна причина: Правило політики маршрутизації відправляє трафік у пусту таблицю, або таблиця не має default маршруту.

Виправлення: Аудит ip rule, потім ip route show table X. Додайте відсутні маршрути в цю таблицю або видаліть/підкоригуйте правило.

3) Default маршрут є, але «unreachable» зберігається для конкретного префікса

Симптом: Інтернет працює, але певний RFC1918 діапазон або корпоративна підмережа «недоступні».

Корінна причина: Існує маршрут unreachable для того префіксу (іноді встановлений VPN-клієнтом, kube‑утилітою або агентом безпеки) або більш специфічний неправильний маршрут перевизначає default.

Виправлення: Знайдіть конкретний префікс: ip route show match 10.0.0.0/8. Видаліть або виправте маршрут у його джерелі (профіль з’єднання, VPN-скрипт, netplan).

4) «Network is unreachable» після зміни netmask/prefix

Симптом: Ви змінили /24 на /32 (або навпаки) і тепер шлюз «недосяжний».

Корінна причина: Kernel не вважає gateway on-link; підключений маршрут не покриває IP шлюзу.

Виправлення: Виправте довжину префіксу. Якщо вам справді потрібен /32, додайте явний on-link маршрут до шлюзу і default маршрут через нього (і очікуйте пояснень пізніше).

5) Дві NIC, два default, переривчаста доступність

Симптом: Працює, потім перестає, особливо після ребута або оновлення DHCP.

Корінна причина: Конкуруючі default маршрути з мінливими метриками; kernel обирає інший egress, ніж очікується.

Виправлення: Явно задайте метрики і закріпіть «власника» default маршруту. На серверах — будьте нудними: один default, явні маршрути для решти.

6) IPv6 призначення недоступні, а IPv4 працює (або навпаки)

Симптом: Curl до хоста швидко падає з unreachable; примусово IPv4 працює.

Корінна причина: IPv6 має пріоритет, але немає default маршруту (відсутній RA, accept_ra вимкнено або фаєрвол блокує NDP/RA).

Виправлення: Налаштуйте IPv6 маршрутизацію правильно (RA/DHCPv6/статично) або цілеспрямовано вимкніть IPv6 для інтерфейсу/сервісу. Не лишайте його напіввключеним.

7) «Unreachable» в просторі імен / VRF, але не на хості

Симптом: Хост може досягти, але netns або VRF ні.

Корінна причина: Окремі таблиці маршрутизації для namespace/VRF; ви виправили main таблицю хоста, але не таблицю в просторі імен.

Виправлення: Виконайте ip route всередині namespace або VRF і налаштуйте маршрути там.

Особливості Ubuntu 24.04: Netplan, NetworkManager, systemd-networkd

Ubuntu має елегантну ідею та неакуратну реальність: Netplan — це декларативний frontend, а backend renderer — або NetworkManager, або systemd-networkd. На Ubuntu 24.04 обидва поширені залежно від того, чи ви на десктопі, cloud-образі чи «сервері», який хтось встановив з GUI, бо любить кліки.

Операційне правило: не виправляйте маршрутизацію в неправильному шарі. Якщо NetworkManager керує інтерфейсом, редагування unit від networkd нічого не змінить. Якщо networkd — власник, nmcli-зміни не збережуться.

Як дізнатися, хто за що відповідає

Почніть із сервісів:

cr0x@server:~$ systemctl is-active NetworkManager
active

cr0x@server:~$ systemctl is-active systemd-networkd
inactive

Рішення: Якщо NetworkManager active і networkd inactive, вважайте NM джерелом істини для runtime конфігурації. Netplan може все ще генерувати NM конфіг.

Безпечне застосування Netplan

Коли ви змінюєте Netplan, використовуйте try на віддалених коробках. Він автоматично відкатить зміни, якщо ви втратите доступ. Це найкращий ремінь безпеки в Linux-мережах.

cr0x@server:~$ sudo netplan try
Do you want to keep these settings?

Press ENTER before the timeout to accept the new configuration

Changes will revert in 120 seconds

Рішення: Якщо ви підключені по SSH через інтерфейс, який змінюєте — використовуйте try. Якщо любите ризикувати — apply і насолоджуйтеся прогулянкою до дата-центру.

Типові пастки Netplan щодо маршрутів

• Відсутній gateway: DHCP його не надає, або ви використали статичну адресу без routes чи gateway4.
• Неправильний renderer: конфігурація виглядає правильно, але не застосовується.
• Метрики: Netplan підтримує метрики маршрутів; якщо ви не задаєте їх на multi‑NIC системах, ви залишаєте все на волю випадку.

Жарт №2: Змінювати мережеву конфігурацію через SSH — хороший спосіб практикувати уважність. Ви дуже присутні, коли промпт перестає відповідати.

Особливі пастки «unreachable» для IPv6

Ubuntu 24.04 зазвичай має IPv6 увімкнений за замовчуванням. Це добре. Пастка — частковий IPv6: адреси є, але маршрутизації немає, тож застосунки, що віддають перевагу IPv6, падають швидко.

Завдання: подивитись IPv6 маршрути і чи є default

cr0x@server:~$ ip -6 route show default
default via fe80::1 dev ens18 proto ra metric 100 pref medium

Що це означає: У вас є IPv6 default маршрут, вивчений через Router Advertisement (RA). Якщо його немає, IPv6 трафік може бути недоступним.

Рішення: Якщо вам потрібен IPv6, переконайтеся, що RA приймається (accept_ra), і що фаєрвол не блокує RA/NDP. Якщо IPv6 не потрібен — вимкніть його явно на інтерфейсі або через sysctl — не лишайте його напіввключеним.

Завдання: примусити IPv4, щоб підтвердити гіпотезу

cr0x@server:~$ curl -4 -sS --connect-timeout 3 https://example.com
<html>...</html>

Що це означає: IPv4 шлях в порядку; IPv6 — зламаний.

Рішення: Виправте IPv6 маршрутизацію або налаштуйте вибір джерела/вимкніть IPv6 для шляху сервісу. Не звинувачуйте «інтернет».

Завдання: перевірити стан NDP-сусіда для default шлюзу

cr0x@server:~$ ip -6 neigh show dev ens18
fe80::1 lladdr 00:11:22:33:44:55 router REACHABLE

Що це означає: L2‑сусідство для IPv6 здорове. Якщо unreachable зберігається, фокусуйтеся на маршрутах/правилах або upstream.

Рішення: Якщо neighbor має статус FAILED або INCOMPLETE, усувайте проблеми з VLAN, фільтрацією RA або функціями безпеки комутатора.

Політика маршрутизації та кілька таблиць (дорослі проблеми)

Політика маршрутизації — це місце, куди прості мережі йдуть ставати «цікавими». Саме там «Network is unreachable» часто неправильно діагностують як проблему з кабелем, бо хтось дивиться тільки на ip route (main таблицю) і говорить, що все гаразд.

Як політика маршрутизації створює unreachable

Уявіть:

• У вас є VPN інтерфейс wg0 з 10.10.0.5/16.
• Правило каже: «From 10.10.0.0/16, lookup table 100.»
• Таблиця 100 містить лише підмережу VPN, без default маршруту.

Будь-який потік з джерелом 10.10.0.5 тепер не може дістатися в інтернет. Kernel дивиться таблицю 100, не знаходить нічого і каже «Network is unreachable». Це логічна поведінка. Ваш дизайн — неповний.

Завдання: вивести всі пріоритети правил (порядок має значення)

cr0x@server:~$ ip -details rule
0:      from all lookup local
100:    from 10.10.0.0/16 lookup 100
32766:  from all lookup main
32767:  from all lookup default

Що це означає: Kernel спочатку потрапить на пріоритет 100. Якщо воно співпаде — main стає неактуальним.

Рішення: Виправте правило або наповніть таблицю. Не «лише додайте default до main» у надії, що це вирішить проблему.

Завдання: показати типи маршрутів, що явно блокують трафік

cr0x@server:~$ ip route show type unreachable
unreachable 10.0.0.0/8 metric 1024

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

Рішення: З’ясуйте, хто його встановив (NM connection, netplan, скрипти, агент безпеки). Видаляйте в джерелі, а не вручну, якщо тільки ви не в режимі аварійного триажа.

Завдання: перевірити вибір таблиці за fwmark (якщо використовуєте маркування nftables/iptables)

cr0x@server:~$ ip rule | grep -n fwmark
12:200:  from all fwmark 0x1 lookup 200

Що це означає: Маркований трафік використовує таблицю 200. Якщо таблиця 200 не має маршруту, марковані потоки будуть unreachable, тоді як немарковані — працюватимуть.

Рішення: Перевірте правила фаєрволу для маркування та переконайтеся, що таблиця 200 має default маршрут або відповідні префікси.

Три корпоративні міні-історії (анонімізовані)

Інцидент через хибне припущення: «DHCP завжди дає gateway»

У середньому підприємстві команда розгорнула новий образ Ubuntu 24.04 для build-агентів. Ці машини жили в «tools» VLAN, яка історично використовувала статичні адреси. Хтось переключив VLAN на DHCP, щоб зменшити ручну роботу, і всі були в захваті, бо таблиці Excel — це не інфраструктура.

Образ використовував DHCP, отримав IP і радісно повідомив «connected». Але збірки почали падати, щойно треба було скачати залежності з інтернету. Помилка була миттєва: «Network is unreachable». Інженери думали, що впав проксі, потім звинуватили DNS, потім — команду фаєрволу (завжди популярна мішень).

Насправді все було банально: DHCP‑скоп надавав IP та маску, але не передавав опцію router. Частина парку цього не помічала, бо була ще в статичній конфігурації або мала кешовані маршрути; нові build-агенти були єдиними, хто падали послідовно.

Виправлення не було героїчним. Вони підтвердили це в логах («option routers: (none)»), додали router option до DHCP‑скопу — і проблема зникла. Після інциденту урок став пунктом чекліста: нові підмережі треба перевіряти на IP, маску, router, DNS та MTU — не тільки «чи працює DHCP».

Оптимізація, що обернулася проти: «Два default для надійності»

В іншій компанії були сервери з двома гомінгами: один інтерфейс у production мережі, інший — у management мережі. Хтось вирішив бути хитрим і додати default на management «на випадок», якщо production впаде. Нагадуємо: редунданс, так?

Це працювало у спокійні години. Потім під час вікна технічного обслуговування з’явилися незначні втрати пакетів на production uplink. Linux, будучи раціональним, продовжив обирати default з найменшою метрикою — яка після оновлення DHCP змінилась. Деякі сервери почали відправляти production трафік через management інтерфейс. Повернення трафіку не сходилося. rp_filter скидало пакети. Клієнти бачили переривчасті збої, які практично неможливо було відтворити в лабораторії.

Оптимізація не створила надійності. Вона створила невизначеність. А невизначеність — це просто ненадійність у костюмі.

Виправлення було нудне, але правильне: один default маршрут; явні маршрути для management; і зафіксовані метрики в конфігурації. «Редунданс» перетворили на продуману маршрутизацію failover (протоколи маршрутизації або моніторинг змін), а не на пару конкуруючих default у надії, що вони поведуться чемно.

Нудна, але правильна практика, що врятувала ситуацію: «ip route get як стандартна процедура»

У компанії з великою кількістю Kubernetes-ворклоудів вузли іноді повідомляли «Network is unreachable» при завантаженні образів. Першим інстинктом було звинуватити registry або DNS. Але SRE‑команда мала звичку: кожна мережна скарга починається з ip route get.

Ця звичка окупилася. На ураженому вузлі ip route get показав egress через інтерфейс, створений CNI, з джерелом, що належало до підмережі подів. Це ніколи не мало статись для хостового трафіку. Команда одразу переключилась на політику маршрутизації і знайшла застаріле правило від старого VPN-агента, яке матчило ширше, ніж треба.

Вони видалили агент, почистили правило і додали перевірку на етапі підготовки вузла: гарантувати, що host-default egress використовує первинний NIC і очікуване джерело. Нічого надприродного — просто правило, що ловить дрейф до того, як він перетвориться на інцидент.

Це не було гламурно, але уникнуло довгого шляху з пакетними знімками та пошуками винних. Нудне — це фіча в експлуатації.

Цікаві факти та короткі історичні нотатки

• Linux «iproute2» замінив «net-tools» (напр., route, ifconfig), бо сучасна маршрутизація потребує політичних правил, кількох таблиць і кращої видимості.
• ip route get віддзеркалює пошук FIB kernel і включає вибір джерела — те, що старі інструменти майже не показували.
• Метрики маршрутів не тьмяють вирішення; вони його визначають, коли кілька маршрутів збігаються. Найменша метрика перемагає, навіть якщо це засмучує людей.
• Linux підтримує типи маршрутів як blackhole, unreachable, і prohibit для навмисного блокування трафіку на рівні маршрутизації, а не фаєрволу.
• Політика маршрутизації через ip rule існує десятиліттями, широко використовується провайдерами та мультіхомедними системами задовго до того, як «cloud networking» змусив усіх знову відкрити її.
• IPv6 default маршрути часто приходять через Router Advertisements, а не DHCP. Блокування ICMPv6 може тихо поламати маршрутизацію, а не лише «ping».
• Reverse path filtering (rp_filter) був створений для зменшення спуфінгу, але погано взаємодіє з асиметричною маршрутизацією, якщо його не налаштувати свідомо.
• Network namespaces означають, що кожен namespace має свої таблиці маршрутів. Виправлення хоста не виправить контейнерну namespace, і навпаки.

Чеклісти / покроковий план

Чекліст A: Коли бачите «Network is unreachable» на Ubuntu 24.04

1. Відтворіть з IP: ping -c 1 1.1.1.1.
2. Запустіть ip route get 1.1.1.1.
3. Якщо помилка: перевірте ip rule, потім ip route (і конкретні таблиці).
4. Якщо повертається маршрут: підтвердіть, що dev і src — очікувані.
5. Перевірте default маршрути: ip route show default. Усуньте неоднозначність.
6. Перевірте адреси/довжини префіксів: ip -br addr.
7. Перевірте сусіда шлюзу: ip neigh show dev <dev>.
8. Підтвердіть, який renderer застосовує конфіг: systemctl is-active NetworkManager і systemctl is-active systemd-networkd.
9. Впроваджуйте виправлення в шарі, який є власником конфігурації (Netplan/NM/networkd), а не одноразовими командами.
10. Повторно протестуйте з ip route get і реальним з’єднанням (curl -4/curl -6 за потреби).

Чекліст B: Постійні виправлення (оберіть інструмент та дотримуйтесь його)

• Якщо використовуєте Netplan + networkd: визначте статичні маршрути/gateway в Netplan YAML, потім sudo netplan apply.
• Якщо використовуєте Netplan + NetworkManager: редагуйте Netplan YAML або NM профілі підключення, але не змішуйте одноразові маршрути з постійними профілями.
• Якщо маєте кілька uplink: явно задайте route metrics і додайте явні маршрути для нетипових мереж.
• Якщо використовуєте VPN: перевірте, що політичні таблиці містять default, якщо ви очікуєте full tunnel, або звузьте маршрути для split tunnel.
• Якщо запускаєте контейнери: перевірте, що маршрутизація хоста не змінюється випадково CNI, Docker або агента безпеки, що додає правила/маршрути.

FAQ

1) Чому «Network is unreachable» буває, навіть коли інтерфейс UP?

Бо стан лінку — це не стан маршрутизації. Інтерфейс може бути UP з дійсною IP, але не мати default маршруту, мати неправильну маску або політичні правила, що відправляють трафік у порожню таблицю.

2) Яка найшвидша команда для діагностики?

ip route get <destination-ip>. Якщо помилка — пошук маршруту не вдався. Якщо повернуто маршрут — прочитайте dev і src і перевірте їх на сенс.

3) У мене є default маршрут, чому все одно unreachable?

Або більш специфічний маршрут його перевизначає (включаючи unreachable/blackhole), або політична маршрутизація відправляє пошук у іншу таблицю. Перевірте ip rule і шукайте маршрути для префіксу призначення.

4) Як визначити, що IPv6 — причина невдачі імені хоста?

Примусіть IPv4: curl -4 або ping -4. Якщо IPv4 працює, а звичайний виклик швидко падає — система може обирати IPv6 без дійсного IPv6 default маршруту.

5) Чи є додавання default маршруту через ip route add default валідним виправленням?

Це валідний триаж. Це не довготривале виправлення. Воно зникне після перезапуску і може бути перезаписане DHCP-renew або рестартом мережі. Зробіть зміну постійною в Netplan/NetworkManager/networkd.

6) У чому різниця між «Network is unreachable» і «Destination Host Unreachable»?

«Network is unreachable» зазвичай означає, що пошук маршруту не вдався. «Destination Host Unreachable» часто означає, що маршрут є, але ARP/NDP або подальша маршрутизація не спрацювала, і було отримано ICMP unreachable.

7) Чи може Docker або Kubernetes спричинити «Network is unreachable» на хості?

Так. Вони додають інтерфейси, маршрути і іноді політичні правила. Зазвичай вони поводяться, але коли ні — ви побачите несподівані ip rule, додаткові маршрути або вибір джерела, що вказує на CNI/Docker мережі.

8) Чому працює для root, але не для сервісного користувача (або навпаки)?

Політична маршрутизація може матчити UID (через ip rule uidrange) або fwmarks, застосовані cgroups/iptables/nftables. Перевірте ip rule і наявність маркованих/UID‑специфічних правил.

9) Що робити, якщо сам gateway «недосяжний»?

Зазвичай це означає, що підключений маршрут не охоплює IP шлюзу (неправильна довжина префіксу), або інтерфейс/адреса насправді налаштовані не так, як ви думаєте. Спочатку виправте IP/префікс; маршрутизація йде після цього.

10) Чи варто вимикати rp_filter, щоб це виправити?

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

Висновок: практичні наступні кроки

«Network is unreachable» — це не настрій. Це вердикт маршрутизації. Ставтеся до нього як до такого.

Наступного разу, коли побачите це на Ubuntu 24.04, робіть так:

1. Запустіть ip route get <dst> і вірте виводу.
2. Перевірте ip rule перед тим, як дивитися на ip route і оголошувати перемогу.
3. Виправляйте корінну причину в шарі, що володіє конфігом (Netplan/NetworkManager/systemd-networkd), а не одним рядком-чемпіоном.
4. На multi‑homed системах явно вказуйте метрики та власника default маршруту. Невизначеність — не редунданс.
5. Якщо IPv6 увімкнено — налаштуйте його повністю або вимкніть навмисно. Половинчасто налаштований IPv6 часто призводить до швидких помилок.

Робіть це — і «Network is unreachable» стане менше містикою і більше корисним колегою: різким, точним і іноді дратівливим.