بارگذاری مجدد گواهی Nebula نشانی IP را تغییر نداد: دلیلش اینجاست
بارگذاری مجدد فقط زمانی اعتبارنامه میزبان را دوباره میخواند که نشانی overlay یکسان بماند. تغییر نشانی یعنی راهاندازی مجدد و تغییر شبکه، نه تلاش دوباره.
گواهی میزبان جدیدی با نشانی overlay متفاوت صادر میکنید، آن را روی فایل قدیمی کپی میکنید، بارگذاری مجدد را میفرستید و میزبان همچنان روی نشانی قبلی پاسخ میدهد. واکنش طبیعی این است که گمان کنید بارگذاری مجدد شکست خورده یا فایل اشتباهی خوانده شده است. معمولاً هیچیک رخ نداده است: فرایند در حال اجرا عامدانه همان هویتی را نگه داشته که از قبل داشت، چون جایگزین چیزی را تغییر داده که بارگذاری مجدد نمیتواند اعمال کند.
پشتیبانی بارگذاری مجدد PKI در Nebula با همین مرز مستند شده است و وقتی همان مستندات نشان میدهد بارگذاری مجدد برای تغییرات دیگر کار میکند، بهراحتی از چشم میافتد.
بارگذاری مجدد در واقع چه چیزی را دوباره میخواند
گواهی میزبان فقط یک اعتبارنامه به معنای کلید SSH نیست. نشانی overlay، نام میزبان، عضویت در گروهها و بازه اعتبار را حمل میکند و همه اینها با امضای CA به هم پیوند خوردهاند. سرویسدهنده از این محتوای امضا شده استفاده میکند تا تصمیم بگیرد خود را چگونه معرفی کند و کدام قواعد بر آن اعمال میشود.
بارگذاری مجدد به فرایند اجازه میدهد اعتبارنامه تازهشده را بدون انداختن تونلهایش بردارد، و این برای چرخش دورهای ارزشمند است: همان نشانی، همان نام، همان گروهها، انقضای دیرتر. محدودیت این است که هویت باید یکسان بماند. نشانی overlay را تغییر دهید و مسیر بارگذاری مجدد نمیتواند آن را اعمال کند، چون نشانی بخشی از چیزی است که نمونه در حال اجرا از قبل به آن متعهد شده است.
پس رفتاری که دیدید همان محدودیت مستند است که کار خودش را میکند، نه یک شکست خاموش. فایل روی دیسک نو است؛ هویت در حافظه قدیمی است؛ فرایند هیچ راه پشتیبانیشدهای برای آشتی دادن این تفاوت بدون راهاندازی مجدد ندارد.
نشانی، نام و گروهها یک هویتاند
کمک میکند گواهی را یک رکورد واحد ببینید نه مجموعهای از فیلدها که جداگانه ویرایش میکنید. جابهجا کردن نشانی مانند تغییر یک ترجیح نیست، چون نشانی در پیکربندی همتاهای میزبانهای دیگر، در اتصال سرویسها و در سیاستهای نوشتهشده علیه هویت ظاهر میشود.
| 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 |
گروهها لایق سطر جداگانه هستند چون نسخه آرامتری از همان سردرگمی را ایجاد میکنند. میزبانی که نشانیاش را نگه میدارد اما گروههایش را عوض میکند، پس از راهاندازی مجدد میتواند به سرویسهای دیگری برسد، و آزمونی که فقط نشانی قدیمی را ping میکند کاملاً سالم به نظر میرسد در حالی که تصمیمهای دسترسی در زیر آن تغییر کردهاند. یک سرویس تحت قاعده را بررسی کنید، نه فقط دسترسیپذیری را. تفاوت میان تأیید تونل و تأیید سیاست همین است.
گواهی بارگذاریشده را با جایگزین مقایسه کنید
پیش از آنکه گمان کنید سرویسدهنده فایل را نادیده گرفته است، هر دو را بخوانید. گواهیای را که میخواهید بارگذاری کنید چاپ کنید و فیلدهایی را که فکر میکنید تغییر دادهاید تأیید کنید، سپس تأیید کنید که پیکربندی در حال اجرا به همان مسیر اشاره میکند نه به نسخهای در جای دیگر.
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 آن فایل را میخواند، و گواهی نصبشده در پوشهای موقت هیچ تأثیری ندارد. مسیر را در خط فرمان در حال اجرا بررسی کنید، نه مسیر در مستنداتی که دنبال کردهاید. اگر این دو متفاوت باشند، مشکل را بدون دست زدن به گواهی پیدا کردهاید.
اگر گواهی جدید نشانی متفاوتی داشته باشد و فرایند نشانی قدیمی را نگه داشته باشد، اکنون به جای معما توضیح دارید. اگر پذیرفتنی است آن را دوباره راهاندازی کنید و تغییر نشانی را بهعنوان تغییری برنامهریزیشده در شبکه ببینید نه تصادفی.
تغییر نشانی، تغییر شبکه است
آن را همانطور برنامهریزی کنید که جابهجا کردن یک ماشین را برنامهریزی میکنید. ممکن است میزبانهای دیگر نشانی قدیمی را در پیکربندی خود سنجاق کرده باشند، سرویسها صریحاً به آن متصل شوند و قواعد دیوار آتش علیه آن نوشته شده باشد. تغییر گواهی میزبان را جابهجا میکند و جابهجایی میزبان فرضهای جاهای دیگر را بیاعتبار میکند.
در حین انجام این کار یک مسیر مدیریت دوم در دسترس نگه دارید، چون ممکن است اتصال overlay همان چیزی باشد که قطع میکنید. انجام این کار از روی تونلی که در آستانه شکستن آن هستید، راه کلاسیک تبدیل یک تغییر پنجدقیقهای به یک بازدید حضوری است.
پذیرفتنی بودن راهاندازی مجدد به کاری بستگی دارد که میزبان انجام میدهد و این پرسشی از جنس زمانبندی است نه فنی. آنچه اختیاری نیست، پذیرش نیاز به راهاندازی مجدد است به جای فرستادن بارگذاری مجدد برای بار پنجم.
اعتبارنامه قدیمی را جداگانه بازنشسته کنید
نصب جایگزین روی یک ماشین باعث میشود هر همتا همچنان به اعتبارنامهای که از قبل میشناسد اعتماد کند. اگر دلیل تغییر افشا بوده است، هویت قدیمی باید از طریق رویه اعتماد یا فهرست مسدودسازی بازنشسته شود تا همتاها واقعاً آن را رد کنند.
این گامی جداگانه با راستیآزمایی خودش است: از میزبان دیگری تأیید کنید که هویت قدیمی دیگر کار نمیکند، به جای آنکه گمان کنید فایل جدید کار را انجام داده است. مستندات پیکربندی PKI در Nebula تنظیمات قابل بارگذاری مجدد و محدودیت نشانی که اینجا توضیح داده شد را پوشش میدهد و ارزش دارد پیش از چرخش هر چیز تولیدی آن را کامل بخوانید.