שמות פנימיים נכשלים ב-VPN בזמן שאתרים ציבוריים נפתרים כראוי
שתי תקלות מגיעות יחד: שם האינטראנט אינו נפתר, והשאילתות עדיין יוצאות מהמנהרה. השוו סדר מתאמים, סיומת ומפענח שנדחף.
משתמש אחד מדווח ששם המארח של האינטראנט אינו נפתר דרך ה-VPN. דיווח שני, מאותו מחשב נייד, אומר שבדיקת דליפה עדיין מראה תשובות שמגיעות מהמפענח המקומי. הם נשמעים כמו תקלה אחת והם שתיים, עם ראיות שונות, והתיקון הרגיל לראשונה מחמיר את השנייה. הפרידו ביניהן לפני שנוגעים בהגדרה.
שני תסמינים שאינם תקלה אחת
כישלון בפתרון שם פנימי פירושו שהשאלה הלכה למקום שאין לו תשובה עבורה. שאילתות שיוצאות מהמנהרה פירושן שהשאלה הלכה למקום הלא נכון גם כשהתשובה הייתה זמינה. אלו כשלים הפוכים: האחד תשובה חסרה, השני יעד עודף.
המלכודת היא שהוספת מפענח המשרד בכל מקום מתקנת את הראשון ומבטיחה את השני. הוספת מפענח ציבורי בכל מקום עושה את ההפך.
רשמו את שתי התצפיות עם חותמת זמן, ואז עברו על ארבע הבדיקות שלמטה לפי הסדר.
איזה מפענח של המתאם מקבל את השאלה
ב-Windows לקוח ה-DNS בוחר שרתים לפי סדר כריכת המתאמים, ומתאם המנהרה אינו אוטומטית ראשון. פתחו את ההגדרות המתקדמות של המתאם והעבירו את חיבור הגישה מרחוק מעל המתאם הפיזי, ואז התחברו מחדש כדי שהשינוי יחול על הפעלה חדשה.
סדר הכריכה הוא רק החצי הראשון. הלקוח גם צריך לדעת אילו שמות שייכים לאותו מתאם, וזו שאלת סיומת ולא שאלת סדר.
שימו את ipconfig /all של המכונה העובדת לצד זה של המחשב הנייד, שניהם נלקחו כשהמנהרה פעילה. המכונה העובדת תציג סיומת DNS ייעודית לחיבור במתאם המשרד שלה, והמחשב הנייד אולי לא יציג דבר על המנהרה. ההבדל הזה מסביר סוג שלם של דיווחים שלפיהם השרת שם והשם עדיין נכשל, כי בלי סיומת השם הקצר לעולם אינו מושלם לאזור שמפענח המשרד משרת.
שם קצר צריך סיומת לפני שהוא צריך נתיב
הקלדת שם מארח לא מסויג מבקשת מהמפענח לנחש דומיין. הניחוש מגיע מרשימת הסיומות שמצורפת לחיבור, ואם הרשימה ריקה השאילתה יוצאת כתווית אחת שאף אזור פרטי לא יתאים לה.
העתיקו את הסיומת של המכונה העובדת אל מאפייני IPv4 של מתאם ה-VPN בלשונית DNS, ואז התחברו מחדש. בלינוקס המקבילה היא דומיין החיפוש על קישור המנהרה, ש-systemd-resolved חושף לכל קישור ולא באופן גלובלי.
הפרידו בין שתי ההגדרות בהערות שלכם. סיומת משנה מה נשאל; כתובת המפענח משנה מי נשאל. תיקון אחד כשהשני שגוי מייצר תוצאה שנראית אקראית.
שאלו את המפענח ישירות, ואז את השם
שאילתה ישירה למפענח המשרד מפרידה בין בעיית שם לבעיית נתיב, כי היא עוקפת לגמרי את בחירת המפענח של הלקוח.
nslookup intranet.corp.example 10.20.0.53 nslookup intranet resolvectl status
הפקודה הראשונה שואלת שרת מסוים על שם מלא. אם הוא עונה, המפענח והנתיב אליו תקינים והתקלה בבחירה או בסיומת. אם היא נגמרת בזמן, הכתובת שגויה או אינה נגישה והבעיה בניתוב ולא ב-DNS. הפקודה השנייה מראה מה קורה עם השם הקצר, והשלישית מדפיסה את תצורת המפענח לכל קישור במארח systemd.
שימו לב לתשובות כלליות, שחלק מהרשתות מחזירות לשמות לא מוכרים. תשובה שנראית סבירה אינה הוכחה שהשרת המיועד ענה, לכן השוו את הכתובת שהוחזרה לזו ששירות הפנים באמת משתמש בה. אם הכתובת שייכת לדף חנייה או לפרוקסי, המפענח ענה אבל התשובה מעולם לא הייתה שלכם. ההבחנה הזו חוסכת שעה של מרדף אחרי מנהרה שעבדה כל הזמן.
בלינוקס, לקוח VPN שמשכתב את /etc/resolv.conf מחליף לגמרי את המפענחים המקומיים. vpnc חושף DNSUpdate no כדי לעצור זאת, ו-systemd-resolved יכול לנתב רק את הדומיינים הרשומים לקישור המנהרה. שתי הגישות משאירות שמות ציבוריים אצל המפענח המקומי בזמן שהן שולחות שמות פנימיים למשרד.
דליפות הן כלל, לא תיבת סימון
פתרון שמות הוא חילופי UDP לפורט 53, כך שמנהרה שנושאת תעבורת רשת אבל לא UDP משאירה את השאילתה על הנתיב הפיזי. הוכיחו זאת בלכידה בכרטיס הרשת הפיזי בזמן ששם ציבורי נפתר. שאילתה שנראית בממשק הזה בצורה קריאה פירושה שהמנהרה לא נושאת אותה.
sudo tcpdump -ni eth0 -c 20 'udp port 53' resolvectl query example.com
אם השאילתה מופיעה בממשק הזה בצורה קריאה, המנהרה לא נושאת אותה. התיקון הוא כלל שמתיר פורט 53 רק למפענח שה-VPN דחף וזורק יעדים אחרים, בתוספת תצורת לקוח שאינה משליכה בשקט את האפשרות שנדחפה.
החלק האחרון הזה חשוב יותר ממה שהוא נראה. התחילו את OpenVPN עם route-nopull ואפשרות ה-DNS שנדחפה נעלמת יחד עם הנתיבים, אלא אם מסנן המשיכה מורחב כדי לשמור אותה. ולקוח שמתעלם מdhcp-option DNS ימשיך להשתמש במה שהיה לו קודם. כל שינוי בצד השרת צריך הפעלה חדשה כדי לחול, מפני שרשימת המפענחים נמסרת כשהמנהרה עולה והפעלה מיושנת ממשיכה להציג את המצב הישן.
רשמו איזה כשל באמת ראיתם לפני סגירת הפנייה. תשובה פנימית חסרה ושאילתה שבורחת מהמנהרה דורשות תיקונים שונים, ושינוי סיומת שמתקן את הראשון יכול להחמיר בשקט את השני. מי שיקבל את הפנייה הבא יאמין לתווית, לכן עשו את התווית מדויקת.