שגיאת חפיפת ה-pool ב-Docker אינה בעיית נתיב VPN

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

שתי שגיאות שנראות דומות

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

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

שתיהן בעיות של תוכנית כתובות. רק אחת מהן היא בעיה של Docker.

קראו קודם את ה-pools שהוקצו

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

docker network ls
docker network inspect EXISTING_NETWORK

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

ipv4_address סטטי בשירות הוא הכתובת של קונטיינר אחד, לא הגדרת ה-pool. שינוי שלו אינו מסיר חפיפה, כי החפיפה היא בין תתי-רשתות של רשתות ולא בין קונטיינרים. מסמך network-create של Docker דורש תתי-רשתות שאינן חופפות להקצאה רגילה דרך גשר ומתעד כיצד לבחור אחת במפורש.

בחרו קידומת ששורדת את ה-VPN

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

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

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

הוציאו או שנו רשת בכוונה

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

אם רשת מיושנת מחזיקה בהקצאה המתנגשת, בדקו מי מחובר אליה לפני הסרתה. docker network rm מסרב כל עוד קיימים נקודות קצה פעילות, ו-docker stop מקבל שמות או מזהי קונטיינרים ולא שם רשת. עצירת קונטיינר גם אינה מסירה את הגדרת הרשת שמחזיקה ב-pool.

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

pools ברירת מחדל עוזרים רק להקצאה הבאה

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

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

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

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