מעבר מ-VPN מבוסס PPP בלי להעתיק את ההנחות שלו

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

שלב 1: תעדו מה החיבור הישן מספק

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

עבור L2TP/IPsec, הפרידו במפורש בין שתי השכבות. זהות עמית ה-IPsec מאמתת את המכונות; PPP מאמת את המשתמש, בדרך כלל עם CHAP או MSCHAPv2.

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

שלב 2: תכננו את התחליף בכוונה

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

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

שלב 3: פרסו בהדרגה ואמתו גם היתר וגם חסימה

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

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

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

שלב 4: הוציאו את הזהות הישנה משימוש

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

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

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

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