עריכת resolv.conf לא מתקנת את ה-DNS אחרי ניתוק ה-VPN

אתם מנתקים את ה-VPN, ping 1.1.1.1 עדיין עונה, וכל שאילתת שם נתקעת לפני שהדף סוף סוף מוותר. ואז cat /etc/resolv.conf מציג שרת שמות שהתקיים אי פעם רק בתוך המנהרה, בדרך כלל הראשון ברשימה. מחיקת השורה הזו נראית כמו תיקון לכעשר דקות, עד שהשעיה, נדידת Wi-Fi או הפעלה מחדש מחזירים אותה. הקובץ שערכתם אינו ההגדרה; הוא תיאור של מצב הקישור ששייך לרכיב אחר.

למה ערך מיושן אחד עולה שניות לכל שאילתה

הפותר של glibc עובר על רשימת שרתי השמות לפי הסדר וממתין שההשהיה תפוג לפני שהוא מנסה את הבא, ו־resolv.conf(5) מגביל את הרשימה הזו לשלושה ערכים. שימו פותר מצד המנהרה כמו 10.8.0.1 בראש הרשימה אחרי שהמנהרה נעלמה, וכל שאילתה משלמת את ההשהיה לפני שהיא נופלת לשרת שעונה. זו הסיבה שהתסמין נראה כמו חיבור מת ולא כמו שגיאת DNS: הדפדפנים נחסמים, נגמר להם הזמן ולפעמים הם מגישים כתובת שמורה במטמון שמתיישנת אחר כך.

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

המיתוס: resolv.conf הוא קובץ הגדרות

שאלו מהו הנתיב באמת לפני שאתם משנים אותו:

ls -l /etc/resolv.conf
readlink -f /etc/resolv.conf

במארח עם systemd-resolved זהו קישור סמלי לקובץ stub שמצביע ל־127.0.0.53, והשרתים האמיתיים חיים במצב לפי קישור ש־resolvectl מדפיס. במארח עם NetworkManager זה עשוי להיות קובץ ש־NetworkManager כותב מהחיבור הפעיל. אצל חלק מלקוחות הספקים זהו קובץ פשוט שנכתב מחדש במקום בעת ההתחברות ואם אין לכם מזל אינו משוחזר לעולם בעת הניתוק. אלו שלושה בעלים שונים, ועריכה ידנית של השניים הראשונים או שאינה עושה דבר או שמחזיקה עד לאירוע הרשת הבא.

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

מצאו את הבעלים לפני שאתם עורכים משהו

בדרך כלל שלושה רכיבים מתחרים על אותה הגדרה: systemd-resolved, NetworkManager ומה שלקוח ה־VPN התקין. זהו קודם את זה שחי:

systemctl is-active systemd-resolved
nmcli connection show --active
ps aux | grep -E "openvpn|wg-quick|vpn"

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

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

לקוח שנהרג לא יכול להריץ את וו הניקוי שלו. אי אפשר לתפוס SIGKILL בכלל, בעוד SIGINT ו־SIGTERM ניתנים לתפיסה, ולכן מנהרה ש״פשוט נעצרה״ אחרי הרג כפוי משאירה לעיתים קרובות גם את רישום הממשק וגם את ערך הפותר במקומם. מצאו את ה־PID המדויק ושלחו את האות רק אליו:

ps aux | grep -E "openvpn|wg-quick"
sudo kill <pid>
resolvectl revert tun0

אל תשלחו יד ל־pkill -f vpn או killall vpn לפני שקראתם את רשימת ההתאמות המלאה. -f מתאים לשורת הפקודה כולה, ולכן הוא עלול לסיים סקריפט עטיפה, הפעלת עורך או תהליך לא קשור שנתיבו מכיל את המחרוזת. סיום התהליך הלא נכון באמצע העבודה הוא הדרך שבה בעיית פותר הופכת לקובץ אבוד.

resolvectl revert מאפס את תצורת ה־DNS בזמן ריצה של אותו קישור, שזה צר יותר מאתחול הפותר והרבה יותר צר מעריכת הקובץ הגלובלי. אם קישור המנהרה נעלם לגמרי, systemctl restart NetworkManager בונה מחדש את מצב החיבור וזה השלב ששרשורי המקור חוזרים אליו שוב ושוב. שימו לב למנהל שירותים עם Restart=always, כי הוא יכול להחזיר לקוח שנהרג ואת הגדרות ה־DNS שלו ישר בחזרה.

הכיוון השני: DNS שנדחף ולא הגיע מעולם

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

בדקו את המסירה על ידי ביצועה ידנית, מה שמפריד בין ״השרת שגוי״ ל״אף אחד לא החל אותו״:

resolvectl dns tun0 10.10.10.10
resolvectl domain tun0 ~.

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

nmcli connection modify office ipv4.ignore-auto-dns yes
nmcli connection modify office ipv4.dns 10.10.10.10
nmcli connection modify office ipv4.dns-search "~."

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

עקיפות שהופכות לתקלה הבאה

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

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

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