האם קישור OpenVPN עם מפתח סטטי יכול לשרת כמה לקוחות?

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

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

למה מיועד מצב המפתח הסטטי

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

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

לכן גבול שני העמיתים הוא מבני ולא הגדרה שאפשר לשנות.

למה client-to-client אינו החלק החסר

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

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

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

בניית שרת רב-לקוחות

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

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

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

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

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

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

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

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

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