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 સ્રોત અને ઓળખની ગોઠવણી ડિપ્લોયમેન્ટ નોંધમાં લખો. આગલી નિષ્ફળતા બરાબર આ ત્રણ હકીકતો વિશે જ હશે.