Windows कंटेनर में UNC पहुँच: पहले नाम, फिर पहचान

आपकी सुरंग के दूसरी ओर शेयर चाहने वाला Windows कंटेनर दो स्वतंत्र तरीकों से विफल होता है, और होस्ट का Explorer इनमें से किसी को भी साबित नहीं करता। कंटेनर का अपना नेटवर्क एंडपॉइंट है और अपनी प्रोसेस पहचान है। डेस्कटॉप पर हल होने वाला नाम और फ़ाइल सर्वर वहाँ जो सत्र स्वीकार करता है, डेस्कटॉप का वर्णन करते हैं, वर्कलोड का नहीं।

होस्ट का Explorer प्रमाण नहीं है

होस्ट पर शेयर खोलने में होस्ट का DNS क्लाइंट, होस्ट की रूटिंग तालिका और होस्ट पर लॉग-इन खाता इस्तेमाल होता है। कंटेनर प्रोसेस इनमें से कुछ भी अंतर्निहित रूप से विरासत में नहीं लेती, तब भी जब कंटेनर उसी मशीन पर चलता है और VPN क्लाइंट भी वहीं चलता है। पहली सीमा नेटवर्क पथ है: क्या कंटेनर नाम हल कर सकता है, और क्या यह SMB पोर्ट तक TCP सत्र खोल सकता है। दूसरी पहचान है: क्या फ़ाइल सर्वर वह स्वीकार करता है जो कंटेनर प्रस्तुत करता है, उन अनुमतियों के साथ जो वर्कलोड को चाहिए।

दोनों को एक समस्या मानने से वही जाना-पहचाना चक्र बनता है जिसमें फ़ायरवॉल नियम चौड़े किए जाते हैं, जबकि असल में शेयर से आने वाला पहुँच-अस्वीकृति उत्तर ठीक करना होता है।

कंटेनर के अपने अनुरोध का पालन करें

Windows कंटेनर नेटवर्किंग को Host Networking Service प्रबंधित करती है, जो अपने नेटवर्क नामस्थान वाले एंडपॉइंट बनाती है। आपने जो मोड चुना है वह तय करता है कि एंडपॉइंट अनुवादित, ब्रिज्ड या होस्ट के साथ साझा नेटवर्क से जुड़ा है। यह निर्णय एक साथ दो चीज़ें बदलता है: कंटेनर क्या हल कर सकता है, और फ़ाइल सर्वर कौन-सा स्रोत पता देखता है।

कुछ भी बदलने से पहले पुष्टि करें कि कंटेनर स्वयं क्या देखता है। बाहर हल होने वाला नाम अंदर विफल हो सकता है, क्योंकि कंटेनर का 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) क्रेडेंशियल विनिर्देश के माध्यम से प्रबंधित पहचान प्रदान करता है।

Microsoft की कंटेनर gMSA मार्गदर्शिका उस क्रेडेंशियल-विनिर्देश व्यवस्था और उसकी पूर्वशर्तों का वर्णन करती है, जिनमें डोमेन सदस्यता और क्रेडेंशियल प्राप्त कर सकने वाला होस्ट शामिल है। खाता, प्राप्ति, कंटेनर के भीतर प्रोसेस पहचान और शेयर अनुमतियाँ—सबको मेल खाना चाहिए। VPN लॉगिन वह पहचान नहीं है, और होस्ट उपयोगकर्ता का सत्र दोहराने के लिए किसी इमेज में पासवर्ड बेक करना स्थायी जोखिम बनाता है।

विफल होने वाले चरण को दृश्य रखें

हल करने की विफलता, कनेक्शन अस्वीकृति और पहुँच अस्वीकृति के लिए अलग प्रमाण चाहिए। ये क्रमशः DNS प्रश्न, रूटिंग या फ़िल्टरिंग प्रश्न, और प्रमाणीकरण या अनुमति प्रश्न हैं। एप्लिकेशन की सामान्य त्रुटि के बजाय वह उत्तर पढ़ें जो कंटेनर को मिला।

वर्कलोड की अपनी पहचान से परीक्षण करें और अस्वीकृति का भी परीक्षण करें।

पुनः कनेक्ट के लिए योजना बनाएँ

VPN पथ गिरते हैं। जब सुरंग लौटती है, तो एंडपॉइंट भिन्न अनुवादित पते के साथ लौट सकता है, और मौजूदा SMB सत्र एप्लिकेशन को पता चले बिना मृत हो सकता है। इसे एप्लिकेशन में संभालें: पथ और पहचान फिर से स्थापित करें, क्रिया पुनः आज़माएँ, और कुछ न हुआ मानने के बजाय अज्ञात परिणाम वाली फ़ाइल क्रिया का मिलान करें।

नेटवर्क मोड, DNS स्रोत और पहचान व्यवस्था को परिनियोजन नोट्स में दर्ज करें। अगली विफलता ठीक इन तीन तथ्यों के बारे में होगी।