OpenConnect vpnc-script: איזה קובץ פועל בפועל?

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

שתי תוכנות, שתי אחריות

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

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

אתרו את העוזר שהלקוח הפעיל משתמש בו

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

openconnect --version
ps -o args= -C openconnect
dpkg -L openconnect | grep -i script
ls -l /etc/vpnc/ 2>/dev/null

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

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

קראו את הפעולה הכושלת הראשונה, לא את האזהרה האחרונה

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

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

אמתו חיבור, חיבור מחדש וניתוק

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

ip -brief address show tun0
ip route get 10.24.8.15
resolvectl status tun0
journalctl -u NetworkManager -b --no-pager | grep -i -E 'vpnc|script'

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

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