Перазагрузка сертыфіката Nebula не змяніла IP: вось чаму
Перазагрузка перачытвае ўліковыя даныя хоста толькі тады, калі адрас у оверлеі застаецца тым жа. Змена адраса азначае перазапуск і змену сеткі, а не паўторную спробу.
Вы выпускаеце новы сертыфікат хоста з іншым оверлейным адрасам, капіюеце яго паверх старога файла, адпраўляеце перазагрузку, і хост працягвае адказваць на адрасе, які меў раней. Рэфлекс — меркаваць, што перазагрузка не ўдалася або што быў прачытаны не той файл. Звычайна не адбылося ні таго, ні другога: працэс, які выконваецца, наўмысна захаваў ідэнтычнасць, якая ўжо была, бо замена змяніла нешта, чаго перазагрузка не можа прымяніць.
Падтрымка перазагрузкі PKI у Nebula дакументаваная менавіта з гэтай мяжой, і гэта лёгка прапусціць, калі тая ж дакументацыя паказвае, што перазагрузка працуе для іншых змяненняў.
Што перазагрузка насамрэч перачытвае
Сертыфікат хоста — гэта не проста ўліковыя даныя, як ключ SSH. Ён нясе оверлейны адрас, імя хоста, членства ў групах і акно сапраўднасці, і ўсё гэта звязваецца подпісам CA. Дэман выкарыстоўвае гэты падпісаны змест, каб вырашыць, як сябе прадстаўляць і якія правілы да яго ўжываюцца.
Перазагрузка дазваляе працэсу падхапіць абноўленыя ўліковыя даныя, не скідваючы свае тунэлі, што каштоўна для звычайнай ратацыі: той жа адрас, тое ж імя, тыя ж групы, пазнейшы тэрмін дзеяння. Абмежаванне ў тым, што ідэнтычнасць павінна застацца той жа. Зменіце оверлейны адрас — і шлях перазагрузкі не зможа яго прымяніць, бо адрас з’яўляецца часткай таго, на што працэс ужо абавязаўся.
Такім чынам, паводзіны, якія вы бачылі, — гэта дакументаванае абмежаванне, якое робіць сваю працу, а не маўклівая адмова. Файл на дыску новы; ідэнтычнасць у памяці старая; працэс не мае падтрымліванага спосабу ўзгадніць гэтую розніцу без перазапуску.
Адрас, імя і групы — адна ідэнтычнасць
Карысна думаць пра сертыфікат як пра адзін запіс, а не як пра набор палёў, якія можна рэдагаваць незалежна. Перанос адраса не падобны да змены налады, бо адрас прысутнічае ў канфігурацыях суседзяў на іншых хостах, у прывязках сэрвісаў і ў палітыках, напісаных супраць ідэнтычнасці.
| Field | What changes when you replace it |
|---|---|
| Overlay address | Peers that pinned the old address, service bindings, and any rule written against it |
| Host name | Name-based policy and the identities other hosts expect to see |
| Groups | Which access rules match, even if the address stays identical |
| Validity window | Nothing structural, which is why renewal reloads cleanly |
Групы заслугоўваюць асобнага радка, бо яны выклікаюць цішэйшую версію той жа блытаніны. Хост, які захоўвае свой адрас, але пераходзіць у іншыя групы, пасля перазапуску можа дасягаць іншых сэрвісаў, і тэст, які толькі пінгуе стары адрас, будзе выглядаць цалкам здаровым, пакуль рашэнні аб доступе змяніліся ўнізе. Праверце адзін сэрвіс з правілам, а не толькі дасягальнасць. Гэта розніца паміж пацвярджэннем тунэля і пацвярджэннем палітыкі.
Параўнайце загружаны сертыфікат з заменай
Перш чым меркаваць, што дэман праігнараваў файл, прачытайце абодва. Вывядзіце сертыфікат, які збіраецеся загрузіць, і пацвердзіце палі, якія, на вашу думку, змянілі, потым пацвердзіце, што бягучая канфігурацыя паказвае на гэты шлях, а не на копію ў іншым месцы.
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 апісвае налады, якія можна перазагрузіць, і абмежаванне адраса, апісанае тут, і яе варта прачытаць цалкам, перш чым ратаваць што-небудзь у прадукцыі.