איזו כתובת ייתן המאגר בחיבור החוזר הבא?
כתובות המאגר עוקבות אחרי סדר שאינו אקראי: קודם הכתובת הזכורה, אחר כך החופשית שלא נעשה בה שימוש הכי הרבה זמן. קראו אותו לפני שמצמידים כלל.
כלל שהתאים אתמול מפסיק להתאים היום, כי הלקוח חזר עם כתובת מנהרה אחרת. המקצה לעומת זאת אינו אקראי, והידיעה של הסדר שלו הופכת את ההפתעה לאירוע צפוי. הוא מעדיף את הכתובת שהייתה ללקוח הזה קודם, נופל חזרה לכתובת הפנויה שלא היה בה שימוש הכי הרבה זמן, ושוכח הכול אם לא נותנים לו מקום לזכור. כללים שמניחים חכירה ממשיכים להתאים עד היום שבו, בשקט, הם מפסיקים.
הסדר שלפיו פועל המקצה
עם סשן אחד לכל common name המקצה מחפש קודם כתובת שאותה השתמש הלקוח הזה קודם ושהיא פנויה כעת. אם הכתובת הזאת נעלמה, הוא לוקח את הכתובת הפנויה שהייתה לא פעילה הכי הרבה זמן. כשמופעלים סשנים מקבילים לאותו שם, העדפת הכתובת הקודמת אינה חלה ובמקומה משתמשים בכתובת הפנויה הראשונה, מפני שהסשנים מטופלים כעמיתים נפרדים.
| Situation | Address chosen | Practical effect |
|---|---|---|
| Reconnect, old address still free | The remembered address | Rules appear stable for days |
| Old address taken by another client | Least recently used free address | A working rule silently stops matching |
| Concurrent sessions, same name | First free address, per session | One identity can hold several leases |
מכאן נובעות מיד שתי תוצאות. לקוח שמתחבר מחדש מהר בדרך כלל שומר על הכתובת שלו, ולכן אף אחד לא מבחין במנגנון עד שהוא משתנה. ומכשיר אחר שמתחבר בחלון הקטן הזה יכול לתפוס את הכתובת בזמן שהיא פנויה לזמן קצר, ואחר כך הלקוח הראשון מקבל משהו אחר וכל כלל שמבוסס על המספר הישן שגוי. אף אחד משני האירועים לא מייצר שורת יומן שנראית כתקלה.
למה חכירה נראית יציבה ואחר כך זזה
היציבות כאן היא תכונה מתהווה של חיבורים חוזרים שמגיעים לפני שמישהו אחר דורש את הכתובת. זו אינה הבטחה, והיא אינה נאכפת כשהלקוח מנותק. תכננו שהכתובת תשתנה במקום להיות מופתעים ממנה. מאגר שגדול בקושי ממספר המכשירים הופך התנגשויות לשגרה, מפני שלחלופה של הכתובת שלא היה בה שימוש הכי הרבה זמן אין כמעט ממה לבחור.
המקביליות בשיא היא המספר שלפיו מתכננים, לא מספר המשתמשים. מי שבודק משני מכשירים בבת אחת, או לקוח שמתחבר מחדש לפני שהסשן הישן פג, תופס שתי חכירות לזמן מה. מאגר שתוכנן רק לפי מספר האנשים ייצור בדיוק את התחלופה שאנשים מאשימים בה את השרת.
קובץ ההתמדה זוכר, הוא אינו שומר מקום
כתובת ששורדת הפעלה מחדש של השירות צריכה קובץ התמדה. הוא שומר את שם הלקוח ואת הכתובת בכיבוי וקורא אותם חזרה בעליית השירות, ולכן הפעלה מחדש מתוכננת כבר לא מערבבת את כל הכללים שכתבתם.
ifconfig-pool-persist /etc/openvpn/ipp.txt
server 10.8.0.0 255.255.255.0מה שהוא לא עושה הוא להחזיק את הכתובת כשהלקוח נעדר. במרווח הזה המקצה חופשי לתת את המספר למישהו אחר, והקובץ רושם אז העדפה מיושנת שהחיבור הבא לא יכול לקיים. התייחסו אליו כרמז שמשפר את התנהגות ההפעלה מחדש, לא ככתוב סטטי.
בדקו את המאגר מול כל תת-רשת מנותבת בזמן שאתם בקובץ. טווח חופף מחלק כתובות שהשרת לא יכול לנתב אליהן, והתסמין הוא לקוח שמתחבר, מקבל כתובת ולא מגיע לשום מקום.
להצמיד כתובת כראוי
כשכלל חומת אש או רשומת DNS באמת זקוקים לכתובת קבועה, הקצו אותה במקום לקוות לה. רשומת תצורה לכל לקוח יכולה לדחוף כתובת ומסכה ישירות, והרשומה הזאת ממופתחת לפי שם הלקוח האפקטיבי.
# client-config-dir entry for "laptop-acme"
ifconfig-push 10.8.0.50 255.255.255.0החזיקו כתובות קבועות מחוץ למאגר הדינמי כדי שהמקצה לעולם לא ייתן את אותו מספר לסשן אחר. אחר כך בדקו את טופולוגיית המנהרה, מפני שהיא משנה כמה כתובות מאגר כל לקוח צורך: הפריסה הישנה מנקודה לנקודה צורכת בלוק קטן לכל לקוח, ואילו פריסת תת-רשת משתמשת בכתובת אחת לכל אחד. מאגר שנראה נדיב בטופולוגיה אחת יכול להיות מתיש בשנייה.
אשרו את התוצאה בלקוח במקום לסמוך על הנהלת החשבונות של השרת. כשהסשן חוזר, הסתכלו על כתובת הממשק ועל המסלול שנדחף, מפני שיומן בשרת יכול לדווח על הכתובת שהתבקשה בזמן שהממשק עצמו מחזיק אחרת.
הכתובת המרוחקת היא שאלה נפרדת
הכתובת בשורת ה-remote של הלקוח חייבת להיות נגישה לפני שקיימת מנהרה כלשהי. לשים שם כתובת מאגר, למשל נקודת הקצה של המנהרה של השרת עצמו, פירושו שהלקוח מנסה להגיע לנקודת הקצה דרך מנהרה שהוא עדיין לא בנה, והתוצאה היא לולאה או המתנה שקטה במקום קיצור דרך.
השתמשו בנקודת הקצה הציבורית שסיפק המפעיל, והשאירו את המאגר למה שהוא נועד: כתובות בתוך המנהרה. תיעוד טווח המאגר, ההקצאות הקבועות ונתיב ההתמדה במקום אחד חוסך מהאדם הבא להתייחס לכל חכירה כאל שרירותית.