ทำไม Samba จึงปฏิเสธไคลเอนต์ VPN ที่เข้าถึงเซิร์ฟเวอร์ได้

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

สี่ชั้นที่ล้มเหลวด้วยข้อความเดียวกัน

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

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

หาที่อยู่ต้นทางที่ smbd เห็นจริง

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

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

sudo tcpdump -ni any -c 20 'tcp port 445'
sudo smbstatus -b
ss -tnp | grep ':445'

อ่านทะเบียนที่อนุญาตอย่างที่ Samba อ่าน

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

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

hosts allow = 192.168.50.0/24 10.90.0.0/24
testparm -s
testparm -s /etc/samba/smb.conf client.example 10.90.0.14

แก้ไฟล์ที่อยู่รอดหลังรีบูต

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

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

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

ทดสอบไคลเอนต์ที่ได้รับอนุญาตหนึ่งตัวและที่ถูกกันออกหนึ่งตัว

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

smbclient -L //fileserver -U alice
sudo testparm -s /etc/samba/smb.conf alice-laptop 10.90.0.14
sudo tail -n 40 /var/log/samba/log.smbd

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