Dostęp UNC w kontenerach Windows: najpierw nazwa, potem tożsamość

Kontener Windows potrzebujący udziału po drugiej stronie tunelu zawodzi na dwa niezależne sposoby, a Eksplorator na hoście nie dowodzi żadnego z nich. Kontener ma własny punkt końcowy sieci i własną tożsamość procesu. Nazwa rozwiązywana na pulpicie i sesja akceptowana tam przez serwer plików opisują pulpit, a nie obciążenie.

Eksplorator na hoście nie jest dowodem

Otwarcie udziału na hoście używa klienta DNS hosta, tablicy routingu hosta i konta, na którym host jest zalogowany. Proces kontenera nie dziedziczy niczego z tego domyślnie, nawet gdy kontener działa na tej samej maszynie i klient VPN też tam działa. Pierwszą granicą jest ścieżka sieciowa: czy kontener potrafi rozwiązać nazwę i czy potrafi otworzyć sesję TCP do portu SMB. Drugą jest tożsamość: czy serwer plików akceptuje to, co przedstawia kontener, z uprawnieniami potrzebnymi obciążeniu.

Traktowanie ich jako jednego problemu tworzy znaną pętlę rozszerzania reguł zapory, aby naprawić to, co w rzeczywistości jest odpowiedzią o odmowie dostępu z udziału.

Podążaj za żądaniem samego kontenera

Siecią kontenerów Windows zarządza Host Networking Service, która tworzy punkty końcowe z własną przestrzenią nazw sieci. Wybrany tryb decyduje, czy punkt końcowy jest tłumaczony, mostkowany, czy przyłączony do sieci współdzielonej z hostem. Ta decyzja zmienia dwie rzeczy naraz: co kontener może rozwiązać i jaki adres źródłowy widzi serwer plików.

Zanim cokolwiek zmienisz, potwierdź, co obserwuje sam kontener. Nazwa rozwiązywana na zewnątrz może zawieść wewnątrz, bo konfiguracja DNS kontenera nie jest konfiguracją hosta, a przetłumaczony punkt końcowy może przedstawić źródło, którego reguły serwera plików się nie spodziewają.

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"

Jeśli rozwiązywanie zawiedzie, popraw DNS w konfiguracji sieci, zamiast podmieniać adres. Zastąpienie nazwy adresem IP może zmienić zachowanie uwierzytelniania i tożsamości serwera, co zamienia jeden problem w dwa. Własna polityka klienta VPN jest następną rzeczą do sprawdzenia, ponieważ może traktować procesy hosta i ruch pochodzący z kontenera inaczej.

Tożsamość to osobna decyzja

Litera dysku mapowana przez użytkownika interaktywnego nie jest interfejsem aplikacji. Istnieje w jednej sesji logowania, a proces kontenera nie jest jej częścią. Użyj ścieżki UNC i daj obciążeniu tożsamość, którą obsługuje model wdrożenia. Tam, gdzie domena to obsługuje, grupowe konto usługi zarządzanej (gMSA) zapewnia zarządzaną tożsamość przez specyfikację poświadczeń.

Przewodnik Microsoftu po gMSA w kontenerach opisuje ten układ specyfikacji poświadczeń i jego warunki wstępne, w tym członkostwo w domenie i hosta zdolnego pobrać poświadczenia. Konto, pobranie, tożsamość procesu wewnątrz kontenera i uprawnienia do udziału muszą się zgadzać. Logowanie VPN nie jest tą tożsamością, a wpisanie hasła w obraz, by odtworzyć sesję użytkownika hosta, tworzy trwałe narażenie.

Utrzymuj widoczność zawodzącego etapu

Nieudane rozwiązywanie, odmowa połączenia i odmowa dostępu wymagają różnych dowodów. To odpowiednio pytanie DNS, pytanie routingu lub filtrowania oraz pytanie uwierzytelniania lub uprawnień. Czytaj odpowiedź otrzymaną przez kontener, a nie ogólny błąd aplikacji.

Testuj z własną tożsamością obciążenia i przetestuj też odmowę.

Zaplanuj ponowne połączenie

Ścieżki VPN padają. Gdy tunel wraca, punkt końcowy może wrócić z innym przetłumaczonym adresem, a istniejąca sesja SMB może być martwa, zanim aplikacja to zauważy. Obsłuż to w aplikacji: odtwórz ścieżkę i tożsamość, ponów operację i uzgodnij operację na pliku o nieznanym wyniku, zamiast zakładać, że nic się nie stało.

Zapisz tryb sieci, źródło DNS i układ tożsamości w notatkach wdrożeniowych. Właśnie te trzy fakty będą tematem następnego błędu.