פסק זמן של חיבור VPN: DNS, תעבורה, משא ומתן או התחברות
פסק זמן אומר רק שמועד עבר. השוו בין ארבעה שלבים, פענוח שם, תעבורה, משא ומתן והתחברות, כדי לראות איזה מהם הושלם אחרון.
«החיבור פסק בזמן» היא השגיאה הכי פחות ספציפית שלקוח VPN יכול להדפיס. היא אומרת שפעולה אחת פספסה את המועד שלה, ולכל שלב מהפענוח של השם ועד תשובת ההתחברות יש מועד. לקוחות שמציגים רק את ההודעה האחרונה גורמים לשלבים להיראות זהים, ולכן אנשים מעלים את פרק הזמן, מחליפים פורט ומתקינים מחדש את הפרופיל, בסדר הזה, בלי ללמוד דבר. השוואה בין השלבים מהירה יותר: כל שלב נכשל במקום אחר, וכל כשל משאיר סוג אחר של ראיות.
ארבעה שלבים, ארבעה כשלים שונים
הרצף קבוע גם כשלקוח מסתיר אותו: השם חייב להיפתר, יש להקים תעבורה לכתובת המתקבלת, הפרוטוקול חייב לנהל משא ומתן על הפרמטרים והמפתחות שלו, והחשבון חייב להיות מאומת. מדריך OpenVPN לפתרון בעיות קישוריות הולך באותו סדר עבור הלקוח שלו, והאחרים הולכים אחריו מקרוב. פסק זמן בשלב השני ופסק זמן בשלב הרביעי אין להם דבר במשותף מלבד המילה על המסך.
| Stage | Looks like | What it does not prove |
|---|---|---|
| Name resolution | fails in under a second, before any contact | nothing about the server being up |
| Transport | waits the full timeout, then gives up | nothing about the VPN service behind the port |
| Negotiation | connects, then stalls at handshake | nothing about credentials |
| Login | a reply arrives and is rejected or hangs on a prompt | nothing about reachability |
קראו ביומן את השורה האחרונה שמעידה על התקדמות, לא את השורה האחרונה לפני השגיאה. רוב הלקוחות מדפיסים משהו כמו כתובת שנפתרה, שקע שהוקם, לחיצת יד שהחלה או בקשת אימות, והשלב שאחרי השורה הזו הוא זה שפסק בזמן.
פענוח השם נכשל לפני כל מגע
אם נקודת הקצה לא נפתרת לעולם, ללקוח אין למה להתחבר ולא נעשתה שום עבודת תעבורה. כשל כזה הוא בדרך כלל מיידי ולא פסק זמן מלא, וזו הדרך הזולה ביותר להבדיל אותו מהשאר. בדקו את השם עם פותר המערכת ועם פותר שני, והשוו את שתי התשובות לפני שאתם מסיקים שהשרת למטה.
כתובת ישנה שהועתקה מהודעה בפורום היא סיבה נפוצה לפסק זמן שנראה כמו בעיית שרת, כי הכתובת שייכת עכשיו למשהו אחר או לשום דבר. השתמשו בפרופיל הנוכחי של המפעיל במקום להחליף כתובת שעבדה בעבר. תשובת ping חסרה אינה ראיה לאף כיוון: נקודות קצה רבות מפילות ICMP ובכל זאת משרתות היטב.
הקמת התעבורה מחכה לחבילה שלא תגיע
כשה-DNS תקין והלקוח עדיין שורף את כל פרק הזמן, שכבת התעבורה היא החשודה. ב-TCP אתם יכולים לבדוק את הפורט ישירות; Test-NetConnection ב-Windows או nc -vz ב-Linux אומר לכם אם משהו מקבל את החיבור, וזה שימושי יותר מ-ping. ב-UDP אי אפשר לבדוק באותה דרך, כי אין לחיצת יד להשלים בשכבה הזו, וחוסר הסימטריה הזה יוצר הרבה מסקנות שגויות.
מה שבדיקת TCP מוכיחה מוגבל: שירות שמקבל את פורט 443 אינו בהכרח מאזין ה-VPN, ולנקודת קצה עם UDP בלבד אין פורט TCP כדי לקבל דבר. כתיבה מחדש של פרופיל מ-UDP ל-TCP אינה יוצרת מאזין בצד השני; היא רק משנה את מה שהלקוח שלכם מחכה לו. אם הרשת מסננת את הפרוטוקול, השינוי מייצר פסק זמן אחר באותו שלב.
פורטלים לכודים ראויים לבדיקה משלהם בשלב הזה. עד שהפורטל מאשר את המכשיר, התעבורה היוצאת הולכת לפורטל והניסיון למנהרה פשוט נתלה. השלימו קודם את הפורטל בדפדפן, ואז נסו שוב, ואל תשנו את הפרופיל כל עוד הפורטל ממתין.
משא ומתן והתחברות אומרים שהשרת ענה
ברגע המנהרה מגיעה לשרת, הלקוח מתחיל לחיצת יד והשגיאה משנה אופי. תקיעה כאן עוסקת בתאימות ולא בנגישות: גרסאות פרוטוקול לא תואמות, הגדרת צופן או ערוץ נתונים שהצד השני לא יקבל, או פרופיל שמצפה לתכונה שהשרת לא מציע. OpenVPN הזיז את ברירות המחדל של המשא ומתן בין גרסאות ראשיות לעתים קרובות מספיק כדי שפרופיל שנכתב לדור אחד יגיע לשרת ובכל זאת לא יעלה.
אימות הוא השלב האחרון והקל ביותר לקרוא לא נכון. דחייה מפורשת היא תשובה, כלומר הנתיב עובד והבעיה היא הזהות, האישור או מצב החשבון. תהליך התחברות יחיד מבוסס דפדפן הוא מקרה שלישי: הלקוח מחכה לפעולה שלא עשיתם, או לדפדפן שהוא לא יכול להפעיל, ושום דבר לא יגיע עד שתשלימו את השלב הזה.
השוו את הראיות לפני שתשנו את הניסיון החוזר
השאירו את המכשיר והפרופיל קבועים ושנו דבר אחד בכל פעם, החל ברשת. אם אותו פרופיל מתחבר דרך נקודת גישה של טלפון ופוסק בזמן ב-Wi-Fi של המלון, המשתנה הוא הנתיב ולא השרת. אם הוא נכשל בכל מקום, המשתנה הוא הפרופיל או נקודת הקצה. אם הוא נכשל רק בשעה מסוימת ביום, תעדו את חתימת הזמן והשוו אותה לאירועים בצד השרת לפני שאתם מניחים משהו על עומס.
בשירות שאתם מנהלים, ההשוואה המכרעת היא אם הניסיון מגיע בכלל. חיבור שמגיע למאזין ואז נתקע שייך לשלב המשא ומתן; זה שאף פעם לא מופיע בשדה הראייה של המאזין הוא בעיית תעבורה או פענוח, ואף כיול ניסיונות חוזרים לא יזיז אותו. יומני השרת גם מפרידים בין התחברות שנדחתה לנשירה שקטה, וזה ההבדל בין תיקון זהות לתיקון חומת אש.
תעדו את גרסת הלקוח, את שם הפרופיל, את זמן הניסיון עם אזור הזמן שלו ואת השגיאה השימושית הראשונה במקום השורה האחרונה של הניתוק. הסירו מפתחות וחומר נושא אישורים לפני שאתם משתפים את הקטע. אחר כך עשו תיקון משמעותי אחד ונסו שוב, כי מועד ארוך יותר עוזר רק לפעולה האיטית המתועדת ולא עושה דבר לכתובת שגויה או לפורט חסום.