איפה המסלול שייך ב-OpenVPN: אצל הלקוח או אצל השרת?
מסלול גולמי בקונפיגורציית השרת משנה את השרת, לא את הלקוח. בחרו את קובץ הלקוח, push גלובלי או push ללקוח אחד, ובדקו מה הגיע.
אתם מוסיפים את route 10.60.0.0 255.255.255.0 לקונפיגורציית השרת, מפעילים מחדש, מתחברים מחדש ממחשב נייד, והתת-רשת עדיין אינה נגישה מאותו מחשב. השורה התקבלה, השירות עלה בצורה נקייה, ושום דבר ביומן לא נראה שגוי. מה שקרה הוא שהמסלול הותקן על המכונה שערכתם: השער מאמין כעת שהוא יכול להגיע לקידומת הזו, בעוד שהלקוח לא קיבל שום הודעה. המיקום הוא כל השאלה, ויש ארבעה מקומות שבהם אותה שורה יכולה לחיות.
ארבעת המקומות ומי מקבל כל אחד מהם
ניתן להוסיף מסלול באמצעות הקונפיגורציה של הלקוח עצמו, להציע אותו לכל לקוח באמצעות push גלובלי, להציע אותו ללקוח אחד באמצעות קובץ ייעודי ללקוח, או לכתוב אותו בהקשר הניתוב של השרת עצמו.
ארבעת המקרים האלה משתמשים בתחביר כמעט זהה ומפיקים תוצאות שונות לחלוטין. שלושת הראשונים משפיעים על מה שלקוח שולח לתוך המנהרה; הרביעי משפיע על האופן שבו השרת מגיע לרשת, וזה שימושי כשהשרת עצמו זקוק לנתיב ומזיק כשמבלבלים אותו עם הפצה.
החליטו איזה מארבעתם אתם רוצים לפני שתכתבו את השורה, ואז אשרו את הנמען.
| Placement | Effect | Receiver |
|---|---|---|
| Client profile route | Installed by the client at connect | That client only |
Global push "route ..." | Sent to every client that accepts pushed options | All pulling clients |
| Client-specific push | Sent to the matching client context | One identity |
| Server config route, no push | Added to the server's own table | The gateway itself |
למה מסלול השרת הגולמי מפתיע אנשים
קונפיגורציית השרת היא המקום הראשון שבו מנהלי מערכת מסתכלים, והנחיית מסלול שם נקראת כמו הצהרה על רשת ה-VPN. זה לא. OpenVPN מתייחס אליה כהתקנת מסלול מקומית על המכונה שמריצה את הדמון, וזה בדיוק אותו סוג של שינוי שהייתם עושים עם ip route ואז שוכחים.
הפצה דורשת שהמסלול יידחף ב-push, ו-push דורש שהלקוח ימשוך אותו. לקוח שהופעל עם אפשרויות משיכה מושבתות מתעלם מההצעה לגמרי. בדקו את שני הקצוות של לחיצת היד הזו לפני שתכתבו מחדש את קובץ השרת, כי יומן השרת לא יתלונן: מצידו ההצעה נשלחה. מסלול שהתקבל נכנס לתוקף רק בחיבור הבא, ואף פעם לא בהפעלה שאתם כבר נמצאים בה.
ברגע שתראו את שתי הפעולות כנפרדות, הכשל מפסיק להיות מסתורי: השרת מגיע לקידומת, הלקוח לא, ושתי הקביעות נכונות בו-זמנית.
קבצים לכל לקוח והזהות שאליה הם מתאימים
קובץ ייעודי ללקוח נקרא על שם הזהות שהשרת אימת, שזו כברירת מחדל השם הנפוץ של התעודה. שם חיבור ידידותי בלקוח שולחני אינו הערך הזה, ואי-התאמה יוצרת קובץ שלעולם לא נקרא.
בדקו את הספרייה שהשרת באמת משתמש בה, ואז אשרו ששם הקובץ תואם בדיוק לזהות המאומתת, כולל אותיות גדולות וקטנות.
grep -n 'client-config-dir' /etc/openvpn/server/server.conf
ls -l /etc/openvpn/ccd/בתוך אותו קובץ עדיין צריך לדחוף את המסלול, כי ההקשר לכל לקוח הוא סט אפשרויות שמוחלות על ההפעלה של אותו לקוח, ולא טבלת ניתוב מקומית. מסלול גולמי שם סובל מאותה בעיה כמו מסלול גולמי בקובץ הגלובלי.
הקובץ של הלקוח עצמו והכלי שמנהל אותו
מסלול שמוצב בקונפיגורציה של הלקוח מותקן כשהלקוח מתחבר ומוסר כשמתנתק, וזה מחזור החיים הנכון עבור יעד סטטי.
אם מנהל רשת הוא הבעלים של הפרופיל, הוא עשוי לייבא את האפשרויות האלה פעם אחת ואז לשמור עותק משלו. עריכת הקובץ שהורד לאחר מכן לא משנה דבר, וזה מקור נפוץ ל"המסלול קיים אבל לא חל".
בדקו את הפרופיל הפעיל ולא את הקובץ שהורדתם, ובדקו את ההגדרות המיובאות שמנהל הרשת מציג. אחר כך התחברו ושאלו את המערכת איזה נתיב כתובת מסוימת משתמשת בו, במקום להניח שהמנהרה ניצחה כי המסלול היה קיים בקובץ טקסט.
אמתו בלקוח, ואז בדקו את נתיב החזרה
שאלו את טבלת הניתוב של הלקוח עצמו על היעד, לא את זו של השרת. חיפוש של מארח בודד בתוך הקידומת מספיק כדי להראות את הממשק ואת הקפיצה הבאה שישמשו.
ip route get 10.60.0.10אם החיפוש מצביע על המנהרה, ההפצה עבדה והבעיה שנותרה נמצאת במקום אחר. אם הוא מצביע על שער ברירת המחדל, המסלול לא הותקן, סונן על ידי אפשרות בצד הלקוח, או שייך לפרופיל שהלקוח לא משתמש בו.
נחשו שההפצה עבדה ובכל זאת שום דבר לא מגיב: אז בדקו את העברת החבילות בשער, את נתיב החזרה של הצד השני וכל חומת אש ביניהם. מסלול בוחר נתיב, הוא לא מעניק גישה.