לקוח שנשלל עדיין מתחבר: הרשימה מעולם לא הגיעה
שלילה היא קלט לאימות התעודה, לא פקודה שמסיימת הפעלה. השוו כיצד חיבור חדש ומנהרה פעילה רואים את הרשימה.
שלילה לעולם אינה נכנסת למנהרה פעילה כדי למחוק הפעלה. הרשימה היא קלט לאימות התעודה והיא נבדקת במהלך החלפת ערוץ הבקרה שפותח הפעלת TLS. העובדה האחת הזו מסבירה את שתי ההפתעות: לקוח שנשלל מתחבר שוב כי הרשימה מעולם לא הגיעה למאמת, והפעלה קיימת ממשיכה לחיות כי איש לא אימת דבר מחדש.
רשימה היא קלט, לא פעולה
בעת הקמת ההפעלה השרת מאמת את תעודת הלקוח מול עוגני האמון שלו, והוראת השלילה מוסיפה לכך חיפוש ברשימה. הבדיקה מתרחשת בשרת, ולכן הלקוח אינו יכול לראות שתעודתו נשללה וממשיך להציע את אותה תעודה. לכן פרופיל שעדיין מתחבר מוכיח רק שמאמת כלשהו קיבל את השרשרת, ולא שהשלילה נכשלה.
הרשימה עצמה היא אובייקט חתום עם תאריך הנפקה ותאריך עדכון הבא. רשימה לא קשורה, רשימה שנחתמה בידי רשות אחרת או כזו שתאריך העדכון הבא שלה עבר אינן תחליף לרשימה הנוכחית, והאם רשימה מיושנת נדחית או מתקבלת בשקט תלוי בפריסה.
חיבור חדש מול הפעלה פעילה
השלילה מוערכת כשההפעלה נוצרת או מנוהלת מחדש, ולא מול ערוץ הנתונים בכל מנה. לקוח שכבר מחובר מחזיק במפתחות תעבורה, ולכן ממשיך להעביר מנות לאחר שתעודתו מופיעה ברשימה. מרווח המו״מ מחדש המוגדר כברירת מחדל נמדד בשעות, ולכן רשימה מעודכנת יכולה לחול על מצטרפים חדשים בעוד מנהרה פעילה נשארת.
| Situation | What the list does | When it applies |
|---|---|---|
| Fresh connection | Blocks the handshake | At verification, immediately |
| Renegotiation | Blocks the new exchange | At the next renegotiation interval |
| Established data channel | Nothing | Until the session ends |
אכיפה מיידית דורשת פעולה מכוונת ולא רק את הרשימה. הפעלה מחדש של השירות מכריחה כל לקוח להתחבר שוב, ואילו סיום הפעלה אחת דרך ממשק הניהול מותיר את האחרות ללא פגע. בחרו אחת לכל אירוע ורשמו באיזו השתמשתם. לשתי האפשרויות רדיוס השפעה שונה, וזו ההחלטה האמיתית.
מסרו את הקובץ שהמאמת באמת קורא
את הרשימה יש ליצור מרשומת הרשות ואחר כך להעתיק לכל מכונה שמאמתת תעודות. יצירתה במארח ה-CA ובלי להתקין אותה בשרת היא הכשל הנפוץ ביותר, והיא נראית בדיוק כמו תכונת שלילה שבורה.
ca ca.crt
cert server.crt
key server.key
crl-verify /etc/openvpn/crl.pemשני פרטים מכריעים אם הקובץ באמת נקרא. נתיב יחסי נפתר מול ספריית התצורה, ולכן עותק שהושאר בספריית הבית של מפעיל עשוי לא להימצא לעולם. והדמון בדרך כלל מוותר על הרשאות לאחר העלייה, ולכן חשבון הריצה זקוק להרשאת חיפוש בכל ספריית אב ולהרשאת קריאה בקובץ. בדקו את שניהם עם חשבון הריצה ולא עם root, אחרת הבדיקה מוכיחה את הדבר הלא נכון.
במארחי systemd יחידה מוקשחת יכולה גם להסתיר את הנתיב, בתצוגה לקריאה בלבד או בספריית מערכת מוגנת. מבפנים לשירות זה אינו ניתן להבחנה מקובץ חסר, ולכן בדקו את מגבלות היחידה לפני שאתם יוצאים לחפש טעות הרשאה. קראו את קובץ היחידה לפני שאתם מאשימים את מצב הקובץ.
אמתו בשרת, לא בלקוח
יומן השרת נוקב במה שקרה: פתיחת הרשימה, טעינתה או כישלון אימות עם המספר הסידורי שנשלל. הלקוח מדווח רק על כשל לחיצת יד כללי, ולכן יומני הלקוח הם מקום גרוע לחפש בו החלטת שלילה.
אמתו בניסיון טרי מהפרופיל שנשלל ואז עצרו. חיבור מוצלח מאותו פרופיל הוא האות לבדוק את נתיב הקובץ ואת חשבון הריצה, ולא להניח שהרשימה הייתה שגויה. שמרו את הניסיון המוצלח הזה כמבחן קבלה, ואל תספרו התחברות מחדש שלא צפיתם בה.
מה לא שולל דבר
מחיקת הפרופיל ממחשב נייד, הסרת קובץ התעודה מהלקוח או אמירה למשתמש להפסיק להתחבר אינן משנות דבר בשרת. התעודה נשארת תקפה עד שהרשות רושמת את השלילה והמאמת קורא את הרשימה שנוצרה.
זו גם הסיבה שכדאי לכתוב את השרשרת: רשמו את השלילה, צרו וחתמו את הרשימה, הפיצו בדיוק את הקובץ הזה, ואמתו שחשבון השירות יכול לקרוא אותו. כל חוליה קצרה, וכל חוליה חסרה משאירה לקוח שנשלל מתחבר בשמחה. רשימת בדיקה בת ארבע שורות עדיפה על הנחה בלי אף אחת.