בקשת תמיכה ב-VPN ביתי צריכה זרימה אחת, לא ערימת קונפיגורציה

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

למה הבקשה מקבלת תשובות לא מועילות

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

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

מלאו את הרשומה הזו לפני הפרסום

Goal: the one resource or operation that should work
Path: client -> access network -> VPN endpoint -> resource
Owners: who controls the client, the gateway and the resource
Software: product, version and protocol in use
Expected: what success would look like
Observed: exact non-secret error or response
Time and change: when it started and what changed
Control: one comparable operation that still works

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

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

תנו שם לשלב שנכשל, לא ליומן כולו

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

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

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

שלחו אותו לבעלים שיכול לפעול

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

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

הסתירו סודות בלי לשטח את הטופולוגיה

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

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

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