פסק זמן TLS של שישים שניות: איזה צד באמת הפסיק?

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

תנו לניסיון אחד זהות שאפשר לחפש

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

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

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

ארבע תצפיות, ארבעה צעדים הבאים שונים

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

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

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

תקנו את השלב שהראיות משמנות לו שם

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

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

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

grep -nE 'TLS Error|VERIFY ERROR|CRL|handshake failed' /var/log/openvpn/server.log
date -u; timedatectl | head -3

מה הארכת החלון באמת משנה

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

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