כתובות OpenVPN יציבות צריכות לעקוב אחרי הזהות, לא אחרי כתובת ה-IP המקורית

תוכניות כתובות שאומרות ״המחשב הנייד הזה מקבל 10.90.0.10״ הן למעשה הצהרות על זהות: איזה התקן מאומת רשאי להחזיק בכתובת הזו. לכתובת ה-IP הציבורית הנוכחית של אותו התקן אין כמעט קשר לכך, כי NAT וניידות משנים אותה בלי לשנות מי המשתמש. בנייה של התוכנית על כתובת המקור מייצרת כללים שנשברים ברשת המלון הראשונה. בנייה שלה על הזהות המאומתת מייצרת תוכנית ששורדת נסיעות.

התחילו ממה שהשרת יכול לאמת, ואז החליטו למה הכתובת מיועדת.

בחרו את מפתח הזהות לפני הכתובת

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

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

הזמינו כתובות מחוץ לטווח הדינמי

ברשת עם טופולוגיית תת-רשת כמו 10.90.0.0/24, שמרו את הכתובות הנמוכות לחברים בעלי שם והניחו את המאגר הדינמי בטווח נפרד. הקצאה לחבר מוצמד נראית כך ifconfig-push 10.90.0.10 255.255.255.0 בקובץ שהשרת בוחר עבור הזהות הזו. הארגומנט השני אומר משהו אחר תחת net30, ולכן הדוגמה אינה ניטרלית מבחינת הטופולוגיה. קראו את הטופולוגיה לפני שמעתיקים אותה.

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

קדימות ההקצאה מחליטה מי מנצח

המדריך מתעד סדר: הקצאה מפורשת שנוצרת במהלך client-connect יכולה להיכנס לתוקף לפני רשומת client-config-dir, שבתורה קודמת להקצאה רגילה מהמאגר. הסדר הזה מסביר את רוב הדיווחים ״הכתובת המוצמדת לא הוחלה״. הוא גם אומר שמקצה דינמי שכותב תצורה לכל הפעלה יכול לדרוס בשקט קובץ סטטי שחשבתם שהוא סמכותי.

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

מקצה דינמי צריך את אותו מודל

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

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

החליטו אם הכתובת היא מדיניות או נוחות

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

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