כתובות לקוח סטטיות של OpenVPN מאחורי OPNsense
קובץ pool הופך כתובת לדביקה, לא לקבועה. נעצו כתובות לקוח באמצעות דריסות, הרחיבו את טווח המנהרה עבור חשבון ה-/30, ואז פרסמו אותן.
שמות זקוקים לכתובות שאינן זזות, וקובץ ה-pool של OpenVPN רק הופך כתובת לדביקה. אם תאבדו את הקובץ הזה, או תפיקו מחדש תעודה תחת שם משותף אחר, הלקוח החוזר נוחת במקום אחר ב-pool בעוד רשומת ה-DNS שלו עדיין מצביעה על הכתובת הישנה. התשובה העמידה היא דריסה ספציפית ללקוח שמעצבת את הכתובת, יחד עם רשת מנהרה רחבה יותר כך שהכתובות המעוצבות ישבו מחוץ לטווח הדינמי. החשבון שמאחורי ההרחבה הזו הוא המקום שבו מתגוררת רוב הבלבול.
OPNsense שומר את הדריסות האלה בהגדרות השרת הספציפיות ללקוח, במפתח של השם המשותף של התעודה, מה שהופך את השם המשותף לחלק מתוכנית הכתובות.
חכירה דביקה אינה כתובת סטטית
קובץ ה-pool כותב מיפויים של כתובת ללקוח ומחזיר אותם כשלקוח מוכר מתחבר מחדש. זו נוחות ולא חוזה: אפשר לייצר את הקובץ מחדש, המיפוי נעלם כשזהות הלקוח משתנה, ושני שרתים שחולקים pool לא יסכימו לגביו. דריסה ספציפית ללקוח עובדת אחרת, מפני שהכתובת מגיעה מהתצורה ולא מההיסטוריה. היא גם שורדת אתחול והתקנה מחדש של המכשיר, כל עוד הדריסה נשמרת בגיבוי יחד עם שאר התצורה.
החלופה הדינמית, כלומר חיבור ה-VPN ל-DNS באמצעות סקריפט client-connect ועדכונים דינמיים, עובדת ומחייבת resolver שמקבל עדכונים ועוד סקריפט בכל התחברות. במכשיר אתם מוגבלים לחבילות שהספק מספק, ובדרך כלל שם נעצרת התוכנית הזו.
חשבון ה-/30 שאיש אינו נהנה ממנו
בטופולוגיית net30 המוגדרת כברירת מחדל, כל לקוח מקבל /30 משלו: הכתובת השמישה הראשונה הולכת לצד השרת, השנייה ללקוח. לכן הדריסות חייבות לשבת מחוץ לרשת המנהרה הדינמית של השרת, כלומר יש להרחיב קודם את הרשת הזו. שרת על 10.8.0.0/24 יכול לעבור ל-10.8.0.0/23, ולהשאיר חצי מהטווח הישן ללקוחות דינמיים ואת החצי השני לדריסות. הוסיפו את ה-/24 המקורי כרשת מקומית IPv4 נוספת כדי שתעבורה לשני החצאים תנותב לתוך המנהרה.
כל כתובת דריסה חייבת ליפול על גבול /30, ולכן האוקטט האחרון הוא כפולה של ארבע. /30 על 10.8.1.0 נותן ללקוח 10.8.1.2, וזו הכתובת שרשומת ה-DNS נושאת. בחירה ב-10.8.1.3 במקום זה מייצרת לקוח שמתחבר ואינו יכול להעביר תעבורה, מפני שהכתובת שייכת לתת-רשת שהטופולוגיה מעולם לא הקצתה לו.
קל יותר לשמור על התוכנית אם הדריסות מוקצות מראש הטווח המורחב ומטה, כך שה-pool הדינמי מתרחב אל החלל הפנוי ולא סביב איים קבועים.
רשתות מקומיות והאזור שהלקוחות שואלים
תעבורה מלקוח ללקוח זקוקה להרשאה משלה. רשימת הרשתות המקומיות IPv4 של השרת חייבת לכלול את שני חצאי הטווח, הדינמי והסטטי; בלעדיה השרת מקבל מנה מלקוח אחד ואין לו מדיניות שמתירה להעביר אותה לאחר. התסמין נראה כמו כשל DNS, מפני שהשם נפתר והחיבור בכל זאת נכשל. בדקו גם את הגדרת מלקוח ללקוח באותו זמן, שכן רשומת רשת מקומית לבדה אינה מפעילה העברה בין עמיתים.
פרסמו את הרשומות באזור שלקוחות מרוחקים באמת שואלים. רשומה באזור שמשרת רק ה-resolver של ה-LAN אינה נראית ללקוח שה-resolver שנדחף אליו מצביע למקום אחר, והוספת רשומות נוספות לאזור הלא נכון לעולם אינה מתקנת זאת. אשרו את אפשרות ה-DNS שנדחפה ואת דומיין החיפוש לפני שמוסיפים משהו.
מה לבדוק בחיבור חדש
חברו מחדש את הלקוח ואשרו שהכתובת שהוקצתה תואמת לדריסה שלו לפני שתבדקו משהו אחר. אחר כך פתרו את השם מלקוח שני והתחברו לשירות לפי שם, מה שבוחן יחד את רשומת ה-DNS, את המסלול ואת חומת האש. אשרו את מסלול התשובה בצד השרת, מפני ששם שנפתר בעוד השירות נשאר בלתי נגיש הוא בעיית ניתוב או מדיניות ולא בעיית שמות. החזיקו את טבלת הדריסות לצד רשימת התעודות כדי ששתיהן ייבדקו יחד.
תעודה שמופקת מחדש תחת שם משותף אחר מפסיקה להתאים לדריסה שלה ומחזירה את הלקוח ל-pool הדינמי. צפו לכך אחרי כל שינוי זהות.