שם נפוץ אחד, שני אישורים: רשימת היתר או ביטול?

הוצאת אישור מחשב נייד מחדש תחת אותו שם נפוץ מרגישה כמו החלפה, וכולם מניחים שהישן מת. הוא לא. קודמו נשאר אישור תקף החתום על ידי אותה רשות, וכל בקרה שמקבלת לקוחות לפי שם תמשיך לקבל אותו. מה שמפריד בין בדיקת זהות לבדיקת אישורים הוא המספר הסידורי, ושם צריך להיות התיקון.

התחילו במדיניות השמות שהשרת משתמש בה

שתי בקרות מתבלבלות: קבלת לקוח בגלל מי שהוא טוען להיות, והוצאת אישור מסוים אחד משירות. הראשונה היא בדיקת שם, השנייה היא בדיקת ביטול. הן עונות על שאלות שונות, ופריסה יכולה להחזיק באחת בלי השנייה.

קראו את תצורת השרת וציינו איזה מקור זהות פועל. username-as-common-name הופך את שם המשתמש המאומת לשם האפקטיבי לחיפושים ספציפיים ללקוח. בלעדיו משתמשים בשם הנפוץ של הנושא מהאישור. תהיה התשובה אשר תהיה, רשמו אותה לפני שתגעו ברשימת היתר כלשהי.

שני המסלולים מייצרים קבוצה שונה של שמות מורשים לאותו אישור. ניחוש כאן פירושו עריכת הקובץ הלא נכון והסקה שהבקרה אינה פועלת.

בדקו מה באמת מקבל לקוח

הגדרת client-config-dir עם קובץ תואם מספקת אפשרויות לכל לקוח; כשלעצמה היא אינה כלל קבלה. קבלה לפי שם מחייבת ccd-exclusive, שדוחה לקוחות שאין להם קובץ תואם. הפעלתו בפריסה פעילה מנתקת את כל מי שלשמו אין קובץ, אז ספרו את הקבצים לפני שתהפכו משהו.

grep -nE 'ccd-exclusive|client-config-dir|username-as-common-name' /etc/openvpn/server/server.conf
ls -1 /etc/openvpn/ccd/

הספירה היא הבדיקה: השוו את רשימת הספרייה לזהויות שאתם מצפים שיתחברו.

לאחר מכן ודאו שכל שם קובץ תואם בדיוק לזהות האפקטיבית, כולל אותיות גדולות וקטנות ורווחים. קובץ עבור office-laptop לא עושה דבר עבור אישור שהנושא שלו Office-Laptop. קורא. גם רווחים בסוף מסתתרים מרשימה רגילה, וכך קובץ שנראה קיים נשאר בלתי קרוא.

בדקו את ה-CRL שהשער טוען

CRL מפרט אישורים שבוטלו לפי מנפיק ומספר סידורי, וזו הרזולוציה שבדיקת שם חסרה. שני אישורים יכולים לחלוק שם נפוץ ולהיות שונים במספר הסידורי, ורק רשימה ברמת המספר הסידורי מפרידה ביניהם.

ודאו את הנתיב המוגדר, את תאריך ההנפקה ואת שדה העדכון הבא לפני שתסמכו על הקובץ בכלל.

openssl crl -in /etc/openvpn/crl.pem -noout -lastupdate -nextupdate
openssl x509 -in office-laptop.crt -noout -serial -subject

השוו את המספר הסידורי ב-CRL למספר הסידורי באישור שאתם מתכוונים לשמור. ההשוואה הזו היא כל המבחן, ולעשות אותה פעם אחת בעין שווה יותר מלסמוך על סקריפט שאיש לא קרא. הפיצו את ה-CRL המעודכן בנתיב שהשער כבר קורא. CRL שנמצא בספרייה הלא נכונה אינו אוכף דבר, ואף יומן לקוח לא יזכיר אותו.

החליפו, ואז הוכיחו את שתי התוצאות

הנפיקו את ההחלפה תחת אותו שם נפוץ, רשמו את שני המספרים הסידוריים, ורק אז בטלו את הישן. הסדר הזה משאיר זהות עובדת זמינה בזמן שאתם מכינים את השינוי.

בדקו קודם את ההחלפה: היא אמורה לאמת את עצמה ולהגיע לכל מה שהשם שלה זכאי לו. אחר כך בדקו את האישור הישן וודאו שהוא נדחה, כי החלפה מוצלחת אינה אומרת דבר על ביטול. אם שניהם עדיין מתחברים, קלט הביטול אינו נקרא או שהמספר הסידורי הישן מעולם לא נרשם. אם אף אחד אינו מתחבר, שברתם את כלל הקבלה ולא את האישור.

סשנים שכבר הוקמו הם עניין נפרד, שכן הביטול חל על אימותים חדשים אלא אם השער מוגדר גם להפיל חיבורים חיים. החליטו אם נדרשת הסרה מיידית לפני שתבטיחו זאת למישהו.

מה שבדיקת שם לעולם לא תוכל לעשות

רשימת היתר עונה אם הזהות הזו רשאית להתחבר. היא אינה יכולה לומר באיזה אישור השתמשה הזהות הזו, והיא תקבל אישור ישן יותר כל עוד האישור נשאר תקף ולא מבוטל. הפער הזה עולה במהלך אירוע, כשההחלפה הונפקה לפני חודשים והקודם עדיין עובד.

היכן שנדרשת בקרה ברמת האישור, השתמשו במנגנון שמפרט את האישור: רשומות CRL, או וו אימות שבודק טביעת אצבע שהמפעיל מתחזק. שניהם עולים תחזוקה, ושניהם כנים לגבי האובייקט שהם בוחנים. מדריך OpenVPN 2.6 מתעד crl-verify וקבלת לקוח ספציפית כאפשרויות נפרדות מסיבה זו.

רשמו איזו בקרה עושה איזו עבודה, ואז בדקו את המקרה השלילי. ביטול שמעולם לא ראיתם אותו דוחה חיבור הוא תצורה שאתם מקווים שתעבוד.