Windows konteynerlərində UNC girişi: əvvəl ad, sonra kimlik

Tunelinizin o biri tərəfində yerləşən paylaşmaya ehtiyac duyan Windows konteyneri iki müstəqil şəkildə uğursuz olur və host-un Explorer-i bunların heç birini sübut etmir. Konteynerin öz şəbəkə son nöqtəsi və öz proses kimliyi var. Masaüstündə həll olunan ad və fayl serverinin orada qəbul etdiyi sessiya masaüstünü təsvir edir, iş yükünü yox.

Host-un Explorer-i sübut deyil

Paylaşmanı host-da açmaq host-un DNS müştərisindən, host-un marşrut cədvəlindən və host-da daxil olunmuş hesabdan istifadə edir. Konteyner prosesi bunların heç birini gizli şəkildə miras almır, hətta konteyner eyni maşında işləyəndə və VPN müştərisi də orada işləyəndə belə. Birinci sərhəd şəbəkə yoludur: konteyner adı həll edə bilirmi və SMB portuna TCP sessiyası aça bilirmi. İkincisi kimlikdir: fayl serveri konteynerin təqdim etdiyini, iş yükünün ehtiyac duyduğu icazələrlə qəbul edirmi.

Onlara bir problem kimi yanaşmaq, əslində paylaşmadan gələn giriş-rədd cavabını düzəltmək üçün firewall qaydalarını genişləndirməyin tanış dövrəsini yaradır.

Konteynerin öz sorğusunu izləyin

Windows konteyner şəbəkəsi Host Networking Service tərəfindən idarə olunur və o, öz şəbəkə ad məkanı olan son nöqtələr yaradır. Seçdiyiniz rejim son nöqtənin tərcümə olunduğunu, körpüləndiyini və ya host ilə paylaşılan şəbəkəyə qoşulduğunu müəyyən edir. Bu qərar eyni anda iki şeyi dəyişir: konteynerin nəyi həll edə bildiyini və fayl serverinin hansı mənbə ünvanını gördüyünü.

Heç nəyi dəyişməzdən əvvəl konteynerin özünün nə müşahidə etdiyini təsdiqləyin. Çöldə həll olunan ad içəridə uğursuz ola bilər, çünki konteynerin DNS konfiqurasiyası host-un konfiqurasiyası deyil və tərcümə olunmuş son nöqtə fayl serverinin qaydalarının gözləmədiyi mənbə təqdim edə bilər.

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"

Əgər həll uğursuz olarsa, ünvanı əvəz etmək əvəzinə şəbəkə konfiqurasiyasında DNS-i düzəldin. Adı IP ilə əvəz etmək autentifikasiya və server kimliyinin davranışını dəyişə bilər və bu, bir problemi ikiyə çevirir. VPN müştərisinin öz siyasəti yoxlanmalı növbəti şeydir, çünki o, host proseslərinə və konteynerdən qaynaqlanan trafikə fərqli yanaşa bilər.

Kimlik ayrı bir qərardır

İnteraktiv istifadəçinin qoşduğu disk hərfi tətbiq interfeysi deyil. O, bir giriş sessiyasında mövcuddur və konteyner prosesi onun bir hissəsi deyil. UNC yolundan istifadə edin və iş yükünə yerləşdirmə modelinin dəstəklədiyi kimlik verin. Domenin dəstəklədiyi yerlərdə qrup üzrə idarə olunan xidmət hesabı (gMSA) etimadnamə spesifikasiyası vasitəsilə idarə olunan kimlik təqdim edir.

Microsoft-un konteyner gMSA təlimatı bu etimadnamə spesifikasiyası quruluşunu və onun ilkin şərtlərini təsvir edir; bunlara domen üzvlüyü və etimadnaməni əldə edə bilən host daxildir. Hesab, əldəetmə, konteyner daxilindəki proses kimliyi və paylaşma icazələri hamısı uyğun olmalıdır. VPN girişi o kimlik deyil və host istifadəçisinin sessiyasını təkrarlamaq üçün obrazın içinə parol yerləşdirmək daimi bir məruz qalma yaradır.

Uğursuz mərhələni görünən saxlayın

Həll uğursuzluğu, bağlantı rəddi və giriş rəddi fərqli sübutlar tələb edir. Bunlar müvafiq olaraq DNS sualı, marşrutlaşdırma və ya filtrləmə sualı, və autentifikasiya və ya icazə sualıdır. Tətbiqin ümumi xətası əvəzinə konteynerin aldığı cavabı oxuyun.

İş yükünün öz kimliyi ilə sınaqdan keçirin və rədd halını da sınayın.

Yenidən qoşulmağı planlaşdırın

VPN yolları kəsilir. Tunel qayıdanda son nöqtə fərqli tərcümə olunmuş ünvanla qayıda bilər və mövcud SMB sessiyası tətbiq bunu görmədən ölü ola bilər. Bunu tətbiqdə idarə edin: yolu və kimliyi yenidən qurun, əməliyyatı təkrar cəhd edin və nəticəsi bilinməyən fayl əməliyyatını heç nə olmadığını güman etmək əvəzinə uzlaşdırın.

Şəbəkə rejimini, DNS mənbəyini və kimlik quruluşunu yerləşdirmə qeydlərində yazın. Növbəti uğursuzluq məhz bu üç fakt haqqında olacaq.