העברת OpenVPN מ-TAP ל-TUN: סדר הגירה שעובד

החלפת dev tap ב-dev tun משנה את מה שהמנהרה נושאת, לא רק את שמה. ממשק TAP מוסר מסגרות Ethernet לגשר, ולכן לקוחות מתנהגים כאילו חוברו למיתוג המשרד. ממשק TUN נושא חבילות IP, ולכן לקוחות זקוקים לנתיבים והצד השני זקוק לדרך חזרה. הלקוחות, תוכנית הכתובות ונתיב החזרה של ה-LAN חייבים לזוז כולם עם השינוי הזה.

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

עשו מלאי של מה שבאמת תלוי ב-Ethernet

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

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

בנו את תוכנית הכתובות ונתיבי החזרה

בחרו קידומת לקוחות שאינה חופפת ל-LAN, לטווח הגשר הישן או לכל רשת שלקוח כבר מגיע אליה.dev tun, topology subnet ו-server 10.78.0.0 255.255.255.0, אבל זהו מקטע ולא פרופיל עובד. שמרו סביבו את מדיניות TLS, הזהות, התעבורה והגישה המאושרת, והשתמשו בקידומת שאימתתם שהיא פנויה.

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

הריצו פיילוט במאזין נפרד

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

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

העבירו לקוחות בקבוצות עם אפשרות חזרה

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

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

הוציאו את הגשר משימוש רק לאחר הקבלה

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

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