Samba สูญเสียแชร์ภายในเครื่องทันทีที่ OpenVPN เชื่อมต่อ และอุโมงค์แทบไม่เคยเป็นสาเหตุ การเมานต์ปกติ NAS ทำงานอยู่ และรีโซลเวอร์ที่อุโมงค์ติดตั้งไว้กำลังตอบคำถามเกี่ยวกับชื่อที่มันไม่เคยเห็น Samba ถามรีโซลเวอร์นั้นแต่เนิ่นๆ ในลำดับการค้นหาของมัน เชื่อคำตอบ และเชื่อมต่อไปยังที่อยู่ที่ไม่มีอะไรฟังอยู่ การแก้แชร์หมายถึงการแก้คำตอบ ไม่ใช่การแก้การเมานต์

การตรวจสอบห้าข้อ ตามลำดับที่กำจัดความเป็นไปได้ได้มากที่สุดในแต่ละขั้น

ใครตอบชื่อสั้น

ถามระบบปฏิบัติการ ไม่ใช่ตัวจัดการไฟล์ resolvectl status พิมพ์เซิร์ฟเวอร์ DNS ที่ผูกกับแต่ละลิงก์และทำเครื่องหมายว่าลิงก์ใดเป็นเส้นทางเริ่มต้น และการสอบถามชื่อสั้นจะรายงานเซิร์ฟเวอร์ที่ตอบ รันหนึ่งครั้งสำหรับชื่อ NAS และอีกครั้งสำหรับชื่อที่คุณรู้ว่ามีอยู่ในโดเมนของสำนักงาน หากคำตอบทั้งสองมาจากเซิร์ฟเวอร์ต่างกัน คุณพบการแยกแล้ว

ตรวจสอบว่าคำตอบเป็นคำตอบเชิงลบหรือที่อยู่ คำตอบเชิงลบหมายความว่า Samba ควรไปยังกลไกอื่น และความล้มเหลวอยู่ที่อื่น ที่อยู่หมายความว่า Samba เชื่อมต่อกับสถานที่จริงและไม่ได้รับอะไรกลับมา

ทำไม Samba จึงเชื่อคำตอบที่ผิด

Samba แปลชื่อผ่านลำดับตายตัวที่กำหนดโดย name resolve order ในดิสทริบิวชันส่วนใหญ่ค่าเริ่มต้นรวม host ซึ่งหมายถึง DNS และทำงานก่อนกลไกสำหรับ LAN เท่านั้น เช่น การออกอากาศ NetBIOS อุโมงค์ที่ดันรีโซลเวอร์จึงได้สิทธิ์ปฏิเสธครั้งแรกในทุกชื่อแชร์ รวมถึงชื่อป้ายเดียวที่ไม่ควรออกจากอาคารเลย

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

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

การซ่อมสองแบบที่มีขอบเขตต่างกัน

การซ่อมแบบแคบยังคงรีโซลเวอร์ที่ถูกดันไว้และเปลี่ยนสิ่งที่ Samba ได้รับอนุญาตให้ถาม เพิ่มสองบรรทัดในคอนฟิก Samba ที่เดมอนอ่านจริง แล้วรีสตาร์ตบริการ:

[global]
   name resolve order = wins lmhosts bcast
   dns proxy = no

หากไม่มี host ในรายการนั้น DNS จะออกจากเส้นทางการค้นหาแชร์ และชื่อป้ายเดียวจะอยู่บนเซ็กเมนต์ภายในเครื่อง ชื่อของสำนักงานยังคงแปลได้ตามปกติสำหรับโปรแกรมอื่นทุกตัว เพราะสิ่งนี้เปลี่ยนเฉพาะ Samba ราคาที่ต้องจ่ายคือ Samba ไม่สามารถใช้ DNS ได้เลยอีกต่อไป แชร์ที่ระบุด้วยชื่อสำนักงานแบบเต็มจึงกลายเป็นปัญหา

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

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

ซัฟฟิกซ์สามารถอธิบายได้ทุกอย่าง

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

วิธีแก้ที่นี่คือใช้ชื่อภายในเครื่องแบบเต็ม หรือเพิ่มกฎ DNS แยกส่วนที่เป็นเจ้าของซัฟฟิกซ์ภายในเครื่อง ทั้งสองไม่ต้องแตะ Samba

พิสูจน์หลังเชื่อมต่อใหม่

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

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

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

บทความที่เกี่ยวข้อง