نیمی از محیط پس از تمدید دوباره متصل می‌شود و سه دستگاه امتناع می‌کنند، هر یک با هشداری درباره هویت دروازه. خود تمدید روتین است. آنچه آن سه دستگاه نگه می‌دارند یک پین به شیء قدیمی است، و پین فهرست CA، بررسی نام یا ورودی مخزن اعتماد نیست. پیش از دست زدن به هر کلاینتی سه سازوکار را مقایسه کنید.

یک تمدید، دو رفتار

کلاینت‌هایی که دوباره متصل می‌شوند تصمیم اعتمادی دارند که هنوز می‌گذرد، و آنهایی که امتناع می‌کنند شرطی دارند که گواهی جدید آن را برآورده نمی‌کند. این تفاوت اطلاعات است نه نویز. پیام کلاینت شکست‌خورده را دقیق بخوانید. عدم تطابق نام، صادرکننده ناشناخته و اثر انگشت تغییرکرده سه حکم متفاوت‌اند و تنها آخری به پین اشاره دارد.

همچنین بررسی کنید کلاینت شکست‌خورده کدام پروفایل را انتخاب کرده است. نسخه واردشده‌ای که در مخزن خودش زندگی می‌کند وقتی مدیر فایل اصلی را جای دیگری ویرایش می‌کند تغییر نمی‌کند.

تمدید شیء را جایگزین می‌کند، نه فقط تاریخ را

اثر انگشت محتوای رمزگذاری‌شده گواهی را شناسایی می‌کند. تمدید گواهی جدیدی تولید می‌کند، بنابراین اثر انگشت حتی وقتی نام موضوع و کلید عمومی یکسان می‌مانند تغییر می‌کند. این برای کلاینت‌هایی که به CA اعتماد می‌کنند و نام را بررسی می‌کنند مورد انتظار و بی‌ضرر است. برای کلاینتی که برای پذیرش دقیقاً یک گواهی پیکربندی شده کشنده است، و برای کلاینتی که مخزن اعتمادش هرگز صادرکننده جدید را دریافت نکرده نیز کشنده است.

openssl x509 -in server.pem -noout -subject -issuer -dates -fingerprint -sha256
openssl x509 -in server.pem -noout -pubkey | openssl sha256

خط دوم به پرسش دیگری پاسخ می‌دهد: آیا جفت کلید زنده ماند. تمدیدی که کلید را دوباره استفاده کرده آن مقدار را حفظ می‌کند و تنها گواهی را تغییر می‌دهد، که دقیقاً همان حالتی است که مدیر وسوسه می‌شود فرض کند چیزی تغییر نکرده است. گواهی مستقرشده را بازرسی کنید، نه آن یکی روی میزبان ساخت. مقایسه یک فایل در مخزن اثبات می‌کند چه تولید شده، نه آنچه یک شنونده اکنون ارائه می‌دهد.

بخوانید کلاینت چه چیزی را پین می‌کند

برخی کلاینت‌ها اثر انگشت را در پروفایل خود نگه می‌دارند و در هر اتصال آن را مقایسه می‌کنند. دیگران آن را در مخزن اعتماد پلتفرم ذخیره می‌کنند، و برخی دیگر فقط به CA تکیه می‌کنند. ترمیم در هر حالت متفاوت است، پس ابتدا سازوکار را شناسایی کنید.

grep -n 'peer-fingerprint' /etc/openvpn/client/*.conf
openssl s_client -connect gw.lab.example.net:443 -servername gw.lab.example.net < /dev/null 2>&1 | openssl x509 -noout -fingerprint -sha256

فرمان اول پینی را در یک پروفایل متعارف نشان می‌دهد؛ دومی اثر انگشتی را نشان می‌دهد که نقطه پایانی واقعاً همین حالا ارائه می‌کند. وقتی این دو متفاوت باشند، خرابی را بدون حدس زدن پیدا کرده‌اید. مقدار جدید را در هر کلاینتی که شکایت می‌کند نچسبانید. کلاینتی که به دلیل صادرکننده امتناع می‌کند به امتناع ادامه می‌دهد و شما به خودتان آموخته‌اید که اثر انگشت مشکل بود در حالی که نبود.

گواهی هر بک‌اند را مقایسه کنید

نتایج متناوب معمولاً به معنای بیش از یک نقطه پایانی است، و تمدیدی که روی یک گره اعمال شده دیگران را با شیء قدیمی رها می‌کند. هر بک‌اند را با نشانی مقایسه کنید نه با نام مشترک.

for h in 10.30.0.11 10.30.0.12; do echo "$h"; openssl s_client -connect $h:443 -servername gw.lab.example.net < /dev/null 2>&1 | openssl x509 -noout -subject -dates -fingerprint -sha256; done

استخری که یک گره در آن عقب مانده کلاینتی را توضیح می‌دهد که در تلاش دوم متصل می‌شود و در اولی شکست می‌خورد. همچنین بررسی پایشی را توضیح می‌دهد که در حال شکایت کاربران می‌گذرد. ابتدا عقب‌ماندگی را درست کنید. غلتاندن پیکربندی اعتماد پیش از آنکه هر گره گواهی جدید را ارائه کند پنجره‌ای می‌سازد که هیچ چیز کار نمی‌کند، و غلتاندن پس از آن کلاینت‌ها را به شکست غیرقابل پیش‌بینی وا می‌گذارد.

اعتماد را از مسیر مدیریت‌شده تغییر دهید

جایگزینی را پیش از پذیرش در هر جا از طریق کانال اداری از قبل قابل اعتماد تأیید کنید. تاریخ انقضای باورپذیر اثبات مالکیت نیست. پیکربندی مدیریت‌شده را از طریق فرآیندی که مالک آن است به‌روز کنید، با هر هم‌پوشانی برنامه‌ریزی‌شده از هویت‌های قابل قبول، و بررسی نامی را که استقرار می‌طلبد حفظ کنید. پین بدون بررسی نام طرحی ضعیف‌تر از اعتماد CA است که جایگزینش کرده.

سپس به تفکیک کلاینت بررسی کنید: متصل شوید، هویتی را که پذیرفت تأیید کنید و نسخه گواهی‌ای که اکنون به آن اعتماد دارد را یادداشت کنید. هشداری که یک بار کنار گذاشته شود راهی برای بازگشت در تمدید بعدی دارد.

مقالات مرتبط