החלפת ספק בלי למספר מחדש את כתובות ה-VPN של האתר

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

שתי תוכניות כתובות שזזות באופן בלתי תלוי

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

החלפת ספק נוגעת בתוכנית החיצונית. היא כשלעצמה אינה מחייבת שינוי של התוכנית הפנימית.

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

המנהרה החיצונית נושאת את השיחה הפנימית

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

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

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

למעבר הספק עדיין יש רשימת בדיקה

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

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

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

מה לא שורד: מקור ציבורי והפעלות

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

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

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

אמתו את המעבר בארבע בדיקות

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

בשער Linux, שלושת אלה מכסים את אמצע הרשימה:

ip route get 10.55.8.20
ip xfrm policy list
curl -sS -o /dev/null -w "%{http_code}" --max-time 8 http://10.55.8.20/health

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