ה-VPN השתלט על ה-DNS ושבר שמות מקומיים: תקנו את הרשימה

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

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

איזו רשימה האפליקציות באמת משתמשות בה

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

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

netsh interface ipv4 show dnsservers
Get-DnsClientServerAddress -AddressFamily IPv4

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

הסירו את השרתים הנדחפים, או דרגו אותם נמוך יותר

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

netsh interface ipv4 delete dnsservers name="Corp VPN" address=all validate=no
netsh interface ipv4 add dnsservers name="Corp VPN" address=172.16.20.1 index=1 validate=no

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

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

היכן אפשר לסנן את ה-push

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

pull-filter ignore "dhcp-option DNS "

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

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

גרמו לתיקון לשרוד התחברות מחדש

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

Resolve-DnsName intranet.corp.example -Server 172.16.20.1
Resolve-DnsName printer.lan

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

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