Samba บนที่อยู่ VPN: ทำไมตัวรับฟังจึงหายไป

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

แชร์ใช้งานได้จนกระทั่งอุโมงค์เริ่มใหม่

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

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

การเข้าถึงไม่ใช่ที่อยู่สำหรับผูก

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

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

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

ให้ผูกกับที่อยู่ที่มั่นคงแทน

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

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

ss -ltnp | grep ':445'

ทดสอบการเชื่อมต่อใหม่ ไม่ใช่ไฟเขียว

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

smbclient -L //files.corp.example -U alice

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