הסרת רשומת VPN מיושנת ממסד הנתונים של resolvconf

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

לאשר ש-resolvconf הוא הבעלים של המצב

זהו קודם את הבעלים, כי אותו סימפטום תחת systemd-resolved דורש פקודות אחרות ותיקון אחר. חבילת resolvconf שומרת מסד נתונים תחת /run/resolvconf ומפנה את /etc/resolv.conf אל הקובץ שהיא בונה מאותו מסד נתונים. שתי קריאות מכריעות את השאלה: היעד של הקישור הסימבולי, והאם החבילה מותקנת ופעילה. יעד תחת /run/systemd/resolve מעיד על התכנון האחר, שבו שום דבר מכאן ומטה לא חל.

dpkg -l resolvconf | tail -1
ls -l /etc/resolv.conf
systemctl is-active resolvconf.service

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

מסד הנתונים מכיל קלטים, לא את התשובה

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

sudo resolvconf --list
sudo resolvconf -i

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

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

להוכיח שלרשומה אין בעלים

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

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

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

לבדוק את ההסרה ואת השכתוב

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

sudo resolvconf -d "RECORD_KEY_FROM_THE_LIST"
sudo resolvconf --list
resolvectl query host.corp.example || getent hosts host.corp.example

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

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

ווי ניתוק שנהרג משאיר את הרשומה מאחור

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

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

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