מדוע חיבור VPN מחדש מבקש שוב פרטי זיהוי
סיסמה שמורה ואסימון לשימוש חוזר פגים לפי לוחות זמנים שונים. קראו איזה חומר ביקש החיבור מחדש לפני שמשנים משהו בלקוח.
מנהרה שעבדה שעות מבקשת סיסמה ברגע שהמחשב הנייד מתעורר, ושום דבר בהגדרות לא השתנה. מה שכן השתנה הוא מצבו של פרט הזיהוי שהחיבור מחדש ניסה לעשות בו שימוש חוזר. שלושה סוגי חומר קובעים זאת, ורק אחד מהם שורד פער שרירותי.
קראו איזה מהם ביקש הלקוח, כי שלושתם פגים לפי שעונים שונים ונכשלים בהודעות שונות.
שלושה סוגי חומר לשימוש חוזר
סיסמה שמורה במטמון היא סוד שהלקוח מחזיק, והיא נשארת תקפה עד שהחשבון משנה אותה. אסימון הפעלה מונפק על ידי השרת לאחר התחברות מוצלחת, נושא אורך חיים משל עצמו וניתן לבטלו בכל רגע. כרטיס הפעלה של TLS או אסוציאציית אבטחה של IKE הם מצב פרוטוקול, זול לחידוש ותלוי לחלוטין לא בסיסמה שלכם. כל אחד מונפק על ידי רכיב אחר, וכל אחד פג בתנאים שלו.
הראשון שורד אתחול, השני שורד בדרך כלל השהיה, והשלישי אולי לא ישרוד שינוי רשת כלל. ערבוב ביניהם מייצר את התיקון הלא נכון, כמו איפוס סיסמה שמעולם לא נדחתה.
ההנחיה עצמה היא האבחנה. חלון דפדפן או קוד של גורם שני אומרים שהשרת דרש אימות אינטראקטיבי, בעוד כשל שקט בלי הנחיה אומר שהלקוח לא הגיע רחוק מספיק כדי להישאל.
| Material | Typical lifetime | What invalidates it |
|---|---|---|
| Cached password | Until changed | Account or password policy change |
| Session token | Minutes to hours | Expiry, revocation, reauthentication policy |
| Tunnel SA or TLS ticket | Configured rekey interval | Rekey, network change, peer restart |
חידוש מפתחות אינו אימות מחדש
חידוש מפתחות מחליף מפתחות תוך שמירה על הזהות המאומתת, ולכן הוא מתרחש בשקט מדי פעם במנהרה בריאה. אימות מחדש חוזר על בדיקת הזהות עצמה, וזה האירוע שזקוק לכם. IKEv2 מפריד בין השניים במפורש, ועמית יכול לדרוש אימות מחדש מלא במרווח מוגדר, בין אם התרחשו חידושי מפתחות בינתיים. שני האירועים נראים זהים מבחוץ עד שקוראים איזה מהם היומן מציין.
OpenVPN מתנהג באותה דרך באוצר המילים שלו: מרווח משא ומתן מחדש מרענן את ערוץ הנתונים, ואסימון אימות יכול להיות מוחזר ללקוח כדי להימנע מהתחברות מלאה בחיבור הבא. לאסימון הזה יש אורך חיים, והשרת מחליט אם לקבל אותו שוב.
לכן חיבור מחדש אחרי שמונה שעות יכול להיכשל במקום שבו חיבור מחדש אחרי שמונה דקות הצליח, בלי שום שינוי הגדרות באף צד. זו כל ההסבר להנחיה שמופיעה רק אחרי הצהריים.
כשהלקוח אינו יכול להשלים את האתגר החדש
מדיניות שדורשת שלב בדפדפן תיכשל בלקוח שאין לו דרך להציג כזה. שרתים ללא ממשק, סקריפטים של אתחול ופרופילים ישנים שנבנו לאימות בסיסמה בלבד כולם נתקלים בקיר הזה, והכשל מופיע לעתים קרובות כזמן המתנה כללי ולא כשגיאת אימות.
מעברים בין מכשירים ורשתות יכולים גם הם ליפול בתוך חלון הערכת מדיניות, ולכן נדידה מ-Wi-Fi לנקודת גישה מתלכדת עם בדיקה שהייתה מתרחשת בכל מקרה. הצירוף הזה גורם לרשת להיראות אשמה כשהגורם הוא הטיימר.
openvpn --config client.ovpn --verb 3 2>&1 | grep -i -E "reneg|auth" ipsec statusall | grep -i -E "rekey|reauth"
השורה הראשונה מציגה אירועי משא ומתן מחדש ואימות ביומן של הלקוח עצמו, והשנייה מציגה את אסוציאציות האבטחה שעמית strongSwan מחזיק כעת. השוו את חותמות הזמן לרגע שבו הופיעה ההנחיה; התאמה מאשרת את הטיימר ולא את הרשת.
מה לדווח, ומה לא לכבות
אם התחברות ידנית מצליחה והשימוש החוזר האוטומטי נכשל בעקביות, אמרו זאת בדיוק למפעיל. זה נוקב ברכיב: מסלול השימוש החוזר, לא פרט הזיהוי. כללו את שעת הכשל, החשבון שבו השתמשתם וסוג ההנחיה שראיתם.
אל תכבו את הגורם השני, אל תדלגו על אימות תעודה ואל תדביקו פרטי זיהוי בסקריפט כדי שהחיבור מחדש יהיה שקט. כל אחד מהם מסיר את הבדיקה שהמדיניות קיימת כדי לאכוף, וכל אחד הופך הנחיית התחברות לתקרית.
בקשו במקום זאת את הזרימה הנתמכת: לקוח שיכול להשלים את האתגר, אורך חיים של אסימון שמתאים ליום העבודה, או פרופיל לא אינטראקטיבי מאושר למכונה שאינה יכולה לבקש. כל אלה הן החלטות הגדרה שמישהו יכול לאשר, מה שפתרון עוקף אינו.