נתב חדש, אותו שרת VPN: העבר את הכניסה הציבורית שלו

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

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

כתוב את המסירה לפני שאתה מנתק

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

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

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

העבר קודם את הכתובת, אחר כך את ההעברה

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

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

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

החלט מי מעדכן את השם הציבורי

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

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

הוכח את ההחלפה מבחוץ

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

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

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

שמור את המיפוי החדש עם הערות השחזור שלך

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

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