OpenVPN בלי תעודת לקוח: מדיניות שרת, לא פרופיל

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

הפרופיל אינו המדיניות

Community OpenVPN 2.6 מגיע עם תעודות לקוח חובה, כי verify-client-cert כברירת מחדל הוא require. הגדרתו ל-none היא מה שמפסיק את הדרישה לתעודה ומעביר את אימות הלקוח לכל סידור של שם משתמש וסיסמה שהשרת כבר מפעיל. מדריכים ישנים מגיעים אל client-cert-not-required, הכתיב הישן של אותו רעיון, ולכן השתמשו בהנחיה שהגרסה המותקנת שלכם מתעדת. בכל מקרה השינוי מתרחש בשרת, ואף פרופיל לקוח לא יכול לבצע אותו.

הקטע שלהלן הוא כל השינוי בצד השרת, וכשלעצמו אינו תצורת אימות עובדת. verify-client-cert none מסיר את דרישת התעודה, בעוד username-as-common-name הופך את שם החשבון לזהות שרואים קריאות חוזרות מאוחרות יותר וקבצים לכל לקוח. אף אחת מהשורות לא בודקת סיסמה, ולכן מאמת עדיין חייב להתקיים.

verify-client-cert none
username-as-common-name

המאמת הזה הוא תוסף או סקריפט שמופעל על ידי auth-user-pass-verify, והוא חייב להיות במקום לפני שאחת השורות למעלה משמעותית. היפוך הסדר נותן חלון שבו השרת לא דורש תעודה ולא בודק חשבון.

מה עדיין מאמת את השרת

ויתור על תעודת הלקוח אינו ויתור על TLS. השרת שומר על התעודה והמפתח שלו, והלקוח שומר על אמון ה-CA ועל בדיקות שם המארח שמונעות ממנו לדבר עם מתחזה. הסרת remote-cert-tls server או חבילת ה-CA משום שלקוח אין עוד תעודה היא קריאה שגויה נפוצה וחמורה, ו תיעוד 2.6 מפורש שהשני כיוונים בלתי תלויים. האחד מוכיח את השרת ללקוח; האחר מוכיח את הלקוח לשרת.

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

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

מה המאמת חייב לעשות

משנדרישת התעודה הוסרה, הכול נשען על המאמת: תוסף, או סקריפט שמופעל על ידי auth-user-pass-verify. עליו לדחות אישורים לא תקפים, לדחות חשבונות מושבתים או לא כשירים, ולהיכשל בסגור כשאינו יכול להגיע ל-backend שלו. username-as-common-name מופעל לעתים קרובות לצידו, והוא משנה את הזהות שרואים קריאות חוזרות מאוחרות יותר וקובצי תצורה לכל לקוח. הוא אינו מאמת סיסמה, ואינו הופך חשבון לא כשיר לכשיר. אלה משימות נפרדות, וערבובן הוא הדרך שבה הגירה עוברת את מבחן המסלול המאושר ונכשלת בתקרית האמיתית הראשונה שלה.

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

שנו מדיניות, פרופיל ומיפוי יחד

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

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

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