למה מיפוי הפורט של VPN ב-Docker שלך לעולם לא מגיע ל-OpenVPN
פורט המארח, פורט הקונטיינר והתעבורה הם שלושה החלטות נפרדות. עקוב אחר ניסיון UDP אחד דרך כל גבול לפני שנוגעים בתעודות.
הקונטיינר שלך יכול להאזין על UDP 1195 בזמן שהמארח מפרסם 1194, וזה נכון כל עוד המיפוי אומר כך. המספרים יוצרים טבלת תרגום: הלקוח מחייג לפורט המארח, Docker כותב מחדש את היעד לפורט הקונטיינר, והתשובה מגיעה מ־OpenVPN על הפורט שהתצורה שלו עצמה מציינת. אי־התאמה בכל אחת מהחוליות האלה מייצרת כשל שקט שנראה כמו חומת אש. תעודות וצפנים נמצאים בהמשך ואינם יכולים לתקן אותו.
עקוב אחר מקטע אחד מהלקוח לתהליך לפני שתשנה משהו באימות.
שלושה מספרים, חיבור אחד
שלושת המספרים הם היעד המרוחק שהלקוח משתמש בו, המיפוי המפורסם במארח, והמאזין בתוך הקונטיינר. הם לא חייבים להיות שווים, אבל הם חייבים ליצור שרשרת. מספרים שווים הם מקרה מיוחד שבמקרה הוא הנפוץ ביותר, ולכן קל לכתוב אי־התאמה פעם אחת וקשה לראות אותה אחר כך.
כתוב את השרשרת בשורה אחת לפני ניפוי: כתובת ופורט הלקוח, המיפוי במארח, המאזין בקונטיינר, התעבורה. פגם בשרשרת מופיע כמספר שמופיע פעמיים עם ערכים שונים.
| Location | Example |
|---|---|
| Remote client destination | Host address, UDP 1194 |
| Published mapping | Host UDP 1194 to container UDP 1195 |
| Container listener | OpenVPN on UDP 1195 |
מה התחביר הקצר באמת אומר
בצורה הקצרה הצד השמאלי הוא פורט המארח והצד הימני הוא פורט הקונטיינר, וסיומת עם לוכסן בוחרת את התעבורה. אם משמיטים את הסיומת, Docker מתייחס למיפוי כ-TCP, כך שמאזין UDP מאחורי מיפוי בלי פרוטוקול הוא מאזין שאיש לא יכול להגיע אליו. ברירת המחדל הזו מתועדת ועדיין מפתיעה אנשים שהתאימו את המספרים והכריזו שהעבודה נגמרה.
הצורה הארוכה מקבעת את כתובת הכריכה ואת הפרוטוקול במפורש, וזה שווה את השורות הנוספות בכל דבר שפונה לרשת. קרא את המיפוי המפורסם בחזרה במקום לסמוך על הקובץ שיצר אותו.
ports:
- 1194:1195/udpהיכן המקטע יכול להיעצר
בקשה יכולה להיזרק לפני Docker, בתוך Docker, או אצל המאזין. לפני Docker יכול להיות חומת אש בענן או נתב שעושה העברה משלו, וההתקן הזה צריך את הפורט שפונה למארח ואת התעבורה הנכונה. בתוך Docker, מיפוי לפורט קונטיינר שגוי מעביר לשקע סגור.
אחר כך המאזין: התצורה של OpenVPN מציינת פורט ופרוטוקול, ולקוח שמגיע לאחר בתוך הקונטיינר לא מגיע לשום דבר. בדיקת שירות UDP ב-TCP לא מוכיחה דבר באף אחד מהשלבים האלה, לכן השתמש בתעבורה שהלקוח ישתמש בה.
כתובות הכריכה קובעות את הנגישות
מיפוי מפורסם שכרוך ל-loopback נגיש רק מהמארח, בעוד שכרוך לכל הממשקים נגיש בכל מקום שחומת האש מאפשרת. השניים נראים זהים בקובץ Compose שמשמיט את הכתובת, וברירת המחדל של Docker היא הרחבה.
החלט איזו חשיפה הפריסה מתכוונת לה, ואז כתוב אותה במפורש. בדיקה פנימית שמתחברת דרך loopback ולקוח מרוחק שלא יכול להתחבר יכולים שניהם להיות תיאורים מדויקים של אותו קונטיינר.
קרא את המצב הפעיל
בדוק את המיפוי האפקטיבי של הקונטיינר הפעיל ואת המאזין במרחב השמות של הרשת שלו. ייתכן שקובץ Compose נערך אחרי שהקונטיינר התחיל, מטא-נתוני התמונה עשויים להצהיר על פורט בלי לפרסם אותו, וקונטיינר שני עשוי כבר להחזיק בפורט המארח. הצהרה על פורט בתמונה אינה פרסומו, ואף אחד מהשניים אינו זהה להאזנה.
שלושה מצבים שונים, שלוש פקודות שונות, ורק האחרונה נוגעת ל-OpenVPN.
אחרי שהמיפוי נכון
ברגע שהמקטע מגיע ל-OpenVPN, היומן שלו הוא המקום לקרוא על TLS ואימות. יצירה מחדש של תעודות כדי לתקן מקטע שמעולם לא הגיע היא עבודה מבוזבזת שמוסיפה משתנה שני. שמור את הערת המיפוי לצד פרופיל הלקוח כדי שהאדם הבא יקרא שורה אחת במקום לגלות מחדש את שלושת המספרים. לכידת מקטע אחת בצד המארח מכריעה איזו משלוש החוליות שגויה, והיא עולה פחות מיצירת תעודה מחדש.
פרסום דרך גשר הוא המקרה המתואר כאן. רשת המארח וכתובות קונטיינר מנותבות מדלגות על התרגום, ולכן אותם מספרים משמעותם משהו אחר בתכנונים האלה.