Debian 13: нова назва інтерфейсу зламала мережу — стабільні імена, що витримують перезавантаження (випадок №7)

January 7, 2026 • February 3, 2026 • Читання: 7 хв • Views: 4

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

02:13. Ви перезавантажуєте сервер на Debian 13 після планового оновлення ядра. Він повертається — так би мовити. SSH недоступний, моніторинг показує помилки, а на консолі світиться індикатор лінку на мережевій картці, яка, виявляється, «не існує».

Немає нічого більш принизливого, ніж втратити хост через те, що мережевій карті захотілося нового прізвиська. Цей випадок про те, як повернути хост у робочий стан, а потім зробити так, щоб таке ніколи не повторилося — навіть після перезавантажень, оновлень ядра, заміни NIC, перестановки PCIe і поганої пам’яті вашого майбутнього «я».

Що насправді зламалося: змінилась назва, а не мережа

Коли «мережа перестала працювати» після перезавантаження на Debian 13, найпоширеніша реальність — банальна: NIC усе ще працює, лінк присутній, драйвер завантажений, DHCP працює… але ваша конфігурація вказує на eth0, а ядро тепер називає інтерфейс enp2s0 (або enp5s0f1, або ens192, або щось таке ж непомпезне).

Ця невідповідність достатня, щоб:

Перешкодити ifupdown підняти інтерфейс через «пристрій не знайдено».
Порушити статичну IP-конфігурацію в /etc/network/interfaces.
Пошкодити NetworkManager-з’єднання, прив’язані до імені пристрою.
Зламати bonds і bridges, які посилаються на членські інтерфейси за іменем.
Зламати підінтерфейси VLAN (наприклад, bond0.123 або enp2s0.10).
Заплутати моніторинг і правила фаєрвола, якщо вони прив’язані до імен інтерфейсів.

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

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

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

Перше: чи бачить ядро NIC і чи є лінк?

Перевірте: ip -br link та dmesg на предмет приєднання драйвера.
Якщо NIC відсутній повністю — ви налагоджуєте апарат/драйвер/прошивку, а не іменування.
Якщо він присутній але не налаштований — ймовірно, несумісність імен.

Друге: чи змінилося ім’я інтерфейсу і чи конфіг очікує старе?

Порівняйте: ip -br addr проти /etc/network/interfaces або профілів NetworkManager.
Шукайте в логах: «Cannot find device» або «unknown interface».

Третє: що визначає ім’я (systemd/udev, BIOS/прошивка, гіпервізор)?

Перевірте: udevadm test-builtin net_id та networkctl status.
Вирішіть, чи закріпити через .link, орієнтуватися на MAC, на PCI-путь, чи відключити predictable naming.

Якщо дотримуватись цього порядку, то ви уникнете класичної помилки: годину «чинити DHCP», коли насправді ім’я NIC просто зрушилося.

Цікавинки та історія: чому Linux так називає NIC

eth0 теж не був стабільним. Старі назви залежали від порядку виявлення; додавання NIC могло поміняти eth0/eth1 між перезавантаженнями.
Predictable names стали поширеними приблизно з systemd v197. Мета: стабільні імена, засновані на топології апаратного забезпечення, а не на порядку виявлення.
Звичні шаблони фактично кодують розташування. enp2s0 приблизно означає «Ethernet, шина PCI 2, слот 0». Це корисно — поки прошивка не змінить нумерацію.
Є кілька схем іменування. systemd може використовувати індекс на платі, індекс слота, шлях, MAC або суміш залежно від інформації, яку надає платформа.
Гіпервізори люблять втручатися. У віртуальних машинах ваша «апаратна топологія» може змінитися після міграції, зміни віртуальної NIC або іншого представлення шини.
udev-правила раніше були основним підходом. Багато старих гайдів показують кастомні udev-правила; systemd .link файли зараз чистіший і підтримуваний механізм.
MAC-адреси стабільні, доки не стануть нестійкими. Деякі віртуальні платформи генерують нові MAC при клонуванні, або адміністратори «швидко змінюють» MAC і забувають про це.
Перейменування може відбутися через зміни в initramfs. Якщо initramfs містить інші правила або драйвери, рішення про іменування може прийматися раніше або інакше.

Одна парафразована думка від голосу надійності, яку варто приклеїти на липку нотатку: paraphrased idea — John Allspaw, про експлуатаційну надійність і навчання на інцидентах.

Практичні завдання: команди, що означає вивід і яке рішення ви приймаєте

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

Завдання 1: швидко перелічити інтерфейси (і помітити перейменування)

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

Що це означає: У вас є enp2s0 та enp3s0, а не eth0. Один — UP, інший — DOWN.

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

Завдання 2: підтвердити адреси і чи застосовано DHCP/статичний IP

cr0x@server:~$ ip -br addr
lo               UNKNOWN        127.0.0.1/8 ::1/128
enp2s0           DOWN
enp3s0           UP             192.0.2.10/24 fe80::3efd:feff:fedd:eeff/64

Що це означає: enp3s0 має IPv4-адресу; enp2s0 — ні. Сервіс, імовірно, належить на enp3s0.

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

Завдання 3: перевірити стан лінку і швидкість (фізична перевірка)

cr0x@server:~$ ethtool enp3s0 | sed -n '1,20p'
Settings for enp3s0:
	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

Що це означає: Кабель і порт комутатора в порядку. Це не «мережа впала».

Рішення: Припиніть звинувачувати комутатор. Переходьте вгору по стеку: іменування/конфіг/керування сервісами.

Завдання 4: подивитись, як systemd бачить інтерфейс і чому

cr0x@server:~$ networkctl status enp3s0
● 2: enp3s0
                 Link File: /usr/lib/systemd/network/99-default.link
              Network File: n/a
                      Type: ether
                     State: routable (configured)
                      Path: pci-0000:03:00.0
                    Driver: e1000e
                HW Address: 3c:fd:fe:dd:ee:ff
                     Address: 192.0.2.10/24
                            fe80::3efd:feff:fedd:eeff/64

Що це означає: systemd застосував стандартні правила і бачить PCI-путь. Чудово: ви можете співпасти за цим.

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

Завдання 5: визначити кандидатів на «predictable name», які udev генерує

cr0x@server:~$ udevadm test-builtin net_id /sys/class/net/enp3s0 2>/dev/null | grep ID_NET_NAME
ID_NET_NAME_MAC=enx3cfdfeddeeff
ID_NET_NAME_PATH=enp3s0
ID_NET_NAME_SLOT=ens3

Що це означає: Система може назвати NIC за MAC (enx...), шляхом (enp3s0) або по слоту (ens3) залежно від схеми та правил.

Рішення: Оберіть вашу опору: на фізичних серверах MAC-орієнтація дуже стабільна, але на клонованих VM — менш стабільна. Path/slot стабільні, коли апаратна топологія стабільна.

Завдання 6: знайти, що очікує ваша конфігурація (ifupdown)

cr0x@server:~$ grep -RIn 'auto\|allow-hotplug\|iface' /etc/network/interfaces /etc/network/interfaces.d
/etc/network/interfaces:3:auto lo
/etc/network/interfaces:5:auto eth0
/etc/network/interfaces:6:iface eth0 inet static

Що це означає: У вашій конфігурації жорстко вказано eth0. Debian 13 використовує predictable naming, тож eth0 не існує.

Рішення: Не просто перейменовуйте eth0 в одному файлі, якщо є bonds/bridges/правила фаєрвола також. Або закріпіть інтерфейс назад на очікуване ім’я, або оновіть усі споживачі цілеспрямовано.

Завдання 7: перевірити логи сервісу для чесного повідомлення про помилку

cr0x@server:~$ journalctl -u networking -b --no-pager | tail -n 30
ifup: unknown interface eth0
ifup: failed to bring up eth0
networking.service: Failed with result 'exit-code'.

Що це означає: Сервіс падає тому, що ім’я не існує. Не маршрутизація. Не DNS. Не DHCP.

Рішення: Виправте іменування або конфіг. Перезапуск сервісу 15 разів не створить eth0.

Завдання 8: перевірити, які драйвери прив’язані і чи перейменовувалось під час завантаження

cr0x@server:~$ dmesg -T | egrep -i 'renamed|link up|eth|enp' | tail -n 25
[Mon Dec 30 02:13:22 2025] e1000e 0000:03:00.0 enp3s0: renamed from eth0
[Mon Dec 30 02:13:22 2025] e1000e 0000:03:00.0 enp3s0: Link is Up 1000 Mbps Full Duplex

Що це означає: Ядро спочатку назвало його eth0, потім udev/systemd перейменував у enp3s0.

Рішення: Якщо хочете зберегти eth0, зробіть це явно (і послідовно). Інакше мігруйте конфіги на predictable name.

Завдання 9: підтвердити політику імен за замовчуванням у cmdline ядра

cr0x@server:~$ cat /proc/cmdline
BOOT_IMAGE=/vmlinuz-6.12.0 root=/dev/mapper/vg0-root ro quiet

Що це означає: Ви не перевизначаєте іменування через net.ifnames=0 або biosdevname=0.

Рішення: Якщо вам потрібен грубий інструмент (вимкнути predictable naming), це місце, де це відобразиться після налаштування.

Завдання 10: показати MAC, розташування PCI і відображення інтерфейсів одним махом

cr0x@server:~$ for i in /sys/class/net/en*; do n=$(basename "$i"); printf "%s " "$n"; cat "$i/address"; readlink -f "$i/device"; done
enp2s0 3c:fd:fe:aa:bb:cc
/sys/devices/pci0000:00/0000:00:1c.0/0000:02:00.0
enp3s0 3c:fd:fe:dd:ee:ff
/sys/devices/pci0000:00/0000:00:1c.4/0000:03:00.0

Що це означає: Ви можете співпасти NIC за MAC (address) або за device path (.../0000:03:00.0).

Рішення: Оберіть критерій співпадіння для вашого правила стабільного іменування. На фізичних серверах PCI-путь зазвичай стабільний. У VM MAC може бути більш стабільним, ніж слот PCI (залежить від гіпервізора).

Завдання 11: виявити, чи NetworkManager керує пристроями та профілями

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

Що це означає: NetworkManager не працює; ймовірно, керування — ifupdown або systemd-networkd.

Рішення: Не виправляйте не той менеджер. Якщо NetworkManager активний — перегляньте профілі; якщо ні — зосередьтесь на ifupdown або systemd-networkd.

Завдання 12: якщо NetworkManager активний, перевірити, чи профілі прив’язані до імені пристрою

cr0x@server:~$ nmcli -f NAME,UUID,DEVICE con show
Wired connection 1  2a0b1c1d-8a9b-4c1f-9a62-2c4f2f0b7e1a  --

Що це означає: Профіль існує, але не прикріплений до жодного пристрою (DEVICE — --).

Рішення: Або перев’яжіть профіль до нового імені інтерфейсу, або усуньте залежність від імені, налаштувавши відповідність по MAC у профілі.

Завдання 13: якщо systemd-networkd, перевірити стан юніта і відповідність конфігів

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

Що це означає: systemd-networkd працює. Добре: ви можете співпасти в .network файлах по MAC/Path/Name і уникнути крихкого іменування.

Рішення: Вирішіть, чи виправляєте іменування (.link), чи співпадаєте в .network по стабільних властивостях (часто краще).

Завдання 14: перевірити залежності VLAN/bond/bridge (типові побічні ушкодження)

cr0x@server:~$ ip -d link show | egrep -A2 'bond|bridge|vlan'
5: bond0: <NO-CARRIER,BROADCAST,MULTICAST,MASTER,UP> mtu 1500 qdisc noqueue state DOWN mode DEFAULT group default qlen 1000
    link/ether 3c:fd:fe:dd:ee:ff brd ff:ff:ff:ff:ff:ff
7: br0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN mode DEFAULT group default qlen 1000
    link/ether 3c:fd:fe:dd:ee:ff brd ff:ff:ff:ff:ff:ff

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

Рішення: Виправте базове іменування інтерфейсу спочатку, потім перевірте створення bond/bridge. Не налагоджуйте LACP, поки не підтвердите наявність slave-ів.

Завдання 15: перевірити правила фаєрвола, що залежать від імен інтерфейсів

cr0x@server:~$ nft list ruleset | grep -n 'iifname\|oifname' | head
42:		iifname "eth0" accept
88:		oifname "eth0" masquerade

Що це означає: Ваш фаєрвол буквально чекає на eth0. Він буде блокувати трафік на enp3s0.

Рішення: Або оновіть правила під стабільне ім’я, яке ви зберігатимете, або підбирайте по адресі/підмережі/mark там, де це можливо.

Завдання 16: переконатися, що ви не створили «дві істини» через застарілі конфіги

cr0x@server:~$ ls -1 /etc/systemd/network /etc/network/interfaces.d 2>/dev/null
/etc/network/interfaces.d:
eth0.cfg

/etc/systemd/network:
10-wan.network

Що це означає: У вас можуть одночасно існувати і ifupdown, і systemd-networkd конфіги. Це рецепт для «іноді працює».

Рішення: Оберіть один мережевий стек для хосту. Видаліть або відключіть інший. Змішане керування — це не «гнучкість», це майбутнє джерело інцидентів.

Невідкладне відновлення: як повернути доступ, не загнавши себе в пастку

Коли ви упали, вам потрібні дві речі: відновити доступ і уникнути погіршення ситуації. Хитрість — застосувати тимчасове виправлення, яке можна відкотити, а потім ввести постійну зміну політики.

Крок відновлення 1: вручну підняти правильний інтерфейс

Якщо у вас є доступ до консолі (KVM, serial, консоль гіпервізора), ви часто можете відновити підключення достатньо довго, щоб розгорнути реальне виправлення.

cr0x@server:~$ ip link set enp3s0 up
cr0x@server:~$ ip addr add 192.0.2.10/24 dev enp3s0
cr0x@server:~$ ip route add default via 192.0.2.1
cr0x@server:~$ ping -c 2 192.0.2.1
PING 192.0.2.1 (192.0.2.1) 56(84) bytes of data.
64 bytes from 192.0.2.1: icmp_seq=1 ttl=64 time=0.420 ms
64 bytes from 192.0.2.1: icmp_seq=2 ttl=64 time=0.391 ms

Що це означає: Ви підтвердили L1–L3 працездатність. Тепер можна зайти віддалено (якщо SSH/фаєрвол це дозволяє).

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

Крок відновлення 2: не «ремонтуйте», перейменовуючи все хаотично

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

Жарт №1: Перейменування інтерфейсів — єдина кризова тотожність, яка може вивести дата-центр з ладу, не змінивши жодного кабелю.

Стратегії стабільного іменування, що переживають перезавантаження (оберіть своє)

Є три розумні стратегії. Дві — сучасні. Одна — спадкова «ковдра безпечності», що іноді досі правильна.

Стратегія A (рекомендована): Зберігайте predictable naming, закріпіть через systemd `.link`

Зазвичай це найкращий варіант на Debian 13. Ви зберігаєте predictable naming, але перевизначаєте його для інтерфейсів, які вам важливі (WAN/LAN/зберігання/heartbeat). Можна співпасти за MAC, за PCI-путем, за драйвером або за індексом на платі — і задати ім’я, яке контролюєте (наприклад, wan0, lan0, stor0).

Чому воно переживає перезавантаження: правило виконується при виявленні пристрою. Кожен запуск — ті самі критерії матчать ту саму назву.

Де воно підводить: якщо ваші критерії співпадіння насправді нестабільні (MAC VM змінюється, прошивка змінює шлях), воно може зламатися.

Стратегія B (також добра): Не переймайтесь іменем; матчіть у конфігах по MAC/шляху

Якщо ви використовуєте systemd-networkd, можна писати .network файли, що матчать по MAC або шляху, а потім налаштовувати IP/шлюз не турбуючись, як саме інтерфейс називається. Це вражаюче стійко.

Чому воно переживає перезавантаження: навіть якщо ім’я зміниться, матч все одно знайде правильний NIC.

Де воно підводить: інструменти й політики (фаєрвол, моніторинг) часто все ще покладаються на імена інтерфейсів. Також людям зручніше читати осмислені імена під час налагодження о 03:00.

Стратегія C (грубий інструмент): Вимкнути predictable naming і повернутися до `eth0`

Це підхід «зробити як 2012». Він може бути коректним у контрольованих середовищах, де застаріле ПЗ очікує eth0, або коли ви стандартизуєте стару автоматизацію.

Чому воно переживає перезавантаження: воно повертає традиційне нумерування ядра. Але пам’ятайте: порядок виявлення теж може змінюватися.

Де воно підводить: додавання/видалення NIC або зміна драйверів може поміняти eth0 і eth1. Передбачуваність не гарантована; просто знайоме відчуття.

Правильний шлях (здебільшого): systemd `.link` файли

Якщо хочете стабільні, осмислені імена інтерфейсів — робіть це через .link файли в /etc/systemd/network/. Вони явні, читабельні й під вашим контролем, а не тим, що апарат відчуває сьогодні.

Оберіть схему іменування, що відповідає вашій реальності

Фізичний сервер, NIC залишається в тому самому слоті: матч за PCI-путем (Path=pci-0000:03:00.0) або за MAC.
VM, які мігруються: частіше матч за MAC (якщо MAC стабільні на вашій платформі), але остерігайтесь клонування.
Мережі зберігання та HA-кластери: розгляньте імена за роллю (stor0, hb0), щоб люди перестали плутати «лівий порт» і «правий порт».

Створити link-файл, що закріплює ім’я за MAC

cr0x@server:~$ sudo tee /etc/systemd/network/10-wan.link >/dev/null <<'EOF'
[Match]
MACAddress=3c:fd:fe:dd:ee:ff

[Link]
Name=wan0
EOF

Що це означає: Будь-який NIC з цією MAC буде перейменований на wan0 рано під час завантаження.

Рішення: Використовуйте матч по MAC, коли довіряєте стабільності MAC. Для фізичних серверів зазвичай це нормально. У клонованих VM може знадобитися інший підхід.

Створити link-файл, що закріплює ім’я за PCI-путем

cr0x@server:~$ sudo tee /etc/systemd/network/10-stor.link >/dev/null <<'EOF'
[Match]
Path=pci-0000:02:00.0

[Link]
Name=stor0
EOF

Що це означає: Пристрій на цьому PCI-путі стане stor0.

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

Застосувати зміни безпечно

Перейменування інтерфейсу на робочій системі може відсікати вас, якщо ви сидите на ньому. Плануйте момент.

cr0x@server:~$ sudo udevadm control --reload
cr0x@server:~$ sudo udevadm trigger -c add -s net

Що це означає: udev перезавантажує правила і повторно тригерить мережеві пристрої. На деяких системах перейменування набуде чинності; на інших знадобиться перезавантаження для чистого переходу.

Рішення: Якщо це віддалений хост і у вас немає OOB-консолі, заплануйте maintenance reboot і зробіть усе чисто.

Перевірити нове ім’я і оновити споживачів конфігурації

cr0x@server:~$ ip -br link | grep -E 'wan0|stor0|enp|eth'
wan0             UP             3c:fd:fe:dd:ee:ff <BROADCAST,MULTICAST,UP,LOWER_UP>
stor0            DOWN           3c:fd:fe:aa:bb:cc <BROADCAST,MULTICAST>

Що це означає: Перейменування працює.

Рішення: Тепер оновіть один раз — ваші bond/bridge/VLAN конфігури, правила фаєрвола й моніторинг, щоб використовувати wan0/stor0 (або ж співпадати по MAC там, де можливо).

Одна деталь, яку люди пропускають: іменування відбувається рано

Якщо ваш initramfs включає мережу і намагається підняти інтерфейс по імені (diskless boot, remote root, iSCSI, деякі зашифровані-рут конфігурації), ваше іменування має бути консистентним і на цьому етапі. Якщо ви змінюєте правила іменування, перебудуйте initramfs якщо ваше середовище цього потребує.

cr0x@server:~$ sudo update-initramfs -u
update-initramfs: Generating /boot/initrd.img-6.12.0

Що це означає: Ваш initramfs тепер містить оновлені правила/конфіги (якщо стосуються).

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

Грубий підхід: вимкнення predictable naming (коли це прийнятно)

Іноді ви отримуєте у спадок автоматизацію, яка очікує eth0. Іноді скрипт вендора жорстко прив’язаний до цього і його важко переписати. Іноді потрібен найшвидший шлях відновити флот без переписування всього під час інциденту.

Вимкнення predictable names прийнятне, коли ви також забезпечуєте стабільний порядок probe (або у вас є один NIC). Це неприйнятно для багатопортових хостів з bond’ами і VLAN-транками, якщо вам не подобається рулетка.

Встановити параметри ядра для відключення predictable names

cr0x@server:~$ sudo sed -i 's/GRUB_CMDLINE_LINUX="/GRUB_CMDLINE_LINUX="net.ifnames=0 biosdevname=0 /' /etc/default/grub
cr0x@server:~$ sudo update-grub
Generating grub configuration file ...
Found linux image: /boot/vmlinuz-6.12.0
Found initrd image: /boot/initrd.img-6.12.0
done

Що це означає: Майбутні завантаження попросять ядро повернутися до традиційного іменування. Залежно від середовища ви, ймовірно, знову побачите eth0.

Рішення: Робіть це лише якщо готові терпіти зміну порядку enumeration або якщо ви фіксуєте порядок іншим способом. Інакше краще використати .link чи матч по MAC у конфігах.

Перезавантажитись і підтвердити

cr0x@server:~$ sudo reboot
Connection to server closed by remote host.
Connection to server closed.

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

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

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

Bonds, VLANs, bridges і гіпервізори: де перейменування шкодить найбільше

Машини з однією NIC часто переживають перейменування з невеликим незручностям. Багатопортові машини можуть зовсім згаснути, або ще гірше: частково працювати так, що витрачається багато годин.

Bonds (LACP/active-backup)

Bonds залежать від імен slave-ів. Якщо slave не існує, bond піднімається без учасників і показує NO-CARRIER.

Типовий симптом: device bond існує, але трафік не йде. Ви бачите bond інтерфейс у стані DOWN, хоча фізичний NIC має лінк.

Bridges (поширені у віртуалізації)

Bridges залежать від правильного enslaving uplink. Якщо ім’я uplink змінилося, мережа VM може все ще піднятися (бридж існує), але бути ізольованою.

Саме звідси походить «у хоста все працює, а в VM — ні».

VLAN-підінтерфейси

Якщо у вас є enp3s0.100, а базовий інтерфейс став wan0, ім’я VLAN має стати wan0.100, якщо ви визначаєте його саме так. Якщо ви жорстко прописали старе базове ім’я, VLAN-інтерфейси не з’являться.

Гіпервізори і «стабільне» віртуальне залізо

У світі VM «стабільний PCI-путь» часто — це обман, який ви розповідаєте собі, щоб спати. Міграції, оновлення версій і зміна моделі віртуальної NIC можуть змістити представлення шини/слота. Іноді VM бачить ту саму MAC, іноді — ні.

Жарт №2: Міграція через гіпервізор — це просто «зміна апаратного забезпечення» в костюмі, що наполягає, що це «live event».

Три міні-історії з корпоративного поля бою

Міні-історія 1: Інцидент через хибне припущення («eth0 завжди основний»)

Середня компанія мала змішаний флот: кілька старих Debian-серверів з eth0/eth1 і новіші з predictable names. Команда підтримувала скрипт provisioning, що робив одну річ дуже ефективно: він припускав, що eth0 — публічний інтерфейс, і писав фаєрвол-правила відповідно.

На Debian 13 нова партія хостів з’явилась як enp1s0 і enp2s0. Скрипт і далі писав nftables-правила для eth0. Сервіс мережі підняв enp1s0, але фаєрвол відмовляв у вхідному SSH, бо правило allow не співпадало.

Режим відмови був тонким: хости могли виходити назовні (агент моніторингу дзвонив додому, оновлення пакетів працювали), але вхідне управління було мертвим. Люди звинувачували security groups, балансувальник навантаження і DNS. Ніхто не звинуватив ім’я інтерфейсу, бо лампочки лінку були включені і «мережа працює».

Виправлення не полягало в заміні eth0 на enp1s0 у скрипті. Виправлення — припинити покладатися на імена інтерфейсів для політики. Вони змінили правила фаєрвола, щоб матчити по джерельних підмережах і стану з’єднання, і закріпили імена інтерфейсів через .link лише там, де операційна роль вимагала цього.

Після цього той самий скрипт працював для обох схем іменування. Інцидент закінчився, і компанія засвоїла класичний урок SRE: припущення невидимі, доки не лякають голосно.

Міні-історія 2: Оптимізація, що відгукнулась боком (pin по MAC… потім клонування VM)

Інша організація стандартизувала імена інтерфейсів через .link по MAC. Було акуратно: wan0, lan0, stor0. Людям це сподобалося. Моніторинг став чистішим. Документація перестала вживати «лівий порт» як технічний термін.

Потім вони розгорнули шаблон VM для нового сервісу. Шаблон містив .link файли, що збігалися з MAC шаблонної VM. У продакшені клоновані машини отримали нові MAC — як і повинно бути — але .link правила нічого не збігали. Імена повернулись до predictable defaults.

Тепер у них було два світи: шаблон показував wan0, продакшн — ens192. Автоматизація розгортання посилалась на wan0. Деякі хости піднімались без IP. Інші піднімались, бо інший компонент матчився по DHCP client ID, створюючи випадковий частковий успіх, що затягнув інцидент.

Виправлення полягало в тому, щоб не захардкоджувати ідентичність хоста в шаблон. Вони перейшли на матч за PCI-путем у VM тільки коли гіпервізор зберігав його стабільним, інакше матчили в .network по MAC, але генерували MAC для правила вже під час провізіонінгу (а не в золотому образі).

Оптимізація — «зробити імена гарними скрізь» — відгукнулась боком, бо вона підсунула ідентичність в артефакт, що мав бути загальним. Добрі наміри, типовий результат.

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

Команда фінансових послуг мала звичку, що здавалася надто обережною: кожна зміна, що зачіпає мережу, вимагала (1) перевіреного OOB-доступу та (2) preflight-скрипта, який порівнював налаштовані імена інтерфейсів з реальними пристроями.

Коли вони піднімали ноду кластера до Debian 13, ім’я NIC змінилося, бо в гіпервізорі раніше таж тижня змінилася модель віртуального заліза. Preflight-скрипт відразу це підмітив: «Configured interface bond slaves not present.» Він відміняв зміну до перезавантаження.

Оскільки вони були «нудні», вони діяли швидко. Вони відкоригували .link іменування до ролі, оновили bond-конфи, перебудували initramfs і запланували перезавантаження в контрольованому вікні — все з підтвердженим OOB-доступом.

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

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

Симптом: networking.service падає з «unknown interface eth0».
Корінна причина: Конфіг посилається на спадкове ім’я; система використовує predictable naming.
Виправлення: Закріпіть ім’я інтерфейсу через .link файл або оновіть конфіги на нове стабільне ім’я; не забудьте про фаєрвол/bonс/ VLAN.
Симптом: Інтерфейс показує UP з лінком, але без IP після перезавантаження.
Корінна причина: DHCP-клієнт або статична конфіг прив’язані до іншого імені або профіль NetworkManager не прикріплений.
Виправлення: Перев’яжіть профіль (NetworkManager) або матчте по MAC/шляху (systemd-networkd) і переконайтесь, що лише один менеджер мережі контролює пристрій.
Симптом: Bond/bridge існує, але NO-CARRIER і трафік помер.
Корінна причина: Slave-інтерфейси/ uplink bridge вказані старим іменем; slave-и не були приєднані.
Виправлення: Спочатку виправте базове іменування інтерфейсу; потім перевірте enslaving; далі перевірте switch/LACP.
Симптом: Хост може виходити назовні, але ви не можете зайти по SSH; моніторинг частково працює.
Корінна причина: Правила фаєрвола матчать iifname "eth0", яке більше не існує.
Виправлення: Оновіть фаєрвол на правильне стабільне ім’я або переробіть на матч по підмережі/стану; перевірте набір правил після перейменування.
Симптом: Працює до перезавантаження; після — ім’я знову змінюється.
Корінна причина: Ви зробили runtime-перейменування або відредагували один конфіг, але не визначили стабільну політику іменування.
Виправлення: Створіть .link правила (або навмисно вимкніть predictable naming) і зафіксуйте вибір; перебудуйте initramfs якщо ранній етап завантаження має значення.
Симптом: «Стабільне» іменування по MAC ламається лише на клонованих/нових VM.
Корінна причина: Золотий образ включав MAC-орієнтовані правила для MAC шаблона.
Виправлення: Генеруйте .link правила під час провізіонінгу або матчте по інших стабільних ідентифікаторах; тримайте шаблони загальними.
Симптом: Два інтерфейси міняються ролями після додавання нової NIC.
Корінна причина: Ви вимкнули predictable naming і покладались на порядок probe.
Виправлення: Увімкніть predictable naming і закріпіть через .link, або явно матчте у вашій мережевій конфігурації по MAC/шляху.
Симптом: Випадкові флапи або дубльовані імена після змін.
Корінна причина: Конфліктуючі правила: кілька .link файлів матчать один і той же NIC, або одночасно управляють ifupdown і networkd.
Виправлення: Забезпечте унікальні матчі, контролюйте пріоритет файлів (лексичний порядок) і працюйте з одним мережевим менеджером на хості.

Контрольні списки / покроковий план

Покроково: швидко виправити зламаний хост прямо зараз (одна NIC)

Підключіться через консоль (IPMI/iDRAC/virt console). Не експериментуйте через помираючу SSH-сесію.
Запустіть ip -br link і ip -br addr. Визначте NIC, що повинна мати сервісний IP.
Перевірте journalctl -u networking -b (або логи networkd/NetworkManager). Підтвердіть, що це невідповідність імен, а не збій драйвера.
Тимчасово присвойте IP/шлюз через ip addr add/ip route add, якщо потрібен віддалений доступ негайно.
Створіть .link файл, щоб назвати NIC стабільно (wan0 підходить) використовуючи MAC або шлях.
Оновіть мережеву конфігурацію, щоб посилатись на wan0 (або матчити по MAC/шляху, якщо використовуєте networkd).
Оновіть правила фаєрвола, що матчать за іменами інтерфейсів.
Перебудуйте initramfs, якщо раннє завантаження мережі має значення у вашому середовищі.
Перезавантажтеся у контрольованому вікні і перевірте ім’я, IP, маршрутизацію та вхідний доступ.

Покроково: виправити хост з bond/bridge (багато NIC)

Визначте фізичні NIC і їх відповідність MAC/шляху (udevadm test-builtin net_id і /sys/class/net).
Вирішіть стабільні імена за роллю: wan0, lan0, stor0, а не за номером слота, який ви не запам’ятаєте.
Створіть по одному .link на роль з унікальними матчами (MAC або PCI-путь). Переконайтесь, що немає накладань.
Оновіть визначення slave для bond і порти для bridge на нові стабільні імена.
Перевірте ip -d link show bond0, щоб упевнитися в правильних slave і появі carrier.
Лише після цього перевіряйте налаштування комутатора для LACP або VLAN trunking.
Перезавантажтесь один раз, перевірте ще раз і збережіть «known good» виводи для майбутніх порівнянь.

Перевірки перед змінами для оновлень до Debian 13 (зробіть це перед перезавантаженням)

Підтвердіть, що out-of-band консоль доступна.
Збережіть вивід ip -br link, ip -br addr та networkctl status.
Проведіть інвентар залежностей: nftables правила, bonds, bridges, VLAN, моніторинг.
Переконайтесь, що у вас немає конфліктуючих менеджерів (ifupdown vs networkd vs NetworkManager), якщо тільки у вас не дуже специфічна причина.
Якщо ви залежите від раннього мережевого завантаження (remote root, iSCSI тощо), сплануйте перебудову initramfs і тестові завантаження.

Питання й відповіді (FAQ)

1) Чому Debian 13 перейменував мій інтерфейс після оновлення?

Тому що імена формуються правилами udev/systemd, які можуть змінюватись з оновленнями, різними драйверами, прошивкою/BIOS або зміною топології (фізичною чи віртуальною). Ваш NIC не «зламався»; змінився його ідентифікатор.

2) Може просто вимкнути predictable interface names?

Лише якщо у вас є вагома причина (спадкове ПЗ, одиночний NIC, контрольований хардвер) і ви приймаєте, що порядок виявлення все ще може змінюватися. Для багатопортових серверів краще використовувати .link закріплення або матч по MAC/шляху в networkd.

3) Чи завжди найкраще матчити по MAC-адресі?

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

4) У чому різниця між закріпленням імен через `.link` і матчем у `.network`?

.link контролює саме ім’я інтерфейсу. .network співпадає з інтерфейсом, щоб застосувати налаштування IP. Ви можете уникнути залежності від імен, матчучи в .network, але імена все одно важливі для людей та інших інструментів.

5) Мій інтерфейс перейменовано, але DHCP працює. Чому сервіси зламалися?

Бо сервіси часто залежать від імен інтерфейсів: правила фаєрвола (iifname), політики маршрутизації, VLAN-пристрої, bond-и або скрипти. DHCP, що працює, лише доводить, що NIC отримав адресу, але не те, що вся система узгоджена щодо імені.

6) Як зрозуміти, яке ім’я «правильне» для мого хоста?

Перестаньте думати про «правильне» й почніть думати про «стабільне». Обирайте імена за роллю (WAN/LAN/зберігання) і прив’язуйте ці імена до стабільних ідентифікаторів (MAC/шлях). Потім робіть конфіги, що посилаються на ці рольові імена.

7) Чи можуть два `.link` файли конфліктувати за один NIC?

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

8) Чи потрібно перебудовувати initramfs після зміни правил іменування?

Часто — ні для типової серверної загрузки. Але якщо ви використовуєте ранню мережу (diskless, remote root, iSCSI, деякі зашифровані конфігурації), вважайте це обов’язковим: перебудуйте і протестуйте.

9) Як щодо контейнерів — чи їм це важливо?

Контейнери зазвичай бачать veth-імена і неймспейси; але uplink хоста все одно важливий для фаєрвола, маршрутизації і CNI-конфігів. Якщо ви порушите uplink хоста, контейнери впадуть разом з ним.

10) Який найбезпечніший довготривалий підхід для змішаного флоту?

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

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

Якщо Debian 13 «зламав мережу», припускайте, що це невідповідність імен інтерфейсу, поки не доведено інше. Підтвердіть наявність NIC, підтвердіть лінк, підтвердіть, що конфіг посилається на ім’я, якого вже немає. Потім виправте це один раз і правильно.

Оберіть стабільну стратегію іменування: рольові імена через .link за замовчуванням — найкраща відповідь.
Аудитуйте залежності: bonds/bridges/VLAN, правила фаєрвола, моніторинг і будь-які скрипти, що очікують eth0.
Зробіть виправлення стійким до перезавантажень: зафіксуйте політику іменування, оновіть конфіги, перебудуйте initramfs якщо ранній етап завантаження має значення.
Інституціалізуйте це: додайте preflight-перевірку, яка порівнює налаштовані імена інтерфейсів з реальними пристроями перед перезавантаженнями/оновленнями.

Мета — не тільки впоратися з цим інцидентом. Мета — зробити так, щоб наступне перезавантаження було нудним.