Docker: ไม่มีพูลแอดเดรสที่กำหนดไว้ล่วงหน้าเหลืออยู่ในระหว่างเซสชัน VPN

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

ยืนยันว่าอะไรล้มเหลวก่อนที่จะเปลี่ยนอะไร

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

บันทึกเวอร์ชัน Engine ในตั๋วในเวลาเดียวกัน ทุกฮิวริสติกในส่วนที่เหลือของคู่มือนี้ผูกกับเวอร์ชัน และข้อกล่าวอ้างที่ไม่มีเวอร์ชันคือข่าวลือ

นับการจัดสรรที่คุณมีอยู่แล้ว

แสดงรายการเครือข่าย แล้วตรวจสอบเครือข่ายที่สำคัญ: docker network ls ตามด้วย docker network inspect NETWORK_NAME อ่านเซิร์ฟเวอร์ย่อย IPAM และคอนเทนเนอร์ที่เชื่อมต่อกับแต่ละเครือข่าย โครงการ Compose หลายโครงการใช้บล็อกมากกว่าที่จำนวนคอนเทนเนอร์บ่งชี้ เพราะทุกโครงการมักสร้างเครือข่ายเริ่มต้นของตนเอง คอนเทนเนอร์ที่หยุดแล้วไม่ได้คืนการจัดสรรของเครือข่าย

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

จดจำนวนไว้ นั่นคือเส้นฐานที่บอกคุณว่าการเปลี่ยนแปลงครั้งต่อไปช่วยได้หรือไม่

เปรียบเทียบมุมมองของเดมอนต่อเส้นทาง

VPN อาจมีอิทธิพลต่อการเลือกผู้สมัคร แต่การใช้งานจริงเป็นตัวกำหนดว่าจะอย่างไร ใน Moby 28.2.2 บน Linux InferReservedNetworks รวบรวมแอดเดรสของเนมเซิร์ฟเวอร์และเส้นทาง IPv4 on-link บางเส้น และไม่ได้สงวนทุกเส้นทางจากทุกตารางไว้เฉย ๆ เส้นทางลิงก์ที่รวบรวมยังตัดแอดเดรสปลายทางที่ไม่ระบุออก ดังนั้นเส้นทาง 0.0.0.0/1 เพียงเส้นเดียวไม่ได้สงวนทุกแอดเดรส คำนำหน้า on-link แบบกว้างอื่น เช่น 128.0.0.0/1 อาจตัดกับช่วงผู้สมัครที่คุ้นเคย 172 และ 192

เปรียบเทียบ ip -4 route show table all ก่อนและหลังที่ VPN เชื่อมต่อ บนโฮสต์ของเดมอน ส่วนต่างคือหลักฐาน และเวอร์ชันคือขอบเขตของข้อกล่าวอ้าง

อย่าพูดทั่วไปถึงฮิวริสติกของรุ่นหนึ่งกับทุกรุ่น นั่นคือทางที่คำตอบในฟอรัมกลายเป็นการเปลี่ยนนโยบาย

เลือกการแก้ไขที่เล็กที่สุดที่ได้ผล

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

การเปลี่ยน default-address-pools คือนโยบายที่กว้างขึ้นเกี่ยวกับการจัดสรรในอนาคต เลือกฐานที่ไม่ขัดแย้งและขนาดที่จัดสรรเหมาะสม รวมเข้ากับการตั้งค่าเดมอนที่มีอยู่ และวางแผนผลกระทบการรีสตาร์ตที่บันทึกไว้ เครือข่ายที่มีอยู่จะไม่ถูกเปลี่ยนหมายเลขอย่างเงียบ ๆ

อย่าปิดใช้งานการพุชเส้นทางของบริษัทเพื่อให้การจัดสรรสำเร็จ แผนแอดเดรสที่ชัดเจนมักแก้อาการในเครื่องได้โดยไม่ทำให้นโยบายบังคับอ่อนแอลง

ยอมรับการจัดสรรและการกำหนดเส้นทางแยกจากกัน

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

เก็บส่วนต่างเส้นทางและจำนวนพูลไว้กับบันทึกการเปลี่ยนแปลง เพราะการอัปเดตไคลเอนต์ VPN ครั้งถัดไปอาจเปลี่ยนอย่างแรกได้โดยไม่แตะ Docker

คู่มือจะสมบูรณ์เมื่อคนอื่นสามารถทำการตรวจทั้งสองซ้ำและได้คำตอบเดียวกัน