שרת OpenVPN עם nopool: הצהר על טווח מאגר מפורש

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

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

התחל מתת-הרשת שכבר יש לך

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

grep -nE '^(topology|server|ifconfig-pool|max-clients|client-config-dir)' /etc/openvpn/server/lab.conf
ip -4 addr show tun0

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

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

הוסף nopool והצהר על הטווח

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

topology subnet
server 10.70.0.0 255.255.255.0 nopool
ifconfig-pool 10.70.0.50 10.70.0.120 255.255.255.0

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

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

החזק הקצאות קבועות מחוץ לטווח הדינמי

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

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

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

החל דרך מחזור החיים ואז אמת

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

systemctl restart openvpn-server@lab
journalctl -u openvpn-server@lab -n 30 --no-pager
# on a fresh client
ip -4 addr show tun0

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

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

החזרה לאחור של שינוי טווח

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

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

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