הצב את שער ה-VPN לצד Windows XP, לא בתוכו

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

התחל במתאם של המארח, לא בלקוח VPN

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

C:\> route add 10.20.30.0 mask 255.255.255.0 192.168.50.1 -p

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

שים את המנהרה על חומרה שאתה יכול לעדכן

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

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

אפשר שירותים, לא רשתות

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

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

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

השחזור חייב לעבוד בלי המנהרה

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

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

תעודות, שעונים ואזהרות חתימה

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

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