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

למה ההגדרה באמת מתחייבת

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

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

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

ארבע שאלות שמתמזגות לאחת

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

השחזור שואל מה קורה כשהקישור משתנה או נעלם, וזו השאלה הצרה שאליה מתייחס vpn.persistent. החיות שואלת אם הלקוח יכול לדעת שהצד השני הפסיק לענות, והתנהגות ה-keepalive או ההפעלה מחדש של OpenVPN עונה על כך במקומה; שני המנגנונים מתוארים לעיתים קרובות באותה מילה ומיושמים במקומות שונים. בדקו אותם בנפרד, בכלים שונים, אחרת תייחסו התנהגות אחת לשנייה.

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

רשימת בדיקה שמחזיקה אותן בנפרד

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

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

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

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

אימות הוא חלק מהשחזור

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

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

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

התמדה אינה kill switch

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

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

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

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