Windows 컨테이너의 UNC 액세스: 이름이 먼저, ID가 다음

터널 반대편의 공유가 필요한 Windows 컨테이너는 두 가지 독립적인 방식으로 실패하며, 호스트의 탐색기는 그중 어느 것도 증명하지 않습니다. 컨테이너에는 자체 네트워크 엔드포인트와 자체 프로세스 ID가 있습니다. 데스크톱에서 확인되는 이름과 파일 서버가 그곳에서 받아들이는 세션은 데스크톱을 설명할 뿐 워크로드를 설명하지 않습니다.

호스트의 탐색기는 증거가 아닙니다

호스트에서 공유를 여는 일은 호스트의 DNS 클라이언트, 호스트의 라우팅 테이블, 호스트에 로그온한 계정을 사용합니다. 컨테이너 프로세스는 컨테이너가 같은 머신에서 실행되고 VPN 클라이언트도 그곳에서 실행되는 경우에도 이런 것을 암묵적으로 물려받지 않습니다. 첫 번째 경계는 네트워크 경로로, 컨테이너가 이름을 확인할 수 있는지, SMB 포트로 TCP 세션을 열 수 있는지입니다. 두 번째는 ID로, 파일 서버가 워크로드에 필요한 권한으로 컨테이너가 제시한 것을 받아들이는지입니다.

둘을 하나의 문제로 다루면, 실제로는 공유에서 온 액세스 거부 응답을 고치려고 방화벽 규칙을 넓히는 익숙한 순환에 빠집니다.

컨테이너 자체의 요청을 따라가십시오

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로 바꾸면 인증과 서버 ID의 동작이 달라질 수 있어, 한 문제가 두 문제가 됩니다. 다음으로 점검할 것은 VPN 클라이언트 자체의 정책으로, 호스트 프로세스와 컨테이너에서 발생한 트래픽을 다르게 취급할 수 있기 때문입니다.

ID는 별도의 결정입니다

대화형 사용자가 매핑한 드라이브 문자는 애플리케이션 인터페이스가 아닙니다. 그것은 하나의 로그온 세션에 존재하며, 컨테이너 프로세스는 그 일부가 아닙니다. UNC 경로를 사용하고 배포 모델이 지원하는 ID를 워크로드에 부여하십시오. 도메인이 지원하는 곳에서는 그룹 관리 서비스 계정(gMSA)이 자격 증명 사양을 통해 관리되는 ID를 제공합니다.

Microsoft의 컨테이너 gMSA 안내서는 그 자격 증명 사양 배치와 전제 조건을 설명하며, 여기에는 도메인 가입과 자격 증명을 검색할 수 있는 호스트가 포함됩니다. 계정, 검색, 컨테이너 내부의 프로세스 ID, 공유 권한이 모두 맞아야 합니다. VPN 로그인은 그 ID가 아니며, 호스트 사용자의 세션을 재현하려고 이미지에 암호를 구워 넣는 것은 상시 노출을 만듭니다.

실패하는 단계를 보이게 유지하십시오

확인 실패, 연결 거부, 액세스 거부에는 각각 다른 증거가 필요합니다. 그것은 각각 DNS 질문, 라우팅 또는 필터링 질문, 인증 또는 권한 질문입니다. 애플리케이션의 일반 오류가 아니라 컨테이너가 받은 응답을 읽으십시오.

워크로드 자체의 ID로 시험하고 거부되는 경우도 시험하십시오.

재연결을 계획하십시오

VPN 경로는 끊깁니다. 터널이 돌아올 때 엔드포인트가 다른 변환 주소로 돌아올 수 있고, 기존 SMB 세션은 애플리케이션이 알아차리지 못한 채 죽어 있을 수 있습니다. 애플리케이션에서 경로와 ID를 다시 세우고, 작업을 재시도하며, 아무 일도 없었다고 가정하는 대신 결과가 알려지지 않은 파일 작업을 조정하십시오.

네트워크 모드, DNS 원본, ID 배치를 배포 노트에 기록하십시오. 다음 실패는 바로 이 세 가지 사실에 관한 것이 될 것입니다.