Перезавантаження сертифіката Nebula не змінило IP: ось чому

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

Підтримка перезавантаження PKI у Nebula задокументована саме з цією межею, і її легко проґавити, коли та сама документація показує, що перезавантаження працює для інших змін.

Що перезавантаження насправді перечитує

Сертифікат хоста — це не просто облікові дані, як ключ SSH. Він несе адресу в оверлеї, ім’я хоста, членство в групах і строк дії, і все це пов’язане підписом CA. Демон використовує цей підписаний вміст, щоб вирішити, як себе подавати й які правила до нього застосовуються.

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

Тож побачена поведінка — це задокументоване обмеження, яке робить свою роботу, а не тиха відмова. Файл на диску новий; ідентичність у пам’яті стара; процес не має підтримуваного способу узгодити цю різницю без перезапуску.

Адреса, ім’я та групи — одна ідентичність

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

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

Порівняйте завантажений сертифікат із заміною

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

nebula-cert print -path /etc/nebula/host.crt
systemctl status nebula
ps -o args= -p $(pgrep -f 'nebula -config' | head -1)

Аргументи процесу важливіші, ніж очікують. Модуль, який передає -config /etc/nebula/config.yml, читає запис pki.cert того файлу, а сертифікат, встановлений у тимчасовий каталог, ні на що не впливає. Перевірте шлях у робочому командному рядку, а не шлях у документації, якої ви дотримувалися. Якщо вони різняться, ви знайшли проблему, навіть не торкаючись сертифіката.

Якщо новий сертифікат має іншу адресу, а процес зберіг стару, тепер у вас є пояснення, а не загадка. Перезапустіть його, якщо це прийнятно, і ставтеся до зміни адреси як до планованої зміни мережі, а не випадкової.

Зміна адреси — це зміна мережі

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

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

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

Відкличте старі облікові дані окремо

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

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