mDNS בתוך VPN: מדוע שמות .local לא נפתרים

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

בדקו מה נפתר היום ומה רק נראה נפתר

הפרידו קודם בין שתי השאלות: שאילתת unicast לשם מארח שואלת פותר, בעוד חיפוש אחר _ipp._tcp שואל את הקישור המקומי. ב-Linux, avahi-browse -a מראה מה multicast DNS יכול לראות, ו-resolvectl query name.local מראה מה עושה מחסנית הפותר עם השם הזה. ב-macOS, dns-sd -B _ipp._tcp מפרט שירותים שנתגלו בלי צורך בכתובת תחילה.

אם הכתובת עונה והשם לא, הניתוב עובד והגילוי לא. שם .local יכול להיענות גם על המארח עצמו דרך nss-mdns בלי ש-avahi-browse מותקן, לכן getent או פינג מוצלח לאותו שם אינם הוכחה שהגילוי חצה את המנהרה; תוצאת החיפוש ותוצאת הפותר הן ראיות שונות. אפליקציות שומרות במטמון את מה שגילו, ולכן התקלה מופיעה לעיתים קרובות שעות אחרי ההתחברות ולא בזמן ההתחברות. סגרו ופתחו מחדש את האפליקציה, ואז בדקו אם הרשומה במטמון מכילה שם או כתובת, כי כתובת ממשיכה לעבוד הרבה אחרי שהגילוי נעצר.

מדוע השאילתה לעולם לא חוצה את המנהרה

multicast DNS שולח שאילתות לכתובת 224.0.0.251, בתוך בלוק בקרת הרשת המקומית, בפורט UDP 5353. נתבים אינם מעבירים כתובות מהבלוק הזה, ולכן השאילתה נשארת בקישור שאליו נשלחה. השולחים גם מגדירים את TTL של IP, או את מגבלת הקפיצות של IPv6, ל-255 כדי שהמקבל יוכל לדחות חבילה שכבר חצתה נתב; כך הפרוטוקול מזהה זיוף מחוץ לקישור, לא כך הוא נשאר מקומי. מקומיות מגיעה מכתובת היעד, לא מ-TTL של קפיצה אחת.

גם סוג המנהרה חשוב. ממשק בסגנון tun מעביר חבילות IP ושום דבר אחר, ולכן שום קבוצת multicast לא שורדת דרכו. גשר בסגנון tap מרחיב את תחום השידור עצמו, ולכן כמה עיצובים ישנים גישרו במקום לנתב, וירשו כל בעיה שהגישור מביא.

חריג LAN מהימן לא משנה דבר מזה, כי הוא קובע איזה תעבורה רשאית להשתמש במנהרה במקום ללמד את המנהרה להעביר multicast. לחבילה עדיין אין מקטע משותף להישמע בו.

בחרו עיצוב שמות שתוכלו לתחזק

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

פרוקסי גילוי או משקף mDNS יכול לגשר על הפער, וזה עיצוב אמיתי עם מארח משלו, חשיפה משלו ודרישות לקוח משלו. הוא לא מופיע מפני שהוספתם מסלול. לעולם אל תעבירו שאילתות .local לפותר ציבורי: התחום שמור לשימוש multicast מקומי לפי RFC 6762, ושליחתו החוצה מייצרת כשלים איטיים וחשיפת נתונים מיותרת.

אמתו את השירות, לא את השם

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

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