DNS של VPN עובד, אבל שמות .local עדיין נכשלים: מי פותר אותם?

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

שני פותרים, שתי תשובות שונות

חיפוש glibc מסורתי עובר על שורת hosts: ב-nsswitch.conf ושואל כל מודול בתורו עד שאחד עונה. לקוח שמדבר עם systemd-resolved דרך מאזין ה-stub שואל במקום זאת תהליך אחד, והתהליך הזה מיישם מדיניות לכל קישור בתוספת המקרים המיוחדים שלו. אפליקציה שמביאה פותר משלה, או שמקשרת ספרייה שעושה זאת, יכולה לעקוף את שניהם. לכן שם מארח אחד יכול להיות עם שלושה בעלים במחשב אחד, ורק אחד מהם יודע מה ה-VPN התכוון.

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

איזו פקודה באמת שאלה את הפותר שלכם

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

getent ahosts files.corp.local
resolvectl query files.corp.local
resolvectl status

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

למה .local מדלג על אזור ה-unicast שלכם

ההפניה של systemd-resolved מציינת ששמות מרובי תוויות שמסתיימים ב-.local הולכים בדרך כלל ל-DNS מרובה שידור כאשר mDNS מופעל, ולא ל-DNS חד-שידורי רגיל. RFC 6762 מקצה את מרחב השמות הזה ל-multicast מקומי לקישור, כך שאזור ארגוני יכול להחזיק רשומה נכונה שלעולם לא נשאלת לגבי הסיומת הזו. המנהרה יכולה לנתב את הפותר בצורה מושלמת ועדיין להפסיד במירוץ. ping שמצליח מהמטמון לא אומר דבר על החיפוש שהתרחש זה עתה.

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

החריג הצר מנצח סידור מחדש גלובלי

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

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

מה להוכיח אחרי השינוי

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

getent ahosts files.corp.local
resolvectl query files.corp.local
curl -sv --max-time 5 https://files.corp.local/ 2>&1 | head -n 20

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