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

מה הרשימה בעצם מדדה

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

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

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

עקבו אחר שלבי הלקוח, לא אחרי הספינר

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

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

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

משתנה אחד לכל ניסיון

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

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

כשכל צומת נכשל באותה דרך

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

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

קראו את הכשל בשלב שבו הוא התרחש

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

dig +short node.example.net
curl -s --max-time 5 telnet://node.example.net:443
openvpn --config node.ovpn --verb 4 2>&1 | grep -iE "TLS|AUTH|PUSH"

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

מאמרים קשורים