เมานต์ CIFS ของคุณล้มเหลวผ่าน VPN เพราะลำดับใน nsswitch
แชร์ตอบด้วยที่อยู่แต่ค้างด้วยชื่อ การค้นหาจึงตายก่อน SMB จะเริ่ม เปรียบเทียบ getent กับ host แล้วอ่านบรรทัด hosts ตามลำดับ
อุโมงค์เชื่อมต่ออยู่ เซิร์ฟเวอร์ไฟล์ตอบ ping ด้วยที่อยู่ จากนั้น mount.cifs ที่ใช้ชื่อโฮสต์จะค้างอยู่พักหนึ่งแล้วรายงานว่าเข้าถึงโฮสต์ไม่ได้ และคุณเริ่มสร้างโปรไฟล์ VPN ใหม่ทั้งที่มันไม่เคยเป็นปัญหา บน Linux ชื่อถูกแก้โดย glibc ก่อนที่แพ็กเก็ต SMB ใดจะเกิดขึ้น และลำดับในตัวแก้ชื่อนั้นอาจจบการค้นหาก่อนที่ DNS จะถูกถามด้วยซ้ำ นี่คือเส้นทางที่ผมเดิน เริ่มจากคำสั่งที่ล้มเหลว ไม่ใช่จากไคลเอนต์
อ่านความล้มเหลวในที่ที่ถูกต้อง
เครื่องมือสองตัวเดินคนละเส้นทางไปยังชื่อเดียวกัน และการเปรียบเทียบใช้คำสั่งเดียว getent เดินผ่านสแตกบริการชื่อที่ตั้งค่าไว้ ส่วน host และ dig ถาม DNS โดยตรงและไม่สนใจสแตกนั้น หากคำถามโดยตรงคืนที่อยู่และ getent คืนอะไรเลย แสดงว่าเซิร์ฟเวอร์ DNS เข้าถึงได้ และการตั้งค่าตัวแก้ชื่อของคุณคือสิ่งที่ล้มเหลว
getent hosts fileserver.corp.example
host fileserver.corp.example 10.61.0.1
getent -s dns hosts fileserver.corp.example
คำสั่งที่สามคือตัวตัดสิน มันบังคับแหล่ง DNS และข้ามส่วนที่เหลือของสแตก เมื่อมันทำงานแต่ getent ธรรมดาไม่ทำงาน คุณได้พิสูจน์แล้วว่าลำดับเป็นความผิด ไม่ใช่อุโมงค์และไม่ใช่เซิร์ฟเวอร์
บรรทัด hosts คือลำดับที่หยุดเร็ว
ตัวแก้ชื่อ glibc อ่าน /etc/nsswitch.conf และไล่รายการ hosts: จากซ้ายไปขวา ดิสทริบิวชันหลายตัวส่งบรรทัดที่การค้นหา multicast มาก่อนพร้อมการกระทำคืนค่าก่อนกำหนดติดอยู่ การกระทำนั้นไม่ใช่ของประดับ เมื่อ mDNS ตอบ “not found” [NOTFOUND=return] จะจบการค้นหาทั้งหมด ชื่อองค์กรจึงไม่ถูกส่งไปยังตัวแก้ชื่อที่ VPN ดันมา ไม่มีอะไรบันทึกไว้ เพราะไม่มีคำถามใดถูกส่งให้ตัวแก้ชื่อปฏิเสธ นั่นคือเหตุผลที่เมานต์ดูเหมือนค้างแล้วรายงานว่าโฮสต์เข้าถึงไม่ได้
cat /etc/nsswitch.conf | grep '^hosts:'
# illustrative repair: dns before the early-return action
hosts: files myhostname mdns4_minimal dns [NOTFOUND=return] wins mdns4
ย้าย DNS ไปก่อนการกระทำคืนค่าก่อนกำหนดแทนการลบ mDNS และเปลี่ยนผ่านการจัดการกำหนดค่า การแก้ด้วยมือจะอยู่ได้จนถึงการสร้าง image ครั้งถัดไป แล้วตั๋วเดียวกันก็มาจากเครื่องอื่นที่ไม่จำการแก้ไข
ตัวแก้ชื่อไม่ใช่โดเมนค้นหา
การแก้ชื่อยังต้องการให้ชื่อถูกทดลอง ชื่อที่ไม่ผ่านการรับรองอย่าง fileserver จะกลายเป็น fileserver.corp.example ก็ต่อเมื่อมีโดเมนค้นหาแนบกับอินเทอร์เฟซที่พาคำถามไป VPN ที่ดันเซิร์ฟเวอร์ DNS โดยไม่มีรายการค้นหาจะสร้างการแยกที่เฉพาะเจาะจงมาก: ชื่อที่ผ่านการรับรองเต็มรูปแบบแก้ได้ แต่ชื่อสั้นทุกตัวล้มเหลว.
ทดสอบทั้งสองรูปแบบก่อนแก้ไขโปรไฟล์ เพราะความล้มเหลวทั้งสองชี้ไปคนละทาง บนโฮสต์ systemd-resolved ลิงก์อุโมงค์มีเซิร์ฟเวอร์และโดเมนเส้นทางของตัวเอง ดังนั้นอ่านลิงก์ไม่ใช่ไฟล์ส่วนกลาง
resolvectl status
resolvectl query fileserver.corp.example
resolvectl dns
resolvectl domain
หากคำถามถูกกำหนดให้ลิงก์ที่ไม่พาอุโมงค์ โดเมนเส้นทางจะหายไปแม้ที่อยู่ DNS จะอยู่ก็ตาม นั่นคือปัญหาเชิงนโยบายในการกำหนดค่า resolved ไม่ใช่ปัญหาเส้นทางในอุโมงค์
คอนเทนเนอร์พาสำเนาคำตอบของตัวเอง
คอนเทนเนอร์ที่สร้างจาก image ทั่วไปมักมี resolv.conf แบบตายตัว การเปลี่ยนแปลงตัวแก้ชื่อบนโฮสต์ไปไม่ถึงมัน และโดเมนค้นหาก็เช่นกัน งาน build ที่เมานต์แชร์ผ่านอุโมงค์จึงล้มเหลว ขณะที่คำสั่งเดียวกันทำงานนอกคอนเทนเนอร์ ให้ DNS และการตั้งค่าค้นหาของคอนเทนเนอร์เองในไฟล์ compose หรืออาร์กิวเมนต์ run ไม่ใช่แค่ในโปรไฟล์โฮสต์
ตรวจสอบในคอนเทนเนอร์ก่อนโทษ image คำสั่งสองคำสั่งสร้างการวินิจฉัยทั้งหมดซ้ำได้ในไม่กี่วินาที และคำสั่งที่สองพิสูจน์ว่าตัวแก้ชื่อใดตอบจริง
จากนั้นจึงดูแชร์และตัวกรอง
เมื่อชื่อแก้ได้ ความล้มเหลวที่เหลือเป็นปัญหาเครือข่ายธรรมดา SMB ต้องใช้ TCP 445 ไปยังเซิร์ฟเวอร์ และการเรียกดูรายการเวิร์กกรุปขึ้นกับบริการชื่อที่อุโมงค์อาจไม่ส่งต่อ จับคู่ด้วยชื่อโฮสต์แทนการรอให้รายการเต็ม และให้ไคลเอนต์บอกว่าถึงขั้นไหน การเชื่อมต่อถูกปฏิเสธและ timeout ที่เงียบก็ควรแยกจากกัน เพราะอันแรกมักหมายถึงมีบางอย่างตอบ และอันหลังหมายถึงไม่มีอะไรตอบ
getent hosts fileserver.corp.example
nc -vz fileserver.corp.example 445
mount -t cifs //fileserver.corp.example/share /mnt/share \
-o vers=3.1.1,username=svc_mount,uid=1000
ที่อยู่ที่แก้ได้แต่พอร์ต 445 ถูกปฏิเสธหรือหมดเวลาเป็นปัญหาไฟร์วอลล์หรือ listener ที่ปลายทาง ชื่อที่แก้ไม่ได้คือปัญหาตัวแก้ชื่อ และเมานต์ที่ยืนยันตัวตนได้แต่คืนข้อผิดพลาดสิทธิ์ไม่ใช่ทั้งสองอย่าง ดังนั้นอย่าเปิดคำถามเครือข่ายอีกเมื่อเซสชันตั้งขึ้นแล้ว
เก็บข้อสรุปให้แคบเท่าหลักฐาน เมื่อที่อยู่ทำงานแต่ชื่อไม่ทำงาน อุโมงค์กำลังทำหน้าที่ของมัน และการแก้ไขอยู่ที่ลำดับตัวแก้ชื่อ โดเมนค้นหา หรือการกำหนดค่าของคอนเทนเนอร์เอง