ทำไมคำเตือนการล้างเส้นทางของ vpnc จึงปรากฏในคอนเทนเนอร์

บันทึกของคอนเทนเนอร์ใหม่มักจบลงด้วยข้อร้องเรียน Read-only file system เกี่ยวกับ /proc/sys/net/ipv4/route/flush และบรรทัดนั้นถูกโทษว่าเป็นความผิดของอุโมงค์ที่อาจสมบูรณ์ดี การเขียนที่อยู่เบื้องหลังมุ่งเป้าไปที่รายการเคอร์เนลซึ่งไม่ทำอะไรที่เป็นประโยชน์อีกแล้วเมื่อแคชเส้นทาง IPv4 หายไป ภายในคอนเทนเนอร์ /proc/sys ถูกเมานต์แบบอ่านอย่างเดียว การเปลี่ยนเส้นทางจึงถูกปฏิเสธก่อนที่ค่าจะเข้าไปถึง และเชลล์ก็พิมพ์การปฏิเสธนั้น อุโมงค์ที่ทำงานได้อาจพิมพ์คำเตือนนี้ได้ตราบใดที่บรรทัดเก่ายังอยู่ในสคริปต์ และ --privileged ไม่เคยทำให้การเขียนมีความหมาย

สคริปต์พยายามล้างอะไร

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

รายการนั้นเองยังคงอยู่เป็นไฟล์เก่าแบบเขียนอย่างเดียว สคริปต์ที่ยังเขียนลงไปจึงไปถึงเส้นทางจริงและการตรวจสอบสิทธิ์จริง บนโฮสต์การเขียนคืนค่าสำเร็จและไม่เปลี่ยนแปลงสิ่งใด ในคอนเทนเนอร์การเปลี่ยนเส้นทางเดียวกันนั้นชนกับ /proc/sys แบบอ่านอย่างเดียวและล้มเหลวด้วย EROFS ซึ่งเชลล์พิมพ์เป็นข้อความระบบไฟล์แบบอ่านอย่างเดียว บนเคอร์เนลที่เส้นทางหายไปจริง ถ้อยคำจะกลายเป็น No such file or directory และข้อสรุปไม่เปลี่ยน

ข้อผิดพลาดทั้งสองกล่าวถึงสิ่งต่างกัน และความต่างนั้นควรทำให้ชัดเจน Read-only file system หมายความว่าเคอร์เนลไปถึงรายการและปฏิเสธการเขียน No such file or directory หมายความว่ารายการหายไป ไม่มีข้อความใดรายงานเกี่ยวกับอุปกรณ์อุโมงค์ เส้นทาง หรือการแปลงชื่อ ดังนั้นจึงไม่มีข้อความใดพิสูจน์สิทธิ์ที่มากขึ้นได้

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

ตรวจสอบการเมานต์และเส้นทางก่อนเพิ่มสิทธิ์

การอ่านสามอย่างแยกคำเตือนด้านภาพออกจากความล้มเหลวจริง: สคริปต์ที่ติดตั้งยังมีบรรทัดนั้นหรือไม่ /proc/sys ถูกเมานต์อย่างไร และ ทราฟฟิกของแอปพลิเคชันไปที่ใดจริง ๆ เรียกใช้ในเนมสเปซคอนเทนเนอร์เดียวกันหรือบนโฮสต์ที่คำเตือนปรากฏ เพราะการตรวจสอบบนเครื่องที่ไม่เกี่ยวข้องตอบคำถามอื่น

grep -n 'ipv4/route/flush' /usr/share/vpnc-scripts/vpnc-script
findmnt -no OPTIONS /proc/sys
ip -4 route get 10.20.5.10

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

การแก้ไขมาจากไหนจริง ๆ

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

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