Docker: לא נותרו מאגרי כתובות מוגדרים מראש במהלך הפעלת VPN

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

אשרו מה נכשל לפני שאתם משנים משהו

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

רשמו בו-זמן את גרסת Engine בכרטיס. כל יוריסטיקה בהמשך מדריך זה תלויה בגרסה, וטענה בלי גרסה היא שמועה.

ספרו את ההקצאות שכבר יש לכם

הציגו את הרשתות ואז בדקו את החשובות: docker network ls ואחריו docker network inspect NETWORK_NAME. קראו את תת-הרשתות של IPAM ואת המכולות המחוברות לכל אחת. כמה פרויקטי Compose צורכים יותר בלוקים ממה שמספר המכולות שלהם מרמז, כי כל פרויקט נוטה ליצור רשת ברירת מחדל משלו. מכולה עצורה אינה משחררת את הקצאת הרשת שלה.

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

רשמו את המספר. הוא קו הבסיס שאומר לכם אם השינוי הבא עזר.

השוו את תפיסת הדמון את המסלולים

VPN יכול להשפיע על בחירת המועמדים, אבל המימוש המדויק קובע איך. ב-Moby 28.2.2 על Linux, InferReservedNetworks אוסף כתובות שרתי שמות ומסלולי IPv4 מסוימים מסוג on-link, והוא אינו שומר בפשטות כל מסלול מכל טבלה. מסלולי הקישור שנאספו גם פוסלים כתובת יעד לא מוגדרת, כך שמסלול 0.0.0.0/1 לבדו אינו שומר כל כתובת. קידומת on-link רחבה אחרת, כגון 128.0.0.0/1, יכולה לחתוך את טווחי המועמדים המוכרים 172 ו-192.

השוו את ip -4 route show table all לפני ואחרי שה-VPN מתחבר, במארח של הדמון. הדלתא היא הראיה, והגרסה היא היקף הטענה.

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

בחרו את התיקון הקטן ביותר שעובד

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

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

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

קבלו את ההקצאה והניתוב בנפרד

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

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

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