Firefox ที่เปิดใน namespace ส่ง URL ต่อให้อินสแตนซ์ที่มีอยู่แล้ว

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

สัญญาณคือหน้าต่างปรากฏขึ้นทันทีโดยไม่มีการเริ่มแบบเย็น

หน้าต่างใหม่ไม่ใช่อินสแตนซ์ใหม่

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

การท่องเว็บส่วนตัวและตัวเลือกหน้าต่างใหม่ไม่ใช่การควบคุมการแยกเครือข่าย

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

บังคับอินสแตนซ์แยกบนโปรไฟล์แยก

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

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

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

ตรวจสอบว่าโปรเซสใดแบกทราฟฟิก

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

readlink /proc/ACTUAL_PID/ns/net

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

เมื่อ namespace ผิดจริง

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

การแชร์หน้าจอไม่ได้แชร์ resolver เช่นกัน

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