שעון מכשיר שגוי יכול לעצור את ה-VPN: בדקו את הזמן קודם

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

השגיאה נראית כמו בעיית תעודה, לא כמו בעיית שעון

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

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

קראו את הרגע, ואז את התעודה

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

date -u
timedatectl
openssl s_client -connect vpn.example.com:443 -servername vpn.example.com </dev/null 2>/dev/null | openssl x509 -noout -dates

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

timedatectl timesync-status
chronyc tracking

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

קודי התחברות נכשלים מסיבה קשורה אך שונה

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

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

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

תקנו את המקור, לא את השעה המוצגת

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

sudo systemctl status systemd-timesyncd
sudo chronyc sources -v
ping -c1 203.0.113.20

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

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