فهرست مسدودسازی Nebula: آن را توزیع کنید، فانوس دریایی این کار را نخواهد کرد
یک ورودی فهرست مسدودسازی فقط روی میزبان‌هایی اعمال می‌شود که آن را بارگذاری کرده‌اند. توزیع فهرست را با چرخش CA مقایسه کنید، سپس یک همتای ردشده و یک همتای کارآمد را بررسی کنید.
اعمال فهرست مسدودسازی ویژگی میزبانی است که بررسی را انجام می‌دهد، نه گواهی‌ای که بررسی می‌شود. دستگاهی که هرگز ورودی را بارگذاری نکرده است همچنان هویت را می‌پذیرد، و هیچ چیز در دست‌دادن شما را هشدار نمی‌دهد که دو همتا اختلاف دارند. راه‌حل ارزان و راه‌حل گران برای یک اعتبارنامه افشاشده در دامنه و در برگشت‌پذیری تفاوت دارند، پس آگاهانه انتخاب کنید. بخش‌های زیر پوشش می‌دهند که ورودی چه می‌کند، کجا باید تحویل داده شود، چه زمانی چرخش پاسخ بهتر است و چگونه اثبات کنید که هر یک از این دو کار کرده است.
یک ورودی فهرست مسدودسازی در واقع چه می‌کند
پیکربندی PKI اثرانگشت‌هایی را فهرست می‌کند که میزبان باید رد کند، حتی اگر گواهی به‌درستی امضا شده و منقضی نشده باشد. اعمال به‌صورت محلی و در برابر فهرستی انجام می‌شود که آن میزبان هنگام راه‌اندازی سرویس بارگذاری کرده است. هیچ چیز درباره ورودی درون گواهی سفر نمی‌کند، پس همتا نمی‌تواند تصمیم را از اعتبارنامه‌ای که به او نشان داده می‌شود بیاموزد. به همین دلیل فانوس دریایی اینجا هیچ نقشی ندارد: فانوس‌ها به همتاها کمک می‌کنند یکدیگر را بیابند و ترافیک را جایی که مسیر مستقیم شکست می‌خورد بازپخش کنند. آن‌ها لایه کشف و بازپخش هستند، نه کانال توزیع پیکربندی.
به‌روزرسانی یک دستگاه تصمیم‌های همان دستگاه را تغییر می‌دهد و هر همتای دیگر را دقیقاً همان‌گونه که بود رها می‌کند. همتایی که به مرجع امضا اعتماد دارد و هرگز ورودی را ندیده است دلیلی برای رد کردن چیزی ندارد. بنابراین آزمایش ابطال با تماشای فانوس دریایی چیزی را اثبات نمی‌کند، چون از مؤلفه‌ای که تماشا می‌کنید هرگز خواسته نشده فهرست را اعمال کند.
گواهی را شناسایی کنید، نه دستگاه را
اثرانگشت اعتبارنامه‌ای را که قصد رد کردنش را دارید به کار ببرید، چون نام میزبان، برچسب دستگاه یا نشانی کنونی امروز یک دستگاه و ماه بعد چیز دیگری را شناسایی می‌کند. هیچ‌یک از این رشته‌ها در فهرست مسدودسازی ظاهر نمی‌شود و هیچ‌یک از نصب دوباره جان سالم به در نمی‌برد. گواهی را چاپ کنید، اثرانگشت را بخوانید و بررسی کنید که به اعتبارنامه‌ای تعلق دارد که بازنشسته می‌شود، نه به جانشین آن. خواندن هر دو فایل زمانی مهم است که جانشین پیش‌تر صادر شده باشد، زیرا گواهی قدیمی و جدید می‌توانند نامی مشترک داشته باشند و در هر میدان دیگر تفاوت کنند.
ثبت کنید کدام اثرانگشت و چه زمانی مسدود شد، تا یک حسابرسی بعدی تغییری تکمیل‌شده را از تغییری قصدشده جدا کند. به آنچه ورودی انجام نمی‌دهد هم توجه کنید: مرجع امضا را باطل نمی‌کند و مانع پذیرش گواهی آینده از آن مرجع نمی‌شود. مسدود کردن گواهی یک میزبان و جایگزین کردن یک مرجع به‌خطرافتاده دو عملیات متفاوت با پیامدهای متفاوت‌اند.
nebula-cert print -path /etc/nebula/host.crt
pki:
blocklist:
- "a1b2c3d4e5f6"آن را مانند هر پیکربندی دیگری توزیع کنید
با فهرست مانند پیکربندی‌ای با سازوکار تحویل رفتار کنید، نه مانند فایلی که کسی هر وقت یادش آمد ویرایش می‌کند. کل فهرست را به جای یک دلتا بفرستید، تا میزبانی که یک به‌روزرسانی پیشین را از دست داده همگرا شود نه اینکه شکاف جمع کند. مستندات Nebula PKI دقیقاً همین را توصیه می‌کند، و ارزش دارد که توصیه را تحت‌اللفظی دنبال کنید نه اینکه آن را به فرایندی دستی بازنویسی کنید.
تأیید کنید که سرویس در حال اجرا محتوا را دوباره بارگذاری کرده است، نه فقط اینکه فایل روی دیسک تغییر کرده است. پیگیری کنید کدام دستگاه‌ها تغییر را اعمال کرده‌اند و فهرست باقی‌مانده را تا خالی شدن قابل مشاهده نگه دارید. لپ‌تاپی که یک هفته بسته مانده همتایی است که هرگز تصمیم را نیاموخته است، و ممکن است از شبکه‌ای که هیچ‌کس انتظار نداشت دوباره وصل شود. روش تحویل را کنار اثرانگشت ثبت کنید، چون ابطال بعدی از آن دوباره استفاده می‌کند و در اولی است که فرایند اشکال‌زدایی می‌شود.
فهرست مسدودسازی یا چرخش مرجع
ورودی فهرست مسدودسازی باریک است: یک هویت از کار می‌افتد و بقیه ادامه می‌یابد. چرخش مرجع امضا گسترده است: هر گواهی که صادر کرده بی‌اعتماد می‌شود و هر میزبان به اعتبارنامه تازه و لنگر اعتماد تازه نیاز دارد. اولی ابطال هدفمند است و دومی مهاجرت، پس به تأییدهای متفاوت و پنجره‌های نگهداری متفاوت نیاز دارند. جدول این دو را از نظر دامنه، تلاش و برگشت‌پذیری کنار هم می‌گذارد.
| Question | Blocklist entry | Authority rotation |
|---|---|---|
| What stops working | One identity | Every certificate from that authority |
| Fleet work | Push one file and confirm a reload | New credentials and a new trust anchor everywhere |
| Reversible | Yes, remove the line | No, the old authority stays distrusted |
| Fits | A lost or stolen device | A leaked authority key |
لپ‌تاپ گم‌شده فهرست مسدودسازی را می‌طلبد، چون شعاع اثر یک هویت است و اگر اثرانگشت اشتباه را مسدود کرده باشید تغییر برگشت‌پذیر است. کلید مرجع افشاشده چرخش را می‌طلبد، چون فهرست مسدودسازی نمی‌تواند به گواهی‌هایی که هنوز صادر نشده‌اند کمک کند. میان این دو حد، بپرسید آیا اعتبارنامه افشاشده می‌توانست چیز دیگری را امضا کند، چون یک مرجع بیش از یک میزبان است.
پیش از یک حادثه تصمیم را بنویسید، چون انتخاب زیر فشار به‌طور پیش‌فرض گزینه گسترده را تولید می‌کند. هر مسیری که بروید، کار باقی‌مانده یکسان است: اثبات اینکه اعمال روی میزبان‌هایی که اهمیت دارند رخ داده است. ثبت اثرانگشت و تاریخ در همان لحظه چیزی است که اثبات را بعداً ممکن می‌کند.
رد شدن و باقی‌مانده را بررسی کنید
از هویت مسدودشده وصل شوید و شکست را تأیید کنید، سپس از یک همتای مجاز وصل شوید و تأیید کنید که هنوز به آنچه نیاز دارد می‌رسد. تغییری که همه را می‌شکند ابطال موفقی نیست. هر دو را از نشست‌های تازه انجام دهید، چون وضعیت ذخیره‌شده می‌تواند نتیجه را پنهان کند.
بررسی کنید آیا یک نشست برقرارشده پس از تغییر پایان می‌یابد، و رفتار را برای نسخه و پیکربندی خود یادداشت کنید به جای اینکه فرض کنید ویرایش یک فایل چیزی را پایان می‌دهد. گزینه disconnect_invalid مشتریانی را پوشش می‌دهد که گواهی‌هایشان منقضی یا نامعتبر است، پس پیش از تکیه بر آن تأیید کنید که در مورد شما چگونه اعمال می‌شود. اگر پایان فوری یک الزام است، آن را به‌طور مشخص آزمایش کنید و آنچه مشاهده کردید ثبت کنید. سپس آزمون را پس از راه‌اندازی دوباره تکرار کنید، چون میزبانی که فهرست را فقط تا راه‌اندازی بعدی‌اش اعمال می‌کند مشکل تحویلی دارد که آزمون نخست آن را پنهان کرده بود. فانوس دریایی سالم به شما می‌گوید کشف کار می‌کند، نه اینکه همتایی خط‌مشی‌ای اعمال کرده است.