Debian 13: Мережа не піднімається після перезавантаження — лаконічний чекліст для systemd-networkd

Ментальна модель: що насправді означає «мережа піднята»

Люди кажуть «мережа впала», ніби це одна річ. На Debian 13 із systemd-networkd «мережа піднята» — це ланцюжок окремих умов:

• Фізичний лінк: NIC бачить carrier, autoneg завершено, драйвер працює коректно.
• Інтерфейс існує і має ім’я: ваша конфігурація відповідає фактичній назві інтерфейсу після predictable udev naming.
• Адресація: DHCP успішний (або застосовано статичні адреси) і адреса реально прив’язана до інтерфейсу.
• Маршрутизація: є маршрут за замовчуванням (або потрібні політичні маршрути) і ядро обирає те, що ви очікуєте.
• DNS: /etc/resolv.conf вказує на реальний резолвер, або systemd-resolved налаштовано коректно, або ви надали явні nameserver-и.
• Фаєрвол: локальний фаєрвол не ковтає тихо DHCP-відповіді, ARP або ваш власний SSH.
• Залежності: сервіси, які мають запускатися «після мережі», випадково не блокують саму мережу (таке трапляється).

systemd-networkd відповідає лише за частину цього. Воно конфігурує лінки, адреси і маршрути, і може передавати DNS-параметри в systemd-resolved. Воно не веде переговори зі свічем. Також не виправить ситуацію, якщо модуль ядра «вирішив» бути примхливим після оновлення прошивки.

Тому правило просте: не «перезапускайте мережу» і не сподівайтеся. Визначте, яке саме посилання в ланцюжку зламане. Виправте його, потім підтвердіть наступне.

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

Перше: чи це невідповідність імен/конфігурації або конфлікт сервісів?

Найшвидші збої — нудні: змінилася назва інтерфейсу або два стеку мережевого управління конфліктують. Підтвердьте назву інтерфейсу і хто його «володіє».

• Перевірте фактичні імена NIC і стан (ip link).
• Перевірте, чи systemd-networkd увімкнено і працює.
• Шукайте NetworkManager, залишки ifupdown або конфіг мосту контейнерів, які заступаються.
• Переконайтеся, що /etc/systemd/network/*.network відповідає правильному інтерфейсу (по імені або MAC).

Друге: чи лінк піднятий і чи застосовується DHCP/статична адресація?

Якщо NIC не має carrier або DHCP ніколи не завершується, ви витратите години на переслідування маршрутів і DNS.

• Підтвердьте carrier і погоджені швидкість/дуплекс (ethtool).
• Перевірте networkctl status на предмет «configured» vs «configuring» vs «failed».
• Читайте журнал systemd-networkd на предмет явних помилок DHCP і таймаутів.

Третє: маршрутизація і DNS, у такому порядку

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

• Перевірте маршрут за замовчуванням і вибраний вихідний IP (ip route, ip route get).
• Перевірте шлях резолвера (resolvectl status і фактичну символічну лінку /etc/resolv.conf).
• Тільки після цього тестуйте зовнішню мережу й розв’язання імен.

Оперативна порада: Коли ви на консолі о 3:00, вам потрібен один наратив: «Лінк хороший → адреса присутня → маршрут є → DNS коректний.» Все інше — емоції.

Цікаві факти та історичний контекст (щоб не повторювати помилки)

1. Імена інтерфейсів predictable не завжди були за замовчуванням. Старі Linux-системи використовували eth0/eth1; сучасне іменування на основі udev намагається бути стабільним при переміщенні слотів, але зміни в прошивці/PCI можуть все ще перейменувати інтерфейси.
2. Debian історично використовував ifupdown. Багато років /etc/network/interfaces керував мережею. Багато «містичних» збоїв — просто залишкова логіка з тієї епохи.
3. systemd-networkd навмисно мінімалістичний. Він призначений для серверів і контейнерів: менше складних елементів, декларативна конфігурація, менше desktop-магії.
4. systemd-resolved змінив значення «налаштування DNS». Багато хто досі редагує /etc/resolv.conf вручну, а потім дивуються, чому він перезаписується або вказує на stub-резолвер.
5. DHCP — це не лише «отримати IP». Лізи містять маршрути, MTU, DNS, NTP і можуть залежати від client identifier та DUID — деталі, які виринають після перезавантажень або перевстановлення.
6. wait-online — це політика, а не вимога. systemd-networkd-wait-online може завадити запуску сервісів до того, як мережа стане придатною, але також може блокувати завантаження, якщо його неправильно використати.
7. Netplan популяризував декларативну конфігурацію в інших дистрибутивах. Debian цього не вимагає; деякі адміністратори копіюють моделі з інших дистрибутивів і в результаті нічого не конфігурують.
8. Carrier не гарантує зв’язності. Лінк може бути «up», але VLAN-теги неправильні, свічпорт у невірному VLAN або режим bonding не відповідає конфігурації свічу.

Практичні завдання: команди, очікувані результати та рішення

Це реальні завдання, які ви можете виконати на системі Debian 13. Для кожного: команда, на що звертати увагу і яке рішення приймати далі.

Завдання 1 — Підтвердити, які сервіси реально працюють

cr0x@server:~$ systemctl status systemd-networkd --no-pager
● systemd-networkd.service - Network Configuration
     Loaded: loaded (/lib/systemd/system/systemd-networkd.service; enabled; preset: enabled)
     Active: active (running) since Sun 2025-12-28 01:07:14 UTC; 2min 11s ago
       Docs: man:systemd-networkd.service(8)

Значення: Якщо це не «active (running)», припиніть гадати. Якщо він вимкнений, під час завантаження нічого не буде конфігуровано.

Рішення: Якщо inactive/failed — переходьте до журналу (Завдання 6) і валідації конфігурації (Завдання 8). Якщо працює — продовжуйте.

Завдання 2 — Перевірити конфліктуючі менеджери мережі

cr0x@server:~$ systemctl is-enabled NetworkManager 2>/dev/null; systemctl is-active NetworkManager 2>/dev/null
enabled
active

Значення: Якщо NetworkManager активний на сервері, який ви мали намір керувати через networkd, ви в зоні «два капітани за одним кораблем».

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

Завдання 3 — Визначити імена інтерфейсів, що існують зараз

cr0x@server:~$ ip -br link
lo               UNKNOWN        00:00:00:00:00:00 <LOOPBACK,UP,LOWER_UP>
enp6s0           DOWN           3c:fd:fe:aa:bb:cc <BROADCAST,MULTICAST>
enp7s0           UP             3c:fd:fe:dd:ee:ff <BROADCAST,MULTICAST,UP,LOWER_UP>

Значення: Тепер ви знаєте, які імена можна співставляти у файлах .network. Також зверніть увагу, який інтерфейс має LOWER_UP (carrier).

Рішення: Якщо ваша конфігурація посилається на eth0, але на системі є enp7s0, це ваша помилка. Виправити співставлення (Завдання 9).

Завдання 4 — Запитайте у networkd, що він думає про стан

cr0x@server:~$ networkctl status enp7s0 --no-pager
● 2: enp7s0
             Link File: /usr/lib/systemd/network/99-default.link
          Network File: /etc/systemd/network/10-lan.network
                  Type: ether
                 State: routable (configured)
          Online state: online
                Address: 192.0.2.10/24
                         fe80::3efd:feff:fedd:eeff/64
                Gateway: 192.0.2.1
                    DNS: 192.0.2.53

Значення: «routable (configured)» — це бажаний стан. «configuring» означає, що DHCP або погодження лінку не завершено. «failed» — конфіг не застосовано або нижчий шар не пройшов.

Рішення: Якщо не configured — йдіть до журналів DHCP і діагностики лінку (Завдання 5–7).

Завдання 5 — Перевірити фізичний лінк і погодження

cr0x@server:~$ ethtool enp7s0 | sed -n '1,25p'
Settings for enp7s0:
	Supported ports: [ TP ]
	Supported link modes:   1000baseT/Full
	Supported pause frame use: No
	Supports auto-negotiation: Yes
	Advertised link modes:  1000baseT/Full
	Advertised auto-negotiation: Yes
	Speed: 1000Mb/s
	Duplex: Full
	Auto-negotiation: on
	Link detected: yes

Значення: Якщо Link detected: no, припиніть звинувачувати DHCP. У вас проблема з кабелем/свічпортом/VLAN/драйвером. Якщо швидкість несподівано 10Mb/s — можуть бути проблеми з кабелем, що викликають переривчасті таймаути DHCP.

Рішення: Спочатку виправте L1/L2. Якщо лінк добрий — переходьте до DHCP/адрес.

Завдання 6 — Прочитати логи networkd з цього завантаження (істина, а не відчуття)

cr0x@server:~$ journalctl -u systemd-networkd -b --no-pager -n 80
Dec 28 01:07:15 server systemd-networkd[412]: enp7s0: DHCPv4 client: started
Dec 28 01:07:18 server systemd-networkd[412]: enp7s0: DHCPv4 address 192.0.2.10/24, gateway 192.0.2.1 acquired
Dec 28 01:07:18 server systemd-networkd[412]: enp7s0: Gained carrier

Значення: Ви шукаєте явні помилки: «no carrier», «DHCPv4 lease lost», «could not set address», «link is not managed».

Рішення: Якщо бачите «link is not managed» — ваше match неспівпадає (Завдання 9). Якщо DHCP таймаутиться — переходьте до Завдань 7 і 11.

Завдання 7 — Перевірити стан DHCP-клієнта і деталі лізи

cr0x@server:~$ networkctl status enp7s0 --no-pager | sed -n '1,120p'
● 2: enp7s0
                 State: configuring (configuring)
          Online state: unknown
                Address: fe80::3efd:feff:fedd:eeff/64

Значення: Тільки link-local IPv6 зазвичай означає, що IPv4 DHCP не спрацював і статичної IPv4 немає.

Рішення: Якщо затримка в конфігуруванні — захопіть трафік DHCP (Завдання 11) і перевірте фаєрвол/мост/віртульні VLAN.

Завдання 8 — Перевірити, що файли конфігурації networkd існують і коректні

cr0x@server:~$ ls -l /etc/systemd/network
total 8
-rw-r--r-- 1 root root 210 Dec 27 22:10 10-lan.network
-rw-r--r-- 1 root root 120 Dec 27 22:10 10-lan.link

Значення: Якщо цей каталог порожній, networkd зробить дуже мало, хіба що ви покладаєтесь на дефолтну поведінку DHCP (а це не план; це відчуття).

Рішення: Відкрийте файли і підтвердьте критерії match і налаштування DHCP/статичні (Завдання 9).

Завдання 9 — Підтвердити, що правила співставлення дійсно відповідають вашому NIC

cr0x@server:~$ sed -n '1,120p' /etc/systemd/network/10-lan.network
[Match]
MACAddress=3c:fd:fe:dd:ee:ff

[Network]
DHCP=yes
IPv6AcceptRA=yes

Значення: Співставлення по MAC стійке до перейменувань інтерфейсу. Співставлення по Name=enp7s0 годиться, поки BIOS/PCI не змінить нумерацію. Оберіть свій компроміс.

Рішення: Якщо ваш match не співпадає — networkd ігноруватиме файл. Виправте match, потім перезапустіть networkd (Завдання 10).

Завдання 10 — Перезапустити networkd і спостерігати, як воно застосовує конфіг живцем

cr0x@server:~$ systemctl restart systemd-networkd
cr0x@server:~$ journalctl -u systemd-networkd -n 30 --no-pager
Dec 28 01:10:02 server systemd-networkd[615]: enp7s0: Link UP
Dec 28 01:10:02 server systemd-networkd[615]: enp7s0: DHCPv4 client: started
Dec 28 01:10:05 server systemd-networkd[615]: enp7s0: DHCPv4 address 192.0.2.10/24, gateway 192.0.2.1 acquired

Значення: Якщо перезапуск виправляє проблему, швидше за все це гонка при завантаженні (затримка ініціалізації прошивки, готовності драйвера або неправильне використання wait-online), а не постійна помилка конфігурації.

Рішення: Якщо проблема виникає тільки при завантаженні — виправляйте порядок за допомогою політики wait-online та стабільності драйверів/прошивки (див. розділ чеклісту).

Завдання 11 — Захопити DHCP-пакети, щоб довести, чи існують відповіді

cr0x@server:~$ timeout 15 tcpdump -ni enp7s0 -vvv 'udp port 67 or udp port 68'
tcpdump: listening on enp7s0, link-type EN10MB (Ethernet), snapshot length 262144 bytes
IP (tos 0x0, ttl 64, id 42121, offset 0, flags [none], proto UDP (17), length 328)
    0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 3c:fd:fe:dd:ee:ff, length 300, xid 0x6a2c9f10, Flags [none]
IP (tos 0x0, ttl 64, id 1242, offset 0, flags [none], proto UDP (17), length 342)
    192.0.2.1.67 > 255.255.255.255.68: BOOTP/DHCP, Reply, xid 0x6a2c9f10, yiaddr 192.0.2.10, length 314

Значення: Якщо бачите запити, але немає відповідей — проблема зовнішня (VLAN свіч, DHCP relay, фаєрвол, port security). Якщо бачите відповіді, але networkd досі не конфігурує — проблема локальна (фаєрвол, конфлікт менеджера або розбір лізи).

Рішення: Немає відповідей: ескалюйте до мережевої команди з доказами. Відповіді є: фокусуйтеся на конфігурації хоста і логах.

Завдання 12 — Перевірити адреси і маршрути, як їх бачить ядро

cr0x@server:~$ ip -4 addr show dev enp7s0
2: enp7s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    inet 192.0.2.10/24 brd 192.0.2.255 scope global dynamic enp7s0
       valid_lft 86368sec preferred_lft 86368sec
cr0x@server:~$ ip route
default via 192.0.2.1 dev enp7s0 proto dhcp src 192.0.2.10 metric 1024
192.0.2.0/24 dev enp7s0 proto kernel scope link src 192.0.2.10

Значення: Відсутність маршруту за замовчуванням означає «тільки локальна LAN». Невірний маршрут за замовчуванням означає «мережеве рулетування». Метрики важливі при наявності кількох uplink-ів.

Рішення: Якщо маршрут за замовчуванням відсутній — виправте опції DHCP або встановіть статичний gateway у файлі .network. Якщо неправильний — перевірте кілька DHCP-клієнтів або декілька конфігурацій, які застосовуються одночасно.

Завдання 13 — Підтвердити шлях резолвера (і перестати редагувати не ту ділянку)

cr0x@server:~$ ls -l /etc/resolv.conf
lrwxrwxrwx 1 root root 39 Dec 27 22:10 /etc/resolv.conf -> /run/systemd/resolve/stub-resolv.conf
cr0x@server:~$ resolvectl status | sed -n '1,120p'
Global
       Protocols: -LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
 resolv.conf mode: stub
Current DNS Server: 192.0.2.53
       DNS Servers: 192.0.2.53

Значення: Якщо resolvectl не показує DNS-серверів — у вас є маршрути, але немає розв’язування імен. Якщо /etc/resolv.conf вказує на старий статичний файл, в той час як systemd-resolved включений, ви, ймовірно, дебагуєте не той шлях.

Рішення: Вирішіть, чи хочете ви використовувати resolved. Якщо так — передайте йому DNS через networkd. Якщо ні — відключіть його і керуйте /etc/resolv.conf вручну.

Завдання 14 — Підтвердити, що означає «online» у вашій системі (wait-online)

cr0x@server:~$ systemctl status systemd-networkd-wait-online --no-pager
● systemd-networkd-wait-online.service - Wait for Network to be Configured
     Loaded: loaded (/lib/systemd/system/systemd-networkd-wait-online.service; enabled; preset: enabled)
     Active: active (exited) since Sun 2025-12-28 01:07:19 UTC; 3min ago

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

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

Завдання 15 — Перевірити, чи не бракує драйвера/прошивки після оновлень

cr0x@server:~$ dmesg -T | grep -Ei 'firmware|enp7s0|link up|link down|renamed' | tail -n 30
[Sun Dec 28 01:07:13 2025] r8169 0000:07:00.0 enp7s0: renamed from eth0
[Sun Dec 28 01:07:14 2025] r8169 0000:07:00.0 enp7s0: Link is Up - 1Gbps/Full - flow control off

Значення: Невдалі завантаження прошивки, скидання драйвера і перейменування видно тут рано. Рядок про перейменування — попередження, що співставлення по імені може бути крихким.

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

Завдання 16 — Перевірити правила фаєрволу, які ламають DHCP або ARP (так, це реально)

cr0x@server:~$ nft list ruleset | sed -n '1,120p'
table inet filter {
	chain input {
		type filter hook input priority filter; policy drop;
		ct state established,related accept
		iif "lo" accept
		tcp dport 22 accept
	}
}

Значення: Політика input із дефолтним drop без явного дозволу DHCP може зламати DHCP (UDP 67/68) в залежності від структури правил і хуків. Також стежте за дивностями у raw таблиці і фільтрацією мостів.

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

Жарт #1: DHCP — як консьєрж у готелі: корисний, але якщо ви приходите о 2:00 і стійка закрита, доведеться спати в холі.

Три міні-історії з корпоративного життя (як це ламається на практиці)

Інцидент №1: Аутейдж через хибне припущення

Оточення було максимально простим навмисно: невеликий парк серверів Debian за top-of-rack свічем, DHCP-резервації за MAC, і systemd-networkd, що все керує. Команда мала одне міцне припущення: «імена інтерфейсів стабільні на серверах». Вони вказували Name=enp3s0 скрізь.

Потім партія хостів отримала оновлення BIOS. Воно змінило PCI-перелік трохи так, що NIC перемістився з однієї ідентичності слота на іншу. Ядро не «зламалося»; воно зробило те, що завжди робить. Ім’я інтерфейсу змінилося.

Після перезавантаження networkd стартував чисто, прочитав .network файл і застосував його до рівно нуля інтерфейсів. Ніяких помилок, які кричали б у консоль. Ніякого DHCP. Ніяких маршрутів. Моніторинг показував хости недоступними; remote hands наполягали, що індикатори лінку світяться нормально.

Виправлення технічно тривіальне: співставлення по MAC у [Match], і за бажанням додати .link, щоб закріпити стабільне ім’я, якщо команда цього хоче. Але справжнє виправлення — процедурне: припинити покладатися на «достатньо стабільне». Якщо правило match може застаріти без зміни конфігурації, воно застаріє — зазвичай під час вікон обслуговування, коли всі втомлені.

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

Інша організація гналася за часом завантаження. Вони хотіли, щоб прикладні сервіси піднімалися швидше після перезавантаження, тому прибрали все, що виглядало як очікування. systemd-networkd-wait-online був відключений по всій інфраструктурі, і деякі юніти переписали, щоб стартувати раніше.

Завантаження дійсно прискорилося. Так само прискорилися і відмови.

Декілька сервісів припускали, що мережа вже маршрутизована, коли вони стартували. На холодних рестартах DHCP іноді займав кілька секунд довше через те, що свічпорт використовував функцію безпеки, яка затримувала форвардинг, поки не верифікував MAC. Сервіси стартували, не змогли підключитися до зовнішніх залежностей і пішли в цикли помилок. Мережа піднімалася за кілька моментів — але занадто пізно для додатку, який уже вирішив, що світ зламався.

Постмортем був болючим, бо все виглядало гаразд, коли інженери заходили: мережа була піднята, DHCP видано, маршрути в порядку. Помилка полягала в часуванні. «Оптимізація» прибрала точку синхронізації, не замінивши її нічим коректним.

Зрештою вони знову ввели gating, але вибірково: тільки для хостів і сервісів, які справді потребують мережі при старті, і з більш тісним охопленням (очікувати конкретний інтерфейс, а не «будь-який лінк»). Штраф у часі завантаження був малим. Поліпшення надійності — значним.

Інцидент №3: Нудна практика, що врятувала день

Це мій улюблений приклад, бо він навмисно непримітний. Команда працювала з systemd-networkd за двома правилами: співставлення по MAC, і мати мінімальну «відому хорошу» статичну конфігурацію, готову розгорнути автоматично для кожної стойки.

Одного ранку, після планового вимкнення живлення, низка свічів повернулась з частковою конфігурацією. DHCP relay був зламаний в одному VLAN. Сервери перезавантажилися, лінк піднявся, DHCP-запити пішли і нічого не повернулося. Мережа не була «впала»; вона просто відмовляла видавати адреси на сегменті.

On-call не марнував часу. Він відкрив консоль, запустив 15-секундний tcpdump на DHCP-портах, не побачив відповідей і застосував попередньо визначений статичний fallback (адреса, gateway, DNS). Це зробило хости досяжними миттєво, що дозволило команді мережі полагодити relay без одночасної боротьби з «не можу дістатися до коробки».

Ключ не в геройстві. Ключ — мати протестований аварійний план. Коли ви вже знаєте, що «добре» виглядає, ви перестаєте трактувати відмови як загадку.

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

1) «Інтерфейс UP, але немає IPv4-адреси»

Симптом: ip link показує UP,LOWER_UP, але ip -4 addr порожній.

Корінна причина: DHCP не працює, відповіді DHCP блокуються, або інтерфейс не керується networkd через невірний match.

Виправлення: Підтвердьте networkctl status і журнал networkd. Запустіть DHCP tcpdump. Виправте [Match] правила або дозвольте DHCP через фаєрвол.

2) «networkctl показує ‘link is not managed’»

Симптом: networkctl status enp7s0 каже, що не керується.

Корінна причина: Відсутній відповідний .network файл, або інший менеджер взяв контроль.

Виправлення: Додайте .network файл з коректним match; вимкніть конфліктуючий менеджер для цього інтерфейсу.

3) «DHCP успішний, але немає маршруту за замовчуванням»

Симптом: У вас є адреса, але ip route не містить default via.

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

Виправлення: Встановіть Gateway= явно для статичних налаштувань, або виправте DHCP-скоуп. Якщо multi-homed — визначте метрики і політичну маршрутизацію свідомо.

4) «Можу пінгувати шлюз, не можу розв’язати імена»

Симптом: ping 192.0.2.1 працює, ping deb.debian.org не працює.

Корінна причина: DNS не налаштовано, stub systemd-resolved неправильно під’єднано, або застарілий /etc/resolv.conf.

Виправлення: Використайте resolvectl status. Вирішіть, використовувати resolved чи ні. Переконайтеся, що DNS задано в networkd або статичний resolv.conf належним інструментом.

5) «Мережа працює після ручного перезапуску, але не при завантаженні»

Симптом: systemctl restart systemd-networkd піднімає мережу; перезавантаження — ні.

Корінна причина: Гонка при завантаженні: драйвер не готовий, лінк піднімається пізніше, VLAN-інтерфейс створюється після спроби networkd застосувати конфіг, або wait-online невірно вказано.

Виправлення: Використайте детерміновані match-правила; розгляньте додавання RequiredForOnline=, налаштуйте wait-online для потрібного інтерфейсу, і перевірте драйвер/прошивку в dmesg.

6) «SSH недоступний після перезавантаження, локальна консоль OK»

Симптом: Хост працює, але віддалений доступ не працює, поки хтось не «помацає» мережу локально.

Корінна причина: Фаєрвол завантажується до появи адрес/маршрутів, або політика drop блокує DHCP/ARP/neighbor discovery у ранньому етапі завантаження.

Виправлення: Зробіть правила фаєрволу, які явно дозволяють необхідний трафік для ініціалізації, або активуйте фаєрвол поетапно після конфігурації мережі (обережно, з чіткими залежностями).

Жарт #2: Фраза «працює на моїй машині» менше заспокоює, коли ваша машина — сервер у зачиненому стійці, до якого вам не дозволено дістатися.

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

Чекліст A — Негайна тріажа на консолі (10 хвилин, без ідеології)

1. Перелік інтерфейсів і carrier: ip -br link. Якщо немає LOWER_UP — спочатку виправте фізичний рівень/свіч/VLAN/драйвер.
2. Підтвердити власника: systemctl is-active systemd-networkd і перевірте конфлікти NetworkManager/ifupdown.
3. Запитайте networkd: networkctl status. Знайдіть «not managed», «configuring» або «failed».
4. Читання логів: journalctl -u systemd-networkd -b. Шукайте таймаути DHCP, помилки match, флапи лінку.
5. Перевірте стан ядра: ip -4 addr і ip route. Якщо немає маршруту за замовчуванням — виправте це перед DNS.
6. Перевірка DNS: resolvectl status і ls -l /etc/resolv.conf. Переконайтеся, хто «володіє» DNS.
7. Якщо DHCP завис: запустіть 15-секундний tcpdump на DHCP. Доведіть, чи є відповіді.

Чекліст B — Зробіть вашу networkd конфігурацію стійкою

1. Співставлення по MAC (зазвичай): В [Match] віддавайте перевагу MACAddress= для фізичних NIC. Іменування підходить для віртуальних інтерфейсів, якими ви повністю керуєте.
2. По одному інтерфейсу на файл: Уникайте «масових» match-ів, які випадково конфігурують management і storage NIC однаково.
3. Будьте явними щодо DHCP vs статичного: Не залишайте «дефолтну поведінку DHCP» випадковістю. Якщо хочете DHCP — вкажіть це. Якщо статичну — опишіть повністю (Address, Gateway, DNS).
4. Визначте наміри маршрутизації на multi-homed хостах: Встановіть метрики, правила політичної маршрутизації і уникайте двох маршрутів за замовчуванням, якщо ви цього дійсно не маєте на увазі.
5. Вирішіть модель DNS: Або працюєте з systemd-resolved і інтегруєте його, або відключаєте його й керуєте /etc/resolv.conf. Мішана власність породжує Heisenbug-и.

Чекліст C — Порядок завантаження без самозробленого болю

1. Використовуйте wait-online лише за потреби. Якщо нічого не потребує мережі під час старту — не блокуйте завантаження заради відчуття безпеки.
2. Якщо потрібен wait-online — звузьте область. Очікування «будь-якого інтерфейсу» на хості з опціональними лінками породжує підвішування завантаження.
3. Припиніть писати сервіси, що припускають миттєву готовність мережі. Додайте повторні спроби/бекоф. Сервіси повинні переживати повільну DHCP-лізу без істериці.
4. Слідкуйте за регресіями драйверів/прошивки. Якщо мережа ламається після зміни ядра/прошивки — перевірте це в dmesg і не бійтеся відкотити, поки не протестуєте.

Цитата про надійність (одна, і лише одна)

Надія — це не стратегія. — James Cameron

Це не «ops-теорія». Це різниця між читанням логів і перезавантаженням, поки «запрацює».

FAQ

1) Чи варто використовувати systemd-networkd на Debian-серверах?

Якщо ви цінуєте передбачувану поведінку та просту конфігурацію — так. Воно відмінно підходить для серверів, VM і всього, що ви хочете конфігурувати декларативно. Якщо вам потрібен інтерактивний Wi‑Fi або інтеграція з GUI — це територія NetworkManager.

2) Після перезавантаження змінилося ім’я інтерфейсу. Як запобігти поломці конфігурації?

Не співставляйте по імені для фізичних NIC. Співставляйте по MACAddress= в секції [Match]. Якщо вам дійсно потрібні стабільні імена — використайте .link файл, щоб призначити ім’я за MAC.

3) DHCP іноді працює, іноді ні. З чого почати перевірку?

Перевірте carrier і поведінку свічу. Запустіть ethtool і захопіть DHCP-пакети з tcpdump. Якщо ваш хост надсилає запити, але не бачить відповідей — це майже ніколи не «Linux-проблема».

4) Чому перезапуск systemd-networkd це виправляє?

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

5) Чи слід увімкнути systemd-networkd-wait-online?

Тільки якщо у вас є сервіси, які дійсно потребують налаштованої мережі до старту. Якщо ви його вмикаєте — налаштуйте юніти чекати саме те, що їм потрібно — бажано конкретний інтерфейс і стан, а не «мережу загалом».

6) DNS не працює, а маршрути в порядку. Куди дивитися?

Почніть з resolvectl status і ls -l /etc/resolv.conf. Підтвердьте, чи ви використовуєте systemd-resolved (stub mode) або статичний resolv.conf. Виправте власність, потім сервери імен.

7) Чи може nftables ламати DHCP?

Так. Особливо з політиками з дефолтним drop і неповними дозволами. DHCP використовує UDP 67/68 і широковещання; деякі надто жорсткі набори правил блокують його. Доведіть це tcpdump і відкоригуйте правила.

8) Як налагодити відсутній маршрут за замовчуванням на хості з кількома NIC?

Використайте ip route і ip route get 1.1.1.1, щоб побачити обраний шлях і вихідну адресу. Потім визначте метрики або політичну маршрутизацію, щоб ядро перестало «вибирати» і почало виконувати ваші правила.

9) Чи достатньо «link up», щоб вважати мережу здоровою?

Ні. «Link up» означає лише електричний/оптичний carrier. Вам все ще потрібні правильні VLAN-теги, адресація, маршрути і робочий DNS. «LOWER_UP» — це перший крок, а не фініш.

Висновок: наступні кроки, за які ви подякуєте собі

Коли мережа Debian 13 не піднімається після перезавантаження, найшвидший шлях — дисципліна: перевірте лінк, перевірте адресацію, перевірте маршрути, перевірте DNS — у цьому порядку. Читайте журнал networkd, ніби він вам винен гроші. Не гадіть.

Наступні кроки, які окупляться:

• Оновіть ваші .network файли: співставляйте по MAC (або іншій стабільній властивості), а не по імені інтерфейсу, якщо ви не контролюєте іменування.
• Вирішіть, чи ви — systemd-resolved shop, і налаштуйте DNS відповідно. Без гібридів.
• Аудит конфліктів: лише один мережевий менеджер повинен налаштовувати даний інтерфейс.
• Якщо гонки при завантаженні реальні у вашому середовищі — використовуйте wait-online селективно і проектуйте сервіси з повторними спробами замість магічного порядку.
• Майте протестований статичний аварійний план для доступу до management. «Ми не можемо дістатися до коробки» — не весела проблема, коли коробка недосяжна.