Ubuntu 24.04 «No route to host»: чекліст ARP/gateway/ACL, що припиняє здогадки (випадок №32)

December 8, 2025 • February 3, 2026 • Читання: 6 хв • Views: 6

Було корисно?

«No route to host» — це помилка, яка змушує розумних людей робити дурні речі, наприклад перезапускати мережу на продуктивному сервері, бо «це зазвичай допомагає».
Іноді допомагає. Частіше вона просто додає другий інцидент до першого.

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

Що насправді означає «No route to host» в Linux

В Linux «No route to host» зазвичай відповідає помилці на кшталт EHOSTUNREACH або ENETUNREACH. Це не істерика програми; це ядро, яке каже:
«Я не можу доставити цей пакет, і в мене є конкретна причина, яка не є «таймаутом».»

Ускладнення в тому, що кілька режимів відмови можуть проявлятися тим самим повідомленням для користувача:

Відсутній відповідний маршрут у таблиці маршрутів (немає маршруту за замовчуванням, неправильний префікс, неправильний VRF/таблиця).
Неможливість отримати супутника (ARP для IPv4, NDP для IPv6) — маршрут є, але не вдається знайти MAC-адресу наступного хопа.
Негайний ICMP unreachable, що повертається маршрутизатором, фаєрволом або хостом (політика блокує і вибирає «unreachable» замість «drop»).
Локальна політика каже «не дозволяти» (nftables, policy routing, RP filter або локальний маршрут до ніде).

Практичний висновок: якщо трактувати кожен «No route to host» як «щось з маршрутизацією», ви витратите час даремно. Іноді маршрути в порядку; шлюз живий; але відповіді ARP немає, бо VLAN неправильний або контролі безпеки мовчки відокремлюють вас від наступного хопа.

Цитата, яку я тримаю під рукою для таких інцидентів: парафразована ідея від W. Edwards Deming: «Без даних ви просто ще одна людина з думкою».
Цей чекліст орієнтований на дані: виконайте команду, прочитайте вивід, прийміть рішення.

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

Ви хочете найшвидший шлях до вузького місця. Не найелегантніший. Не той, що зробить команду мережі найщасливішою. Найшвидший.

Перший крок: підтвердити локальний намір маршрутизації (чи знаємо, куди відправляти пакети?)

Перевірте маршрут, який використає ядро: ip route get <dest>
Підтвердьте наявність маршруту за замовчуванням, якщо призначення за межами підмережі.
Переконайтеся, що вибір адреси джерела відповідає вашим очікуванням (на багатошарових хостах бувають сюрпризи).

Другий крок: підтвердити L2-суміжність до вашого наступного хопа (чи можемо ми ARP для шлюзу?)

Пропінгуйте шлюз за замовчуванням (або хоча б ініціюйте ARP): перевірте стан ip neigh.
Якщо ARP застряг у стані INCOMPLETE/FAILED, ви не досягаєте свого шлюзу на рівні Layer 2. Перестаньте звинувачувати маршрути.

Третій крок: підтвердити, що політика не блокує (ACL/фаєрвол/група безпеки/RPF)

Перевірте локальні правила nftables/ufw.
Зробіть захоплення на вихідному інтерфейсі: чи виходять ARP-запити? Чи приходять відповіді?
Якщо пакети виходять і не повертаються — це вищестояща мережа (комутатор/VLAN/ACL) або сам шлюз.

Жарт №1: Найшвидший спосіб «полагодити» мережеву проблему — перезавантажити щось, аж поки не виявиться, що ви перезапустили єдиний сервер із логами.

Цікаві факти & контекст (бо системи мають історію)

ARP передував сучасному вибуху Інтернету. Він був описаний у 1982 році (RFC 826). Ми досі дебагуємо той самий базовий механізм у 2025 році.
Стан сусідів у Linux — це повноцінний скінченний автомат. Ті позначки REACHABLE, STALE, DELAY, PROBE, FAILED — не для краси; вони підказують поведінку ядра.
ICMP «host unreachable» іноді — це ввічливість. Багато фаєрволів просто відкидають пакети; деякі явно відхиляють з ICMP, через що «No route to host» з’являється миттєво, а не після таймауту.
Reverse path filtering (rp_filter) старіший за більшість cloud VPC. Він існує щоб зменшити спуфінг, але все ще ламає асиметричну маршрутизацію у реальних системах.
Мережевий стек Ubuntu змінився більше культурно, ніж технічно. Netplan (YAML → renderer) зробив управління конфігом дружнішим, але також додав шар, де «виглядає правильно» може виявитися неправильним при рендерингу.
«No route to host» — це не те саме, що «Connection timed out». «No route» зазвичай означає негайну жорстку відмову; «timeout» часто означає, що пакети зникають (drop/blackhole).
Гратітуїтний ARP існує щоб зменшити час простою. Хости оголошують «ця IP тут на цьому MAC», щоб оновити кеші — корисно під час failover, небезпечно при неправильній конфігурації.
Політична маршрутизація в Linux існує десятиліттями. Декілька таблиць маршрутів + правила — потужні, але також надійний спосіб створити невидимі проблеми з підключенням.

Ментальна модель: L2 vs L3 vs policy

Коли Ubuntu каже «No route to host», вам слід негайно категоризувати відмову. Не за відчуттями — за шарами і рішеннями, які приймає ядро.

Рівень 3: «Який наступний хоп?»

Ядро консультується з таблицями маршрутів (можливо кількома через правила політики). Якщо не може знайти маршрут — ви отримаєте швидку помилку. Якщо знаходить, воно обирає:
префікс призначення → наступний хоп (шлюз або on-link) → вихідний інтерфейс → IP джерела.

Рівень 2: «Який MAC?»

Якщо наступний хоп on-link (включно з вашим шлюзом), Linux має вирішити MAC-адресу через ARP (IPv4) або NDP (IPv6).
Якщо ARP не вдається, маршрутизація може бути ідеальною, але ви все одно ні до чого не доберетесь. Ось чому прихильники «маршрут виглядає правильно» програють суперечки під час інцидентів.

Політика та контролі безпеки: «Нам дозволено?»

Пакет може бути заблокований локально (nftables/ufw), відхилений вгору за ланцюгом (ACL, security group, фаєрвол), або відкинутий через anti-spoof перевірки (rp_filter).
Такі відмови можуть проявлятися як негайні unreachable або як мовчазність. «No route to host» часто означає, що десь є явний reject.

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

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

Task 1: Reproduce the failure with a deterministic tool

cr0x@server:~$ nc -vz -w 3 10.40.12.50 22
nc: connect to 10.40.12.50 port 22 (tcp) failed: No route to host

Значення: Це помилка на рівні ядра, а не каприз SSH-клієнта. Якщо ви бачите «No route to host» тут, можна припинити чіпати SSH-конфіг.

Рішення: Перейдіть до вибору маршруту (ip route get) і перевірки сусідів.

Task 2: Ask the kernel which route it would use

cr0x@server:~$ ip route get 10.40.12.50
10.40.12.50 via 10.40.12.1 dev ens192 src 10.40.12.20 uid 1000
    cache

Значення: Linux вважає, що має відправляти трафік до шлюзу 10.40.12.1 через ens192, використовуючи IP джерела 10.40.12.20.

Рішення: Якщо це неправильно (неправильний шлюз, інтерфейс або джерело), виправте маршрути/нетплан. Якщо правильно — перевірте наступний хоп через ARP/пінг.

Task 3: Confirm you actually have the expected routes

cr0x@server:~$ ip route show
default via 10.40.12.1 dev ens192 proto dhcp src 10.40.12.20 metric 100
10.40.12.0/24 dev ens192 proto kernel scope link src 10.40.12.20 metric 100

Значення: Маршрут за замовчуванням існує. Маршрут підмережі існує. Це не випадок «немає маршруту в таблиці».

Рішення: Спускатися до ARP/вирішення сусідів для 10.40.12.1.

Task 4: Check link state and carrier (don’t skip this)

cr0x@server:~$ ip link show ens192
2: ens192: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP mode DEFAULT group default qlen 1000
    link/ether 00:50:56:aa:bb:cc brd ff:ff:ff:ff:ff:ff

Значення: LOWER_UP каже, що NIC має carrier. Якщо там NO-CARRIER або стан DOWN, ваша проблема на фізичному/віртуальному рівні зв’язку.

Рішення: Якщо немає LOWER_UP, зупиніться і виправте лінк (vSwitch port group, кабель, bond, драйвер). Якщо є — продовжуйте.

Task 5: Check the neighbor (ARP) entry for your gateway

cr0x@server:~$ ip neigh show dev ens192
10.40.12.1 INCOMPLETE
10.40.12.77 lladdr 00:25:90:12:34:56 STALE

Значення: INCOMPLETE для шлюзу означає, що ARP-запити були відправлені (або спроба була зроблена), але відповідь не була отримана. Це великий підказчик.

Рішення: Ймовірно, це невідповідність VLAN, ізоляція порту комутатора, upstream ACL, неправильна маска підмережі або сам шлюз вимкнений. Перевірте ARP-трафік за допомогою tcpdump.

Task 6: Force ARP activity by pinging the gateway

cr0x@server:~$ ping -c 2 -W 1 10.40.12.1
PING 10.40.12.1 (10.40.12.1) 56(84) bytes of data.

--- 10.40.12.1 ping statistics ---
2 packets transmitted, 0 received, 100% packet loss, time 1010ms

Значення: Ping не отримав відповідей. Сам по собі це не доводить провал ARP — ICMP може бути заблокований — але в поєднанні з сусіднім станом INCOMPLETE це сильний доказ.

Рішення: Захопіть ARP. Якщо не бачите відповідей — припиніть припускати «маршрут». Це суміжність.

Task 7: Capture ARP on the egress interface

cr0x@server:~$ sudo tcpdump -ni ens192 arp
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on ens192, link-type EN10MB (Ethernet), snapshot length 262144 bytes
12:41:05.112233 ARP, Request who-has 10.40.12.1 tell 10.40.12.20, length 28
12:41:06.113244 ARP, Request who-has 10.40.12.1 tell 10.40.12.20, length 28

Значення: Запити виходять із хоста. Відповідей немає. Це не локальна проблема фаєрвола; ARP зазвичай не фільтрується nftables у звичних IP-ланцюгах.

Рішення: Ескалюйте до команди, яка керує комутаторами/VLAN/portgroup/VRF/здоров’ям шлюзу. Якщо ви бачите відповідь, ваш хост має її вивчити; потім перевіряйте rp_filter, policy routing або upstream ACL.

Task 8: Verify IP addressing and prefix are what you think

cr0x@server:~$ ip -br addr show ens192
ens192           UP             10.40.12.20/24 fe80::250:56ff:feaa:bbcc/64

Значення: У вас налаштований префікс /24. Якщо мережа насправді /25 або /23, ви можете ARP-ити не того, хто on-link, або відсутній on-link шлюз.

Рішення: Якщо підозрюєте невідповідність префіксу, підтвердьте з проєктом мережі/джерелом істини і виправте netplan або діапазон DHCP. Не «приміряйте /16, щоб побачити», бо так створюють другий інцидент.

Task 9: Check policy routing rules (the silent saboteur)

cr0x@server:~$ ip rule show
0:      from all lookup local
1000:   from 10.40.12.20 lookup 100
32766:  from all lookup main
32767:  from all lookup default

Значення: Трафік із 10.40.12.20 використовує таблицю маршрутів 100. Якщо в таблиці 100 немає маршрутів, ви можете отримати «no route» незважаючи на ідеальну main-таблицю.

Рішення: Перевірте таблицю 100. Якщо вона неправильна, виправте правило або заповніть маршрути правильно.

Task 10: Inspect the alternate routing table (if rules exist)

cr0x@server:~$ ip route show table 100
default via 10.40.12.254 dev ens192

Значення: Таблиця 100 надсилає трафік за замовчуванням до 10.40.12.254. Якщо ваш реальний шлюз — 10.40.12.1, ви знайшли неправильний маршрут. Якщо .254 не існує, ARP провалиться і ви побачите поведінку unreachable.

Рішення: Виправте правило політичної маршрутизації або маршрут за замовчуванням у таблиці. Потім повторіть ip route get і ip neigh.

Task 11: Check reverse path filtering (rp_filter) for asymmetric routes

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

Значення: rp_filter=1 — це «strict». У багатошаровому середовищі або при асиметричній маршрутизації строгий RPF може скидати відповіді і створювати заплутані unreachable/таймаути.

Рішення: Якщо у вас асиметрична маршрутизація за задумом, розгляньте rp_filter=2 (loose) або зміну архітектури. Не вимикайте глобально, якщо не можете пояснити модель загроз.

Task 12: Check local firewall (nftables/ufw) for rejects

cr0x@server:~$ sudo nft list ruleset | sed -n '1,120p'
table inet filter {
        chain input {
                type filter hook input priority filter; policy accept;
        }
        chain forward {
                type filter hook forward priority filter; policy accept;
        }
        chain output {
                type filter hook output priority filter; policy accept;
        }
}

Значення: Цей хост нічого не блокує за допомогою nftables. Якщо ви бачите reject with icmpx type host-unreachable, це може пояснити негайне «No route to host».

Рішення: Якщо ланцюг output відхиляє трафік до призначення або підмережі, виправте правила. Якщо ruleset пустий/accept — дивіться вгору по потоку.

Task 13: Verify UFW status (because someone always enabled it “temporarily”)

cr0x@server:~$ sudo ufw status verbose
Status: inactive

Значення: UFW не бере участі. Якщо активний — перевірте вихідні відмови або блокування маршрутів (менш поширено, але буває).

Рішення: Якщо UFW активний і підозрілий — або налаштуйте політику, або тимчасово дозволіть для діагностики — задокументуйте зміни і поверніть назад.

Task 14: Check for a stale/wrong ARP entry (rare, but quick)

cr0x@server:~$ ip neigh show 10.40.12.1
10.40.12.1 lladdr 00:11:22:33:44:55 STALE

Значення: У вас є MAC для шлюзу. Якщо він неправильний (failover шлюзу, переміщення VRRP), ви можете тимчасово відкидати трафік.

Рішення: Очистіть запис і дозвольте повторне вивчення. Якщо він одразу знову вивчає той самий MAC і все ще падає — проблема поза вашим хостом.

cr0x@server:~$ sudo ip neigh flush 10.40.12.1 dev ens192
10.40.12.1 dev ens192 flushed

Task 15: Validate netplan rendered config (Ubuntu 24.04 reality)

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

Значення: Netplan тут використовує DHCP. Якщо ви очікуєте статичні маршрути/шлюз, або не застосували правильну конфігурацію, або DHCP перезаписує ваші наміри.

Рішення: Перевірте netplan YAML у /etc/netplan/, потім netplan try (акуратно) або погодьте вікно технічного обслуговування для змін, що можуть бути руйнівними.

Task 16: Check systemd-networkd or NetworkManager depending on renderer

cr0x@server:~$ networkctl status ens192
● 2: ens192
                     Link File: /usr/lib/systemd/network/99-default.link
                  Network File: /run/systemd/network/10-netplan-ens192.network
                          State: routable (configured)
                   Online state: online
                          Address: 10.40.12.20
                                   fe80::250:56ff:feaa:bbcc
                          Gateway: 10.40.12.1

Значення: Рендерер вважає, що ви маршрутизовані і маєте шлюз. Це не доводить, що ARP працює, але підтверджує наявність конфігурації.

Рішення: Якщо networkctl не показує шлюзу — виправте конфіг. Якщо показує шлюз, але ARP не працює — досліджуйте upstream L2/ACL.

Task 17: Trace the path and see where “unreachable” appears

cr0x@server:~$ tracepath -n 10.40.12.50
 1?: [LOCALHOST]                      pmtu 1500
 1:  10.40.12.1                                            0.314ms
 2:  no reply
 3:  no reply
     Too many hops: pmtu 1500

Значення: Ви дотягуєтеся до хопа 1 (шлюзу). Якби раніше ARP не працював, цього не відбулося б. Тож ви вже пройшли L2.

Рішення: Якщо хоп 1 досяжний, а призначення ні — перевіряйте маршрути/ACL далі: правила фаєрвола, між-VLAN ACL, security groups або відсутні маршрути у зворотному напрямку.

Task 18: Capture ICMP unreachable to prove an ACL reject

cr0x@server:~$ sudo tcpdump -ni ens192 icmp or icmp6
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on ens192, link-type EN10MB (Ethernet), snapshot length 262144 bytes
12:55:22.443322 IP 10.40.12.1 > 10.40.12.20: ICMP host 10.40.12.50 unreachable, length 68

Значення: Шлюз явно повідомляє, що хост недосяжний. Це не помилка вашого Ubuntu-хоста; це рішення маршрутизації/ACL вгору по ланцюжку.

Рішення: Ескалюйте з доказами: додайте мітку часу, тип/код ICMP і IP маршрутизатора, що надіслав повідомлення. Запитайте: чи є маршрут до 10.40.12.50? Чи ACL блокує?

Жарт №2: ARP — як офісні плітки — якщо ніхто не відповідає, це не означає, що ви неправі; означає, що ви говорите в іншу кімнату.

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

Міні-історія 1: Інцидент через неправильне припущення

Середня компанія мала чіткий поділ мереж «apps» і «databases». Нова VM Ubuntu 24.04 розгорнулась у підмережі apps.
Інженер припустив, що «шлюз за замовчуванням маршрутизує все внутрішнє», бо в попередньому середовищі так було.

Нова VM видавала «No route to host» при підключенні до бази. Таблиця маршрутів виглядала нормально. Маршрут за замовчуванням був присутній. Команда витратила годину на суперечки про синтаксис netplan і чи немає бага в systemd-networkd.
Тим часом команда баз даних наполягала, що нічого не змінювала.

Прорив прийшов від tcpdump: миттєво повернувся ICMP «host unreachable» від шлюзу. Це означало, що це не мовчазний drop і не локальна проблема.
Шлюз активно відмовляв у переадресації.

Неправильне припущення: внутрішня маршрутизація була універсальною. Насправді команда мережі місяців тому ввела між-VLAN ACL, які дозволяли лише певним підмережам доступ до VLAN бази.
Ця VM потрапила в «general apps» VLAN, який не був у allow-list.

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

Міні-історія 2: Оптимізація, що обернулась проти

Інша організація хотіла швидший failover для пари маршрутизаторів, що виконують redundancy першого хопа.
Вони налаштували таймери ARP і neighbor на серверах «щоб пришвидшити конвергенцію», а також зменшили деякі retry/backoff поведінки.

Це працювало в лабораторії. У проді створилося переривчасте «шторми»: під час failover шлюзу деякі Linux-хости швидко позначали запис сусіда як FAILED,
а потім відмовлялися говорити зі шлюзом до наступного вікна вирішення. Клієнти бачили сплески «No route to host», що породжувало сварки між SRE та мережевою інженерією.

Захоплення пакетів показало ARP-запити під час failover, але відповіді приходили трохи пізніше — запізніло для нових, скорочених таймерів.
«Оптимізація» зекономила мілісекунди в хорошому випадку і додала секунди в поганому.

Відкат був негайний. Потім вони зробили правильну оптимізацію: покращили сигналізацію failover на шлюзі (gratuitous ARP/ND), перевірили поведінку комутаторів і тестували з реалістичною затримкою/джиттером.
Тримайте таймери сусідів близько до дефолтних, поки не змоделюєте наслідки і не готові їх брати на себе.

Міні-історія 3: Нудна, але правильна практика, що врятувала день

У фінансовій компанії була непрезентабельна вимога: у кожному звіті про інцидент мають бути ip route get, ip neigh та 30-секундний tcpdump-зріз.
Команда скаржилася. Здавалося, це формальність. Поки не сталася реальна проблема.

Одного дня кілька Ubuntu 24.04 вузлів перестали доступатися до внутрішнього API з «No route to host». На чергуванні виконали стандартний набір.
Маршрути були правильні. Шлюзи досяжні. Але tcpdump показав ICMP host-unreachable від VIP фаєрвола.

Це миттєво звузило коло: пристрій вгору по ланцюжку відхиляв, а не скидaв трафік. Команда фаєрвола змогла знайти записи в логах за VIP і міткою часу.
Виявилося, що новий шаблон ACL мав «deny any any» вище за специфічний allow, але тільки для однієї зональної пари.

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

Поширені помилки: симптом → root cause → fix

Цей розділ різкий навмисно. Це пастки, через які «No route to host» живе довше, ніж мав би.

1) Симптом: «No route to host» до будь-чого поза підмережею

Root cause: Відсутній маршрут за замовчуванням або неправильний шлюз.

Fix: Перевірте ip route. Виправте netplan або DHCP. Підтвердьте з ip route get 8.8.8.8 (або внутрішньою IP поза підмережею).

2) Симптом: Маршрут є, але шлюз у `INCOMPLETE` в `ip neigh`

Root cause: ARP-відповіді не доходять до хоста: неправильний VLAN, невірне тегування порту, port security, шлюз вимкнений або L2-ізоляція.

Fix: tcpdump -ni <if> arp. Якщо запити виходять, але відповідей немає — ескалюйте до L2/мережевої команди з доказами. Перевірте VM portgroup/VLAN tag.

3) Симптом: Негайне «No route to host», але ARP в порядку і шлюз пінгується

Root cause: Вищестоящий пристрій надсилає ICMP unreachable (ACL reject, відсутній маршрут до призначення або policy routing на шлюзі).

Fix: Захопіть ICMP tcpdump-ом. Визначте IP відправника (часто шлюз/фаєрвол). Виправте ACL/маршрут вгору по ланцюжку.

4) Симптом: Тільки одна IP-адреса джерела не працює на хості з кількома IP

Root cause: Правило policy routing відправляє цей джерело в порожню/неправильну таблицю маршрутів.

Fix: ip rule show і ip route show table X. Узгодьте правила з бажаним egress/шлюзом.

5) Симптом: Працює в одному напрямку, падає в іншому; помилки змінюються між timeout і unreachable

Root cause: Асиметрична маршрутизація в поєднанні зі строгим RPF на одному боці.

Fix: Перевірте rp_filter і upstream anti-spoof контролі. Використайте loose mode, якщо обґрунтовано, або виправте симетрію маршрутів.

6) Симптом: Після failover шлюзу деякі хости отримують «No route to host» на хвилини

Root cause: Стаєвий кеш сусідів + відкладені gratuitous ARP/ND або агресивне налаштування таймерів.

Fix: Переконайтеся, що шлюз надсилає gratuitous ARP/ND при failover. Розгляньте очищення записів сусідів на вплинутих хостах лише як останній засіб.

7) Симптом: Лише певні порти показують «No route to host» (не «connection refused»)

Root cause: Фаєрвол відхиляє з ICMP unreachable для певних портів/флоу або якийсь middlebox політично класифікує трафік.

Fix: Tcpdump для ICMP unreachables під час невдалого підключення. Підтвердіть з мережею/безпечністю; відкоригуйте ACL-політику.

8) Симптом: IPv6 призначення не працює з «No route to host», IPv4 працює

Root cause: Відсутній маршрут IPv6 за замовчуванням або провал NDP; RA вимкнені; фаєрвол блокує ICMPv6 (що непомітно ламає IPv6).

Fix: Використайте ip -6 route і ip -6 neigh. Переконайтеся, що ICMPv6 дозволено; підтвердіть router advertisements, якщо вони використовуються.

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

Це секція «робіть щось щоразу». Роздрукуйте її. Покладіть у runbook інцидентів. Призначте відповідального, щоб зупинити вільну дебаг-рутин.

Чекліст A: Перевірка локального хоста (Ubuntu 24.04)

Підтвердьте, що інтерфейс увімкнений і має carrier.
Використайте ip link show. Якщо немає carrier — виправте віртуальне/фізичне з’єднання перед будь-чим іншим.
Підтвердьте адресацію і префікс.
Використайте ip -br addr. Якщо префікс неправильний — маршрути та ARP-бехавіор обманюватимуть вас.
Підтвердьте маршрут за замовчуванням і конкретний маршрут.
Використайте ip route show і ip route get <dest>.
Перевірте policy routing.
Використайте ip rule show. Якщо є неначальницькі правила — перевірте відповідні таблиці.
Перевірте сусідній запис для наступного хопа (шлюзу).
Використайте ip neigh show. INCOMPLETE — ваш великий червоний прапор.
Перевірте локальний фаєрвол на предмет reject-ів.
Використайте nft list ruleset і ufw status.
Захопіть трафік 30 секунд.
Використайте tcpdump для ARP і ICMP. Це ваші докази і компас.

Чекліст B: Дерево рішень «L2, L3 чи політика?»

Якщо ip route get не вдається (немає маршруту): виправте маршрути/шлюз/політичну маршрутизацію.
Якщо маршрут є, але ARP для шлюзу — INCOMPLETE: це суміжність (VLAN/tagging/комутатор/шлюз вниз).
Якщо ARP для шлюзу вирішується і шлюз відповідає, але призначення недосяжне:
перевіряйте upstream маршрути/ACL. Захопіть ICMP unreachables.
Якщо ніхто не відповідає і ніхто не відхиляє (таймаути): шукайте drop (ACL drop, security group drop, MTU blackhole, upstream фаєрвол silent drop).

Чекліст C: Пакет для ескалації (що надсилати мережевій/сервісній команді)

Якщо потрібна інша команда, не надсилайте «все не працює». Надішліть компактний набір:

ip route get <dest> (показує наступний хоп, інтерфейс, IP джерела)
ip route show і ip rule show (підтверджують локальний намір)
ip neigh show для шлюзу і призначення (показує стан ARP)
30 секунд tcpdump з ARP і/або ICMP unreachables (показує, хто відхиляє)
Точний мітка часу і призначення/порт (щоб вони змогли корелювати логи)

FAQ

1) Чому я отримую «No route to host», коли таблиця маршрутів виглядає правильно?

Тому що маршрутизація — лише перший крок. Linux може знати наступний хоп, але все ще не отримувати ARP/NDP для цього хопа.
Перевірте ip neigh для шлюзу; INCOMPLETE або FAILED означає, що у вас немає L2-доступу до наступного хопа.

2) Яка найшвидша одиночна команда, з якої почати?

ip route get <dest>. Вона показує інтерфейс, шлюз і обраний IP джерела. Якщо цей вивід вас дивує — ви знайшли категорію проблеми.

3) Як ACL може викликати «No route to host» замість таймауту?

Деякі ACL/фаєрволи налаштовані на reject замість drop. Reject може згенерувати ICMP «host unreachable» (або подібне),
що ядро відображає як «No route to host» миттєво. Захопіть ICMP tcpdump-ом, щоб довести це.

4) Чи те саме «No route to host» й «Destination Host Unreachable» в ping?

Вони пов’язані, але не ідентичні. «Destination Host Unreachable» — інтерпретація ping для ICMP unreachable або локальної помилки маршрутизації.
«No route to host» — це помилка сокета, яку бачать програми. Обидва часто вказують на недосяжність на L2/L3, але треба знайти, де саме генерується unreachable.

5) Чому це падає лише для однієї IP-адреси призначення, а не для всієї підмережі?

Поширені причини: відсутній специфічний маршрут вгору по ланцюжку, ACL, що таргетує цей хост, сам хост вимкнений або конфлікт ARP/дублікат IP.
Використайте tracepath і tcpdump для ICMP unreachables, щоб знайти відхиляючий хоп.

6) Як netplan в Ubuntu 24.04 впливає на це?

Netplan — шар конфігурації; рішення про пересилання приймає ядро. Помилки netplan проявляться як неправильні адреси, маршрути, шлюз або renderer.
Перевіряйте за допомогою netplan get і networkctl status (або інструментів NetworkManager, якщо це ваш рендерер).

7) Чи може DNS викликати «No route to host»?

DNS може привести вас до неправильного IP, але помилка все одно стосується досягнення того IP. Якщо підозрюєте DNS, розв’яжіть ім’я в адресу,
потім виконайте ip route get для цієї адреси і дійте далі.

8) Що робити, якщо ARP працює для шлюзу, але з’єднання все одно кажуть «No route to host»?

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

9) Як швидко відрізнити «drop» від «reject»?

Reject часто відбувається миттєво і може показати ICMP unreachable в tcpdump. Drop зазвичай призводить до таймауту. Це не ідеально, але добрий евристичний підхід.
Завжди підтверджуйте захопленням на вихідному інтерфейсі.

10) Чи варто очищувати ARP-кеш як виправлення?

Як діагностичний крок — іноді. Як звичка — ні. Очищення записів сусідів може приховати системну проблему (праксія failover, неправильне тегування VLAN, дублювання IP).
Використайте це, щоб підтвердити поведінку, а потім виправте корінну причину.

Висновок: кроки, що запобігають повторенню

«No route to host» — це не загадка. Це прохання: покажіть рішення маршруту, покажіть стан сусіда, покажіть результат політики.
Зробіть ці три речі — і проблема зазвичай перестане бути таємницею за кілька хвилин.

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

Уніфікуйте ваш набір діагностики: ip route get, ip neigh, ip rule і короткий tcpdump.
Навчіть команду трактувати INCOMPLETE запис як «зупинитися і перевірити VLAN/шлюз», а не «спробувати інший маршрут».
Документуйте, які підмережі дозволені звертатись до яких сервісів. «Маю маршрути» — міф у сегментованих мережах.
У change management вимагайте доказу зв’язності з щонайменше одного хоста в кожному сегменті після оновлень ACL/маршрутів.