כתבו תקציר עיצוב VPN שמישהו באמת יכול לסקור

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

ראשית, האם השאלה היא החלטה או משאלה

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

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

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

שנית, נקבו בשמות הזרימות והדחיות

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

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

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

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

בדיקה 3: הפרידו עובדות מהנחות

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

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

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

ip route get 10.50.0.10
traceroute -n -m 6 10.50.0.10
nc -vz 10.50.0.10 443

רביעית, כתבו את חוזה הכשל

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

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

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

בדיקה 5 ו-6: בחרו את התפר ותעדו את השינוי

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

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

git diff --stat design/vpn-brief.md
grep -n 'assumption' design/vpn-brief.md
ip route get 10.50.0.10

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