ifconfig-push: כתובת עמית ב-net30 או מסכת רשת משנה ב-subnet?

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

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

שתי הצורות, זו לצד זו

בפריסת net30 מסורתית כל לקוח מחזיק בבלוק /30: כתובת רשת, שתי כתובות שמישות וכתובת שידור. ifconfig-push לוקח את כתובת הלקוח ואת כתובת העמית, והעמית הוא הכתובת השמישה השנייה באותו בלוק, שבה משתמש צד השרת של הקישור מנקודה לנקודה.

# net30: client address and its peer
ifconfig-push 10.99.0.6 10.99.0.5
# topology subnet: client address and the pool netmask
ifconfig-push 10.99.0.20 255.255.255.0

תחת topology subnet הלקוח חולק רשת משנה אחת עם השרת, ואותה הנחיה לוקחת כתובת ומסכת רשת משנה. הכתובת של השרת עצמו מגיעה מהנחיית server, לא מהשדה השני. ערבוב הצורות יוצר לקוח שחושב שהוא נמצא בקישור מנקודה לנקודה, בעוד השרת מנתב אותו כמארח ברשת משנה, או להפך. לכן אסור לשייך מסכת רשת משנה ל-net30 לעולם.

שתי השורות בבלוק הן שורות בודדות עבור קובץ CCD. כל לקוח מקבל בדיוק אחת מהן.

קראו את הטופולוגיה שהשרת באמת מריץ

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

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

השאירו את הכתובת הקבועה מחוץ למאגר הדינמי

כתובת קבועה חייבת לשבת מחוץ למאגר הדינמי, אחרת שני לקוחות עלולים לקבל את אותה כתובת. בטופולוגיית subnet, nopool בשורת server מדכא את המאגר האוטומטי, וטווח ifconfig-pool מפורש מגדיר מה לקוחות דינמיים מקבלים.

dev tun
topology subnet
server 10.99.0.0 255.255.255.0 nopool
ifconfig-pool 10.99.0.100 10.99.0.210 255.255.255.0
client-config-dir /etc/openvpn/ccd

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

אמתו את ההקצאה שהלקוח באמת קיבל

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

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