המנהרה פעילה, אז למה השם הפרטי עדיין נכשל?

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

לאיזה פותר הגיעה השאילתה?

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

resolvectl status
scutil --dns | head -40
dig +short internal.example.com

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

השתמשו בכתובת שרשת הענן באמת עונה עליה

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

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

מנהרה לא נושאת את מרחב השמות

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

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

עברו את הגבולות לפי הסדר

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

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

שמרו את השרשרת במקום שבו האדם הבא ימצא אותה

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

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