Презареждането на сертификата на 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 покрива настройките, които могат да се презареждат, и ограничението за адреса, описано тук, и си заслужава да се прочете изцяло, преди да обновявате нещо в продукция.