duplicate-cn נותן לשני מכשירים זהות אחת, לא שתיים

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

המיתוס: הפעלה שנייה היא זהות שנייה

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

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

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

מה באמת משתנה כששתי הפעלות חולקות שם

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

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

ודאו מה הבנייה שלכם עושה בפועל לפני שאתם מתכננים סביבה, כי את השפעת האפשרות מגדירה האפשרות עצמה ולא שמועות:

grep -n 'duplicate-cn\|client-config-dir\|username-as-common-name' /etc/openvpn/server.conf

הכתובת הסטטית שחשבתם שהקציתם

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

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

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

מה זהות משותפת לא יכולה לעשות בזמן הסרה

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

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

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

מתי שיתוף נכון, ואיך להגביל אותו

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

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

בכל מסלול שתבחרו, בדקו את מודל הניהול ולא את הכניסה. חברו את שני המכשירים, ודאו שיש להם כתובות שונות, ואז דמו אובדן ובדקו שאתם יכולים להסיר בדיוק אחד מהם. המדריך openvpn(8) מגדיר את היקף האפשרות; נוהל ההסרה שלכם הוא שקובע אם השיתוף באמת מקובל.