למה DNS מפסיק לעבוד אחרי ש־OpenVPN מתחבר ב-Windows
המפענח עדיין עונה לפינג בעוד שפורט 53 לא מגיע לשום מקום. בדקו אם block-outside-dns מסנן, ואז ספקו מפענח שהמנהרה יכולה להגיע אליו.
פינג למפענח של המשרד עדיין מקבל תשובה אחרי ש־"OpenVPN" מתחבר, ובכל זאת כל חיפוש שם נכשל. הכתובת נגישה בעוד שהפורט אינו, שילוב שמתקבל על הדעת ברגע שיודעים ש-Windows יכול לסנן DNS לפי מתאם. כש-block-outside-dns נמצא בפרופיל, המסנן הזה הוא החשוד הראשון וטבלת הניתוב היא המקום הלא נכון לחפש בו. שתי הבדיקות שלמטה מפרידות בין השכבות בשניות.
כתובת נגישה, פורט מת
פינג מוצלח מוכיח שהמארח פעיל ושקיים מסלול. הוא לא אומר דבר על הרשאה להגיע לפורט 53, כי המסנן המדובר פועל בשכבה אחרת ותלוי במתאם. לכן אותו מחשב יכול לענות ל-ICMP ולסרב לכל שאילתה שנשלחת לאותה כתובת. הריצו את שתי הבדיקות באותה הפעלה לפני שתשנו הגדרה כלשהי.
ping <resolver-ip>
nslookup <name> <resolver-ip>הזוג הוא האבחנה. תעבורה רגילה לתת-הרשת ממשיכה לעבוד בזמן שפתרון השמות מת, ואנשים מסיקים שהשרת שבור או ש-DNS מעולם לא נדחף. שני ההסברים יקרים למרדף, והראיות מצביעות למקום צר יותר. אשרו את הזוג לפני שנוגעים בהגדרה.
האפשרות היא כלל של פלטפורמת הסינון
תיעוד OpenVPN מתאר את block-outside-dns כמגבלה של Windows Filtering Platform שמונעת מיישומים להגיע ל-DNS במתאמים שמחוץ למנהרה. היא מכסה TCP ו-UDP בפורט 53. מכיוון שהמסנן חי ב-WFP ולא ברשימת כללי חומת האש הרגילה, הוספת כלל הרשאה במקום אחר לא בהכרח משנה את התוצאה. לכן העצה הנפוצה לאפשר DNS ממשיכה להיכשל.
ההגדרה יכולה להגיע מהפרופיל המיובא או מהשרת, והקובץ שערכתם לאחרונה "אינו הוכחה למה שהלקוח טען". קראו את התצורה האפקטיבית ואת יומן החיבור יחד. האפשרות גם ייחודית ל-Windows, והתייחסות אליה כאל ניידת מייצרת עצות שאינן חלות.
חפשו את רכיב הלקוח שמחזיק במגבלה במקום להוסיף כללים. הבעלים הוא הדבר שיכול באמת להסיר אותה.
מסנן אינו מפענח
חסימת תעבורה מחוץ למנהרה אינה מתקינה מפענח עובד בתוכה. האפשרות מסירה מסלול ומשאירה את תצורת ה-DNS של המנהרה למי שהקים את הפרופיל. פרופיל שמעולם לא דחף מפענח אין לו כעת אף אחד.
עברו על שלוש בדיקות לפי הסדר. ראשית, איזה מפענח היישום שנכשל באמת משתמש. שנית, אם הלקוח החל את הגדרות ה-DNS של ה-VPN. שלישית, איזה ממשק נושא את התעבורה לאותו מפענח.
- מפענח בשימוש: השוו את
Resolve-DnsName -Server <resolver-ip> <name>לשרתי ה-DNS ש-ipconfig /allמפרט. - DNS של ה-VPN הוחל: בדקו את רשומות ה-DNS של מתאם המנהרה באותה פלט של
ipconfig /all. - ממשק בשימוש:
Find-NetRoute -RemoteIPAddress <resolver-ip>מציין את ממשק היציאה עבור היעד הזה.
מפענח LAN הופך לבלתי נגיש לפי התכנון תחת מדיניות זו, גם בזמן שתעבורת LAN אחרת עובדת. זו האפשרות עושה את עבודתה. אם התכנון זקוק ל-DNS דרך ה-VPN, תקנו את רישום המפענח ואת מסלול המנהרה; אם נדרש split DNS עם חריגים מקומיים, בעל התצורה חייב לבטא את החריגים האלה בדרך נתמכת.
מה האפשרות אינה מכסה
פורט 53 אינו כל פתרון השמות. DNS over HTTPS ו-DNS over TLS משתמשים בתעבורות שונות, ויישומים מסוימים מריצים היגיון מפענח משלהם ללא תלות בהגדרות המערכת. לכן דפדפן יכול לפתור שמות בעוד ששורת הפקודה אינה יכולה.
התייחסו להבדל הזה כאבחנה ולא כסתירה. השוו בין השניים לפני שתחליטו שמפענח המערכת שבור.
שמרו על מסקנה צרה כשאתם כותבים אותה. האפשרות הזו מגבילה תעבורה אחת בפלטפורמה אחת, ושאר מסלול הפתרון הוא שאלת תכנון נפרדת עם בעלים משלו.
בדקו את המצב לפני ואחרי ניתוק
הריצו את אותו חיפוש במהלך החיבור ושוב אחרי שהלקוח הבעלים מתנתק. הראשון אמור להיכשל עבור מפענח חיצוני כשהמנהרה פעילה, והשני אמור להצליח ברגע שהמסנן מוסר. אם הוא עדיין נכשל אחרי הניתוק, המסנן לא נוקה.
ipconfig /displaydns
nslookup <name> <resolver-ip>הפעלה מחדש של שירות הלקוח או של המחשב מנקה בדרך כלל מסנן ישן. זה מאשר את האבחנה בלי להוכיח תיקון קבוע. רשמו מה ראיתם, כי מסנן ששורד ניתוק יעשה זאת שוב, והרישום הוא מה שמצדיק דוח באג.
רק אחרי הבדיקות האלה יש היגיון בהחלפת המפענח או בבנייה מחדש של מדיניות חומת האש. שניהם שינויים גדולים ממה שהראיות תומכות בו.