เราเตอร์ในฐานะไคลเอนต์ SMB หรือตัวส่งต่อแพ็กเก็ต: แบบใดเหมาะสม
การส่งต่อทราฟฟิก SMB กับการเมานต์เป็นสองบทบาทที่แยกกัน ตรวจสอบข้อมูลรับรอง การรองรับเคอร์เนล และการจัดการความล้มเหลวก่อนที่เราเตอร์จะเป็นไคลเอนต์
การส่งต่อทราฟฟิก SMB ไม่ใช่งานเดียวกับการสิ้นสุดทราฟฟิกนั้น และเราเตอร์ที่ทำอย่างหนึ่งอาจดูแลอีกอย่างไม่ได้ การส่งต่อหมายถึงเราเตอร์เคลื่อนย้ายแพ็กเก็ตที่มันไม่เคยวิเคราะห์เนื้อหา การเมานต์หมายถึงเราเตอร์กลายเป็นไคลเอนต์ไฟล์ พร้อมซอฟต์แวร์ที่อาจไม่ได้มาด้วย ข้อมูลรับรองที่ต้องปกป้อง และรูปแบบความล้มเหลวที่เป็นของมันแล้ว การเลือกระหว่างสองอย่างคือคำถามว่าไฟล์ต้องการที่ใด ไม่ใช่คำถามว่าจะโน้มน้าวแพลตฟอร์มกำหนดเส้นทางให้ติดตั้งอะไรได้
การส่งต่อและการสิ้นสุดเป็นงานที่ต่างกัน
ในบทบาทส่งต่อ เราเตอร์มีความรับผิดชอบเดียว คือส่งแพ็กเก็ตระหว่างไคลเอนต์กับเซิร์ฟเวอร์พร้อมบังคับใช้นโยบายที่เส้นทางต้องการ มันไม่พิสูจน์ตัวตนกับแชร์ ไม่แคชข้อมูลไฟล์ และไม่สนใจว่าเซิร์ฟเวอร์พูด SMB2 หรือ SMB3 เพราะไม่เคยอ่านลึกขนาดนั้นในสตรีม ถ้าแชร์เข้าถึงไม่ได้ ผู้ใช้เห็นข้อผิดพลาดและเราเตอร์ยังคงกำหนดเส้นทางต่อไป
ในบทบาทไคลเอนต์ เราเตอร์เข้าร่วมบทสนทนาของโปรโตคอล มันเจรจาไดอะเล็กต์ พิสูจน์ตัวตน แปลงชื่อ ถือจุดเมานต์ และนำเสนอมุมมองระบบไฟล์ภายในให้ทุกสิ่งที่ทำงานอยู่เหนือมัน นี่คือบริการจริงที่มีวงจรชีวิต และมันทำให้เกตเวย์กลายเป็นส่วนพึ่งพิงของเวิร์กโฟลว์ไฟล์ มันยังสืบทอดรูปแบบความล้มเหลวทั้งหมดของส่วนพึ่งพิงนั้น รวมถึงการรอตอนบูตและข้อมูลรับรองที่หมดอายุ
การเปรียบเทียบไม่ได้อยู่ที่ความสามารถเพียงอย่างเดียว แพลตฟอร์มที่เมานต์แชร์ได้ไม่ได้หมายความว่าควรทำโดยอัตโนมัติ และแพลตฟอร์มที่เมานต์ไม่ได้เลยอาจยังเป็นที่ที่เหมาะสมในการกำหนดเส้นทางทราฟฟิก
การเมานต์ CIFS ในเคอร์เนลต้องใช้อะไรจริง ๆ
บนอุปกรณ์ที่ใช้ Linux ไคลเอนต์ CIFS ในเคอร์เนลกับไคลเอนต์ในพื้นที่ผู้ใช้เป็นความสามารถแยกกัน และอิมเมจเล็ก ๆ มักไม่มีทั้งสองอย่าง ต้องมีการรองรับเคอร์เนลในอิมเมจที่รันอยู่ ต้องมีตัวช่วยเมานต์ และไดอะเล็กต์ SMB ที่เจรจากับเซิร์ฟเวอร์ต้องเป็นแบบที่ทั้งสองฝ่ายยอมรับ เรื่องนี้ คู่มือไคลเอนต์ CIFS ของ Linux อธิบายไว้ คือโครงสร้างเคอร์เนลและตัวเลือกการเมานต์ และเป็นแหล่งอ้างอิงที่ถูกต้องก่อนสันนิษฐานว่าบิลด์ของผู้ขายมีมันอยู่
ตรวจสอบความสามารถก่อนออกแบบรอบ ๆ มัน และตรวจสอบเวอร์ชันไม่ใช่การมีอยู่ของชื่อคำสั่ง ชื่อโมดูลในรายการแพ็กเกจไม่เหมือนกับไคลเอนต์ที่ทำงานได้
lsmod | grep -w cifs
modinfo cifs | head -5
mount.cifs --version
smbclient -L //fs02.corp.internal -U svc-router -m SMB3โมดูลเคอร์เนลที่โหลดได้และเครื่องมือในพื้นที่ผู้ใช้ที่รายงานเวอร์ชันยังไม่รับประกันว่าการเมานต์จะอยู่รอดจากการเปลี่ยนคีย์ VPN ดังนั้นให้ถือว่าการตรวจสอบเป็นเงื่อนไขเริ่มต้น ไม่ใช่ข้อพิสูจน์ ถ้าอิมเมจให้การรองรับ SMB1 เท่านั้น นั่นคือเหตุผลให้หยุด ไม่ใช่เหตุผลให้เปิดใช้บนเซิร์ฟเวอร์
ข้อมูลรับรองและตัวตนต้นทางแตกต่างจากของแล็ปท็อป
คำขอที่ส่งต่อพาตัวตนของแล็ปท็อปผ่านอุโมงค์ ขณะที่คำขอที่สร้างบนเราเตอร์พาแอดเดรสต้นทางของตัวเอง เส้นทางตัวแปลงชื่อ และการกรองขาออก สิ่งเหล่านี้อาจไปตกในกฎไฟร์วอลล์อื่น มุมมอง DNS อื่น และรายการอนุญาตอีกชุดทางฝั่งเซิร์ฟเวอร์ ดังนั้นสำเนาที่ทำงานจากสถานีงานจึงไม่ได้พิสูจน์อะไรเกี่ยวกับการเมานต์ของเราเตอร์เอง ทดสอบการเมานต์จากเชลล์ของเราเตอร์เอง ไม่ใช่จากสถานีงานที่อยู่ข้างหลัง
ให้ตัวตนบริการที่มีสิทธิ์แคบแก่เราเตอร์หากบทบาทนั้นได้รับการอนุมัติ อย่าวางรหัสผ่านโดยตรงในบรรทัดคำสั่งเมานต์ เพราะมันค้างอยู่ในประวัติเชลล์และปรากฏในตารางโปรเซสขณะเมานต์ทำงาน
เก็บข้อมูลรับรองผ่านกลไกป้องกันของแพลตฟอร์มและอ่านจากไฟล์ที่มีสิทธิ์จำกัด ไฟล์นั้นควรอ่านไม่ได้สำหรับทุกบัญชี ยกเว้นบัญชีที่รันการเมานต์
install -m 600 /dev/null /etc/cifs-reports.creds
printf 'username=svc-router\npassword=REPLACE_ME\ndomain=CORP\n' > /etc/cifs-reports.creds
mount -t cifs //fs02.corp.internal/reports /mnt/reports -o credentials=/etc/cifs-reports.creds,vers=3.1.1,roความล้มเหลวเป็นของใครเมื่อแชร์หายไป
ระบบไฟล์ระยะไกลที่หายไปมีพฤติกรรมต่างจากเส้นทางที่หายไป การเมานต์อาจบล็อกโปรเซสที่แตะมัน อาจล้มเหลวตอนบูตก่อนที่อุโมงค์จะมีอยู่ และการเขียนที่ตั้งใจไว้สำหรับเซิร์ฟเวอร์อาจไปตกผิดที่หากมีไดเรกทอรีภายในอยู่ใต้จุดเมานต์ นี่คือความล้มเหลวด้านที่เก็บข้อมูลที่ทีมเครือข่ายเป็นเจ้าของแล้ว ไม่ว่าทีมจะต้องการหรือไม่ ไม่มีใครตกลงกับความเป็นเจ้าของนั้น แต่มันมาพร้อมกับการเมานต์
ออกแบบลำดับการบูตและตัวเลือกการเมานต์โดยรอบความเป็นจริงนั้น การเมานต์แบบอ่านอย่างเดียวที่มีเวลาจำกัดสั้นและมีขั้นตอนกู้คืนที่เขียนไว้ ปกป้องได้ง่ายกว่าการเมานต์แบบเขียนที่ทุกอย่างอื่นต้องพึ่งพา ยืนยันว่าอุโมงค์ขึ้นก่อนที่สิ่งใดจะพยายามเมานต์ ไม่อย่างนั้นการบูตครั้งแรกหลังไฟดับจะค้าง
สำหรับการประมวลผลไฟล์ขนาดใหญ่ หรือสิ่งใดก็ตามที่ส่งออกข้อมูลต่อไปอีกทอดหนึ่ง โฮสต์แยกมักให้ขอบเขตความเป็นเจ้าของที่ชัดเจนกว่า เราเตอร์ยังคงกำหนดเส้นทาง และเวิร์กโฟลว์ไฟล์ได้เครื่องที่รีบูตได้โดยไม่ต้องพาเครือข่ายไปด้วย
ตรวจสอบการตัดสินใจกับงานจริง
เขียนว่างานใดต้องใช้ไฟล์และงานนั้นรันที่ไหน ถ้าคำตอบคือสถานีงาน กำหนดเส้นทางแชร์แล้วหยุดตรงนั้น. ถ้าคำตอบคือบริการบนอุปกรณ์ ให้ยืนยันความสามารถของไคลเอนต์ ไดอะเล็กต์ที่รองรับ และเส้นทางข้อมูลรับรองก่อนการเมานต์ครั้งแรก แล้วตัดสินว่าอุปกรณ์นั้นเป็นโฮสต์ที่ถูกต้องจริงหรือไม่
ตรวจสอบมุมมองที่เมานต์และพื้นที่ว่างจากตัวเราเตอร์เอง เพราะนั่นคือที่ที่ภาระงานจะเห็น ทำการตรวจสอบซ้ำหลังเชื่อมต่อใหม่ ไม่ใช่แค่หลังบูตสะอาด
findmnt -t cifs -o TARGET,SOURCE,OPTIONS
df -h /mnt/reports
ls -l /mnt/reports | headการเมานต์ที่แสดงรายการไฟล์แต่รายงานว่าระบบไฟล์เต็มหรืออ่านอย่างเดียวได้บอกคุณแล้วว่าคุณจะเจอความล้มเหลวแบบใดตอนตี 2 ยืนยันเส้นทางกู้คืนด้วย: ถอดเมานต์อย่างสะอาด ลดอุโมงค์ลง นำกลับขึ้นมาและเมานต์อีกครั้งโดยไม่ต้องรีบูตอุปกรณ์ ถ้าลำดับนั้นต้องเปิดเคสสนับสนุนทุกครั้ง เราเตอร์ก็เป็นที่ผิดสำหรับบทบาทไคลเอนต์