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

Як виглядає, коли іменування інтерфейсів ламається

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

Типові симптоми в Debian 13

• Віддалений хост недоступний після перезавантаження, але на консолі видно звичний запит логіна.
• Помилки мережевих сервісів, такі як «Cannot find device» або «Unknown interface» від ifupdown, systemd-networkd або NetworkManager.
• Фізичний лінк є (комутатор показує лінк), але IP не налаштований.
• Маршрути відсутні: маршрут за замовчуванням не встановлено, бо потрібний інтерфейс ніколи не піднявся.
• Bonding/VLAN/bridge пристрої відсутні: якщо базова назва інтерфейсу змінилася, усі вкладені інтерфейси також ламаються.

Проблеми з іменуванням інтерфейсів — це тип бага, який змушує сумніватися в реальності. Ваш конфігураційний файл правильний. Кабель в порядку. Комутатор в порядку. Сервер в порядку. Просто він тепер має інше ім’я.

Жарт №1: Передбачувані імена інтерфейсів — як «тимчасові» правила firewall: передбачувані тільки якщо ви ніколи нічого не змінюєте.

Цікаві факти й історичний контекст (чому це повторюється)

Іменування інтерфейсів — це одна з тих тем в Linux, де значення за замовчуванням змінювались кілька разів, і кожна зміна була «на краще» в якомусь сенсі, але продовжує дратувати операторів.

1. Раніше Linux за замовчуванням давав eth0, eth1, … на основі порядку виявлення, який може змінюватися, коли драйвери завантажуються по-іншому або обладнання змінюється.
2. Systemd ввів «predictable network interface names», щоб уникнути рулетки eth0, прив’язуючи імена до інформації від прошивки/топології PCI (наприклад, enp3s0).
3. Debian прийняв передбачувані імена роками тому, але реальний результат залежить від таблиць прошивки, налаштувань BIOS та того, чи перекривають дистрибутивні правила udev власні .link файли.
4. Існує кілька схем іменування: за шляхом PCI (enpXsY), за індексом на материнській платі (eno1), за слотом (ens1), за MAC (enx...) і класичне ядро-орієнтоване (eth0).
5. Cloud-образи часто використовують прив’язку за MAC, бо «той самий» віртуальний NIC може мати різні PCI-адреси залежно від версії гіпервізора та типу машини.
6. Оновлення прошивки можуть змінити SMBIOS/ACPI, що тонко змінює інформацію, яку systemd вважає «передбачуваною».
7. Initramfs має значення: якщо потрібна мережа на ранньому етапі завантаження (iSCSI root, NFS root, віддалене розблокування), зміни імен можуть ламається ще до того, як userspace зможе відновитися.
8. Контейнери ускладнюють відладку: всередині неймспейсу ви можете бачити eth0, тоді як хост перейменував фактичний NIC під вашою автоматизацією.
9. Bond і bridge збільшують радіус ураження: одне перейменування може зламати slave в bond, VLAN-дочірні інтерфейси, мости, правила firewall, моніторинг і припущення систем управління конфігурацією.

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

Це послідовність «припини гадати». Оптимізовано для поширеного випадку: сервер вгору, але мережа не налаштована, бо змінилося ім’я NIC.

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

• Запустіть ip -br link і ip -br addr, щоб перелічити інтерфейси й хто має адреси.
• Перевірте networkctl list, якщо використовуєте systemd-networkd.
• Пошукайте «новий» enp*/eno*/ens* з очікуваною MAC-адресою.

Друге: підтвердьте, чого очікує ваша мережна конфігурація

• ifupdown: grep -R "iface" /etc/network/interfaces*
• systemd-networkd: ls /etc/systemd/network і перегляньте *.network
• NetworkManager: nmcli con show і подивіться на connection.interface-name

Третє: доведіть відповідність (MAC ↔ ім’я інтерфейсу) і виберіть стабільний ідентифікатор

• Використайте ip link або udevadm info, щоб зіставити MAC і шлях PCI.
• Виберіть підхід: systemd .link файли по MAC, або відповідність за PCI-шляхом, або явно відключити передбачувані імена (рідко найкраще), залежно від вашого середовища.

Коли ви зможете відповісти «як зараз називається NIC?» і «чого очікує конфігурація?», решта — механіка.

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

Це перевірки рівня production. Кожна включає, що означає вивід і яке рішення потрібно прийняти далі. Запускайте їх на консолі, якщо сервер відрізаний. Якщо SSH ще є — робіть їх в будь-якому разі: перейменування інтерфейсів зазвичай з’являються при наступному перезавантаженні, а не під час поточного інциденту.

Завдання 1: Швидко перелічити інтерфейси й їхній операційний стан

cr0x@server:~$ ip -br link
lo               UNKNOWN        00:00:00:00:00:00 <LOOPBACK,UP,LOWER_UP>
enp4s0           DOWN           3c:fd:fe:aa:bb:cc <BROADCAST,MULTICAST>
enp5s0           UP             3c:fd:fe:11:22:33 <BROADCAST,MULTICAST,UP,LOWER_UP>

Значення: enp5s0 має carrier і піднятий. enp4s0 існує, але він down (або не підключений, або адміністративно відключений).

Рішення: Сфокусуйтеся на enp5s0 як ймовірному основному NIC. Далі підтвердьте, чи має він очікуваний IP.

Завдання 2: Перевірте, які інтерфейси мають IP-адреси

cr0x@server:~$ ip -br addr
lo               UNKNOWN        127.0.0.1/8 ::1/128
enp4s0           DOWN
enp5s0           UP             192.0.2.10/24 2001:db8:10::10/64

Значення: Мережа налаштована на enp5s0. Якщо ви очікували це на enp4s0 або enp3s0, ваша конфігурація не синхронна.

Рішення: Якщо ви все ще офлайн, проблема може бути в маршрутах, firewall, VLAN або невірному шлюзі — а не лише в іменах. Далі перевірте маршрутизацію.

Завдання 3: Перевірте маршрути (звичайно відсутній маршрут за замовчуванням)

cr0x@server:~$ ip route
default via 192.0.2.1 dev enp5s0
192.0.2.0/24 dev enp5s0 proto kernel scope link src 192.0.2.10

Значення: Існує маршрут за замовчуванням через enp5s0. Якщо ви не бачите рядка default, ваша мережна конфігурація не застосувалася або DHCP не запустився.

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

Завдання 4: Виявіть, як ваша конфігурація іменує інтерфейс (ifupdown)

cr0x@server:~$ grep -R "iface " /etc/network/interfaces /etc/network/interfaces.d 2>/dev/null
/etc/network/interfaces:iface enp3s0 inet static
/etc/network/interfaces:iface enp3s0 inet6 static

Значення: Ваша конфігурація очікує enp3s0, але ядро/systemd зараз показує enp5s0. Це невідповідність може залишити вас відрізаним.

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

Завдання 5: Для systemd-networkd — перелік статусу link і що networkd думає

cr0x@server:~$ networkctl list
IDX LINK   TYPE     OPERATIONAL SETUP
  1 lo     loopback carrier     unmanaged
  2 enp5s0 ether    routable    configured
  3 enp4s0 ether    no-carrier  unmanaged

Значення: networkd налаштував enp5s0. Якщо потрібний інтерфейс «unmanaged», ваші правила матчингу його проминули (часто через перейменування).

Рішення: Перегляньте .network файли на предмет Name= або MACAddress= і сплануйте стабільний ідентифікатор.

Завдання 6: Для NetworkManager — перевірте, який профіль прив’язаний до якого інтерфейсу

cr0x@server:~$ nmcli -f NAME,DEVICE,TYPE,STATE con show --active
NAME            DEVICE  TYPE      STATE
prod-uplink     enp5s0  ethernet  activated

Значення: Профіль з іменем prod-uplink активний на enp5s0. Якщо нічого не активне, NM може чекати конкретного імені інтерфейсу.

Рішення: Перевірте nmcli con show prod-uplink на предмет connection.interface-name. Якщо встановлено старе ім’я — виправте його або використайте стабільне іменування.

Завдання 7: Зіставте MAC-адреси з іменами інтерфейсів (якор гарантії)

cr0x@server:~$ ip -br link | awk '{print $1, $3}'
lo 00:00:00:00:00:00
enp4s0 3c:fd:fe:aa:bb:cc
enp5s0 3c:fd:fe:11:22:33

Значення: Тепер ви можете зіставити MAC з вашим інвентарем/портом комутатора/політикою безпеки до імені Linux-пристрою.

Рішення: Якщо ваша автоматизація надійно знає MAC, прив’язуйте по MAC (systemd .link або правила networkd). Якщо MAC змінюються (деякі хмарні середовища), оберіть інші стабільні атрибути.

Завдання 8: Отримайте підказки ID_NET_NAME_* від systemd/udev

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

Значення: udev обчислив кілька кандидатів на стабільні імена. Поточна назва — enp5s0 (за шляхом), але також є варіанти ens3 (за слотом) і MAC-варіант enx....

Рішення: Оберіть, що найбільш стабільне у вашому середовищі. Фізичним серверам часто підходять імена за слотом або onboard; VM краще підпадають під MAC-матчинг або явну прив’язку.

Завдання 9: Побачити PCI-шлях і драйвер для NIC (допомагає пояснити перейменування)

cr0x@server:~$ lspci -nnk | grep -A3 -i ethernet
03:00.0 Ethernet controller [0200]: Intel Corporation I210 Gigabit Network Connection [8086:1533]
	Subsystem: Intel Corporation Device [8086:0001]
	Kernel driver in use: igb
	Kernel modules: igb

Значення: PCI-адреса 03:00.0 — це uplink NIC. Якщо прошивка/BIOS змінює нумерацію шин або топологію, імена на основі шляху можуть змінитися.

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

Завдання 10: Підтвердьте, чи передбачувані імена ввімкнені через cmdline ядра

cr0x@server:~$ cat /proc/cmdline
BOOT_IMAGE=/vmlinuz-6.12.0-1-amd64 root=UUID=8b1d... ro quiet

Значення: Немає net.ifnames=0 або biosdevname=0 — передбачуване іменування активне (типово для Debian).

Рішення: Не поспішайте відключати передбачувані імена глобально. Це крайній захід. Краще використовувати явне іменування через .link файли або правила матчингу.

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

cr0x@server:~$ journalctl -b -u systemd-udevd --no-pager | grep -E "renamed|ID_NET_NAME|link_config"
Dec 30 10:12:01 server systemd-udevd[322]: enp3s0: Interface name change detected, renamed to enp5s0

Значення: udev явно записав перейменування зі старого на нове. Це ваш курячий слід.

Рішення: Впровадьте стабільне іменування, щоб посилання в конфігах не застаріли. Також пошукайте кастомні udev правила або .link файли, які можуть конфліктувати.

Завдання 12: Перевірте наявні systemd .link файли, що можуть переоприділяти імена

cr0x@server:~$ ls -1 /etc/systemd/network/*.link 2>/dev/null
/etc/systemd/network/10-uplink.link

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

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

Завдання 13: Проінспектуйте .link файл і перевірте, що він матчує лише потрібний інтерфейс

cr0x@server:~$ sed -n '1,120p' /etc/systemd/network/10-uplink.link
[Match]
MACAddress=3c:fd:fe:11:22:33

[Link]
Name=uplink0

Значення: Це хороший приклад: матч за унікальною MAC і присвоєння зручної людино-зрозумілої назви.

Рішення: Якщо MAC правильна, це переживе перезавантаження і перестановки PCI. Якщо MAC зміниться (клонування VM, заміна NIC), оновіть файл і при потребі перебудуйте ранні залежності завантаження.

Завдання 14: Застосуйте зміни імен безпечно (перезапуск udev і перепідключення не завжди достатні)

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

Значення: Перезавантажує правила udev і тригерить додавання net-пристроїв. Перейменування можуть застосуватися в реальному часі або ні; systemd обережно ставиться до перейменування активних інтерфейсів.

Рішення: Заплануйте контрольований вікно перезавантаження після впровадження стабільного іменування. Для віддалених систем переконайтеся в наявності позаосновного доступу або резервного каналу.

Завдання 15: Перевірте лінк і параметри перемовин (бо іноді це не іменування)

cr0x@server:~$ sudo ethtool enp5s0 | egrep "Link detected|Speed|Duplex"
Speed: 1000Mb/s
Duplex: Full
Link detected: yes

Значення: Фізичний лінк добрий. Якщо лінк down, перейменування може бути червоним гвинтом, а «новий NIC» — просто відключений.

Рішення: Якщо лінк down, перевірте порт комутатора/VLAN/патчинг і підтвердьте, що ви прив’язуєте правильну MAC до правильного порту.

Корінні причини: як Debian 13 отримує «нову» назву NIC

Debian 13 не прокинувся й не обрав хаос. Імена інтерфейсів обчислюються з інформації, яку ОС отримує від ядра, прошивки й правил udev. Коли будь-яке з цих входів змінюється, ім’я може змінитися. Ось поширені тригери, які я бачив у реальних середовищах.

1) Змінилася топологія PCI (реальне або «віртуальне» обладнання)

Імена на основі шляху PCI, як enp5s0, кодують шину/пристрій/функцію. Якщо нумерація шин змінюється, змінюється й ім’я. Причини: оновлення BIOS, увімкнення/вимкнення SR-IOV, зміна налаштувань PCIe bifurcation, додавання/видалення карт або навіть перестановка NIC у інший слот.

2) Прошивка почала по-іншому звітувати індекси слоту/онборду

Імена типу eno1 (onboard) і ens1 (slot) залежать від індексів, які надає прошивка. Коли таблиці прошивки змінюються, «передбачувана» назва Linux стає інакшою.

3) Нове ядро/драйвер змінило час енумерації

Це старий problem eth0 в новому вбранні. Навіть з передбачуваним іменуванням є крайові випадки, коли система відступає до інших евристик, якщо потрібна інформація недоступна досить рано.

4) Конфліктні правила udev або systemd .link файли

Одна команда додає широку правило («перейменувати всі Intel NIC в lan0»), інша команда додає іншу широку правило, і тепер останнє, що застосувалося, виграє. Це не обов’язково навмисно — просто розподілена конфігурація.

5) Клонування VM і зміни MAC-адрес

Іменування за MAC стабільне тільки якщо MAC стабільні. Склонуйте VM, згенеруйте нові MAC — і ваші уважно прив’язані enx... імена стануть іншими. cloud-init і інструменти гіпервізора іноді допомагають тут, іноді ні.

6) Раннє мережеве завантаження (initramfs) бачить інше іменування

Якщо система потребує мережі в initramfs (віддалене розблокування, iSCSI root), вона може впасти ще до того, як буде змінено /etc. Виправлення імен лише в /etc може не допомогти, якщо initramfs все ще очікує старого імені.

Цитата, щоб тримати вас чесними, в парафразі від John Allspaw: Надійність походить від того, як системи фактично поводяться під час змін, а не від того, як ми бажаємо, щоб вони поводилися на діаграмах.

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

Є три загальні підходи. Два хороші. Один спокусливий. Вибирайте залежно від середовища, а не настрою.

Стратегія A (рекомендовано): systemd .link файли — іменування за MAC (або іншими унікальними властивостями)

Це найпряміший спосіб заявити: «інтерфейс з цією MAC називається uplink0». Це явно, перевірно й переживає перезавантаження. На фізичних хостах, де MAC не змінюються, це нудно в кращому сенсі.

Створіть .link файл:

cr0x@server:~$ sudo tee /etc/systemd/network/10-uplink.link >/dev/null <<'EOF'
[Match]
MACAddress=3c:fd:fe:11:22:33

[Link]
Name=uplink0
EOF

Що це означає: systemd-udevd перейменує інтерфейс, що співпадає по MAC, у uplink0 під час ініціалізації пристрою.

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

Потім адаптуйте вашу мережну конфігурацію на uplink0:

• ifupdown: змініть iface enp3s0 на iface uplink0
• systemd-networkd: [Match] Name=uplink0
• NetworkManager: встановіть connection.interface-name uplink0 або прив’язку за MAC

Стратегія B (часто краща для systemd-networkd): match у .network по MAC і уникати перейменування

Якщо вам не важливо, як ядро називає інтерфейс, не перейменовуйте його — просто налаштуйте конфігурацію за матчинґом. Це зменшує сюрпризи з перейменуваннями і уникає краєвих випадків, коли перейменування взаємодіє з іншими сервісами.

Приклад networkd конфігурації з match по MAC:

cr0x@server:~$ sudo tee /etc/systemd/network/10-uplink.network >/dev/null <<'EOF'
[Match]
MACAddress=3c:fd:fe:11:22:33

[Network]
Address=192.0.2.10/24
Gateway=192.0.2.1
DNS=192.0.2.53
EOF

Що це означає: Незалежно від того, чи інтерфейс називається enp5s0 сьогодні або enp2s0 після наступного оновлення BIOS, networkd все одно його налаштує.

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

Стратегія C (останній засіб): відключити передбачуване іменування і повернутись до eth0

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

Спокусливі параметри командного рядка: додати net.ifnames=0 biosdevname=0 до GRUB.

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-1-amd64
done

Що це означає: Ви наказуєте ядру/udev припинити використовувати передбачувані імена. Інтерфейси, ймовірно, стануть eth0, eth1.

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

Що я насправді рекомендую

Для фізичних серверів: використовуйте .link перейменування по MAC, щоб отримати осмисленні імена на кшталт uplink0, storage0, oob0. Ви будете вдячні під час інцидентів.

Для VM і хмари: використовуйте match-by-MAC у вашому мережевому менеджері (або інтеграцію з cloud-init) і уникайте підгонки під топологію PCI, яку може змінювати гіпервізор.

Жарт №2: Якщо ви іменуєте інтерфейси за шляхом PCI, пам’ятайте: шлях змінюється швидше, ніж людина на чергуванні.

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

Міні-історія 1: Аварія через хибне припущення

У них була акуратна конфігурація: хости Debian, кілька NIC, VLAN для фронтенду і бекенду, і добре намірена конвенція «лівий порт завжди enp3s0». Це не було задокументовано, але ставилось як закон фізики.

Потім розгорнули оновлення прошивки на партії серверів. Воно не змінило драйвери. Воно не змінило ОС. Воно змінило те, як BIOS описував топологію PCI. Після перезавантаження «лівий порт» став enp4s0. Система управління конфігом все ще писала /etc/network/interfaces для enp3s0.

Половина серверів повернулась без аплінку. Інша половина — «в порядку», що найгірше, бо переконує керівництво, що це був поодинокий випадок.

Постмортем виявив справжню помилку: вони вважали, що імена інтерфейсів досить стабільні, щоб поводитися як ярлики на фізичних портах. Але Linux дивиться не на ваші пальці на панелі, а на метадані прошивки. Виправлення було простим: матчити конфігурацію по MAC і для людей перейменувати в uplink0 через .link. Складніше було визнати, що припущення — це баг.

Міні-історія 2: Оптимізація, що відбилася боком

Інша організація втомилась від «потворних» імен інтерфейсів. Вони захотіли стандартизувати все: lan0, lan1, stor0. Ціль розумна. Виконання — проблема.

Вони написали правило udev, що матчує по драйверу й вендору: «будь-який Intel NIC стає lan0, якщо він ще вільний». У лабораторії це працювало. На кількох серверах — теж. Потім апаратний апдейт приніс двопортові NIC з тим самим драйвером. Раптом обидва порти відповідали одному правилу.

Під час завантаження «переможець» для lan0 змінювався залежно від порядку енумерації. Їх конфігурація мережі застосовувалася до того NIC, який першим отримав ім’я. Деякі сервери запускались з поміняними фронтендом і сховищем. Це не «вимкнення»; це «небезпечна доступність».

Вони відкотили udev правило і замінили його на systemd .link файли з матчинґом по MAC, по одному файлу на інтерфейс, зберігаючи їх у репозиторії конфігурацій. Менш хитро, більш правильно. Також значно приємніше під час аудитів.

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

Цей випадок майже нудний. Команда платформи мала стандарт: кожна збірка сервера включала записане зіставлення MAC-адрес NIC до призначення («uplink», «storage», «cluster»), збережене поряд з даними про провізіонування хоста. Воно оновлювалося при заміні NIC. Ніяких героїчних дій. Просто нудна облікова робота.

Коли почалися оновлення до Debian 13, декілька хостів повернулись з перейменованими інтерфейсами через зміну налаштувань BIOS на частині машин. Моніторинг сповістив: «host unreachable». На чергуванні використали позаосновну консоль, запустили ip -br link і миттєво зіставили MAC-адреси з відомими ролями.

Вони не гадали. Не переставляли кабелі. Не перезаписували конфіг бездумно. Вони застосували стандартне виправлення: згенерували .link файли з інвентарю, один раз перезавантажили, підтвердили маршрути і шлюз — інцидент закрито.

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

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

1) «Після перезавантаження SSH мертвий, але консольний логін працює.»

Корінна причина: мережна конфігурація посилається на застаріле ім’я інтерфейсу (enp3s0), яке більше не існує.

Виправлення: визначте поточну назву інтерфейсу через ip -br link, потім впровадьте стабільне іменування (systemd .link або match-by-MAC) і оновіть мережну конфігурацію відповідно.

2) «Ім’я NIC змінилося, тож ми правили конфіг. Воно знову змінилося після наступного оновлення.»

Корінна причина: покладання на імена на основі топології в середовищі, де топологія PCI нестабільна (VM, оновлення прошивки, додаткові карти).

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

3) «Bond0 не піднімається; логи показують, що не може додати slave.»

Корінна причина: імена slave в bond змінилися; конфіг bond посилається на старі slave.

Виправлення: матчуйте slave bond по MAC (де підтримується) або забезпечте стабільні імена slave через .link. Потім оновіть конфіг bond до цих стабільних імен.

4) «VLAN інтерфейс відсутній: enp3s0.100 не існує.»

Корінна причина: базове ім’я інтерфейсу перейменовано; VLAN-дочірній залежить від базової назви.

Виправлення: стабілізуйте базову назву (або використайте стабільний міст/bond як батька VLAN), потім відтворіть VLAN-и.

5) «NetworkManager каже, що підключення активоване, але воно на неправильному NIC.»

Корінна причина: профіль підключення не прив’язаний до інтерфейсу або прив’язаний занадто широко; NM обрав інший пристрій після перейменування.

Виправлення: встановіть connection.interface-name або прив’язку за MAC у профілі підключення; перевірте через nmcli.

6) «Ми створили udev правило для перейменування NIC; тепер іноді імена міняються місцями.»

Корінна причина: надто широкі критерії матчингу (драйвер/вендор) і невизначений порядок перейменування.

Виправлення: використовуйте per-interface матчинґ по MAC або стабільному шляху; надавайте перевагу systemd .link над кастомними udev правилами, якщо немає вагомої причини інакше.

7) «Інтерфейс названо правильно, але він не отримує IP.»

Корінна причина: ви виправили імена, але забули про менеджера: конфлікт ifupdown vs networkd vs NetworkManager або неправильно ввімкнений сервіс.

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

8) «Все працювало, поки ми не включили SR-IOV; потім імена змінилися.»

Корінна причина: SR-IOV змінює те, як функції експонуються; адресація PCI і іменування netdev можуть зміститись.

Виправлення: використовуйте матчинґ по MAC або стабільні імена за слотом; документуйте увімкнення SR-IOV як ризик для іменування.

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

Контрольний список A: Відновити відрізаний хост Debian 13 після перейменування NIC

1. Отримайте доступ до консолі (IPMI/iDRAC/ILO, консоль гіпервізора або локальна).
2. Запустіть ip -br link і ip -br addr. Визначте «нову» назву інтерфейсу і MAC.
3. Підтвердіть очікувану MAC з інвентарю або політики порту комутатора (якщо є).
4. Перевірте, який мережевий менеджер відповідає:
   • ifupdown: cat /etc/network/interfaces
   • networkd: networkctl list
   • NetworkManager: nmcli con show --active
5. Застосуйте стабільне іменування:
   • Бажано: .link файл, що перейменовує по MAC на uplink0, або
   • Матч по MAC у мережевому менеджері (без перейменування).
6. Оновіть залежні конфіги: bonds, bridges, VLAN-и, правила firewall, що посилаються на старі імена.
7. Перезавантажте або перезавантажуйте конфіги там, де це безпечно.
8. Перед перезавантаженням переконайтеся, що у вас є позаосновний доступ і план відкату.
9. Перезавантажте раз. Підтвердіть:
   • ip -br addr показує правильний IP на потрібному інтерфейсі
   • ip route має маршрут за замовчуванням
   • пінг шлюзу працює

Контрольний список B: Запобігти цьому в парку (план «ніколи більше»)

1. Обрати якір стабільності залежно від середовища:
   • Фізичні сервери: імена за MAC або за слотом; уникайте path-based, коли прошивка часто змінюється.
   • VM/хмара: найчастіше match-by-MAC, або провайдер-специфічні стабільні ідентифікатори, якщо MAC реюзаються.
2. Стандартизувати ролі інтерфейсів: uplink0, storage0, cluster0. Уникайте ностальгії за «eth0».
3. Зберігайте MAC↔роль у даних провізіонування. Оновлюйте при заміні NIC.
4. Розгортайте systemd .link файли (або правила матчингу менеджера) через CM.
5. Додайте CI/валідацію: якщо імена інтерфейсів у конфігурації відсутні на класі хостів, відхилити збірку/деплой.
6. Під час змін BIOS/прошивки вважайте, що «іменування інтерфейсів може змінитися» — тестуйте канарковий хост end-to-end.
7. Забезпечте вимогу позаосновного доступу для будь-якого хоста, що може себе відключити (особливо сховища, гіпервізори, маршрутизатори).

Контрольний список C: Після виправлення іменування переконайтеся, що інший стек мережі не поламано

1. Лінк: ethtool uplink0 показує Link detected: yes.
2. Адресація: ip -br addr показує очікувані IPv4/IPv6.
3. Маршрутизація: ip route має маршрут за замовчуванням на призначеному інтерфейсі.
4. ARP/neigh: ip neigh show dev uplink0 має доступний запис шлюзу після пінгу.
5. DNS: resolvectl status (або перевірити /etc/resolv.conf) відповідає очікуванням.
6. Firewall: якщо ви використовуєте правила, прив’язані до імен інтерфейсів, переконайтеся, що вони посилаються на нове стабільне ім’я.
7. Залежності: bonds/bridges/VLAN-и підняті (ip -d link допоможе).

Поширені питання

1) Чому Debian 13 перейменував мій інтерфейс, якщо нічого не змінювалося?

Щось змінилося. Це може бути таблиці прошивки, нумерація шин PCI, поведінка ядра/драйвера або оцінка правил udev/systemd. «Нічого не змінювалося» зазвичай означає «нічого, що я робив свідомо». Перевірте journalctl на події перейменування і порівняйте топологію PCI через lspci.

2) Чи варто вимикати передбачувані імена мережевих інтерфейсів?

Не як перший крок. Вимкнення може повернути проблему з порядком енумерації. Краще використовувати systemd .link або match-by-MAC. Вимикайте тільки коли сумісність вимагає і ви можете перевірити стабільність.

3) Чи завжди безпечно матчути по MAC?

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

4) Що краще: перейменувати через .link чи match-by-MAC у networkd?

Перейменування дає стабільні, людино-зрозумілі імена і допомагає з firewall-правилами та панелями. Матч по MAC уникає проблем перейменування й дозволяє залишити ім’я ядра. Якщо багато інструментів посилаються на імена інтерфейсів — перейменовуйте на роль. Якщо потрібна лише коректна конфігурація мережі — match-by-MAC простіше.

5) Чи .link файл застосовується одразу?

Іноді — так, але не на нього розраховуйте. Перейменування активних інтерфейсів навмисно обмежене. Зазвичай ви створюєте файл, перезавантажуєте udev і плануєте перезавантаження для впевненості.

6) Як це взаємодіє з bond і bridge?

Ці пристрої часто посилаються на імена slave. Якщо slave змінюються — bond не збереться; якщо ім’я bond зміниться — bridge і VLAN-и впадуть. Стабілізуйте фізичні інтерфейси перш за все, а потім відновлюйте верхню логічну структуру.

7) Що з initramfs і раннім мережевим завантаженням?

Якщо ви залежите від ранньої мережі (віддалене розблокування, iSCSI root), переконайтеся, що ваше іменування/матчинг доступні в initramfs також. Інакше система може впасти до того, як дійде до нормального userspace. Це зазвичай означає оновлення initramfs після зміни іменування.

8) Ми використовуємо правила firewall, прив’язані до імен інтерфейсів. Що робити?

Припиніть зв’язувати правила з нестабільними іменами. Або перейменуйте інтерфейси на стабільні ролі (uplink0), або зв’яжіть firewall з зонами/адресами/марками там, де це можливо. Якщо імена потрібні — зробіть їх стабільними через .link.

9) Чи можу я вибрати ім’я на кшталт eth0 через .link?

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

10) Яке найшвидше безпечне виправлення під час аварії?

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

Висновок: наступні кроки, які можна зробити сьогодні

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

Зробіть наступне:

1. Оберіть стратегію стабільності: матч по MAC для більшості випадків; іменування за слотом там, де прошивка надійна; уникайте path-based у нестабільних топологіях.
2. Впровадьте стабільність явно: systemd .link для перейменування на рольові імена, або match-by-MAC у вашому мережевому менеджері.
3. Виправте ланцюжок залежностей: bonds, VLAN-и, мости, правила firewall, моніторинг — усе, що посилається на старі імена.
4. Запишіть зіставлення: MAC ↔ роль ↔ порт комутатора. Це не гламурно, але швидко закриває інциденти.
5. Перезавантажте один раз на ваших умовах: перевірте лінк, IP, маршрути і досяжність. Потім живіть далі.

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