ה-VPN שלכם דוחף שלושה שרתי DNS: איזה מהם עונה?
רשומות נוספות יכולות להיות גיבוי, מסלול לפי דומיין או שארית מהקישור הפיזי. שייכו כל אחת לתחום משלה לפני שאתם מכנים את הרשימה דליפה.
פתחו את עמוד ההגדרות לאחר ההתחברות ושלוש כתובות DNS מופיעות ברשימה; שאלת הביקורת היא איזו מהן טיפלה בשאילתה האחרונה שלכם. המספר לבדו אינו עונה על דבר, משום שדחיפת לקוח, ממשק פיזי ומדיניות לפי דומיין כולם כותבים לאותה תצוגה. לרשומות האלה יש תחומים שונים, והתחום ולא המיקום הוא שקובע מי עונה. התחילו בהפרדת המקורות, ואז בדקו את זה שמחזיק בשם שמעניין אתכם.
למה הרשימה ארוכה מהפרופיל שלכם
לקוח VPN דוחף כתובות של פותר עבור קישור המנהרה, ומערכת ההפעלה שומרת אותן לצד מה שהיה לממשק הפיזי מלכתחילה. נתב, חכירת DHCP ארגונית, VPN שני ומדיניות לפי דומיין כל אחד מוסיף רשומה משלו. לכן שלוש כתובות בעמוד יכולות לומר שלושה תחומים ולא שלושה מועמדים למשימה אחת. קריאת המספר כהוכחה לדליפה היא הטעות הראשונה בביקורת הזו.
בתוך ממשק אחד הלקוח אכן מנסה את השרתים שלו לפי סדר, ולכן רשימה מסודרת אינה חסרת משמעות. מה שאינו תור הוא התצוגה המאוחדת, שבה רשומות מהפרופיל, מהקישור הפיזי ומכללי דומיין יושבות זו לצד זו בלי דירוג אחד. ההבחנה הזו קובעת מה תבדקו: הסדר מסביר התנהגות בתוך תחום אחד, והתחום מסביר כל השאר.
DNS מוצפן שובר את התמונה מתוך יישום. דפדפן או לקוח צ׳אט עם פותר DNS-over-HTTPS משלו שולח שאילתות לגמרי מעבר לרשימת מערכת ההפעלה, ולכן הכתובות בעמוד ההגדרות מתארות תנועה שהיישום מעולם לא יצר. בדקו את הגדרת הפותר של היישום עצמו לפני שתאשימו את הפרופיל בשם שיצא שגוי.
מה כל אחת משלוש הבדיקות אומרת
כל מקור משאיר את סימנו במקום אחר, ואף פקודה אחת אינה מציגה את כולם. זו המיפוי שכדאי לשמור לצד עמוד ההגדרות:
| Entry source | Where it is visible | What it proves |
|---|---|---|
| Tunnel profile | Link-scoped DNS on the tunnel device | Which servers the VPN asked you to use, not which one answered |
| Per-domain policy | Suffix list or routing domains | Which names are steered to a particular resolver |
| Physical link | DNS on the LAN interface | Whether a second scope still exists outside the tunnel |
| Application resolver | App settings, absent from the OS list | Whether the system list was consulted at all |
במערכת שמשתמשת ב-systemd-resolved, resolvectl status היא הקובעת, משום שהיא מדווחת על DNS לכל קישור יחד עם תחומי הניתוב. macOS עונה דרך scutil --dns, שמפרט פותרים בעלי תחום לפי סדר הניסיון. Windows מפצל את שני החצאים: Get-DnsClientServerAddress עבור שרתים לכל ממשק ו-Get-DnsClientNrptPolicy עבור כללי הסיומת. הריצו את הפקודה שמתאימה לפותר שבשימוש בפועל, משום שמכונה עם סביבת הרצה של מכולות ופותר שולחני יכולה להחזיק יותר מאחד מותקן.
פותר גיבוי שאינו יכול לענות על האזור שלכם
רשומה שנייה קיימת בדרך כלל לשם זמינות, וזמינות עובדת רק אם הגיבוי מכיר את השמות. שאלו פותר ציבורי על שם מארח פנימי והוא מחזיר NXDOMAIN, או תשובת תו-כללי מתחום חיפוש שאין לו שום קשר אליכם. מעבר גיבוי שאיש לא בדק יוצר אז הפסקה בדיוק ברגע שבו הוא נחוץ.
Split DNS קיים כדי למנוע זאת: סיומות החברה הולכות לפותר שמחזיק באזור, והשמות הציבוריים נשארים בנתיב ברירת המחדל. התכנון תקין, והוא תלוי בכך שרשימת הסיומות שלמה. Microsoft מתעדת את מדיניות הפותר לכל סיומת שמניעה זאת ב-Windows, ואותו רעיון מופיע כתחומי ניתוב ב-systemd-resolved ופותרים בעלי תחום ב-macOS.
השוו את האזורים שהגיבוי רשאי לענות עליהם לסיומות שבמדיניות. ההשוואה הזו מוצאת את הפער לפני שמשתמש מדווח שאתר פנימי אחד הפסיק להיפתר לאחר שינוי במנהרה.
שאלו דרך המדיניות, לא סביבה
שאלו דרך הפותר של מערכת ההפעלה, משום ששאילתה ישירה לשרת עוקפת את המדיניות ומדווחת רק מה שהשרת הזה היה אומר. הפער בין שתי התשובות הוא כל העניין:
resolvectl query intranet.example.com
dig +short intranet.example.com @198.51.100.53אם שאילתת המערכת מחזירה כתובת פרטית בעוד השאילתה הישירה מחזירה NXDOMAIN, המדיניות עובדת והגיבוי הוא נקודת התורפה. אם שתיהן מחזירות אותה תשובה ציבורית, השם נפתר מחוץ לתחום שהתכוונתם אליו, ורשימת הסיומות היא המקום להסתכל בו. שמרו את שני הפלטים, משום שוויכוח על פותר נסגר מהר יותר בשתי שורות מאשר בצילום מסך של עמוד ההגדרות.
לאחר מכן תרגלו את מסלול הכשל, משום שגיבוי שאיש לא בדק הוא הנחה. הפכו את הפותר המועדף לחור שחור לשאילתה אחת וראו איזו כתובת חוזרת:
ip route add blackhole 198.51.100.53/32
resolvectl query intranet.example.com
ip route del blackhole 198.51.100.53/32מחקו את המסלול הזה ברגע שהשאילתה מסתיימת, אחרת האדם הבא יורש תעלומה. אם שמות פנימיים עדיין נפתרים בחלון הזה, משהו מחוץ לתחום המיועד ענה עליהם. אם הם במקום זאת מגיעים לפסק זמן, הגיבוי חסר או מוגבל כראוי, והיומן של הפותר עצמו אומר לכם איזה משני אלה היה.
החליטו: לשמור, להגביל או להסיר
שמרו פותר שני כשהוא עונה על מרחב השמות שאתם צריכים ונשאר נגיש תחת הפרופיל. הגבילו אותו כשהוא אמור לראות סיומת אחת ושום דבר אחר, והסירו אותו כשאין לו לא תחום ולא מטרה מתועדת. רשומה בלי תפקיד היא דליפה עתידית בלי תועלת, וברירת מחדל של ספק אינה מטרה.
רשמו את התוצאה בארבעה עמודות: סיומת, פותר, ממשק ובעלים. השורה הזו עונה על שאלת הביקורת הבאה מהר יותר מכל צילום מסך, והיא שורדת את עדכון הלקוח שמסדר את הרשימה מחדש בשקט.