מדוע חיפושי שמות נכשלים דרך מנהרת OpenVPN מנותבת

מארח עונה ל-ping לפי כתובת ונכשל בכל חיפוש לפי שם. המנהרה פעילה והמסלול קיים, ולכן המסקנה הטבעית היא שה-VPN מוגדר שגוי. מסקנה שימושית יותר היא שהחיפוש מעולם לא היה בר-ניתוב, שכן מנהרה מנותבת נושאת unicast IP, בעוד השאילתה הייתה שידור שחיפש מקטע שאינו קיים בצד השני. ברגע שמתגלה אי-ההתאמה בין השכבות, התיקונים מסתדרים מעצמם לפי עלות.

מיתוס: המנהרה שבורה כי השמות נכשלים

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

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

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

מה TUN נושאת ומה לא

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

תעבורת גילוי אינה מתאימה למודל הזה כלל. שאילתות שמות ישנות של Windows, הכרזות SSDP ובקשות mDNS נשלחות לכולם במקטע ולא ליעד אחד. לקישור מנותב אין «כולם» לשלוח אליו. כל אחד מהמנגנונים האלה מניח תווך משותף.

לכן המנהרה יכולה להיות תקינה בעוד הגילוי נכשל לחלוטין. במשפט הזה יש להחזיק כשמישהו מדווח שה-VPN נפל.

גישור פועל בהסרת הגבול

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

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

בשביל מעבדה קטנה זהו חילוף הוגן. בקרב כוח עבודה מפוזר זה נדיר.

דחיפת DNS ו-WINS היא התיקון הצר יותר

תנו ללקוח מקום מסוים לשאול. dhcp-option DNS ו-dhcp-option DOMAIN מפנים שמות פנימיים לשרת שמכיר את האזור, ולקוח Windows שעדיין נשען על NetBIOS יכול לקבל שרת WINS באותה דרך. המנהרה נשארת מנותבת והמקטע נשאר במקומו.

שני תנאים קובעים אם זה יעבוד. השרת הנקוב חייב להשיב עבור האזור, והשאילתה חייבת להיות מורשית דרך המנהרה.

בדקו את הפותר מהלקוח ולא מתוך המעטפת של השרת עצמו. פותר שעובד מקומית אינו אומר דבר על מה שהמנהרה נושאת.

בררו איזו שכבה נכשלה

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

Multicast נמצא מאחורי אותו קיר. קבוצה כמו 224.0.0.251 אינה מועברת דרך מנהרה מנותבת כברירת מחדל, ומסלול עבור הקבוצה אינו מספיק בלי נתיב שמבין multicast או משקף ב-LAN.