IP סטטי של OpenVPN לכל לקוח: ifconfig-push, לא ipp.txt

עריכת שורה ב-ipp.txt מרגישה כמו הזמנת כתובת, וזה לא כך. הקובץ הזה, הנקרא על ידי ifconfig-pool-persist, מתעד איזו כתובת היה לשם משותף בפעם האחרונה כדי שהמאגר יוכל להחזיר את אותה כתובת כשזה נוח. שום דבר בו לא קושר את החיבור הבא למספר הזה.

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

למה משמש קובץ ההתמדה

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

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

בדקו שנבחר הלקוח הנכון

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

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

בדקו שהמספרים תואמים לטופולוגיה

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

# /etc/openvpn/ccd/partner-a   (subnet topology)
ifconfig-push 10.44.0.61 255.255.255.0

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

בדקו את התוצאה בחיבור חדש

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

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

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