פרסום פורטים של Docker ומקורות VPN: שתי התאמות שאתם מפספסים

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

המיתוס: אפשרו את שרת ה-VPN וסיימתם

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

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

מקור: מאגר לקוחות או שער מתורגם

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

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

פורט: DNAT משנה את המספר שאתם מתאימים

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

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

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

שרשרת: DOCKER-USER, לא INPUT

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

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

אמתו עם חיבורים חדשים

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

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