Nebula нужны три файла: CA, сертификат хоста и ключ хоста

Если дать кому-то каталог Nebula, он обычно копирует всё, включая файл, который никогда не должен покидать вашу рабочую станцию. Путаница понятна: три файла в блоке PKI хоста выглядят одинаково, и два из них — сертификаты. Каждый отвечает на свой вопрос, и только два из них принадлежат узлу. Разложите их по ролям, прежде чем что-то копировать.

Три файла, три разные задачи

Сертификат CA — это якорь доверия: он говорит хосту, каким центрам верить, когда другой хост предъявляет свою личность. Сертификат хоста — это собственное удостоверение узла, подписанное этим центром. Ключ хоста — соответствующая закрытая половина, и он принадлежит ровно одной машине. Узел с сертификатом CA и собственной парой может войти в overlay и доказать, кто он. Узел с чужим ключом тоже может выдавать себя за этого человека, и именно эту ошибку призвана предотвратить такая схема.

Поэтому копирование рабочего каталога хоста на вторую машину — не короткий путь. Это дублированная личность с предсказуемым исходом.

Ключ подписи никогда не путешествует

Ключ подписи CA не входит ни в одну конфигурацию хоста. Он создаёт новые личности, и тот, у кого он есть, может выпустить сертификат для любого адреса overlay и любой группы. Пиринг-узлам для проверки подписей нужен только открытый сертификат CA, поэтому закрытая половина на клиенте вообще не имеет роли. Держите его на машине, где выпускаются сертификаты, и считайте случайную копию инцидентом, а не удобством.

Если сертификаты должны выпускать несколько человек, дайте им процесс, а не копию ключа. Общий ключ подписи на ноутбуке — это полномочие, которое никто не может проверить или отозвать.

Что находится внутри сертификата хоста

Сертификат хоста связывает с ключом нечто большее, чем имя файла. Он несёт адрес узла в overlay, его имя и членство в группе — всё подписано, чтобы пиринг-узел мог решить, принимать ли его. Поэтому переименование хоста означает выпуск нового сертификата, а не правку строки конфигурации.

nebula-cert print -path host.crt показывает, что было выпущено на самом деле. Прочитайте его, прежде чем предполагать, что сертификат содержит нужный вам адрес.

Перезагрузки не всегда достаточно

Некоторые настройки PKI перезагружаются по сигналу, а некоторые нет. Сертификат, у которого изменился адрес в overlay — классический случай, требующий перезапуска процесса, а не перезагрузки.

Убедитесь, какие пути процесс на самом деле открыл, а не только какие пути указаны в файле конфигурации. Затем смените одно удостоверение, проверьте связность и журналы, и только после этого беритесь за следующее. Перезагрузка, которая выглядит успешной, пока старый сертификат остаётся в памяти, создаёт несоответствие, похожее на проблему маршрутизации. Перезапуск дёшев; отладка личности, которую половина overlay всё ещё видит по-старому, — нет.

Удаление личности требует списка блокировки

Замена утраченного или раскрытого удостоверения состоит из двух половин. Новый сертификат возвращает доступ, а старая личность должна перестать приниматься. Это разные операции, и выполнение только первой оставляет скомпрометированное удостоверение действительным.

Список блокировки — это файл, который вы распространяете по хостам, а не то, что lighthouse рассылает сам. Спланируйте, как он дойдёт до каждого узла, включая те, что сегодня офлайн, и запишите, какие отпечатки вы заблокировали. Смените ключ на машине, которая выпускает сертификаты, и храните данные нового сертификата вместе с записью хоста. Отзыв, который существует только на отредактированной вами машине, — не отзыв.