פג התוקף של קוקי ConnMan OpenConnect, לא בעיית תעודה
שני כשלים נראים זהים ביומן. השוו את טביעת האצבע המוצמדת לקוקי של ההפעלה, רעננו את השדה שפג תוקפו ואז הפעילו מחדש את הדמון.
ConnMan עובד אחר צהריים ואז מסרב, ושורת היומן מזכירה אימות תעודה. השורה הזו שולחת אנשים לחבילות CA שמעולם לא היו שבורות. שני כשלים שונים מייצרים כמעט אותה צורת כשל: תוקף קוקי ההפעלה פג, או שתעודת השרת באמת השתנתה. אפשר להבדיל ביניהם בכדקה בערך, ורק אחד מהם נוגע בטביעת האצבע בכלל.
שני כשלים, שורת יומן אחת מבלבלת
הם נבדלים בשתי תצפיות, ואף אחת מהן לא דורשת קריאה שנייה. הראשונה היא מתי החל הכשל: קוקי שפג תוקפו מגיע אחרי שעות או ימים של עבודה, ותעודה מוחלפת מגיעה מיד אחרי שינוי בשער.
| Signal | Expired cookie | Changed certificate |
|---|---|---|
| When it started | after hours or days of working | right after a gateway change |
| Fingerprint from a fresh authenticate | unchanged | different value |
| Usual log tail | HTTP CONNECT 401 / unauthorized | signer not found / verify failed |
| Repair | replace the cookie, restart | re-pin deliberately, then restart |
המבחן של דקה הוא ריצת ה-authenticate שלמטה. השוו את ה-FINGERPRINT שלה ל-OpenConnect.ServerCert בקובץ. טביעת אצבע זהה עם COOKIE שונה פירושה להחליף רק את הקוקי. טביעת אצבע שונה פירושה שתעודת השרת באמת השתנתה, אז הצמידו אותה מחדש במכוון ורשמו מי אישר זאת.
צרו את החומר במקום להקליד אותו
ל-ConnMan אין שלב ייבוא לפרופיל OpenConnect, שלא כמו NetworkManager. הוא קורא קובץ אספקה שערכיו חייבים להיווצר מראש, והדרך הנתמכת ליצור אותם היא מצב authenticate של OpenConnect.
sudo openconnect --csd-wrapper=/home/user/.cisco/csd-wrapper.sh \
--authenticate --user myuser vpn.example.comהפלט מדפיס ארבעה ערכים: POST, COOKIE, HOST ו-FINGERPRINT. טביעת האצבע, עם התחילית sha256:, היא הצמדת השרת. הקוקי הוא חפץ ההפעלה שאורך חייו נקבע בידי השער. התייחסו אליהם כאל שני סוגי סוד: הם פגים לפי לוחות זמנים שונים, ורק אחד מהם אמור להשתנות.
הקובץ נושא את שניהם, והם מזדקנים אחרת
קובץ האספקה נמצא תחת /var/lib/connman-vpn/ ונקרא לכל חיבור בידי דמון ה-VPN, לא בידי יישומון המגש. החזיקו את שם החיבור במקטע הגלובלי ואת פרטי הפרוטוקול במקטע הספק.
[global]
Name = Company VPN
[provider_openconnect]
Type = OpenConnect
Name = Company Cisco VPN
Host = vpn.example.com
Domain = corp.example
OpenConnect.ServerCert = sha256:...
OpenConnect.Cookie = ...השתמשו בשם המארח שהפורטל באמת מגיש. כתובת IP חשופה יכולה לעבור את בדיקת התעודה ובכל זאת להיכשל, כי ההתקן מנתב לפי המארח הווירטואלי ומצפה לשם.
systemctl status connman-vpn --no-pager # is the daemon even installed and running
sudo systemctl restart connman-vpn # after the file edit
journalctl -u connman-vpn --since '1 hour ago' # after the connection attemptמה היומן באמת מראה
תפריט המגש לא יגיד איזה כשל יש לכם. היומן יגיד, אם תקראו את הרצף ולא את השורה המבהילה הראשונה. קוקי מיושן מציג בדרך כלל שהמשא ומתן של TLS הושלם ושכבת ה-HTTP דחתה אחר כך, ולכן המילים על תעודות עומדות לצד כשל הרשאה.
השוו ריצת authenticate טרייה לערכים בקובץ. אם טביעת האצבע תואמת ורק הקוקי שונה, יש לכם את התשובה בלי לגעת בהגדרות האמון.
רעננו את השדה שפג תוקפו
חזרו על פקודת authenticate, החליפו את OpenConnect.Cookie והפעילו מחדש את הדמון. הניחו לטביעת האצבע אלא אם הפלט הטרי מציג ערך שונה; במקרה כזה תעודת השרת באמת הוחלפה, והצמדה מחדש היא החלטה שמישהו צריך לתעד ולא להדביק מהודעת שגיאה.
אוטומציה של הרענון היא סבירה: סקריפט קטן קורא את הסיסמה מקלט תקני, מריץ מצב authenticate ומשכתב רק את שורת הקוקי. החזיקו את פרטי הגישה מחוץ לסקריפט וקריאים רק לחשבון שמריץ אותו, ועשו את השכתוב אטומי כדי שריצה כושלת לא תשאיר קובץ כתוב למחצה.
אם הרענון נדרש כל כמה שעות, כתבו את המרווח. זו תכונה של מדיניות ההפעלות של השער, והיא מחליטה אם לאוטמט את הרענון או לבקש הפעלה ארוכה יותר.