ip netns exec กับ DNS: ทำไมชื่อจึงล้มเหลวภายในเนมสเปซ

คำสั่งหนึ่งเข้าถึง 10.8.0.5 ภายในเนมสเปซ VPN ได้โดยไม่มีข้อผิดพลาด และคำสั่งเดียวกันก็ล้มเหลวทันทีที่ใช้ชื่อโฮสต์ เนมสเปซมีอินเทอร์เฟซ เส้นทาง และซ็อกเก็ตของตัวเอง แต่ไม่มีไฟล์ตัวแก้ไขชื่อของตัวเอง หากไม่มีอะไรวางไฟล์ไว้ที่นั่น กระบวนการข้างในจะอ่าน /etc/resolv.conf ของโฮสต์และถามเซิร์ฟเวอร์ที่อาจเข้าถึงไม่ได้จากสแตกเครือข่ายนั้น

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

ตรวจสอบมุมมองของตัวแก้ไขชื่อที่กระบวนการได้รับจริง

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

สำหรับเนมสเปซที่สร้างด้วย ip netns add การตรวจสอบแบบอ่านอย่างเดียวก็สั้น:

ip netns exec vpn cat /etc/resolv.conf

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

ตัวช่วย exec เมานต์อะไรจริง ๆ

เครื่องมือ ip-netns จัดทำเอกสารการกำหนดค่าต่อเนมสเปซไว้ใต้ /etc/netns/NAME/ เมื่อเริ่มกระบวนการ ตัวช่วยจะสร้างเนมสเปซการเมานต์และเมานต์ไฟล์เหล่านั้นทับเส้นทางปกติ เพื่อให้กระบวนการเห็นสำเนาที่เฉพาะเจาะจงกับเนมสเปซ นี่คือความสะดวกของตัวเริ่มทำงานนี้โดยเฉพาะ การเข้าเนมสเปซเครือข่ายด้วยเส้นทางอื่น เช่น unshare หรือรันไทม์ของคอนเทนเนอร์ ไม่ได้จำลองสิ่งนี้โดยอัตโนมัติ

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

เลือกตัวแก้ไขชื่อที่เนมสเปซเข้าถึงได้

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

แอปพลิเคชันที่มีตัวแก้ไขชื่อของตัวเอง เช่นตัวที่ใช้ DNS over HTTPS อาจเพิกเฉยต่อไฟล์นี้ทั้งหมด หากเครื่องมือมีการตั้งค่า DNS ของตัวเอง การเปลี่ยน resolv.conf จะไม่มีผลกับมัน และเนมสเปซก็ไม่เคยเป็นปัญหา

เขียนไฟล์ในตำแหน่งที่ถูกต้อง

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

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

ทดสอบเส้นทางทั้งหมดอีกครั้ง

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

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