מכולות Windows ו-VPN: מדוע הרשת המקומית נשברת
מכולת Windows משתמשת בטבלת הניתוב של המארח, ולכן VPN שחוסם את תת-הרשת המקומית לוקח איתו גם את קידומת המכולה. מצב Linux הולך בדרך אחרת.
במחשב נייד אחד, עם לקוח VPN אחד מחובר, מכולות Linux ממשיכות לדבר זו עם זו ומכולות Windows נעצרות. המשתנה אינו התמונה, אלא הנתיב שהחבילות עוברות אל המארח. מכולות Windows ברשת ברירת המחדל שואלות את טבלת הניתוב והתרגום של המארח, ולכן מדיניות שמשנה את הניתוב של המארח משנה גם אותן. אמתו זאת בחיפוש נתיב לפני התקנה מחדש של משהו.
היכן חבילות של מכולת Windows נכנסות אל המארח
מכולה ברשת ברירת המחדל nat מקבלת כתובת מקידומת של שירות Host Networking Service, בדרך כלל אי שם בתוך 172.16.0.0/12, ומגיעה אל המארח דרך מתאם וירטואלי. המארח הוא הבעלים של הנתיב לקידומת הזו ומתרגם תעבורה אל המתאם הפעיל. אין מכונה וירטואלית נפרדת באמצע הנתיב הזה.
התכנון הזה הוא מה שהופך את הכשל למכני. כשהמכולה שולחת חבילה, המארח מבצע חיפוש נתיב לקידומת המכולה. הנתיב שמנצח הוא לאן שהחבילה הולכת, ולמכולה אין דעה בעניין.
מה לקוח ה-VPN משנה בנתיב הזה
לקוח ארגוני מתקין לעתים קרובות סט רחב של נתיבים ומסנן שמונע גישה לתת-הרשת המקומית כשהמנהרה פעילה. הכוונה הגנתית: רשת מקומית שנפרצה לא אמורה להגיע למכונה מוגנת. תופעת הלוואי היא שהנתיב של המארח לקידומת המכולה אינו עוד רשת ה-NAT המקומית.
במקום זאת החיפוש מתאים למנהרה והחבילה נמסרת לשער, שמעולם לא שמע על כתובת המכולה הזו. הפינג נכשל, היישום פג תוקף, והמכולה נראית שבורה בזמן שסמל ה-VPN זוהר. הביטו בטבלה של המארח כשאתם מחוברים והנתיב המתחרה גלוי.
| Container mode | Outbound path | Typical result behind the VPN |
|---|---|---|
| Windows, default nat | Host routes and translates container traffic | Container prefix follows the tunnel and fails |
| Windows, transparent | Container sits on the physical link | Depends on the local subnet being allowed |
| Linux engine on Docker Desktop | VM egress proxied by a host process | Often keeps working |
מדוע מכולות Linux מתנהגות אחרת
מנוע Linux מריץ מכולות בתוך מכונה וירטואלית קלה, והחיבורים היוצאים מאותה מכונה נפתחים על ידי פרוקסי בצד המארח בשם המכולה. המארח יוזם את השקע, ולכן הכלל של ה-VPN לגבי קידומת המכולה אינו חל עליו באותה צורה, ועומס העבודה ממשיך להגיע לרשת.
ההבדל הזה גם מסביר מדוע מתכוני Linux אינם עוברים. מכולת Linux שזקוקה למנהרה משלה מקבלת התקן TUN בתוספת היכולת NET_ADMIN. מכולות Windows אינן חושפות ממשק כהתקן, ולכן לתבנית הזו אין מקבילה בצד הזה.
הוכיחו את הנתיב ואז בחרו תכנון
אספו ראיות מהמארח, לא מהמכולה, מפני שהמארח מבצע את החיפוש:
docker network inspect nat --format "{{range .IPAM.Config}}{{.Subnet}}{{end}}"
route print -4
Get-NetRoute -AddressFamily IPv4 | Where-Object DestinationPrefix -like "172.16.*"הריצו את פלט הנתיבים פעם אחת לפני שה-VPN מתחבר ופעם אחת אחר כך. אם בפלט השני קידומת המכולה מצביעה על מתאם המנהרה, האבחון הושלם והפעלה מחדש של מכולות לא תעזור.
האפשרות הראשונה היא החלטת מדיניות: שאלו את בעל הרשת אם אפשר להתיר גישה ל-LAN המקומי עבור התקן זה. כמה לקוחות ארגוניים חושפים זאת כהגדרה, אבל היא מחלישה גבול מכוון. בקשו זאת כחריגה מתועדת עם בעלים ותאריך סקירה. מתג לכל התקן שאיש אינו חוזר אליו הוא הדרך שבה מדיניות הגנתית נעלמת בשקט.
היכן שהמדיניות חייבת לעמוד, העבירו את עומס העבודה במקום להילחם בנתיב. רשת שקופה עם תת-רשת ושער מפורשים שמה את המכולות על הקישור המקומי, עומס עבודה של Linux רץ מאחורי הפרוקסי של המכונה הווירטואלית, ו- מכונה וירטואלית נפרדת עם לקוח משלה שומרת על המדיניות שלה. בחרו אחת בכוונה ובדקו אותה מתוך המכולה, כי שם הבקשה של המשתמש נולדת.