פרסום פורטים ב-Docker מול ה-VPN: לאן הולכת התשובה

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

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

עקוב אחרי ה-tuple דרך NAT היעד

קח מארח בכתובת 192.0.2.10 שמפרסם TCP 2222 לקונטיינר בכתובת 172.30.240.5:22. בקשה מ-198.51.100.25 מתורגמת לפני שהיא מגיעה לקונטיינר, והקונטיינר עונה כעצמו.

WAN request:      198.51.100.25 -> 192.0.2.10:2222
after DNAT:       198.51.100.25 -> 172.30.240.5:22
container reply:  172.30.240.5:22 -> 198.51.100.25

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

למה כלל שמוגבל למארח מפספס אותה

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

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

התאמה שאחרי DNAT היא hook אחר

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

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

עיצוב A: לשאת את ההחלטה כמצב חיבור

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

  1. הקצה שדה סימן ועדיפות כלל שלא מתנגשים עם Docker, עם ה-VPN או עם בעל מדיניות אחר.
  2. זהה רק את חיבור ה-WAN החדש המיועד בנקודה שלפני DNAT שבה מעקב חיבורים זמין.
  3. רשום את ההחלטה על סימן החיבור, בלי לכפות את הבקשה המקורית עצמה לטבלת ה-WAN.
  4. בכיוון התשובה החזר לחבילה רק את סיביות הסימן שלך לפני הניתוב.
  5. בחר טבלת WAN שלמה מוקדם מספיק כדי שכלל VPN לא יוכל לנצח ראשון.

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

עיצוב B: לסיים במארח

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

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

אמת את השינוי, לא את הכוונה

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

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

מאמרים קשורים