שיתוף הרשת של מכולת VPN: מה קורה ל-DNS

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

שלב 1: בדוק מתוך האפליקציה, לא מהמארח

הרץ את החיפוש בתוך המכולה שיש לה הבעיה, לא במארח ולא בדפדפן. docker exec app-container getent hosts db.internal עונה על השאלה היחידה שחשובה: מה הפותר של התהליך הזה מחזיר.

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

שלב 2: קרא את המודל הנתמך של הסביבה

התיעוד של Docker בנושא רשתות מתעד מגבלות על דגלי DNS למכולות שמשתפות מצב רשת של מכולה אחרת. ב-Compose network_mode: service:vpn קושר את האפליקציה למרחב השמות של מכולת ה-VPN, ולכל שירות dns ההגדרות לא מתנהגות כפי שהן מתנהגות בשירות רגיל. הפתרון שמתקבל הוא זה שיש למרחב השמות המשותף.

רשתות גשר שמוגדרות על ידי המשתמש משתמשות גם הן ב-DNS המובנה של Docker אחרת מאשר בגשר ברירת המחדל. לכן dns סעיף שהועתק מדוגמת גשר שעובד יכול לא לעשות דבר כלל במחסנית משותפת. בדוק את הסידור לפני העתקת הסעיף.

כתובת לולאה חוזרת תמיד מתייחסת להקשר הרשת הרלוונטי. בתוך מרחב שמות משותף, 127.0.0.1 אינו הפותר של המארח.

שלב 3: עקוב אחרי השאילתה עד לנמען שלה

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

דף בדיקת IP בדפדפן לא יכול לומר לך לאן הלכו שאילתות השמות. הוא אומר לאן הלכה חיבור HTTP אחד.

שלב 4: תקן את שתי מחלקות הכשל באופן שונה

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

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

שלב 5: בדוק שוב לאחר יצירה מחדש

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

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