ה-VPN עבר: למה לקוח ה-OpenVPN שלכם עדיין מחייג ל-IP הישן

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

הסתכלו על מה שהפרופיל מחייג, לא על מה ש-DNS אומר

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

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

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

grep -nE '^remote|^resolv-retry|^persist-remote-ip|^float' client.ovpn
printf 'resolver says: '; dig +short vpn.example.net

קראו את ניסיון החיבור הבא של הלקוח

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

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

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

דעו איזה אתחול אתם עושים

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

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

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

ארבע האפשרויות והתפקידים הנפרדים שלהן

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

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

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

אשרו את נקודת הקצה החדשה לפני שאתם מאשימים את הלקוח

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

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

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