המארח מגיע לעמית IPsec, מכולת Docker לא

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

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

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

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

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

קראו את המדיניות לפני שנוגעים ב-Docker

בדיקות מארח לקריאה בלבד מכסות את החלטות הניתוב, את מסד המדיניות ואת הכללים שבוחרים ביניהם:

ip rule show
ip route show table all
ip xfrm policy

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

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

בדקו סינון ותרגום לפי הסדר

חומת האש של גשר Linux ב-Docker יכולה לחסום העברה ללא תלות ב-IPsec. עם backend של iptables, בדקו את נתיב FORWARD ואת החלטות DOCKER-USER, וזכרו שכלל שנוסף אחרי פסק קודם אולי לעולם לא ירוץ. ה-backend של nftables משתלב אחרת, לכן אל תיצרו שרשרת DOCKER-USER רק מפני שדוגמת iptables קראה לה כך; בדקו איזה backend הדמון שלכם באמת משתמש בו.

אחר כך בדקו תרגום מקור. כלל MASQUERADE רחב יכול להפוך מנה שהתאימה בעבר לבורר IPsec למנה שכבר לא מתאימה, והתקלה נראית בדיוק כמו בעיית ניתוב. מדריך ההעברה של strongSwan מתעד את פטור ה-NAT הנדרש לפני תרגום כזה עבור תעבורה שכבר תואמת מדיניות.

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

אחר כך החליטו מנותב או מתורגם

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

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

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

אמתו בחיבור חדש, לא בהפעלה מחדש

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

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