การเข้าถึง UNC ในคอนเทนเนอร์ Windows: ชื่อก่อน ตัวตนทีหลัง

คอนเทนเนอร์ Windows ที่ต้องใช้แชร์อีกฝั่งของท่อส่งของคุณล้มเหลวได้สองทางที่เป็นอิสระต่อกัน และ Explorer บนโฮสต์ไม่ได้พิสูจน์ทั้งสองทางนั้น คอนเทนเนอร์มีปลายทางเครือข่ายของตัวเองและมีตัวตนของโปรเซสของตัวเอง ชื่อที่แปลงได้บนเดสก์ท็อปและเซสชันที่ไฟล์เซิร์ฟเวอร์ยอมรับที่นั่นอธิบายเดสก์ท็อป ไม่ใช่งานที่รันอยู่

Explorer บนโฮสต์ไม่ใช่หลักฐาน

การเปิดแชร์บนโฮสต์ใช้ไคลเอนต์ DNS ของโฮสต์ ตารางเส้นทางของโฮสต์ และบัญชีที่ล็อกอินอยู่บนโฮสต์ โปรเซสของคอนเทนเนอร์ไม่ได้รับสิ่งเหล่านี้โดยปริยาย แม้คอนเทนเนอร์จะรันบนเครื่องเดียวกันและไคลเอนต์ VPN ก็รันอยู่ที่นั่นด้วย ขอบเขตแรกคือเส้นทางเครือข่าย คอนเทนเนอร์แปลงชื่อได้หรือไม่ และเปิดเซสชัน TCP ไปยังพอร์ต SMB ได้หรือไม่ ขอบเขตที่สองคือตัวตน ไฟล์เซิร์ฟเวอร์ยอมรับสิ่งที่คอนเทนเนอร์นำเสนอหรือไม่ ด้วยสิทธิ์ที่งานต้องการ

การมองทั้งสองเป็นปัญหาเดียวทำให้เกิดวงจรที่คุ้นเคย คือการขยายกฎไฟร์วอลล์เพื่อแก้สิ่งที่แท้จริงคือคำตอบเรื่องการปฏิเสธการเข้าถึงจากแชร์

ตามคำขอของคอนเทนเนอร์เอง

เครือข่ายของคอนเทนเนอร์ 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) ให้ตัวตนที่จัดการผ่านข้อกำหนดข้อมูลรับรอง

คู่มือ gMSA สำหรับคอนเทนเนอร์ ของ Microsoft อธิบายการจัดวางข้อกำหนดข้อมูลรับรองนั้นและข้อกำหนดเบื้องต้น ซึ่งรวมถึงการเป็นสมาชิกโดเมนและโฮสต์ที่ดึงข้อมูลรับรองได้ บัญชี การดึงข้อมูล ตัวตนของโปรเซสภายในคอนเทนเนอร์ และสิทธิ์ของแชร์ต้องสอดคล้องกันทั้งหมด การล็อกอิน VPN ไม่ใช่ตัวตนนั้น และการอบรหัสผ่านไว้ในอิมเมจเพื่อจำลองเซสชันของผู้ใช้โฮสต์สร้างการเปิดเผยอย่างต่อเนื่อง

ทำให้ขั้นที่ล้มเหลวมองเห็นได้

การแปลงชื่อล้มเหลว การเชื่อมต่อถูกปฏิเสธ และการเข้าถึงถูกปฏิเสธต้องใช้หลักฐานต่างกัน สิ่งเหล่านี้คือคำถามเรื่อง DNS คำถามเรื่องเส้นทางหรือการกรอง และคำถามเรื่องการพิสูจน์ตัวตนหรือสิทธิ์ตามลำดับ อ่านคำตอบที่คอนเทนเนอร์ได้รับ ไม่ใช่ข้อผิดพลาดทั่วไปของแอปพลิเคชัน

ทดสอบด้วยตัวตนของงานเองและทดสอบการถูกปฏิเสธด้วย

วางแผนสำหรับการเชื่อมต่อใหม่

เส้นทาง VPN ขาดหาย เมื่อท่อส่งกลับมา ปลายทางอาจกลับมาพร้อมที่อยู่ที่แปลต่างออกไป และเซสชัน SMB ที่มีอยู่อาจตายโดยที่แอปพลิเคชันไม่รู้ตัว จัดการในแอปพลิเคชัน คือสร้างเส้นทางและตัวตนขึ้นใหม่ ลองดำเนินการอีกครั้ง และกระทบยอดการดำเนินการกับไฟล์ที่มีผลลัพธ์ไม่ทราบแทนการสรุปว่าไม่มีอะไรเกิดขึ้น

บันทึกโหมดเครือข่าย แหล่ง DNS และการจัดวางตัวตนไว้ในบันทึกการติดตั้ง ความล้มเหลวครั้งต่อไปจะเกี่ยวกับข้อเท็จจริงสามข้อนี้