הגעה לממשק רשת בתוך מכולת VPN: בחרו את בעל הפורט

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

למי שייך מרחב השמות של הפורט

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

services:
  vpn:
    image: vpn-client-image
    cap_add: [NET_ADMIN]
    ports:
      - "127.0.0.1:8080:8080"
  app:
    network_mode: "service:vpn"

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

גרמו לאפליקציה להאזין היכן שמרחב השמות מצפה

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

docker compose exec app ss -lntp
docker port vpn
curl -sS -o /dev/null -w '%{http_code}\n' http://127.0.0.1:8080/

רשימת המאזינים בתוך האפליקציה אומרת את האמת על כתובת הקישור, ואילו docker port אומר מה הבעלים באמת פרסם. אם הראשון מראה 127.0.0.1 והשני מראה מיפוי במארח, מצאתם את חוסר ההתאמה בלי לגעת בתצורת ה-VPN.

בחרו איך נכנס נתיב הניהול

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

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

פתחו את פורט הניהול בלי לפתוח הכול

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

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

אמתו מהתקן הניהול, ואמתו שוב מאוחר יותר

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

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