ההפעלה הראשונה מנצחת: הגבלת כניסות OpenVPN לפני פינוי
דחיית כניסה מאוחרת אינה זהה להחלפת הישנה. ההחלטה חייבת להתקבל לפני פינוי אותו שם, ובדיקת המשבצת חייבת להיות אטומית.
מדיניות שמתירה הפעלה אחת לכל חשבון נראית סגורה עד שהכניסה השנייה מגיעה. שני סיומים אפשריים: המצטרף החדש מחליף את ההפעלה הקיימת, או שההפעלה הקיימת שומרת על המשבצת והחדש נדחה. רק השנייה היא מדיניות ההפעלה הראשונה מנצחת. אפשרות הלקוח שאליה רוב האנשים פונים מפעילה מקבילות ולכן אינה מייצרת אותה.
שני חוזים מסתתרים מאחורי הגדרה אחת
כשמקבילות כבויה, חיבור שני הנושא את אותו שם תעודה יכול לדחוק את ההפעלה שכבר פועלת. הפעלת מקבילות מאפשרת כמה הפעלות בעת ובעונה אחת, שזה ההפך ממגבלה. אף אחד מהמצבים אינו מדיניות דחייה, ולכן ההחלטה חייבת להתקבל במקום אחר לגמרי.
כתבו את החוזה לפני שתטמיעו משהו: מי נדחה, איזו ראיה מזהה את ההפעלה הקיימת ומה קורה כשהפעלה מתה בלי ניתוק נקי. מדיניות שאיש לא ניסח כך אינה ניתנת לבדיקה מאוחר יותר.
הפינוי מתרחש לפני וו החיבור שלכם
במסלול הקוד של השרת 2.6, ההכנה המוקדמת ללקוח חדש מסירה מופעים קיימים עם אותו שם כשמקבילות כבויה. ההסרה הזו מתרחשת לפני שרשרת מטפלי החיבור רצה. לכן תסריט שמבחין בכפילות ומחזיר כשל דוחה את החדש אחרי שההפעלה הקיימת כבר נזרקה - בדיוק התוצאה שהמדיניות נועדה למנוע. סדר הקריאות החוזרות במימוש במעלה הזרם הוא התשובה האמינה היחידה לבנייה שלכם.
| Stage | Who can still refuse | Effect on the incumbent |
|---|---|---|
| Certificate check | Server trust configuration | None |
| Authentication decision | The authentication controller | None, because establishment has not run |
| Connect handler | A profile script | Already evicted in the same-name case |
| Post-establishment | Status tooling, monitoring | Both sessions already exist or one is gone |
גם סקר קובץ המצב אינו שער. שני ניסיונות שמגיעים יחד יכולים שניהם לראות משבצת ריקה לפני שאחד מהם מתחייב, ושניהם ממשיכים.
העבירו את ההחלטה לאימות
ממשק הניהול יכול לקחת על עצמו את החלטת האימות לאחר אימות התעודה. בסידור הזה הבקר אינו צופה: הוא מקבל כל מופע לקוח מתחבר ועונה אם אותו מופע רשאי להמשיך. מכיוון שהתשובה מגיעה לפני ההקמה, דחייה משאירה את ההפעלה הקיימת בלי פגע. אותו ערוץ מדווח על ניתוקים, וכך הבקר לומד שמשבצת שוחררה כדין.
כל מופע חדש חייב לעבור את השער הזה, כולל חיבורים מחדש וכל מסלול שמאמת מחדש בלי בקשה. שער שמופעים מסוימים אינם מגיעים אליו לעולם אינו מגן על דבר, וההחמצה נשארת בלתי נראית עד שמישהו מנסה את העקיפה.
אסימונים יכולים לעבור ליד השער
לאחר שאסימון הונפק, השרת יכול לאמת אותו פנימית ולדלג על אימות חיצוני עבור אותו חיבור. קריאת הניהול אינה מתרחשת לעולם, ולכן בדיקת משבצת שמוטמעת רק שם אינה רואה את המופע החדש. ההתנהגות הזו היא נוחות למשתמשים וחור במדיניות מקבילות. הניחו לחיבורים מאומתים באסימון לעבור בדיקה מוסמכת שקולה, או השביתו את מסלול האסימון כשהמדיניות דורשת החלטה בכל חיבור.
אל תפצו על כך בקבלת כל אסימון ללא תנאי. אסימון שפג תוקפו או בלתי חוקי חייב עדיין להיכשל, והוא חייב להיכשל דרך אותה נקודת החלטה כמו כל השאר.
קשרו את ההזמנה למופע, לא לכתובת
כתובת היא זהות גרועה: חיבור מחדש מאותו מחשב נייד יכול להגיע מכתובת אחרת, ופרטי גישה מועתקים יכולים להגיע מאותה כתובת. קשרו את ההזמנה למופע הלקוח שהשרת מקצה, כדי שאימות מחדש של המופע שכבר התקבל יזוהה כבעלים. מזהה מופע חדש חייב לרכוש את המשבצת שלו דרך החלטת הראשון מנצח, גם כשהוא מציג את אותו אסימון.
שחררו רק את ההזמנה של הניסיון שנכשל. אירוע ניתוק מאוחר מניסיון ישן יותר אסור שימחק את המשבצת של בעלים חדש יותר, ולכן השחרור נוקב בשם המופע ולא בחשבון. אחרי הפעלה מחדש של הבקר, התאימו את ההפעלות החיות לפני שתקבלו מישהו, והחילו את אותו כלל בכל שער שמשרת את החשבון.
החליטו בנפרד איך משבצת מיושנת באמת ניתנת לשחזור. למנהל מערכת דרושה דרך מתועדת לנקות אותה, ונתיב זה לא אמור להיות נגיש למשתמש שרק לוחץ על התחבר מחדש.
בדקו את הזוגות החשובים: שתי כניסות כמעט בו-זמנית, חיבור מחדש אחרי סגירה נקייה, אימות מחדש של ההפעלה הקיימת, מצטרף חדש שנדחה והפעלה מחדש של הבקר. בכל מקרה ההפעלה הקיימת חייבת להישאר שמישה והחדש חייב להידחות בלי נזק לחשבונות אחרים.