دسترسی UNC در کانتینرهای Windows: اول نام، بعد هویت

کانتینر Windows که به اشتراکی در آن سوی تونل شما نیاز دارد، به دو شیوه مستقل شکست می‌خورد و Explorer میزبان هیچ‌یک را اثبات نمی‌کند. کانتینر نقطه پایانی شبکه و هویت فرایند خودش را دارد. نامی که روی دسکتاپ حل می‌شود و نشستی که سرور فایل آنجا می‌پذیرد، دسکتاپ را توصیف می‌کنند، نه بار کاری را.

Explorer میزبان دلیل نیست

باز کردن اشتراک روی میزبان از کلاینت DNS میزبان، جدول مسیریابی میزبان و حسابی که روی میزبان وارد شده استفاده می‌کند. فرایند کانتینر هیچ‌یک از این‌ها را به‌طور ضمنی به ارث نمی‌برد، حتی وقتی کانتینر روی همان ماشین اجرا می‌شود و کلاینت VPN هم آنجا اجرا می‌شود. مرز نخست مسیر شبکه است: آیا کانتینر می‌تواند نام را حل کند و آیا می‌تواند نشست TCP به پورت SMB باز کند. مرز دوم هویت است: آیا سرور فایل آنچه کانتینر ارائه می‌دهد را با مجوزهایی که بار کاری نیاز دارد می‌پذیرد.

برخورد با این دو به‌عنوان یک مشکل، همان حلقه آشنای گستردن قواعد فایروال را می‌سازد برای درست کردن چیزی که در واقع پاسخ رد دسترسی از اشتراک است.

درخواست خود کانتینر را دنبال کنید

شبکه کانتینرهای Windows را سرویس شبکه میزبان مدیریت می‌کند که نقاط پایانی با فضای نام شبکه خودشان می‌سازد. حالتی که انتخاب کرده‌اید تعیین می‌کند که نقطه پایانی ترجمه شود، پل شود یا به شبکه‌ای مشترک با میزبان متصل شود. این تصمیم دو چیز را همزمان تغییر می‌دهد: آنچه کانتینر می‌تواند حل کند و نشانی مبدأیی که سرور فایل می‌بیند.

پیش از تغییر هر چیزی تأیید کنید که خود کانتینر چه مشاهده می‌کند. نامی که بیرون حل می‌شود ممکن است درون شکست بخورد، چون پیکربندی DNS کانتینر همان پیکربندی میزبان نیست، و نقطه پایانی ترجمه‌شده ممکن است مبدأیی ارائه دهد که قواعد سرور فایل انتظارش را ندارند.

docker exec -it app powershell -Command "Resolve-DnsName files.corp.example"
docker exec -it app powershell -Command "Test-NetConnection files.corp.example -Port 445"
docker exec -it app powershell -Command "Get-NetIPConfiguration"

اگر حل نام شکست خورد، DNS را در پیکربندی شبکه درست کنید، نه اینکه نشانی را جایگزین کنید. جایگزین کردن نام با IP می‌تواند رفتار احراز هویت و هویت سرور را تغییر دهد و یک مشکل را به دو مشکل تبدیل کند. سیاست خود کلاینت VPN چیز بعدی است که باید بررسی شود، چون ممکن است با فرایندهای میزبان و ترافیکی که از کانتینر منشأ می‌گیرد متفاوت رفتار کند.

هویت تصمیمی جداگانه است

حرف درایوی که کاربر تعاملی آن را نگاشت می‌کند واسط برنامه نیست. در یک نشست ورود وجود دارد و فرایند کانتینر بخشی از آن نیست. از مسیر UNC استفاده کنید و به بار کاری هویتی بدهید که مدل استقرار پشتیبانی می‌کند. جایی که دامنه پشتیبانی می‌کند، حساب سرویس مدیریت‌شده گروهی (gMSA) هویت مدیریت‌شده را از طریق مشخصه اعتبارنامه فراهم می‌کند.

راهنمای gMSA کانتینر مایکروسافت همان چیدمان مشخصه اعتبارنامه و پیش‌نیازهایش را توصیف می‌کند، از جمله عضویت دامنه و میزبانی که بتواند اعتبارنامه را بازیابی کند. حساب، بازیابی، هویت فرایند داخل کانتینر و مجوزهای اشتراک همه باید هم‌راستا باشند. ورود VPN آن هویت نیست، و پختن گذرواژه در یک ایمیج برای بازتولید نشست کاربر میزبان، یک قرار گرفتن دائمی در معرض خطر می‌سازد.

مرحله شکست‌خورده را آشکار نگه دارید

شکست حل نام، رد اتصال و رد دسترسی به شواهد متفاوتی نیاز دارند. این‌ها به‌ترتیب پرسش DNS، پرسش مسیریابی یا فیلتر کردن، و پرسش احراز هویت یا مجوز هستند. پاسخی را بخوانید که کانتینر دریافت کرده، نه خطای عمومی برنامه را.

با هویت خود بار کاری آزمایش کنید و رد شدن را هم آزمایش کنید.

برای اتصال دوباره برنامه‌ریزی کنید

مسیرهای VPN قطع می‌شوند. وقتی تونل بازمی‌گردد، ممکن است نقطه پایانی با نشانی ترجمه‌شده دیگری برگردد و نشست SMB موجود بی‌آنکه برنامه متوجه شود مرده باشد. این را در برنامه مدیریت کنید: مسیر و هویت را دوباره برقرار کنید، عملیات را دوباره امتحان کنید و عملیات فایلی با نتیجه نامعلوم را تطبیق دهید، نه اینکه فرض کنید هیچ چیزی رخ نداده است.

حالت شبکه، منبع DNS و چیدمان هویت را در یادداشت‌های استقرار ثبت کنید. شکست بعدی دقیقاً درباره همین سه واقعیت خواهد بود.