המנהרה המפוצלת שלכם מגיעה לאפליקציה אך לא לשרת ה-DNS שלה
מנהרה מפוצלת יכולה לנתב את תת-הרשת של האפליקציה ובכל זאת להפיל את הפותר שלידה. הוסיפו את מסלול המארח, ואז בדקו איזה שרת Windows באמת בוחר.
ניתוב תת-הרשת של האפליקציה הוא החלק הברור של מנהרה מפוצלת, והוא אינו כל העבודה. הפותר יושב לעתים קרובות בכתובת אחרת מזו של האפליקציה שהוא משרת, ולכן מנהרה שעובדת עשויה להשאיר את החיפוש מחוצה לה. פרופיל שנושא 10.80.0.0/16 ושום דבר אחר שולח את השאילתה עבור 10.90.0.53 דרך הממשק המקומי, שבו אין אזור פרטי. הוסיפו את המסלול אל הפותר, ואז הסתכלו על החצי השני של הבעיה: איזה שרת הלקוח באמת בוחר.
המיתוס: מסלול אחד מכסה את כל השירות
מנהרה מפוצלת היא רשימה של יעדים שעוברים דרך החיבור, לא תיאור של שירות. תת-הרשת של האפליקציה וכתובת הפותר הן שני יעדים, ופרופיל יכול לשאת אחד בלי השני. כשזה קורה, האפליקציה נגישה לפי כתובת בעוד שמה נכשל, מה שנראה כתקלת DNS ולא כפער בניתוב.
גם תת-הרשת שסביב הפותר אינה מכוסה אוטומטית. מסלול מארח לכתובת אחת מספיק לאותו פותר ואינו פותח את שכניו. זהו הרעיון של מסלול מארח: צר מלכתחילה, וקל לשכוח אותו כשהשירות הבא מופיע באותה תת-רשת.
שלושה דברים חייבים להתקיים כדי שהחיפוש יעבוד: הלקוח מנתב את כתובת הפותר דרך המנהרה, השער מקבל ומעביר את הבקשה, והפותר מקבל את המקור שהוא מקבל. גם התשובה חייבת לחזור במסלול המוסכם. אם חסר אחד מהם, הסימפטום זהה, ולכן כדאי לרשום את טבלת הכתובות לפני שנוגעים בתצורה.
קבעו אילו כתובות הפרופיל חייב לשאת
רשמו את היעדים לפי הסדר: רשת האפליקציה, כתובת הפותר ונקודת הקצה הציבורית שמסיימת את המנהרה עצמה. השלישי לעולם לא יינתב אל תוך המנהרה, כי החיבור החיצוני זקוק למסלול שקיים לפני המנהרה.
| Destination | Coverage this example needs |
|---|---|
| Application network | 10.80.0.0/16 through the VPN |
| Private resolver | 10.90.0.53/32 through the VPN |
| Public VPN endpoint | Normal internet path, outside the tunnel |
כללו גם UDP וגם TCP עבור DNS, מכיוון שמצופה מהמימושים לתמוך ב-TCP לצד UDP, ומסלול TCP חסום מייצר כשלים איטיים וחלקיים במקום נקיים. אם האזור הפרטי מוגש גם דרך IPv6, החריגה המקבילה למארח משתמשת בכתובת ובתחילית IPv6 והיא רשומה נפרדת.
רשמו מה הפרופיל כבר מכסה לפני שתוסיפו משהו. מסלול כפול אינו מזיק, אבל מסלול קיים בלתי צפוי אומר לכם שהפרופיל תוכנן לתוכנית כתובות אחרת מזו שקיבלתם.
הוסיפו את מסלול המארח דרך בעל החיבור
בפרופיל Windows מקורי המנוהל מקומית, המסלול שייך לחיבור ולא לטבלת הניתוב הגלובלית של המכונה. הציגו תצוגה מקדימה של ההוספה תחילה, ואז החילו אותה באותו היקף שהפרופיל משתמש בו.
Add-VpnConnectionRoute -ConnectionName 'Office VPN' -DestinationPrefix '10.90.0.53/32' -WhatIf Get-VpnConnection -Name 'Office VPN' | Select-Object -ExpandProperty Routes
הפקודה הראשונה מציגה תצוגה מקדימה של השינוי בלי להתקין דבר, והשנייה מפרטת את המסלולים שהפרופיל נושא כעת. הפניה של Add-VpnConnectionRoute של Microsoft מתעדת את ההיקפים לכל משתמש ולכל המשתמשים; פרופיל לכל המשתמשים זקוק לפרמטר ההיקף שלו, ופקודה לכל משתמש מול פרופיל לכל המשתמשים נכשלת או נוחתת במקום הלא נכון.
כשהפרופיל מנוהל או מגיע מלקוח של ספק, השינוי שייך לאותו בעל. ערימת מסלול מערכת קבוע על גבי מדיניות חיבור עובדת עד שהמדיניות מוחלת מחדש והמסלול נעלם, וזה קורה בדרך כלל בשיחת תמיכה ולא בבדיקות. הכשל הזה שקט: המסלול נעלם, השם מפסיק להיפתר, ואיש אינו מחבר בין שני האירועים. שימו את השינוי ברשומה של הבעל עצמו כדי שההחלה החוזרת הבאה תישא אותו ולא תמחק אותו.
לאחר ההחלה, חברו מחדש את הפרופיל במקום להניח שהמסלול נכנס לתוקף. שינויי מסלול בחיבור חי לא תמיד נקלטים, וחיבור מחדש גם משחזר את המצב שלמשתמשים שלכם באמת יהיה.
בדקו איזה פותר הלקוח באמת השתמש בו
מסלול שולט בחבילות המופנות לפותר. הוא לא קובע אילו שמות צריך לשלוח לשם, והבחירה הזו היא מנגנון נפרד. ב-Windows, כללי מרחב שמות אפקטיביים יכולים לבחור פותר לפי דומיין, בעוד שהגדרות ה-DNS של הפרופיל מספקות ברירת מחדל. שתי השכבות האלה יכולות לחלוק בלי לייצר שום שגיאה, ולכן שאילתה ישירה היא רק חצי מהראיה.
Get-DnsClientNrptPolicy Resolve-DnsName app.svc.example -Server 10.90.0.53 -Type A
הפקודה הראשונה מדפיסה את מדיניות מרחב השמות בתוקף, והשנייה שואלת את הפותר הפרטי ישירות על שם האפליקציה. תשובה ישירה מוכיחה שהמסלול והפותר עובדים; היא לא מוכיחה שהחיפוש של האפליקציה עצמה בחר באותו שרת. השוו אותה לחיפוש רגיל של אותו שם ולתשובה שהאפליקציה מקבלת.
התחשבו במטמונים וב-DNS מאובטח ברמת הדפדפן, שיכול לעקוף לגמרי את פותר המערכת עבור שמות שמשתמש הקליד. סיומת חיפוש היא עוד עקבה מטעה: היא מרחיבה שם קצר לשם מלא ואין לה שום קשר לשאלה איזה שרת עונה.
סיימו בחיבור מחדש ובחזרה על החיפוש הרגיל, ואז אשרו שגלישה רגילה עדיין פועלת לפי המדיניות המאושרת שלה. החלפת הפותר הפרטי בפותר ציבורי כדי ששם לא קשור ייפתר אינה תיקון, והיא מעבירה בשקט שאילתות פרטיות למקום שאליו מעולם לא היו אמורות להגיע.